Original: Reflections on Ethereum Governance Following the 3074 Saga

Author: Derek

Translator: Daisy

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 was planned to be implemented in Ethereum's next 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, arguing that it could exacerbate centralization risks and was 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 related to account abstraction in the Ethereum ecosystem, aimed at improving user account management and interaction methods, enhancing user experience and security.

ERC-4337 allows users to manage their accounts through proxy contracts, reducing complexity and risk when interacting with DApps. ERC-7560 aims to integrate the concepts from proposals like ERC-4337 directly into Ethereum's base layer, enabling all accounts to naturally possess account abstraction capabilities, thus providing deeper integration and optimization.

ERC-4337 is an important step towards 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 has left 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 scenario 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 advance a proposal that everyone is satisfied with, like EIP-7702.

Everyone's voice is heard, and there is no dramatic reversal. 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 require 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, with meetings open to the public, and people like Tim Beiko summarizing 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 input was not adopted by core developers. The members of the ERC-4337 community were generally surprised, with many thinking that EIP-3074 had been abandoned and not even knowing it 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 input from key stakeholders (such as the ERC-4337 community) should be the responsibility of the ACD.

In my view, neither side has fully grasped the core 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 blame games.

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 body for protocol updates; in this case, another governance force actually overrode the ACD and played a decisive role.

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

I refer to this force as the "roadmap."

In short, the entire saga of 3074 transitioning to 7702 is a typical case of the "roadmap" force overriding the decision-making power of the ACD.

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

What is a 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 that is the focus of this discussion.

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

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

Other developers respond: Are you serious?

Think about why Bob's proposal would be quickly dismissed. He indeed proposed an effective scaling solution, as other blockchains like Solana have done, 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 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 participating in the ACD...

Developer conference meetings, where core developers responsible for protocol updates gather, actually follow a higher guiding principle, which I refer to as the roadmap. There are various roadmaps, such as the scalability roadmap, account abstraction roadmap, MEV roadmap, etc. Together, they form the overall Ethereum roadmap, which serves 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 do not always align with it. Particularly, because there is no official process for "approving the roadmap," not all roadmaps enjoy the same level of recognition. This requires the planners behind the roadmaps to actively promote them to core developers and the broader community to gain recognition 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. They believe 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, which they argued would split the abstract account ecosystem by introducing another relatively centralized account abstraction tech stack, 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. EIP-7702 explicitly supports an 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 the 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 more skilled in certain areas than the CTO. 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 actual execution is left to the developers.

Although this analogy is not perfect, it 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 areas. But he has a significant influence on the roadmap for all key aspects of Ethereum (such as scalability, 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.

Every Successful Product is Driven by a Vision

As an entrepreneur, I believe that every successful product is driven by 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, we have the coordinated and efficient Ethereum we see 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. However, 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:

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

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

  3. 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, including Vitalik, can shut down Ethereum. However, 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 innovative, we should accept Vitalik as the de facto CTO, even if this somewhat reduces political decentralization. Until Ethereum matures to a stable and unchanging state like Bitcoin, it needs a widely respected authority figure who not only makes decisions based on technical merits but also ensures these decisions align with Ethereum's long-term vision.

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

  1. Decision deadlock: Parties unwilling to compromise, causing project stagnation, just like the EIP-3074 debate that was only resolved when Vitalik intervened.

  2. Design chaos: The system could become a disjointed 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 framework for understanding Ethereum governance, but there is still a key part of the discussion that has not been 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?

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

Perhaps influenced by our backgrounds or inspired by 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. Our daily work on Ethereum is a practice and affirmation of these values. Through these actions, we give life and legitimacy to the vision, roadmap, and code proposed by Vitalik, researchers, and core developers.

Simplified Model of Ethereum Governance: 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.

  1. Values: Everything starts with a set of fundamental principles and beliefs shared by the Ethereum community.

  2. Vision: As the founder, Vitalik, based on the community's values, outlines the vision for Ethereum's future development.

  3. Roadmaps: With a clear vision, research teams will start formulating specific steps to achieve these dreams. They design technical paths to reach the goals step by step.

  4. Clients: Finally, core developer teams write code and maintain client software based on the roadmap, ensuring that all technical plans become a 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, which may sometimes not be adopted, as shown by the EIP-3074 incident.

Overall, the VVRC model helps us understand how Ethereum governance ideally progresses while 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 avoid repeating incidents like EIP-3074/EIP-7702, here are some suggested improvements:

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

  2. Enhance Community Participation: Set specific time slots for community members to discuss the impact of EIPs on downstream projects during the Ethereum Core Developers Meeting. This can prevent unexpected impacts on communities like EIP-4337 caused by EIP-3074. 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.

  3. 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 there is a disagreement, 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 encounter resistance, they may choose to stop collaborating with core developers. This is one of the reasons why the RIP (Rollup Improvement Proposal) process and native account abstraction (EIP-7560) are mainly advanced as RIPs rather than EIPs.

While RIPs are beneficial for L2 experiments with protocol updates that are difficult to adopt directly on 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.

Conclusion

The EIP-3074/EIP-7702 incident revealed the complexity of Ethereum's governance structure: In addition to the formal governance process (driven by core developers based on EIPs and proposals from the Ethereum Core Developers Meeting), the informal roadmaps proposed by researchers 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, similar 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.