Forward the original title ‘ Reflections on Ethereum Governance Following the 3074 Saga’

Abstract: The article is a statement from Derek Chiang, the CEO of ZeroDev, in response to V’s proposal of EIP-7702 to balance the contradictions between ERC-4337 and EIP-3074. Written from the perspective of a project founder within the AA ecosystem, it objectively highlights Ethereum’s current governance model and its pain points. Derek succinctly points out:

One of Ethereum’s governance conflicts lies in the discrepancies between the roadmap determined by researchers and the perspectives of client development teams like Geth. Vitalik, acting in a role akin to a CTO, ultimately becomes the decisive factor.

After affirming Vitalik’s role, Derek outlines the improvements Ethereum should make to its governance model, offering valuable insights for both the Ethereum and Bitcoin communities.

Text:

If you weren’t familiar with the events surrounding Ethereum’s Account Abstraction (AA) previously, here’s a brief recap: Several weeks ago, the EIP-3074 proposal was approved by Ethereum’s core developers to be included in the next hard fork, “Pectra”. This proposal introduces two new opcodes to the Ethereum Virtual Machine (EVM), allowing Ethereum Externally Owned Accounts (EOAs) to have an almost-native AA experience. Since then, many members of the ERC-4337 community, particularly its proponents, have strongly opposed EIP-3074, citing concerns about potential security risks and its incompatibility with Ethereum’s AA roadmap. In Ethereum’s previous roadmap, ERC-4337 and similar proposals like 7560 (also known as “nativeAA”) were central. In early May, Vitalik proposed EIP-7702 as an alternative to EIP-3074, striking a balance between 4337 and 3074—providing an AA experience for EOA users while maintaining compatibility with ERC-4337 to some extent, as well as compatibility with the “final AA solution” 7560. Currently, Ethereum’s core developers are considering the implications of EIP-7702, and preliminary discussions and community sentiment indicate that EIP-7702 is likely to replace EIP-3074 mentioned earlier. I am very satisfied with this outcome: EOA users will soon be able to experience various products within the ERC-4337 ecosystem and enjoy most of the benefits of AA. However, I can’t help but feel that there could have been a better way to achieve these results, as many have pointed out in recent weeks. I believe that with a better governance process, we could have saved a lot of energy and achieved the desired outcome more quickly. In this article, I would like to:

• Identify what went wrong in the governance process
• Propose a thinking model for Ethereum governance
• Offer suggestions for improvement to avoid similar governance accidents in the future

Conclusion and Reflection on the EIP-3074 Incident

The story mentioned above has left many people unhappy for several reasons: EIP-3074 took several years to be approved. After 3074 was finally approved, Ethereum’s core developers faced strong opposition from the 4337 community. On the other hand, the authors of ERC-4337 repeatedly expressed their concerns about EIP-3074 to the Ethereum core team, but to no avail. Now Ethereum is planning to cancel the approval of 3074 and replace it with another EIP (7702). There’s nothing inherently wrong with any point in the process mentioned above:

• It’s normal for discussions about an EIP to take several years.
• It’s normal for an approved EIP to be rejected afterward.
• If new issues are discovered, approval of an EIP can be revoked after approval.

However, things could have been smoother. Let’s imagine if things had developed like this: during the discussion of 3074, the 4337 community actively engaged with Ethereum’s core developers. If this premise holds true, then there are only two possible outcomes:

• After considering feedback from the 4337 community, the 3074 proposal is approved (and possibly modified). In this case, the 4337 community would accept 3074, and Ethereum’s core team would not need to revoke 3074.
• Alternatively, 3074 is never approved, but the 4337 community and Ethereum’s core team jointly propose a solution that satisfies everyone, similar to 7702. Everyone’s voices are heard, and there’s no dramatic reversal. This would have been ideal—so why didn’t it happen?

What went wrong?

Looking back at the whole process, both sides of the event are blaming each other. Ethereum core developers (as well as the authors of EIP-3074) believe it’s the fault of “4337 supporters” because they didn’t actively participate in the All Core Developers (ACD) discussion process. In this process, EIPs need to undergo lengthy deliberations and ultimately be accepted and implemented by Ethereum client development teams like Geth. Some argue that during the period when EIP-3074 was under consideration, “4337 supporters” could have participated and expressed their views, instead of criticizing it after it had already been approved. After all, the entire ACD process is transparent, meetings are open to everyone, and individuals like Tim Beiko consistently publish summary tweets after each ACD meeting. So, if “4337 supporters” cared so much about the topic, why didn’t they actively and promptly participate in the relevant meetings?

