In-depth exploration of Vitalik and various roadmaps' impact on Ethereum governance

Original Title: 《 Reflections on Ethereum Governance Following the 3074 Saga》

Author: Derek Chiang, Founder of ZeroDev

Compiler: Faust, Geek Web3

Abstract: This article presents the views of Derek Chiang, CEO of ZeroDev, following Vitalik's proposal of EIP-7702 to balance the contradictions between ERC-4337 and EIP-3074. The article objectively points out the current governance model of Ethereum and its pain points from the perspective of a project founder within the AA ecosystem, incisively stating:

One of the governance contradictions in Ethereum lies in the disagreement between the roadmap determined by researchers and the views of client development teams like Geth, with Vitalik taking on the role of the final decision-maker akin to a CTO.

After giving a positive evaluation of Vitalik's role, Derek points out what improvements Ethereum should make in its governance model, which holds significant reference value for both the Ethereum and Bitcoin communities.

Main Text: If you are not familiar with the events related to Ethereum AA (Account Abstraction), here is a brief recap:

A few weeks ago, the EIP-3074 proposal was approved by Ethereum core developers to be included in the next hard fork "Pectra." This proposal will introduce two new opcodes to the EVM, allowing Ethereum EOA accounts to achieve an almost native AA experience.

Since then, many in the ERC-4337 community, especially the proposers of 4337, have been strongly opposing EIP-3074, citing concerns that the proposal would bring many security risks and is incompatible with Ethereum's AA roadmap. The previous roadmap clearly centered around ERC-4337 and similar proposal 7560 (also known as "nativeAA").

In early May, Vitalik proposed EIP-7702 as an alternative to EIP-3074, achieving a balance between 4337 and 3074—providing an AA experience for EOA users while being more compatible with ERC-4337 and aligning with the "final AA solution" 7560.

Currently, Ethereum core developers are considering EIP-7702, and the preliminary discussion results and community sentiment indicate that EIP-7702 is likely to replace the aforementioned EIP-3074.

Personally, 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 brought by AA. However, I can't help but feel that we could have achieved the above outcome in a better way, as many have pointed out over the past few weeks. I believe that with a better governance process, we could have saved a lot of effort and achieved the expected results more quickly.

In this article, I aim to:

• Identify what went wrong in the governance process
• Propose a thinking model for Ethereum governance
• Suggest improvements to avoid similar governance incidents in the future

Summary and Reflection on the EIP-3074 Incident

The story mentioned above has left many unhappy for the following reasons:

EIP-3074 took years to gain approval. After 3074 was finally approved, Ethereum 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 plans to revoke the approval of 3074 and replace it with another EIP (7702).

There is nothing inherently wrong with any point in the above process:

• Discussions about an EIP can take years, which is normal.
• It is normal for an EIP to be rejected after approval.
• If new issues are discovered, approval can be revoked after an EIP is approved.

However, things could have been resolved more smoothly. Let's imagine if things had developed this way:

During the discussion of 3074, the 4337 community actively interacted with Ethereum core developers. If this premise is valid, there would only be two possible outcomes:

• After considering the feedback from the 4337 community, the 3074 proposal would be approved (and possibly modified), in which case the 4337 community would accept 3074, and the Ethereum core team would not need to revoke 3074.
• Alternatively, 3074 would never have been approved, but the 4337 community and the Ethereum core team would have jointly proposed a solution that satisfied everyone, just like 7702.

Everyone's voice would be heard, and there would be no dramatic reversals. This would have been great—so why wasn't it like that?

Where Did It Go Wrong?

Looking back at the entire process, both parties have been blaming each other.

Ethereum core developers (and the authors of EIP-3074) believe it is the fault of the "4337 supporters" for not actively participating in the All Core Developers (ACD) discussion process, in which EIPs need to undergo a long review period before being accepted and implemented by Ethereum client development teams like Geth.

Some argue that during the review of the 3074 proposal, the "4337 supporters" could have participated and expressed their views instead of waiting until 3074 was approved to voice their concerns. After all, the entire ACD process is documented, meetings are open to everyone, and Tim Beiko actively publishes summary tweets after each ACD meeting. So, if the 4337 supporters cared so much about this topic, why didn't they participate actively and timely in the relevant meetings?

