Reflections on Ethereum Governance: Why Are People Dissatisfied with the EIP-3074 Incident?

Author: imToken

 

This article outlines my thoughts on the recent EIP-3047 incident, with thanks to Vitalik and Yoav for reviewing the content.

If you are not familiar with this event, here is a brief recap:

Recently, the EIP-3074 proposal received the green light from core developers and is planned to be implemented in the next Ethereum hard fork, Pectra. The purpose of this proposal is to allow regular Ethereum account (EOA) users to enjoy the many benefits of Account Abstraction (AA).

However, the ERC-4337 community, especially the drafters of the proposal, strongly opposed EIP-3074, mainly arguing that EIP-3047 could exacerbate centralization risks and is inconsistent with the Ethereum account abstraction roadmap, which centers on EIP-4337 and its close relative EIP-7560 (also known as native abstract accounts).

Last week, Vitalik proposed EIP-7702 as an alternative to EIP-3074. It also aims to bring the benefits of account abstraction to EOA users but is designed to better align with the current EIP-4337 standard and smoothly transition to the final form—EIP-7560.

Translator's note: ERC-4337 and ERC-7560 are proposals in the Ethereum ecosystem related to account abstraction, aiming to improve user account management and interaction methods, enhancing user experience and security.

ERC-4337 allows users to manage their accounts through a Proxy Contract, reducing complexity and risk during user DApp interactions. ERC-7560 aims to integrate the concepts from proposals like ERC-4337 directly into Ethereum's base layer, enabling all accounts to inherently possess account abstraction capabilities, thus providing deeper integration and optimization.

ERC-4337 is an important step towards transitioning to ERC-7560, and together they form the core of the Ethereum account abstraction roadmap.

Currently, the core developer team is discussing EIP-7702, and some early signs and community feedback suggest that EIP-7702 is likely to replace EIP-3074 in the Pectra hard fork.

I am personally very pleased with this outcome: EOA users will soon enjoy most of the benefits of account abstraction through the tools and infrastructure built for ERC-4337.

However, the process of achieving this goal leaves me uneasy, feeling far from the optimal path, which is a sentiment shared by many recently. I firmly believe that with a more refined process, we could have reduced the turmoil and reached a consensus more quickly.

In this article, I intend to:

• Analyze the issues in the process
• Propose a framework for understanding Ethereum governance
• Discuss how to improve and avoid repeating this debacle in the future

Why is everyone dissatisfied? 

The entire incident has left many people dissatisfied for several reasons:

• The long approval process: EIP-3074 took years to finally get the green light.
• Delayed feedback: Core developers only widely heard the opposition from the ERC-4337 community after 3074 was approved.
• Unheeded warnings: The authors of the 4337 proposal repeatedly raised concerns about 3074 to core developers, but to little effect.
• Changing course: Now, we face the situation of revoking EIP-3074 and replacing it with EIP-7702.

 Objectively speaking, each of the above steps alone is not problematic: 

• Long discussions are reasonable.
• Encountering opposition after approval is also normal.
• If new issues arise, adjusting or even canceling the original decision is also logical.

 However, we might all agree that this process could have been smoother. Imagine if things had developed like this:

 During the core developers' discussion of EIP-3074, the ERC-4337 community actively participated. In this way, there are only two possible outcomes:

• Either EIP-3074 is approved after considering the feedback from the ERC-4337 community (possibly with some modifications), in which case the ERC-4337 community would support EIP-3074, and there would be no need to overturn the 3074 decision.
• Or, EIP-3074 is never approved, but the ERC-4337 community collaborates with core developers to jointly promote a proposal that everyone is satisfied with, like EIP-7702.

Everyone's voice is heard, and there are no dramatic reversals. This should have been an ideal outcome—but why didn't it happen?

Where is the problem?

Looking back at the entire process, both sides have some blame.

Core developers (including the authors of EIP-3074) feel that if the EIP-4337 team had been more actively involved in the Ethereum All Core Devs (ACD) process, the issue would not have occurred.

In this process, proposals need long discussions and are ultimately accepted and integrated into the protocol by client teams. They believe that the EIP-4337 team could have intervened at any time to raise their concerns, rather than waiting until EIP-3074 was approved. After all, the ACD process is open and transparent, meetings are open to the public, and people like Tim Beiko summarize each meeting on Twitter. If the EIP-4337 team was really so concerned, why didn't they invest the time to participate?

