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

Written by: 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 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 (commonly referred to as AA).

But then, 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 proposals related to account abstraction in the Ethereum ecosystem, aiming to improve user account management and interaction methods, enhance user experience andSafetysex.

ERC-4337 allows users to use proxycontract(Proxy Contract) to manage their accounts, reducing the number of users DApp ERC-7560 aims to integrate the concepts in proposals such as ERC-4337 directly into the base layer of Ethereum, so that all accounts naturally have the ability 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 the Ethereum account abstraction roadmap.

Currently, the core developer team is discussing EIP-7702, and some early signs andCommunityFeedback indicates that EIP-7702 will likely replace EIP-3074 in the Pectra hard fork.

I’m personally very happy with the outcome: EOA users will soon be able to enjoy most of the benefits of account abstraction with the help of tools and infrastructure built for ERC-4337.

However, the process of getting to this point has left me with a feeling that it was far from optimal, a feeling shared by many in recent times. I have no doubt that with a better process, we could have reached consensus more quickly and with less friction.

In this article, I intend to:

• Problems in the analysis process

• Propose a framework for understanding Ethereum governance

• Discuss how to improve and avoid repeating this mistake in the future

Why is everyone dissatisfied?

The whole incident has left many people unhappy for several reasons:

• Long road to approval: It took several years for EIP-3074 to get the green light.

• Feedback lag: The core developers only widely heard the objections from the ERC-4337 community after 3074 was passed.

• Warning failed: Although the author of proposal 4337 repeatedly raised concerns about 3074 to core developers, it had little effect.

• Changing course: Today, we are faced with revoking EIP-3074 and replacing it with EIP-7702.

Objectively speaking, there is nothing wrong with each of the above links individually:

• Long discussions are 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 can probably all agree that this process could have been much smoother. Imagine if things went this way:

The ERC-4337 community was actively involved during the core developers’ discussion of EIP-3074. As a result, there are only two possible outcomes:

• Either EIP-3074 is approved (possibly with some modifications) after taking into account the feedback from the EIP-4337 community, then the EIP-4337 community will support EIP-3074, and there will be no need to overturn the 3074 decision.

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

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

What's the problem?

Looking back at the whole process, both sides of the debate have made accusations.

Core developers (including the author of EIP-3074) feel that the problem would not have occurred 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.

In this process, proposals require long discussions and are eventually accepted and incorporated into the protocol by the client team. They believe that the EIP-4337 team could have intervened at any time to raise their concerns, rather than waiting until EIP-3074 has been 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 cares so much, why not invest time to participate?

On the contrary, the Account Abstraction Team (the author of EIP-4337) emphasized that they actually participated in 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 people thought that EIP-3074 had been abandoned, and they didn’t even know that EIP-3074 was still under consideration.

In addition, some people pointed out 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 update. Others believe that it is the responsibility of the Ethereum Core Developer Conference to proactively solicit opinions from key stakeholders (such as the EIP-4337 community).

In my view, neither side has fully grasped the core of the problem. There is a deeper issue at work, and unless we address it, or at least confront it, we will continue to experience repeated failures of governance and engage in meaningless finger-pointing.

The crux of the matter

The real crux of the governance failure lies in the common misunderstanding of 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, which has enormous influence on major Ethereum matters such as account abstraction and scalability, is rarely formally recognized.

I call this power the "roadmap" here.

In short, the entire turmoil of switching from 3074 to 7702 is a typical case of the power of the "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, for example, the roadmap centered on Rollup, the ETH 2.0 roadmap, or the account abstraction roadmap that is the focus of this discussion.

Imagine a discussion at an Ethereum core developer meeting about how to scale the network:

Core developer Bob proposed: I support EIP-1234, which advocates speeding up the block time by 10 times, increasing the block capacity by 10 times, and reducing the transaction fee by 100 times.

Other developers responded: Are you serious?

Think about it, why was Bob’s proposal rejected so quickly? He did propose an effective expansion plan, which is what other public chains such as Solana do, with significant results.

The reason is that Bob’s proposal runs counter to Ethereum’s expansion roadmap, which is based on Rollup. This roadmap emphasizes that in order to maintainBlockchainGiven the decentralized nature of the blockchain, it is crucial that ordinary users can 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 actually follow a higher guiding principle, which is what I call the roadmap. There are various roadmaps here, 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 are out of sync 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 roadmaps", not all roadmaps have the same degree of recognition. This requires the planners behind the roadmap to actively promote it to core developers and the community at large to win recognition, and then gain the recognition and support of core developers.

Taking account abstraction as an example, Vitalik has repeatedly promoted a roadmap centered around EIP-4337, but it is actually mainly the EIP-4337 team, especially Yoav and Dror, who actively advocate this roadmap in conferences, online forums, and Ethereum Core Developer Conferences.

However, even so, some core developers still oppose the roadmap centered on EIP-4337. 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.