On the other hand, core members of 4337 point out that they have been attending ACD meetings and opposing 3074 as much as possible, but the Ethereum core developers did not listen. As for the members of the 4337 community, most felt blindsided—many thought 3074 was already dead and were unaware that 3074 was likely to be approved.

Many have pointed out that the entire ACD meeting process is very opaque, which is not friendly to those who are "seriously working" in the Ethereum community but cannot keep up with ACD updates in a timely manner. Some also believe that ACD should proactively seek feedback from stakeholders (referring to the 4337 community).

However, I believe both sides missed the point. There is a deeper issue behind this; unless we address or at least acknowledge this problem, we will continue to fall into governance incidents, with both sides blaming each other, which is meaningless.

The Root Cause of Governance Incidents: The Roadmap

Contrary to popular belief, the root of governance incidents lies in the fact that ACD is not the only source of governance power for Ethereum protocol updates; it is overshadowed by another source of governance power. The problem here is that, although this other source of governance power has more influence on core Ethereum issues (such as AA and scalability) than ACD, it is rarely acknowledged.

In this article, I refer to this power as the "roadmap."

As I will point out below, the entire "3074-4337-7702" governance failure incident is a case where the power of Ethereum's existing roadmap overwhelmed the power of ACD. When we talk about governance, we should be extremely concerned when we notice that an invisible force has overshadowed a tangible one, as the invisible is often difficult to explain and not easily noticed by many, thus it must be exposed.

What is the Roadmap?

Anyone in the Ethereum community must have frequently seen the term "roadmap," such as in "rollup-centric roadmap," "ETH2.0 roadmap," or the "AA roadmap" related to this incident.

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

• A core developer, Bob: I support EIP-1234, which proposes that we increase block speed by 10 times, increase block size by 10 times, and reduce fees by 100 times.
• Other core developers: … Are you crazy?

Let’s think about it. Why would the Ethereum core team reject what Bob said? He merely proposed a seemingly reasonable scaling method that many public chains like Solana, Aptos, and Sui have adopted, achieving high TPS.

The reason is that this fictional EIP-1234 contradicts Ethereum's "rollup-centric" scaling roadmap, which states that for decentralization, it is crucial for ordinary users to run nodes at low cost, thus the fictional EIP-1234 could not be accepted as it would significantly increase the cost of running Ethereum nodes.

I use this example to illustrate that the core developers participating in the ACD governance process and deciding protocol updates are guided by a higher power, which I call the "roadmap." Currently, around Ethereum, there are "scaling roadmaps," "AA roadmaps," "MEV roadmaps," etc., which together form the overall roadmap of Ethereum, and core developers must base their decisions on it.

When Core Developers' Views Conflict with the Roadmap

Since the roadmap is not a formal component of the Ethereum governance process, there is often no guarantee that the core team will adhere to it. Moreover, there is 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 pushed for the roadmap centered around 4337, but overall, it has primarily been the team behind 4337, especially Yoav and Dror, advocating for the 4337-centered AA roadmap in forums and ACD meetings.

However, despite these efforts, some Ethereum core developers still strongly oppose the 4337-centered AA roadmap. They believe that 7560 (the native version of 4337 that Ethereum clients will implement in the future) is too complex and not the only viable solution for the "final AA." Ultimately, ACD decided to approve the 3074 proposal, despite opposition from the 4337 team, who argued 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 discussions then became deadlocked, with authors of both 4337 and 3074 unable to persuade each other, and Vitalik proposed EIP-7702 at the last moment as an alternative to 3074, which explicitly aligns with the 4337-centered "final AA," thus resolving the conflict and allowing the final outcome to fit the AA roadmap.

Vitalik's Role: Ethereum's De Facto CTO

Although Vitalik presents himself as a researcher, the story above clearly shows that Vitalik possesses governance power that is distinctly different from other researchers. So the question arises: What role does Vitalik play in Ethereum governance?