On the other hand, core members of 4337 indicate that they have been participating in ACD meetings and opposing 3074 as much as possible, but the Ethereum core developers don’t listen. As for the 4337 community members, many felt blindsided—many thought 3074 was already dead, and some weren’t even aware that 3074 was likely to be approved. Many point out that the entire process of ACD meetings is opaque and not friendly to those who are “serious” in the Ethereum community but cannot keep up with ACD updates in real-time. Some also believe that ACD should actively seek feedback from stakeholders (here referring to the 4337 community).

However, I believe neither side has hit the nail on the head. There are deeper issues behind this, and unless we address or at least acknowledge this problem, we will continue to fall into governance accidents, followed by contradictory accusations from both sides, which are ultimately meaningless.

The root cause of governance accidents: the roadmap

Contrary to popular belief, the root cause of governance accidents lies in the fact that ACD is not the sole governance authority for Ethereum protocol updates; it has been replaced by another governance authority. The problem here is that, despite having more influence than ACD on Ethereum core issues (such as AA and scalability), this other governance authority is rarely acknowledged. In this article, I’ll refer to this type of power as the “roadmap.” As I’ll point out below, the entire “3074-4337-7702” governance failure event is a case of Ethereum’s existing roadmap power overriding ACD power. If we talk about governance, when we notice that an intangible force is overwhelming a tangible one, we should be extremely concerned because intangible things are often difficult to explain and cannot be easily noticed by many people, so they must be exposed.

What is a roadmap?

Anyone in the Ethereum community must have often heard the term “roadmap,” whether in the “ETH2.0 roadmap” or in the context of the “AA roadmap” related to this event.

To illustrate my point, let’s imagine a scene at an ACD meeting where core developers are discussing how to scale Ethereum:

• Core Developer Bob: I support EIP-1234, which proposes to increase block speed by 10 times, increase block size by 10 times, and reduce fees by 100 times.
• Other Core Developers: …Are you out of your mind?

Let’s think about this. Why would the Ethereum core team reject what Bob is proposing? He’s just suggesting a seemingly reasonable way to scale, something that many public chains like Solana, Aptos, Sui, and others have done, achieving high TPS. The reason is that this fictional EIP-1234 contradicts Ethereum’s “rollup-centric” scaling roadmap. This roadmap emphasizes that, for decentralization, ordinary users must be able to run nodes at low cost. Therefore, the fictional EIP-1234 is unlikely to be accepted because it would significantly increase the cost of running Ethereum nodes. I want to use this example to illustrate that core developers participating in the ACD governance process and deciding on protocol updates are guided by a higher-level force, which I call the “roadmap.” Currently, around Ethereum’s roadmap, there are “scaling roadmaps,” “AA roadmaps,” “MEV roadmaps,” and so on. They collectively form Ethereum’s overall roadmap, and core developers must make decisions based on this foundation.

When core developers’ views don’t align with the roadmap

Since the roadmap is not a formal part of the Ethereum governance process, there’s often no guarantee that the core team will adhere to it. Moreover, there’s no formal process for “approving” the roadmap, so not all roadmaps have the same level of “orthodoxy.” Researchers behind the Ethereum roadmap must work hard to promote their roadmap to core developers and the community to gain “orthodoxy” and support from the Ethereum core development team. Regarding AA and account abstraction, Vitalik himself has repeatedly advocated for the 4337-centric AA roadmap, but overall, it’s mainly the team behind 4337, especially Yoav and Dror, who advocate for the 4337-centric AA roadmap on forums and in ACD meetings.

However, despite these efforts, some Ethereum core developers still strongly oppose the 4337-centric AA roadmap. They believe that 7560 (the native 4337 version to be implemented by Ethereum clients in the future) is too complex and not the only viable solution for the “AA endgame.” Ultimately, the ACD decided to approve the 3074 proposal, despite opposition from the 4337 team, which believed that 3074 would fracture the entire AA ecosystem. After 3074 was approved, the entire 4337 community reacted strongly, forcing Ethereum core developers to re-engage in discussions about 3074. The discussion then reached a stalemate, with the authors of 4337 and 3074 unable to persuade each other. Vitalik proposed EIP-7702 as an alternative to 3074 at the last minute, which explicitly accommodates the 4337-centric “AA endgame,” thus resolving the conflict and aligning the final outcome with the AA roadmap.

Vitalik’s Role: Ethereum’s De Facto CTO