However, 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. It clearly supported the account abstraction solution centered on EIP-4337, which pushed the situation towards following the account abstraction roadmap.

Vitalik’s Role

Although Vitalik considers himself a researcher, this incident shows that he plays a unique role in Ethereum governance. This begs the question: What role does Vitalik play in Ethereum governance?

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

If you’ve worked at a tech company of a certain size, say more than 50 people, you’ll understand that the CTO can’t 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.

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 some aspects. Therefore, in technical debates, engineers often make the final decision.

However, the CTO is responsible for setting the company's technical vision, while the implementation is left to the developers.

While this metaphor is not perfect, it fairly accurately depicts Vitalik’s role in the Ethereum ecosystem.

Vitalik doesn’t participate in every technical decision—he can’t do that, and he’s not the best at everything. But he has a huge influence on the roadmap for all key aspects of Ethereum (scaling, account abstraction, proof of stake, etc.), not just because of his technical knowledge, but because he can ultimately judge whether a roadmap is consistent with Ethereum’s vision—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 the founding team, or even just one key founder to establish it.

The beauty of Ethereum is that such a complex, multi-faceted system can work together to become a decentralized computer that transfers huge amounts of value every day. This is not achieved by committee-style decision-making, but thanks to Vitalik's 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 disparage 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 honestlyXiaobai NavigationWhen you joined Ethereum because of its openness, censorship resistance, and innovative vitality, did you care that all this originated from Vitalik’s original idea?

Maybe you haven’t thought about it before, but now that you understand this, do you really mind?

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

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 explains the multiple meanings of decentralization. The key point of the article is that decentralization has three aspects:

Architectural decentralization: How many nodes must fail before the system stops functioning?

Logical decentralization: Can the different parts of the system 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 important position in setting the Ethereum vision and roadmap 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 where it is as stable and unchanging as Bitcoin, there needs to be such a widely respected authority who not only makes decisions based on technical merits, but also ensures that these decisions are in line with the long-term vision of Ethereum.

Without a character like Vitalik, Ethereum may face two scenarios. The EIP-3074 incident is a vivid example:

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

• Chaotic design: The system may become an incoordinated patchwork, as almost happened with EIP-3074 running in parallel and incompatible with EIP-4337.

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

The importance of community

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

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

In fact, the community plays the most core role. Because before the vision is formed, there is something more fundamental - values. We gather into a community because we share certain values. These values are the cornerstone of Vitalik's vision and must match it, otherwise the community will no longer exist.

Whether it is 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 truly decentralized 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’s governance as a well-designed machine. We simplify it into four key parts: Values, Vision, Roadmaps, and Clients, referred to 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 outlines the vision for the future development of Ethereum based on the values of the community.

• Roadmaps: With a clear vision, the research team sets out to develop specific steps to achieve those dreams. They design a technical path to get there.

• 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 proposals 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, while also reminding us that we need to constantly adjust and improve this process to avoid problems similar to EIP-3074 from happening again.

How to Improve Ethereum Governance

In order to optimize the governance structure of Ethereum and ensure that the mistakes of EIP-3074/EIP-7702 are not repeated, here are some suggestions for improvement:

Improve EIP transparency: Ensure 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, so even if the core developers have agreed to EIP-3074, its status is still shown as "under review. It is recommended to notify the community in advance of the EIPs that are about to be adopted through the Ethereum Foundation's social media platform.

Enhance community participation: Set up specific time slots for community members to discuss the impact of EIP on downstream projects in the Ethereum Core Developer Conference, which can prevent unexpected impacts like 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.

Mutual understanding and continuous communication: Core developers and researchers must understand each other. They are both key forces in governance, but they focus on different things. Core developers have "executive power" by implementing the client, which is equivalent to "voting power". Researchers gain wider community support and form "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 will be broken when the two sides conflict, as exemplified by the chaos caused by the passage of EIP-3074.

On the contrary, when researchers encounter resistance, they may choose not to cooperate with core developers. This 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.

Although RIP helps L2 Experimenting with protocol updates that are difficult to adopt directly on L1 is beneficial, but it is not a substitute for participating in the EIP governance process. Researchers must persist in communicating with core developers until the roadmap is agreed upon.

Through the above measures, we can improve the transparency of governance, enhance community participation, promote effective cooperation between core developers and researchers, and reduce possible governance issues in the future.

Summarize

Ethereum's EIP-3074/EIP-7702 incident revealed 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 governance into a model: community values → Vitalik’s vision → research team roadmap → core developer 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 deviations 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 the 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.

The article comes from the Internet:Reflections on Ethereum governance: Why are people unhappy with the EIP-3074 incident?

Related recommendations: Base Social Protocol Kingdom: Massive users and billions of TVL under consumer applications

Base as L2 With its unique advantages and community taste, Base has the potential to attract a large number of new users and achieve large-scale adoption. Written by: IOSG Ventures Special Thanks: Thanks to Fiona, Ray, Jocy, Mitu for their valuable suggestions on the revision of this article! TL,…