Personally, I think it is not unreasonable to view Vitalik as the CTO of a very, very large company (by the way, for the sake of practicality, let's assume that Ethereum as a "company" has no CEO).

If you have ever worked in a tech company with more than 50 employees, you know that a CTO cannot be involved in every technical decision. As a company grows to a certain size, the decision-making process for various technical solutions inevitably becomes decentralized—typically, there is a dedicated team for each area of the company's products/business, and that team usually has the freedom to decide the details of the solutions.

Moreover, a CTO is not necessarily the top expert on all (or any) topics. There may be some engineers in the company who are better than the CTO in specific fields, so in discussions about technical details, it is often the engineers who make the final decisions.

However, the CTO sets the company's technical vision. The execution of that vision is left to the developers.

While this is not a perfect analogy, I believe it reasonably summarizes Vitalik's role in the Ethereum ecosystem. Vitalik does not participate in every technical decision—he cannot. He is not the top expert in every field. But he has overwhelming influence over the roadmap for all key solutions in Ethereum (scaling, AA, POS, etc.), not just because of his technical expertise but also because he is the final arbiter of whether the roadmap aligns with Ethereum's vision (his vision).

Every Successful Product Begins with a Vision

If I think viewing Vitalik as Ethereum's CTO is not controversial enough, then here comes the most controversial part: We should embrace Vitalik as the CTO.

As a founder of a startup, I believe that every successful product must have a coherent long-term vision—yes, Ethereum is also a "product" because it solves real problems for real users. And a coherent vision must be set by a few people, typically just one founder.

The beauty of Ethereum is that, despite being a very complex system with so many components, all the components fit together perfectly to form a well-functioning decentralized computer that settles transactions worth billions of dollars every day.

We have come this far not through some committee's design of solutions, but because Vitalik played a proactive leadership role with his foresight, allowing us to build the coherent and beautiful Ethereum we have today. Ethereum is the idea that Vitalik proposed in 2015, and it still is.

Of course, this is not meant to diminish the contributions of other researchers and engineers, who have made most of the contributions to Ethereum's achievements today. However, this does not contradict the fact that Ethereum is the realization of Vitalik's vision, which is magnitudes larger than anyone else's vision.

To be honest, can you complain about this? When you are attracted by the openness, censorship-resistance, and speed of innovation of the Ethereum ecosystem, have you ever complained that it started with Vitalik's vision? Perhaps you haven't complained because you haven't thought about it that way—but now you have, but do you really care about this issue?

How Does Decentralization Fit In?

But you might ask, what about decentralization? If one person has such overwhelming power over Ethereum, how can we say it is decentralized?

To answer this question, we must revisit Vitalik's classic article on the meaning of decentralization. The key insight of the article is that there are three types of decentralization:

• Architectural Decentralization: How many node failures will cause the system to stop operating?
• Logical Decentralization: Can the various subsystems of the system develop independently while allowing the system as a whole to operate normally? Or must they coordinate closely?
• Political Decentralization: Ultimately, how many people or organizations control this system?

Based on these definitions, Ethereum is clearly architecturally decentralized, and it can be argued that it is also logically decentralized, as there is a lack of strong coupling between its various components (for example, the consensus layer and the execution layer).

In terms of political decentralization, the good news is that no individual or organization can shut down Ethereum, not even Vitalik. However, some may argue that the degree of political decentralization in Ethereum is not as high as people imagine, as Vitalik plays a significant role in defining 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 "rigid" like Bitcoin, becoming an almost unchangeable blockchain, then Vitalik might directly retire. But before we reach that final step, it is crucial to have an authority that is respected by all parties, one that is trustworthy and capable of making judgments on technical decisions, not only based on whether the proposed technical solutions are superior but also based on whether those decisions align with Ethereum's vision.

Without someone like Vitalik, there are only two possible outcomes, vividly illustrated by the story surrounding 3074:

• The Ethereum governance process may fall into an endless deadlock, with both sides unwilling to compromise and no one able to make progress, as indicated by the deadlock in the 3074 debate before Vitalik intervened.
• Or, Ethereum may become a poorly designed "Frankenstein." The aforementioned 3074 and 4337 could become irreconcilable, ultimately leading to the AA ecosystem being split into two incompatible parallel spaces.

The Role of the Community

After the above reflections, we are close to outlining a complete model of Ethereum governance, but so far, there is a noticeable omission in our discussion—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 is not doing nothing?

Fortunately, the community actually plays the most important role. The reason is that before there is a vision, there are values. We come together to form a community because we unite around certain values, and Vitalik's vision must ultimately align with these values; otherwise, it will lose the support of the community.

Everyone in the Ethereum community believes that having a decentralized computer that is accessible to all, censorship-resistant, and trustlessly neutral is beneficial to the world. We uphold and affirm these values through the work we do on Ethereum every day, thereby providing legitimacy to the vision, roadmap, and code set forth by Vitalik, researchers, and core developers.

The VVRC Model of Ethereum Governance

Thus, here is the complete thinking model of Ethereum governance, Values ⇒ Vision ⇒ Roadmap ⇒ Clients, abbreviated as VVRC:

• V == Values == Community;
• V == Vision == Vitalik;
• R == Roadmap == Researchers;
• C == Clients == Core Developers;

Together, they play the following roles:

• The community coalesces around certain specific values.
• Vitalik expresses a vision that aligns with these values.
• Researchers formulate a roadmap based on the vision.
• Core developers implement the client based on the roadmap.

Of course, reality is far more complex than any simple model can capture. In fact, Ethereum core developers are the only ones who can truly "vote" on any proposal through changes to the client code. Vitalik and other researchers only serve in an advisory capacity, and sometimes their opinions are not accepted by core developers, which is precisely why EIP-3074 was approved.

That said, I believe the VVRC model reasonably captures how Ethereum's governance model typically operates, and we need to "debug" this process to prevent incidents like EIP-3074 from occurring again.

How to Improve Ethereum's Governance Model

Now that we have a mental model of how the Ethereum governance process works, here are a few ideas for improving the governance process.

The visibility of the discussion progress of EIPs under review must be improved. The entire community should not be caught off guard by the acceptance of an EIP; unexpected approvals like that of 3074 should not happen again.

Currently, the "status" of EIPs on the EIP website does not reflect their status in the ACD process. This is why it still says 3074 is in "review" status, even though core developers have voted to approve it, with no indication that it was considered for approval from the start.

Ideally, when an EIP is about to be accepted, the Ethereum Foundation should publicly announce the outcome clearly on social media to raise community awareness.

Sometimes core developers may underestimate the impact of a specific EIP 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 to coordinate across time zones, often only "relevant parties" can speak.

That said, occasionally allocating some speaking time for community members to comment on the downstream impacts of certain EIP proposals after they pass is also meaningful.

If researchers feel that their opinions are not being accepted by core developers, as was the case with 4337, they can invite community members to participate to strengthen their arguments.

It is crucial that core developers and researchers mutually acknowledge that, despite their differing strengths, they are both part of Ethereum's governance power. Core developers' authority to make changes and updates to the Ethereum client is the only power that can give a "vote" by changing the protocol itself. Researchers typically have more public support for changes and interpretations of the roadmap, thanks to their active discussions and writings about their ideas.

When these two powers clash, core developers may be inclined to directly overturn researchers' opinions, as core developers did with the opposition from the 4337 team. However, such overturning can lead to conflict, as instability arises when the two powers clash, as evidenced by the dramatic events that occurred after 3074 was approved.

Similarly, when faced with resistance, researchers may be inclined to abandon collaboration with core developers, which I believe is one of the reasons for creating the RIP process and why the native AA (7560) is now primarily promoted as a RIP rather than an EIP.

While experimenting with those controversial protocol updates on L2 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 parties' values fully align with the roadmap.

Conclusion

The 3074/7702 incident reveals the true workings of Ethereum governance—beyond the explicit governance power driven by core developers through the EIP/ACD process, there is also the implicit governance power driven by researchers through the roadmap. When these powers are misaligned, we see deadlocks and pushes, and another force—Vitalik—may be needed to break the balance in some way.

We propose that Vitalik represents a unique force, the "vision" of Ethereum, which is the foundation of any roadmap's legitimacy. We compare Vitalik to the CTO of a large company and acknowledge that his role as a de facto CTO is necessary for Ethereum to maintain its pace of innovation, preventing it from devolving into a "Frankenstein" of stitched-together parts.

Finally, we propose a VVRC model that describes the Ethereum governance model: Values (Community) ⇒ Vision (Vitalik) ⇒ Roadmap (Researchers) ⇒ Clients (Core Developers). We then suggest various ways to fix the "errors" in this model.

Ethereum governance is the "machine that makes the machine"—to ensure Ethereum operates correctly, we must govern it reasonably. Therefore, 3074 provides a valuable case for governance incidents, and I hope the Ethereum community can draw some useful lessons from it to improve future Ethereum governance processes.