Reflections on Ethereum governance: Why are you unhappy with the EIP-3074 incident?

Source: Bulushuo

This article explains my thoughts on the recent EIP-3047 incident. Thanks to Vitalik and Yoav for reviewing the content.

If you are not familiar with this incident, here is a brief review:

Not long ago, the EIP-3074 proposal was greenlit by 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 (commonly referred to as AA).

But then, the ERC-4337 community, especially the drafters of the proposal, expressed strong opposition to the EIP-3074 proposal, mainly because EIP-3047 may increase centralization risks and is inconsistent with the Ethereum account abstraction roadmap, the core of which is EIP-4337 and its close relative EIP-7560 (also called 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 the design is more in line with the current EIP-4337 standard and can smoothly transition to the final form - EIP-7560.

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

ERC-4337 allows users to manage their accounts through a proxy contract, reducing the complexity and risk of user DApp interactions. ERC-7560 aims to integrate the concepts of proposals such as ERC-4337 directly into Ethereum's base layer, making all accounts naturally capable of account abstraction, thereby providing deeper integration and optimization.

ERC-4337 is an important step in the transition to ERC-7560, and together they form the core of Ethereum's 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 am personally very happy with this result: EOA users will soon enjoy most of the benefits of account abstraction with the tools and infrastructure built for ERC-4337.

However, the process of getting to this goal makes me feel that it is far from the best path, which is also the common feeling of many people recently. I’m convinced that with a better process, we could have reached consensus more quickly with less friction.

In this post, I intend to:

• Dissect what went wrong

• Propose a framework for understanding Ethereum governance

• Discuss how to improve and avoid future mistakes

Why is everyone upset?

This whole episode has left many people upset for several reasons:

• The long road to approval: EIP-3074 took years to get the green light.

• Delayed feedback: The core developers only heard widespread opposition from the ERC-4337 community after 3074 passed.

• Failed warning: The author of Proposal 4337 repeatedly raised concerns about 3074 to the core developers, but to little avail.

• Change course: Now we are faced with revoking EIP-3074 and replacing it with EIP-7702.

 Objectively speaking, each of the above steps is not wrong in isolation: 

• The long discussion is reasonable.

• It is normal to encounter opposition after approval.

• If new problems emerge, it is also logical to adjust or even cancel the original decision.

 However, we may all agree that this process could have been smoother. Imagine if this was the case:

 The ERC-4337 community was actively engaged during the core developers’ discussion of EIP-3074. There are only two possible outcomes:

• Either EIP-3074 is approved (possibly with modifications) after taking into account EIP-4337 community feedback, in which case the EIP-4337 community supports EIP-3074 and there is no need to overturn the 3074 decision.

• Or, EIP-3074 is never approved, but the EIP-4337 community works with the core developers to move forward with a proposal that everyone is happy with, as happened with EIP-7702.

Everyone’s voice is heard, and there are no dramatic reversals. This should be the ideal outcome — but why didn’t it happen?

What went wrong?

Looking back at the whole 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 been more actively involved in the Ethereum Core Developer Conference (All Core Devs, commonly referred to as ACD) process, the problem 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 instead of waiting until EIP-3074 was approved. After all, the Ethereum Core Developer Conference process is open and transparent, and the meetings are open to the public. People like Tim Beiko will tweet summaries after each meeting. If the EIP-4337 team really cared so much, why didn't they invest time to participate?

In contrast, the Account Abstraction Team (the authors of EIP-4337) emphasized that they actually attended the Ethereum Core Developer Conference and took every opportunity to oppose EIP-3074, but it was not adopted by the core developers. Members of the EIP-4337 community were generally surprised, and many thought that EIP-3074 had been abandoned, or even knew that EIP-3074 was still under consideration.

In addition, there are also opinions that the Ethereum Core Developer Conference process is too complicated and difficult for people who have full-time jobs and cannot keep up with every step of the update. Others believe that it is the responsibility of the Ethereum Core Developer Conference to proactively solicit the opinions of key stakeholders (such as the EIP-4337 community).

In my opinion, neither side has fully grasped the core of the problem. There is a deeper problem at work, and unless we solve it, or at least face it, we will repeatedly encounter governance failures and fall into meaningless mutual accusations.

The crux

The real crux of the governance failure is that everyone generally misunderstands the Ethereum Core Developer Conference. The Ethereum Core Developer Conference is not actually the only decision-making force for protocol updates. In this case, another governance force actually overrides the Ethereum Core Developer Conference and plays a decisive role.

The problem is that this crucial governance force, although it has a huge influence on major Ethereum matters, such as account abstraction and scalability, is rarely formally recognized.  

I call this power "roadmap" here.  

In short, the whole 3074 to 7702 incident is a typical case of the power of "roadmap" overwhelmed the decision-making power of the Ethereum Core Developer Conference.  

From a governance perspective, when an invisible force overwhelms a visible force, we should be alert, because invisible means unsupervised, so this invisible force must be exposed and examined.

What is a roadmap?

In the Ethereum circle, the word roadmap must be familiar to everyone, such as the roadmap centered on Rollup, the ETH 2.0 roadmap, or the account abstraction roadmap that is the focus of this discussion.  

Imagine that at an Ethereum core developer meeting, everyone is discussing how to scale the network: 

Core developer Bob proposes: I support EIP-1234, which advocates 10 times faster block times, 10 times more block capacity, and 100 times lower transaction fees.

Other developers respond: Are you serious?  

Think about it, why was Bob's proposal rejected so quickly? He did propose an effective scaling solution, which other public chains such as Solana do with great results. 

The reason is that Bob's proposal runs counter to Ethereum's Rollup-centric scaling roadmap. This roadmap emphasizes that in order to maintain the decentralized nature of the blockchain, it is crucial for ordinary users to be able to easily run nodes. Therefore, Bob's proposal was naturally excluded because it greatly increased the difficulty of running nodes and was inconsistent with the roadmap.  

Through this example, I want to show that the core developers who participate in the Ethereum Core Developer Conference and are responsible for protocol updates are actually following a higher guiding principle, which is what I call the roadmap. There are various roadmaps, such as the expansion roadmap, the account abstraction roadmap, the MEV roadmap, etc., which together constitute the overall roadmap of Ethereum and are the basis for core developers to make decisions.

When core developers disagree with the roadmap

Because the roadmap is not part of formal governance, core developers may not always agree with it. In particular, since there is no official process for "approving the roadmap", not all roadmaps have the same degree of recognition. This requires the planners behind the roadmap to actively promote it to the core developers and the community at large to win recognition, and then gain the recognition and support of the core developers.  

Take account abstraction as an example. Vitalik has repeatedly promoted the EIP-4337-centric roadmap, but it was actually mainly the EIP-4337 team, especially Yoav and Dror, who actively advocated this roadmap in conferences, online forums, and the Ethereum Core Developer Conference.  

However, even so, some core developers still oppose the EIP-4337-centric roadmap. They believe that EIP-7560 (the native version of EIP-4337, which needs to be implemented by future clients) is too complicated and is not the only way to achieve the final form of account abstraction. In the end, although the EIP-4337 team opposed EIP-3074, which would split the abstract account ecosystem by introducing another more centralized account abstraction technology stack, the Ethereum Core Developer Conference approved EIP-3074.  

But after EIP-3074 was approved, strong opposition from the entire EIP-4337 community prompted the core developers to re-examine EIP-3074. The two sides argued until Vitalik proposed EIP-7702 as an alternative to EIP-3074 at a critical moment, which explicitly supported the account abstraction scheme centered on EIP-4337, which pushed the situation in the direction of following the account abstraction roadmap.

Vitalik's Role

Although Vitalik considers himself a researcher, this incident shows that he plays a unique and different role in Ethereum's governance. This raises the question: what role does Vitalik play in Ethereum's governance?  

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

If you have worked in a technology company of a certain size, such as more than 50 people, you will understand that the CTO cannot be involved in every technical decision. As a company grows, technical decisions naturally become decentralized, with sub-teams in various product areas generally being able to decide on their own implementation details. Also, the CTO is not necessarily the top expert in all areas. There may be engineers in the company who are better at certain things than the CTO. So in technical debates, it is often the engineers who make the final call. However, the CTO is responsible for setting the technical vision of the company, while the implementation is left to the developers. While this metaphor is not perfect, it depicts Vitalik’s role in the Ethereum ecosystem fairly accurately. Vitalik does not participate in every technical decision - he cannot do so, and he is not the top expert in all areas. But he has a huge influence on the roadmap of all key aspects of Ethereum (such as scaling, account abstraction, proof of stake, etc.), not only because of his technical knowledge, but also because he can ultimately judge whether a roadmap is consistent with Ethereum’s vision - that is, his own vision.

The driving force behind every successful product is vision

As an entrepreneur, I believe that every successful product has a clear vision behind it. And such a vision often requires a few people, usually a founding team, and often only one key founder to establish it.  

The charm of Ethereum is that such a complex and multi-faceted system can work together to become a decentralized computer that circulates huge amounts of value every day. This is not achieved by committee-style decision-making, but thanks to Vitalik's leadership with his vision, we have the coordinated and efficient Ethereum we have today. From its conception in 2015 to today, Ethereum has always been the embodiment of Vitalik's wisdom.  

This is not to belittle the contributions of other researchers and engineers who have made great contributions to the development of Ethereum. But at the same time, it is undeniable that Ethereum is the ultimate manifestation of Vitalik's vision, far beyond the influence of any other individual.  

Ask yourself honestly, when you joined Ethereum for its openness, censorship resistance, and innovative energy, did you care that all of this originated from Vitalik's original idea?  

Maybe you didn't think about it before, but now that you understand this, do you really care?  

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

What about decentralization?

You may ask, if one person has such a significant influence on Ethereum, how can we say that 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 point of the article is that decentralization has three aspects:  

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

2. Logical decentralization: Can the different parts of the system 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, as it can be distributed among many nodes, and different components (such as the consensus mechanism and execution layer) can evolve 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 important position in setting the vision and roadmap of Ethereum means that there may be compromises in political decentralization.  

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

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

1. Decision-making deadlock: All parties are unwilling to compromise and the project stagnates, just like the debate on EIP-3074 was not broken until Vitalik intervened.

2. Design chaos: The system may become an uncoordinated patchwork, just like the situation where EIP-3074 and EIP-4337 were parallel and incompatible.

Therefore, at a stage where Ethereum is still evolving rapidly, Vitalik's leadership is crucial to maintaining an ecosystem that is both decentralized and directional.

The importance of the community

So far, we have almost built a comprehensive understanding of Ethereum governance, but there is still a key part that has not been mentioned in the discussion - the role of the community.

If Vitalik sets the vision, researchers create the roadmap, and core developers implement it, what role does the community play? Surely it’s not insignificant?  

In fact, the community plays the most central role. Because before the vision is formed, there is something more fundamental - values. We are brought together as a community because we share certain values, which are the cornerstones of Vitalik’s vision and must match them, otherwise the community will no longer exist.

Perhaps it was the influence of their upbringing or the inspiration of past experiences, everyone in the Ethereum community has at some point realized the value of building a computer that is accessible to everyone, cannot be censored, and is truly decentralized. Our work on Ethereum every day is the practice and affirmation of these values. It is through these actions that we give life and legitimacy to the vision, roadmap, and code proposed by Vitalik, researchers, and core developers.

Simplified Ethereum Governance Model: VVRC Framework

Imagine Ethereum governance as a well-designed machine. We simplify it into four key parts: Values, Vision, Roadmaps, and Clients, referred to as the VVRC model.

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

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

3. Roadmaps: With a clear vision, the research team will set out specific steps to achieve these dreams. They design a technical path to move towards the goal step by step.

4. Clients: Finally, the core developer team writes code and maintains client software according to the roadmap to ensure that all technical plans can become a reality and can be actually used by users and developers.

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

In general, the VVRC model helps us understand how Ethereum can advance governance under ideal conditions, and it also reminds us that we need to constantly adjust and improve this process to avoid problems like EIP-3074.

How to improve Ethereum governance

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

1. Improve EIP transparency: Make sure that the EIPs under consideration are more open and transparent to the community to avoid situations like EIP-3074 being suddenly accepted and surprising everyone. In fact, the EIP status marked on the EIPs website is not synchronized with the review progress of the Ethereum Core Developer Conference. Therefore, even if the core developers have agreed to EIP-3074, its status is still displayed as "under review. It is recommended to notify the community in advance of the EIP that will be adopted through the Ethereum Foundation's social media platform.

2. Enhance community participation: Set specific time periods for community members to discuss the impact of EIP on downstream projects in the Ethereum Core Developer Conference meeting. This can prevent unexpected impacts such as EIP-3074 on the EIP-4337 community. At the same time, if researchers find that their feedback is not taken seriously by core developers, like the difficulties encountered by the EIP-4337 team, they can invite community members to join the discussion to strengthen their own position.

3. Mutual understanding and continuous communication: Core developers and researchers must understand each other. They are both key forces in governance, but with different focuses. Core developers have "executive power" by implementing the client, which is equivalent to "voting power." And researchers have gained wider community support and formed "roadmap influence" by actively sharing and discussing their roadmaps.

When the two sides disagree, core developers may be inclined to directly overturn the researchers' ideas, just as they did with the EIP-4337 team. But doing so is prone to backlash because the balance of power is broken when the two sides conflict, as exemplified by the chaos caused by the passage of EIP-3074.

Conversely, when researchers encounter resistance, they may choose not to cooperate with core developers, which is one of the reasons why the RIP (Rollup Improvement Proposal) process was born and native account abstraction (EIP-7560) was mainly promoted as a RIP rather than an EIP.

While RIP is beneficial in helping L2 experiment with protocol updates that are difficult for L1 to adopt directly, it is not a substitute for participating in the EIP governance process. Researchers must persist in communicating with core developers until the roadmap is unanimously agreed.

Through the above measures, the transparency of governance can be improved, community participation can be enhanced, and effective cooperation between core developers and researchers can be promoted, reducing possible governance issues in the future.

Summary

Ethereum's EIP-3074/EIP-7702 incident reveals the complexity of its governance structure: In addition to the formal governance process (driven by core developers based on EIP and Ethereum Core Developer Conference proposals), the informal roadmap proposed by researchers also has a huge influence. When these two forces are not coordinated, it may lead to a decision-making deadlock or a sudden turn. At this time, Vitalik's role is particularly critical. He can coordinate all parties with his grasp of Ethereum's vision, similar to the spiritual leader of a project.

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.

In order to improve governance efficiency, it is necessary to correct the problems that deviate from this ideal model in actual operations. After all, good Ethereum governance is the core mechanism that drives the project forward. The EIP-3074 incident, as an example, exposed weaknesses in governance and provided us with an opportunity to learn and improve, ensuring that we can better respond to similar challenges in the future and promote the continued healthy development of Ethereum.