Conversely, the account abstraction team (i.e., the authors of EIP-4337) emphasizes that they did participate in the ACD meetings and seized every opportunity to oppose EIP-3074, but their concerns were not adopted by core developers. Many members of the ERC-4337 community were surprised, thinking that EIP-3074 had been abandoned, and were unaware that EIP-3074 was still under consideration.

Additionally, some opinions point out that the ACD process is too complex, making it difficult for those with full-time jobs who cannot keep up with every step to participate. Others believe that actively seeking the opinions of key stakeholders (such as the ERC-4337 community) should be the responsibility of the ACD.

In my view, neither side fully grasps the core of the issue. There is a deeper problem at play, and unless we address it, or at least acknowledge it, we will repeatedly encounter governance failures and fall into meaningless mutual accusations.

The Crux of the Matter

The real crux of governance failure lies in the widespread misunderstanding of the ACD. The ACD is not actually the sole decision-making power for protocol updates; in this case, another form of governance power actually overrode the ACD's decision-making power.

The problem is that this crucial governance power, while having a significant impact on major Ethereum issues like account abstraction and scalability, is rarely formally recognized. 

I refer to this power as the "roadmap." 

In short, the entire shift from 3074 to 7702 is a typical case of the "roadmap" power overriding the ACD's decision-making power. 

From a governance perspective, when an invisible power overrides a visible power, we should be alert because invisibility means lack of oversight, and thus this invisible power must be exposed and scrutinized.

What is the Roadmap?

In the Ethereum community, the term "roadmap" is likely familiar, such as the Rollup-centric roadmap, the ETH 2.0 roadmap, or the account abstraction roadmap discussed this time. 

Imagine a scenario in an ACD meeting where core developers are discussing how to scale the network: 

Core developer Bob proposes: I support EIP-1234, which advocates speeding up block time by 10x, increasing block capacity by 10x, and reducing transaction fees by 100x.

Other developers respond: Are you serious? 

Think about it, why would Bob's proposal be quickly dismissed? He indeed proposed an effective scaling solution, as other blockchains like Solana operate this way with significant results. 

The reason is that Bob's proposal contradicts the Rollup-centric scaling roadmap that Ethereum adheres to. This roadmap emphasizes that maintaining the decentralization characteristic of the blockchain is crucial, and ordinary users being able to easily run nodes is essential. Therefore, Bob's proposal, which significantly increases the difficulty of running nodes, is naturally excluded as it does not align with the roadmap. 

Through this example, I want to show that the core developers participating in the ACD meetings and responsible for protocol updates actually follow a higher guiding principle, which I call the roadmap. There are various roadmaps, such as the scalability roadmap, the account

Abstract roadmaps, MEV roadmaps, etc., together form the overall roadmap of Ethereum, serving as the basis for core developers' decision-making.

When Core Developers Disagree with the Roadmap

Since the roadmap is not part of formal governance, core developers may not always align with it. Particularly, without an official process for "approving the roadmap," not all roadmaps enjoy the same level of recognition. This requires the planners behind the roadmap to actively promote it to core developers and the broader community to gain acceptance and, consequently, the support of core developers. 

Take account abstraction as an example. Vitalik has repeatedly advocated for a roadmap centered around EIP-4337, but in reality, it is mainly the EIP-4337 team, especially Yoav and Dror, who actively promote this roadmap in meetings, online forums, and Ethereum core developer conferences. 

However, even so, some core developers still oppose the roadmap centered around EIP-4337, arguing that EIP-7560 (the native version of EIP-4337, which future clients need to implement) is too complex and not the only way to achieve the final form of account abstraction. Ultimately, despite the EIP-4337 team's opposition to EIP-3074 for introducing another relatively centralized account abstraction tech stack that could split the abstract account ecosystem, the Ethereum core developer conference still approved EIP-3074. 

But after EIP-3074 was approved, the strong opposition from the entire EIP-4337 community prompted core developers to re-examine EIP-3074. The stalemate continued until Vitalik proposed EIP-7702 as an alternative to EIP-3074 at a critical moment, explicitly supporting the account abstraction scheme centered around EIP-4337, which pushed the situation towards following the account abstraction roadmap.

Vitalik's Role

Although Vitalik sees himself as a researcher, this incident shows that he plays a unique and distinctive role in Ethereum's governance. This raises a question: What exactly is Vitalik's role in Ethereum's governance? 

We can think of Vitalik as the CTO of a large company. 