Despite Vitalik identifying himself as a researcher, the story above clearly indicates that Vitalik holds governance powers distinct from other researchers. So, the question arises: What role does Vitalik play in Ethereum governance? Personally, I believe it might not be inappropriate to consider Vitalik as the de facto CTO of a very large company (incidentally, assuming Ethereum as a “company” without a CEO to align with the reality). If you’ve ever worked in a tech company with over 50 employees, you’d know that the CTO cannot be involved in every technical decision. As the company grows, decision-making processes for various technical solutions inevitably become decentralized—typically, each area of the company’s product/business has a dedicated team, which often has the autonomy to decide on solution details. Additionally, the CTO may not be the top expert in all (or any) topics. There may be engineers within the company who are better in specific areas than the CTO, so in discussions about technical details of solutions, it’s often individual engineers who make the final decisions. However, the CTO sets the company’s technical vision. Execution of the vision is left to the developers. While this isn’t a perfect analogy, I believe it reasonably encapsulates Vitalik’s role in the Ethereum ecosystem. Vitalik doesn’t participate in every technical decision—he possibly couldn’t. He’s also not the top expert in every domain. But he has overwhelming influence in setting the roadmap for all crucial Ethereum solutions (scaling, AA, POS…), not just because of his technical expertise but also because he’s the ultimate judge of whether the roadmap aligns with the Ethereum vision (his vision).

Every Successful Product Starts with a Vision

If considering Vitalik as Ethereum’s CTO isn’t controversial enough, here’s the most controversial part: we should embrace Vitalik as the CTO. As a founder of a startup, I believe every successful product must have a coherent long-term vision—yes, Ethereum is also a “product” because it solves real problems for real users. A coherent vision must be crafted by a few people, such as the founders of a startup, and usually, there’s only one founder. The beauty of Ethereum is that, despite being an extremely complex system with so many components, all these components seamlessly come together to form a well-functioning decentralized computer, settling billions of dollars’ worth of transactions every day. We’ve come this far not through some committee’s design schemes but because Vitalik, with his foresight and insight, has actively provided leadership, allowing us to build today’s coherent and graceful Ethereum. Ethereum is the idea Vitalik proposed in 2015, and it remains so. Of course, this isn’t to diminish the contributions of other researchers and engineers—they’ve made the bulk of Ethereum’s achievements today. However, this isn’t contradictory, because Ethereum is the realization of Vitalik’s vision, magnitudes larger than anyone else’s vision. Honestly, can you complain about this? When you’re drawn to the openness, censorship resistance, and innovation speed of the Ethereum ecosystem, have you ever complained that it stemmed from Vitalik’s vision? Perhaps you haven’t complained because you haven’t thought of it this way—but now that you are, do you mind this issue?

How to Address Decentralization?

But you might ask, what about decentralization? If one person holds such overwhelming power over Ethereum, how can we say it’s decentralized? To answer this question, we must revisit Vitalik’s classic article on the meaning of decentralization. The key insights of the article are that decentralization comes in three types:

• Architectural decentralization: How many nodes can fail before the system stops running?
• Logical decentralization: Can the various subsystems of the system develop independently while still working together cohesively?
• Political decentralization: Ultimately, how many individuals or organizations control the system?

According to these definitions, Ethereum is clearly architecturally decentralized, and one could argue that it’s logically decentralized because its components lack strong coupling (e.g., between the consensus layer and the execution layer). As for political decentralization, the good news is that no individual or organization can shut down Ethereum, not even Vitalik. However, some might argue that Ethereum’s level of political decentralization is not as high as imagined because Vitalik plays a significant role in shaping Ethereum’s vision and roadmap.

However, I believe that if we want Ethereum to continue innovating, we must accept Vitalik as the de facto CTO, even if it means sacrificing some political decentralization. If Ethereum were to become as “stagnant” as Bitcoin, a nearly immutable blockchain, then Vitalik might as well retire. But before we reach that final step, it’s crucial to have an authority respected by all parties, someone trustworthy to make technical decisions based not only on the superiority of proposed technical solutions but also on whether these decisions align with Ethereum’s vision.

Without someone like Vitalik, only two outcomes are likely, vividly illustrated by the story around EIP-3074:

The Ethereum governance process could fall into an endless deadlock, with conflicting parties unwilling to compromise and no one making progress, as demonstrated by the deadlock in the 3074 debate before Vitalik intervened.

Or Ethereum could become a design-incoherent “Frankenstein,” with 3074 and 4337 possibly not giving in to each other, ultimately resulting in the complete rupture of the AA ecosystem into two incompatible parallel spaces.

The Role of Community

After the above considerations, we are almost sketching out a complete Ethereum governance mindset, but there’s an obvious omission in our discussion so far—the community. If Vitalik defines Ethereum’s vision, researchers define the roadmap, and core developers implement the roadmap, then what role does the community play? Surely, it’s not just sitting idle, right? Fortunately, the community plays the most crucial role. The reason is that, before there’s a vision, there are values. We come together as a community because we rally around certain values, and Vitalik’s vision must ultimately align with these values to retain the community’s support. Everyone in the Ethereum community believes that having a decentralized computer accessible to everyone, uncensored, and trust-neutral is beneficial for the world. We uphold and affirm these values every day through the work we do on Ethereum, thereby legitimizing the vision, roadmap, and code set forth by Vitalik, researchers, and core developers.

