Reflections on Ethereum Governance: Why is Everyone Discontent with the EIP-3074 Incident?

Author: imToken

This article elaborates on my thoughts regarding 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:

Not long ago, 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 ordinary Ethereum account (EOA) users to enjoy the many conveniences of account abstraction (AA).

However, the ERC-4337 community, particularly the authors of the proposal, expressed strong opposition to the EIP-3074 proposal, mainly arguing that EIP-3047 could exacerbate centralization risks and is inconsistent with the Ethereum account abstraction roadmap, which centers around 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 align more closely with the current EIP-4337 standard and can smoothly transition to its final form—EIP-7560.

Translator's Note: ERC-4337 and ERC-7560 are both proposals related to account abstraction within the Ethereum ecosystem, aimed at improving user account management and interaction, enhancing user experience and security.

ERC-4337 allows users to manage their accounts through proxy contracts, reducing the complexity and risks when users interact with DApps. ERC-7560 aims to directly integrate the concepts from proposals like ERC-4337 into the Ethereum 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 indicate that EIP-7702 is likely to replace EIP-3074 in the Pectra hard fork.

I personally feel very satisfied with this outcome: EOA users are about to 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 unsettled, feeling that it is far from the best path, which is a common sentiment among many recently. I firmly believe that with a more refined process, we could have reduced turmoil and reached a consensus more quickly.

In this article, I intend to:

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

Why are people dissatisfied?

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

• Lengthy approval process: EIP-3074 took years to finally receive approval.
• Delayed feedback: Core developers only widely heard the opposing voices from the ERC-4337 community after EIP-3074 was approved.
• Failed warnings: Although the authors of the 4337 proposal repeatedly expressed concerns about 3074 to core developers, little was accomplished.
• Change of course: Now, we face the situation of revoking EIP-3074 and replacing it with EIP-7702.

Objectively speaking, each of the above points is not problematic when viewed individually:

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

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

During the core developers' discussions on EIP-3074, the ERC-4337 community actively participated. In this case, there would only be two possible outcomes:

• Either EIP-3074 is approved after considering the feedback from the ERC-4337 community (possibly with modifications), and then the ERC-4337 community would support EIP-3074, eliminating the need to overturn the decision on 3074.
• Or, EIP-3074 is never approved, but the ERC-4337 community collaborates with core developers to advance a proposal that satisfies everyone, like EIP-7702.

Everyone's voice would be heard, and there would be no dramatic reversals. This should have been an ideal outcome—so why was it not realized?

Where is the problem?

Looking back at the entire process, both sides of the debate have their accusations.

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

In this process, proposals require lengthy 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 express 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 summarize each meeting in tweets. If the EIP-4337 team truly cared, why didn't they invest time to participate?

On the other hand, the account abstraction team (i.e., the authors of EIP-4337) emphasizes that they did participate in the ACD and seized every opportunity to oppose EIP-3074, but their concerns were not adopted by core developers. Members of the EIP-4337 community generally felt surprised, with many believing that EIP-3074 had been abandoned, or even unaware that EIP-3074 was still under consideration.

Additionally, there are opinions that the ACD process is too complex, making it difficult for those with full-time jobs who cannot keep up with every update to participate. Some believe that actively soliciting the opinions of key stakeholders (such as the ERC-4337 community) should be the responsibility of the ACD.

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

The crux of the issue

The real crux of governance failure lies in the widespread misunderstanding of the ACD. The ACD is not the sole decision-making authority for protocol updates; in this case, another governance force actually superseded the ACD, playing a decisive role.

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

I refer to this force as the "roadmap."

In short, the entire turmoil of transitioning from 3074 to 7702 is a typical case where the power of the "roadmap" overshadowed the decision-making power of the ACD.

From a governance perspective, when an invisible force overrides a visible one, we should be alert, as invisibility implies a lack of oversight, and thus this hidden power must be exposed and examined.

What is a roadmap?

In the Ethereum community, the term "roadmap" is likely familiar, such as the roadmap centered around Rollup, the ETH 2.0 roadmap, or the account abstraction roadmap, which is the focus of this discussion.