If you have worked in a tech company of a certain size, say over 50 people, you will understand that the CTO cannot be involved in every technical decision. As the company grows, technical decisions naturally become decentralized, with sub-teams in various product areas generally able to decide on their specific implementation details. 

Moreover, the CTO is not necessarily the top expert in all fields. There may be engineers in the company who are better than the CTO in certain aspects. So, in technical debates, it is often the engineers who make the final decisions. 

However, the CTO is responsible for setting the company's technical vision, while the developers handle the specific execution. 

Although this analogy is not perfect, it quite accurately depicts Vitalik's role in the Ethereum ecosystem. 

Vitalik does not get involved in every technical decision—he cannot, and he is not the top expert in all fields. But he has a significant influence on the roadmap for all key aspects of Ethereum (such as scaling, account abstraction, proof of stake, etc.), not just because of his technical knowledge but because he can ultimately judge whether a roadmap aligns with Ethereum's vision—his own vision.

The Driving Force Behind Every Successful Product is Vision

As an entrepreneur, I believe that behind every successful product is a clear vision. Such a vision often needs to be established by a few people, usually the founding team, and often just one key founder. 

The charm of Ethereum lies in the fact that such a complex and multi-faceted system can operate in coordination, becoming a decentralized computer that handles enormous value transactions daily. This is not achieved through committee-style decision-making but thanks to Vitalik's vision leading the way, giving us the coordinated and efficient Ethereum we have today. From the concept in 2015 to today, Ethereum has always been a manifestation of Vitalik's wisdom. 

This does not diminish the contributions of other researchers and engineers, who have made significant contributions to Ethereum's development. But it is undeniable that Ethereum is the ultimate manifestation of Vitalik's vision, far surpassing the influence of any other individual. 

Honestly ask yourself, when you joined Ethereum because of its openness, censorship resistance, and innovative vitality, did you ever care that all of this originated from Vitalik's initial vision? 

Perhaps you didn't think about it before, but now that you understand, do you really mind? 

Ethereum was born from a clear vision and continues to grow in the process of realizing this vision, which is its charm.

What About Decentralization?

You might ask, if one person has such a significant influence on Ethereum, how can we say it is decentralized? 

To answer this question, we can refer to a classic article written by Vitalik, which explains the multiple meanings of decentralization. The key points of the article are that decentralization includes three aspects: 

Architectural decentralization: How many nodes need to fail before the system stops working?

Logical decentralization: Can the system's components evolve independently without affecting the overall functionality?

Political decentralization: How many people or entities control the system? 

Ethereum is undoubtedly decentralized in terms of architecture and logic because it can be distributed among many nodes, and different components (such as the consensus mechanism and execution layer) can develop relatively independently. 

As for political decentralization, the good news is that no single entity can shut down Ethereum, including Vitalik. But it is undeniable that Vitalik's significant role in setting Ethereum's vision and roadmap means there may be compromises in political decentralization. 

My view is that to keep Ethereum continuously innovating, we should accept Vitalik as the de facto CTO role, even if this somewhat reduces political decentralization. Until Ethereum matures to a stable and unchanging state like Bitcoin, there needs to be a widely respected authority figure who makes decisions based not only on technical merits but also ensures these decisions align with Ethereum's long-term vision. 

Without a role like Vitalik, Ethereum might face two scenarios, as vividly illustrated by the EIP-3074 incident: 

• Decision deadlock: Parties unwilling to compromise, causing project stagnation, just like the EIP-3074 debate that was only resolved when Vitalik intervened.
• Design chaos: The system could become an uncoordinated patchwork, as nearly happened with the parallel and incompatible EIP-3074 and EIP-4337.

Therefore, during Ethereum's rapid evolution phase, Vitalik's leadership is crucial for maintaining a decentralized yet directionally coherent ecosystem.

The Importance of the Community

At this point, we have almost built a comprehensive understanding framework of Ethereum governance, but there is still a key part not mentioned—the role of the community.

If Vitalik sets the vision, researchers plan the roadmap based on it, and core developers implement it, then what role does the community play? Surely it is not insignificant, right? 

In fact, the community plays the most central role. Because before the vision takes shape, there is a more fundamental thing—values. We gather as a community because we share certain values, which are the foundation of Vitalik's vision and must match it, or the community will cease to exist.

Perhaps due to the influence of our growth background or the inspiration of past experiences, each person in the Ethereum community has, at some point, realized the value of building a universally accessible, censorship-resistant, truly decentralized computer for the world. Our daily work on Ethereum is a practice and affirmation of these values, and through these actions, we give life and legitimacy to the vision, roadmap, and code proposed by Vitalik, researchers, and core developers.