The VVRC Model of Ethereum Governance

Therefore, here’s the complete mindset of Ethereum governance, abbreviated as VVRC:

• V==Values==Community;
• V==Vision==Vitalik;
• R==Roadmap==Researchers;
• C==Client==Core Developer;

Together they play the following roles:

• The community rallies around specific values.
• Vitalik articulates a vision consistent with these values.
• Researchers formulate a roadmap based on the vision.
• Core developers implement clients based on the roadmap.

Of course, reality is far more complex than any simple model can capture. Core Ethereum developers are the only ones who can truly “vote” on any proposal by altering the client code. Vitalik and other researchers serve as advisors, and sometimes their opinions are not accepted by core developers, which is precisely why EIP-3074 was approved. Nevertheless, I believe the VVRC model reasonably captures the operational mode of Ethereum governance under normal circumstances, and we need to “debug” this process to prevent accidents like EIP-3074 from happening again.

How to Improve Ethereum’s Governance Model

Now that we have a mental model of how the Ethereum governance process operates, here are some ideas for improving governance processes:

The visibility of discussion progress for EIPs under review must be increased. The entire community should not be “surprised” by the acceptance of an EIP, and unexpected approvals like EIP-3074 should not recur. The current “status” of EIPs on the EIP website does not reflect their status in the ACD process. This is why it still says that EIP-3074 is “under review,” despite core developers having voted to approve it, with no indication that it was ever considered for approval from the outset. Ideally, when an EIP is about to be accepted, the Ethereum Foundation should make a definitive public announcement on social media to raise awareness within the community.

Sometimes, core developers may underestimate the impact of specific EIPs on downstream projects and users, as was the case with the 3074 and 4337 communities. Due to the limited time of ACD meetings and the need for coordination across time zones, only “relevant personnel” can often speak at meetings. Nevertheless, it would make sense occasionally to allocate some speaking time to community members to comment on the impact of certain EIP proposals on downstream projects after their approval. If researchers feel that their opinions have not been accepted by core developers, as was the case with 4337, they can invite community members to reinforce their arguments.

It’s crucial for core developers and researchers to mutually acknowledge that, despite differences in power, they are both part of Ethereum’s governance authority. Core developers have the power to change and update Ethereum clients, which is the only way to make changes to the protocol itself and “vote.” Researchers usually have more public support for changes and interpretations to the roadmap, thanks to their active discussion and writing of their ideas.

When these two forces clash, core developers may tend to directly overturn the opinions of researchers, as was the case with the 4337 team. However, such overturning can lead to conflict, as instability arises when the two forces clash, as evidenced by the dramatic events following the approval of EIP-3074.

Likewise, when faced with resistance, researchers may tend to give up on collaboration with core developers. In my view, this is also one of the reasons for creating the RIP process and why the native AA (7560) is now primarily promoted as RIP rather than EIP.

While experimenting with protocol updates on L2 that are controversial for L1 does have its benefits, we cannot view RIP as a substitute for participating in the EIP governance process. Researchers must continue to collaborate with core developers until both sides’ values fully align with the roadmap.

Conclusion

The 3074/7702 incident revealed the true operation of Ethereum governance—aside from the explicit governance power driven by EIP/ACD processes of core developers, there’s also implicit governance power driven by the roadmap pushed by researchers. When these powers are misaligned, we see deadlock and prodding, and another force—Vitalik—may need to intervene in some way to disrupt the balance.

Next, we propose that Vitalik represents a unique force, namely Ethereum’s “vision,” which forms the basis of the legitimacy of any roadmap. We compare Vitalik to a CTO of a large company and acknowledge his role as a pseudo-CTO is necessary for Ethereum to maintain its pace of innovation, preventing Ethereum from devolving into a “Frankenstein” — like a patched-together monster.

Lastly, we present the VVRC model, describing the Ethereum governance model: Values (Community) ⇒ Vision (Vitalik) ⇒ Roadmap (Researchers) ⇒ Client (Core developers). Then, we propose various methods to “debug” this model’s “faults.”

Ethereum governance is a “machine-making machine”—to make Ethereum run correctly, we must govern it properly.

Disclaimer：

1. This article is reprinted from [极客 Web3]. Forward the Original Title‘Reflections on Ethereum Governance Following the 3074 Saga’. All copyrights belong to the original author [Derek Chiang，CEO of ZeroDev]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.