Imagine a scenario in an Ethereum core developer meeting where everyone is discussing how to scale the network:

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

Other developers respond: Are you serious?

Think about it, why would Bob's proposal be quickly dismissed? He indeed proposed a valid scaling solution, as other public chains like Solana have done with significant results.

The reason is that Bob's proposal contradicts the scaling roadmap that Ethereum adheres to, which centers around Rollup. This roadmap emphasizes that to maintain the decentralized nature of the blockchain, it is crucial for ordinary users to easily run nodes. 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 illustrate that the core developers who participate in ACD meetings and are responsible for protocol updates 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., which together form the overall roadmap of Ethereum and serve as the basis for core developers' decision-making.

When core developers are inconsistent with the roadmap

Because the roadmap is not part of formal governance, core developers do not always align with it. Particularly, since there is no 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 recognition and subsequently obtain the support and endorsement of core developers.

Taking account abstraction as an example, Vitalik has repeatedly praised the roadmap centered around EIP-4337, but in reality, it is primarily the EIP-4337 team, especially Yoav and Dror, who have actively advocated for this roadmap in meetings, online forums, and the ACD.

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, more centralized account abstraction technology stack that could split the abstract account ecosystem, the ACD still approved EIP-3074.

But after EIP-3074 was approved, the strong opposition from the entire EIP-4337 community prompted core developers to reevaluate EIP-3074. The two sides argued until Vitalik proposed EIP-7702 as an alternative to EIP-3074 at a critical moment, which explicitly supports the account abstraction plan centered around EIP-4337, thus pushing the situation towards following the account abstraction roadmap.

Vitalik's role

Although Vitalik sees himself as a researcher, this incident illustrates that he plays a unique role in Ethereum governance. This raises the question: what role does Vitalik play in Ethereum governance?

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

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

Moreover, the CTO is not necessarily the top expert in all areas. There may be engineers in the company who are more skilled than the CTO in certain aspects. Therefore, 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.

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

Vitalik does not participate in every technical decision—he cannot do so, 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 scalability, account abstraction, proof of stake, etc.), not only because of his technical knowledge but also because he can ultimately judge whether a roadmap aligns with Ethereum's vision—which is also his own vision.

The driving force behind every successful product is vision

As an entrepreneur, I believe that every successful product is backed by a clear vision. Such a vision often requires a few people, usually the founding team, and often only one key founder to establish.

The charm of Ethereum lies in the fact that such a complex structure, involving multiple layers, can operate in harmony to become a decentralized computer that circulates enormous value daily. This is not achieved through committee-style decision-making but rather thanks to Vitalik leading us with his vision, which has allowed us to have the coordinated and efficient Ethereum we have today. From the conception in 2015 to today, Ethereum has always been a manifestation of Vitalik's wisdom.

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

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

Perhaps you hadn't thought about it before, but now that you understand this point, do you really care?

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

But what about decentralization?

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

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

Architectural decentralization: How many nodes need to fail for the system to stop operating?

Logical decentralization: Can the various parts of the system evolve independently without affecting overall functionality?

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

Ethereum is undoubtedly decentralized in both architectural and logical terms, as it can distribute across numerous nodes, and different components (such as consensus mechanisms and execution layers) can develop relatively independently.

As for political decentralization, the good news is that no single entity can shut down Ethereum, including Vitalik. However, it is undeniable that Vitalik's important position in setting Ethereum's vision and roadmap may imply a compromise in political decentralization.

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

Without a role like Vitalik's, Ethereum could face two scenarios, and this EIP-3074 incident is a vivid example:

• Decision deadlock: Parties unwilling to compromise lead to project stagnation, just like the debate over EIP-3074 continued until Vitalik intervened to break the deadlock.
• Design chaos: The system could become an incoherent patchwork, similar to the near occurrence of EIP-3074 and EIP-4337 being parallel and incompatible.

Therefore, during the rapid evolution phase of Ethereum, Vitalik's leadership is crucial for maintaining an ecosystem that is both decentralized and has a sense of direction.

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 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 will cease to exist.