Ethereum Governance Simplified Model: VVRC Framework

Imagine Ethereum governance as a meticulously designed machine, simplified into four key parts: Values, Vision, Roadmaps, and Clients, abbreviated as the VVRC model.

• Values: Everything starts with a set of fundamental principles and beliefs shared by the Ethereum community.
• Vision: As the founder, Vitalik, based on the community's values, outlines the vision for Ethereum's future development.
• Roadmaps: With a clear vision, research teams will start formulating specific steps to achieve these dreams. They design the technical paths to reach the goals step by step.
• Clients: Finally, core developer teams write code and maintain client software based on the roadmap, ensuring all technical plans can become reality, allowing users and developers to actually use them.

This process sounds smooth, but in reality, it is more complex. For example, core developers actually hold the final decision-making power because they are responsible for the actual software implementation. Vitalik and other researchers provide suggestions, and sometimes their proposals may not be adopted, as shown by the EIP-3074 incident.

Overall, the VVRC model helps us understand how Ethereum governance advances in an ideal situation, while also reminding us to continuously adjust and improve this process to avoid issues like the EIP-3074 incident from happening again.

How to Improve Ethereum Governance

To optimize Ethereum's governance structure and ensure we avoid repeating the mistakes of EI

In light of the EIP-3074/EIP-7702 incident, here are some suggestions for improvement:

Enhance EIP Transparency: Ensure that EIPs under consideration are more open and transparent to the community to avoid surprises like the sudden acceptance of EIP-3074. In reality, the status of EIPs marked on the EIPs website does not synchronize with the review progress of the Ethereum Core Developers Conference. Therefore, even if core developers have agreed to EIP-3074, its status still shows as "under review." It is recommended to notify the community in advance of upcoming EIPs through the Ethereum Foundation's social media platforms.

Increase Community Participation: Set specific time slots for community members to discuss the impact of EIPs on downstream projects during the Ethereum Core Developers Conference. This can prevent unexpected impacts like those EIP-3074 had on the EIP-4337 community. Additionally, if researchers find that their feedback is not being taken seriously by core developers, as experienced by the EIP-4337 team, they can invite community members to join the discussion to strengthen their position.

Mutual Understanding and Continuous Communication: Core developers and researchers must understand each other as they are both key forces in governance, albeit with different focuses. Core developers have "execution power" through client implementation, akin to having "voting power." Researchers, by actively sharing and discussing their roadmaps, gain broader community support, forming "roadmap influence."

When disagreements arise, core developers may tend to directly overturn researchers' ideas, as they did with the EIP-4337 team. However, this approach can lead to backlash, as the power balance is disrupted during conflicts, exemplified by the chaos following the approval of EIP-3074.

Conversely, when researchers face resistance, they may choose to stop collaborating with core developers. This is one reason for the emergence of the RIP (Rollup Improvement Proposal) process and why native account abstraction (EIP-7560) is mainly advanced as RIP rather than EIP.

While RIPs help L2 experiment with protocol updates that are difficult to adopt directly by L1, they cannot replace participation in the EIP governance process. Researchers must persist in communicating with core developers until the roadmap is unanimously agreed upon.

By implementing these measures, governance transparency can be improved, community participation can be enhanced, and effective collaboration between core developers and researchers can be promoted, reducing potential governance issues in the future.

Summary

The EIP-3074/EIP-7702 incident in Ethereum reveals the complexity of its governance structure: besides the formal governance process (driven by core developers through EIPs and proposals at the Ethereum Core Developers Conference), researchers' informal roadmaps also have significant influence. When these two forces are not aligned, it can lead to decision-making deadlocks or sudden shifts. In such cases, Vitalik's role is crucial, as he can coordinate all parties with his grasp of Ethereum's vision, akin to a project's spiritual leader.

We simplify Ethereum's governance into a model: Community Values → Vitalik's Vision → Research Team's Roadmap → Core Developers' Implementation (VVRC Model). This chain shows how decisions are gradually refined from broad ideas to specific technical implementations.

To improve governance efficiency, it is necessary to address issues that deviate from this ideal model in practice. After all, good Ethereum governance is the core mechanism driving the project forward. The EIP-3074 incident, as an example, exposed weaknesses in governance, providing us with opportunities to learn and improve, ensuring better handling of similar challenges in the future and promoting the continuous healthy development of Ethereum.