Perhaps influenced by their upbringing or inspired by past experiences, every individual in the Ethereum community has, at some point, realized the value of building a computer that is accessible to everyone, censorship-resistant, and truly decentralized. Our daily work on Ethereum is a practice and affirmation of these values, and it is through these actions that we give life and legitimacy to the visions, roadmaps, and codes proposed by Vitalik, researchers, and core developers.

Simplified model of Ethereum governance: the VVRC framework

Imagine Ethereum's governance as a well-designed machine, which we simplify into four key parts: Values, Vision, Roadmaps, and Clients, collectively referred to as the VVRC model.

• Values: Everything begins with a set of fundamental principles and beliefs shared by the Ethereum community.
• Vision: Vitalik, as the founder, paints a vision for the future development of Ethereum based on the community's values.
• Roadmaps: With a clear vision, research teams begin to formulate specific steps to realize these dreams. They design a technical path that leads step by step toward the goal.
• Clients: Finally, the core developer team writes code and maintains client software based on the roadmap, ensuring that all technical plans can become a reality, allowing users and developers to actually use them.

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

Overall, the VVRC model helps us understand how Ethereum ideally advances governance while also reminding us that we need to continuously adjust and refine this process to avoid similar issues as EIP-3074 in the future.

How to improve Ethereum governance

To optimize the governance structure of Ethereum and ensure that we avoid repeating the EIP-3074/EIP-7702 incident, here are some improvement suggestions:

Increase EIP transparency: Ensure that EIPs under consideration are more open and transparent to the community, avoiding situations like EIP-3074 being suddenly accepted, catching everyone off guard. In fact, the EIP status marked on the EIPs website has not synchronized with the review progress of the ACD, so even if core developers have agreed to EIP-3074, its status still shows as "under review." Suggestions can be made to notify the community in advance of upcoming EIPs to be adopted through the Ethereum Foundation's social media platforms.

Enhance community participation: Set specific time slots for community members to discuss the impact of EIPs on downstream projects during ACD meetings, preventing unexpected impacts like those caused by EIP-3074 on the ERC-4337 community. Additionally, if researchers find that their feedback is not valued by core developers, as the EIP-4337 team experienced, 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; they are both key forces in governance, just with different focuses. Core developers possess "executive power" through implementing clients, akin to having "voting power." Meanwhile, researchers gain broader community support by actively sharing and discussing their roadmaps, forming "roadmap influence."

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

Conversely, when researchers encounter resistance, they may choose not to collaborate with core developers anymore, which is also one of the reasons for the birth of the Rollup Improvement Proposal (RIP) process and why native account abstraction (EIP-7560) is primarily advanced as RIP rather than EIP.

While RIP is beneficial for helping L2 experiments with protocol updates that L1 finds difficult to adopt directly, it cannot replace participation in the EIP governance process. Researchers must persist in communicating with core developers until the roadmap gains unanimous recognition.

Through these measures, we can enhance governance transparency, increase community participation, and promote effective collaboration between core developers and researchers, reducing potential governance issues in the future.

Conclusion

The EIP-3074/EIP-7702 incident in Ethereum reveals the complexity of its governance structure: in addition to the formal governance process (driven by core developers based on EIPs and ACD proposals), the informal roadmaps proposed by researchers also wield significant influence. When these two forces are misaligned, it can lead to decision deadlocks or sudden shifts, at which point Vitalik's role becomes crucial, as he can coordinate various parties based on his grasp of Ethereum's vision, akin to a project's spiritual leader.

We simplify Ethereum's governance into a model: the community's values → Vitalik's vision → the research team's roadmap → the core developers' implementation (the VVRC model). This chain illustrates how decisions evolve from broad concepts to specific technical implementations.

To improve governance efficiency, we need to address the issues that deviate from this ideal model in practical operations. After all, good governance in Ethereum is the core mechanism driving the project forward. The EIP-3074 incident serves as an example, exposing weaknesses in governance and providing us with opportunities to learn and improve, ensuring that we can better respond to similar challenges in the future and promote the sustainable and healthy development of Ethereum.