The impact of Vitalik and various roadmaps on the governance process of Ethereum.

Original author: Derek Chiang, CEO of ZeroDev

Faust, Geek web3

Abstract: This article is the CEO Derek Chiang’s opinion on the matter after V God proposed EIP-7702 to balance the contradiction between ERC-4337 and EIP-3074. The article objectively points out the current governance model and pain points of Ethereum from the perspective of a project founder in the AA ecosystem, and pointedly states:

One of the governance contradictions in Ethereum is the divergence between the roadmap determined by researchers and the views of client development teams such as Geth. Vitalik, in a role similar to that of CTO, has become the final arbiter.

Derek gave a positive evaluation of Vitalik’s role and pointed out what improvements Ethereum should make in its governance model, which is very meaningful for both the Ethereum community and the Bitcoin community.

Text: If you were not previously familiar with the events related to Ethereum AA (Account Abstraction), here is a brief review:

A few weeks ago, the EIP-3074 proposal was approved by the Ethereum core developers to be included in the next hard fork “Pectra”. The proposal will bring two new opcodes to the EVM, allowing Ethereum EOA accounts to have a near-native AA experience.

Since then, many people in the ERC-4337 community, especially the proposers of 4337, have been strongly opposed to EIP-3074, fearing that it will bring many security risks and be incompatible with Ethereum’s AA roadmap. In Ethereum’s previous roadmap, it was explicitly stated that ERC-4337 and similar proposals 7560 (also known as “nativeAA”) are central.

In early May, Vitalik proposed EIP-7702 as an alternative to EIP-3074, finding a balance between 4337 and 3074 - it brings AA experience to EOA users, but is somewhat more compatible with ERC-4337 and compatible with “AA Final Solution” 7560 to some extent.

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

Personally, I am very satisfied with the result: 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 can have a better way to achieve the above results. Many people have pointed this out in the past few weeks. I think that with a better governance process, we could save a lot of energy and achieve the expected results more quickly.

“In this article, I want to:”

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

Summary and Reflection on EIP-3074 Event

The story mentioned earlier made many people unhappy for the following reasons:

EIP-3074 took years to get approved. After 3074 was finally approved, Ethereum core developers faced strong opposition from the 4337 community.

On the other hand, the authors of ERC-4337 have expressed their concerns about EIP-3074 to the Ethereum core team longest, but to no avail. Now Ethereum is planning to unapprove 3074 and replace it with another EIP (7702).

At any point in the above process, there is basically nothing wrong:

• Discussion of an EIP may take a few years, which is normal.
• It’s normal for EIP to be rejected after approval.
• If new issues are discovered, the approval can be revoked after the EIP is approved.

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

When discussing 3074, the 4337 community actively interacts with the core developers of Ethereum. If this assumption holds, there are only two possible outcomes next:

• After considering the feedback from 4337 communities, proposal 3074 has been approved (and may be modified). In this case, the 4337 community will accept 3074, and the Ethereum core team does not need to withdraw 3074.
• Alternatively, 3074 has never been approved, but 4337 the community and the Ethereum core team have jointly put forward a proposal that satisfies everyone, just like 7702.

Everyone’s voice can be heard, and there are no dramatic reversals. This would be great - so why isn’t it?

What went wrong?

Looking back at the whole process, both sides have been blaming each other.

Ethereum core developers (and authors of EIP-3074) believe this is a mistake by “4337 supporters” as they have not actively participated in the All Core Developers (ACD) discussion process, in which EIPs undergo lengthy deliberation before being accepted and implemented by Ethereum client development teams like Geth.

Some believe that during the 3074 proposal deliberation, the “4337 supporters” could have participated and voiced their opinions, instead of waiting until 3074 has been approved to make retrospective comments. After all, the entire ACD process is transparent, meetings are open to everyone, and individuals like TimBeiko actively post summary tweets after each ACD meeting. So, if the 4337 supporters care so much about this issue, why aren’t they actively and promptly participating in the relevant meetings?

On the other hand, the core members of 4337 pointed out that they have been attending ACD meetings and opposing 3074 as much as possible, but Ethereum core developers did not listen. As for the 4337 community members, many of them were caught off guard - many people thought that 3074 was already dead and didn’t even know that there was a high probability of its approval.

Many have pointed out that the entire process of the ACD conference is not very transparent and is not friendly to those who are “doing serious work” in the Ethereum community but cannot keep up with the ACD update progress in a timely manner. Some even believe that ACD should take the initiative to actively solicit feedback from stakeholders (here referring to the 4337 community).

However, I don’t think either side has hit the nail on the head. There are deeper issues at play here, and unless we address or at least acknowledge this, we will continue to be embroiled in governance mishaps, with both sides futilely blaming each other, which serves no purpose.

The root cause of incident governance: roadmap

Contrary to popular belief, the root cause of governance accidents lies in the fact that ACD is not the sole source of governance rights for Ethereum protocol updates. It has been replaced by another source of governance rights. The problem here is that, despite the fact that the influence of this other governance authority on core issues of Ethereum, such as AA and scalability, is greater than that of ACD, it is rarely acknowledged.

In this article, I will refer to this power as “roadmap”.

As I will point out below, the entire “3074-4337-7702” governance failure incident is a case of Ethereum’s existing roadmap power overwhelming the power of ACD. If we are talking about governance, when we notice that an intangible force overwhelms a tangible force, we should be extremely concerned, because intangible things are often difficult to explain and cannot be noticed by too many people, so they must be exposed.

What is the roadmap?

Anyone in the Ethereum community must have often seen the term “roadmap,” such as in “Aggregation-Centric Roadmap,” “ETH 2.0 Roadmap,” or the “AA Roadmap” related to this event.

To illustrate my point, let’s imagine a scene at the ACD conference where core developers are discussing how to scale Ethereum.

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

Let’s think about it. Why did the Ethereum core team refuse what Bob said? He just proposed a seemingly very reasonable way to expand, Solana, Aptos, Sui, and many other public chains have done this and achieved very high TPS.

The reason is that this fictitious EIP-1234 violates Ethereum’s “rollup-centric” scaling roadmap, which indicates that for decentralization, it is crucial for ordinary users to be able to run nodes at low cost. Therefore, the fictitious EIP-1234 cannot be accepted as it would significantly increase the cost of running Ethereum nodes.

I want to use this example to illustrate that the core developers participating in the ACD governance process and deciding on protocol updates are guided by a higher power, which I call the “roadmap.” Currently, there are various roadmaps around Ethereum, such as the “scaling roadmap,” “AA roadmap,” “MEV roadmap,” etc., which together form the overall roadmap of Ethereum. Core developers must make decisions based on this.

When the views of core developers are not aligned with the roadmap

Since the roadmap is not a formal part of the Ethereum governance process, it is often not guaranteed that the core team will adhere to the roadmap. Additionally, there is no formal process for “approving” the roadmap, so not all roadmaps have the same “orthodoxy”. Researchers behind the Ethereum roadmap must work hard to promote their roadmap to core developers and the community in order to gain “orthodoxy” and support from the Ethereum core development team.

In terms of AA and account abstraction, Vitalik himself has repeatedly pushed for a roadmap centered around 01928374656574839201, but overall, it is the team behind 01928374656574839201, especially Yoav and Dror, who advocate for a 01928374656574839201-centric AA roadmap on forums and ACD conferences.

However, despite these efforts, some Ethereum core developers still strongly oppose the 4337-centric AA roadmap. They believe that 7560 (the native version of 4337 to be implemented in the future Ethereum clients) is too complex and not the only viable solution for the “AA endgame.” Ultimately, ACD decided to approve proposal 3074, despite opposition from the 4337 team, which believes that 3074 would fracture the entire AA ecosystem.

After approval, the entire Ethereum community (Ethereum Improvement Proposal) made a strong response, forcing the core developers of Ethereum to re-engage in the discussion of EIP-3074. The discussion subsequently reached a deadlock, with the authors of EIP-4337 and EIP-3074 unable to persuade each other. Vitalik proposed EIP-7702 as an alternative solution for EIP-3074 at the last moment, which explicitly accommodates the “AA Finality” centered on EIP-4337, thereby resolving the conflict and ensuring that the final result aligns with the AA roadmap.

Vitalik’s Role: The Essential CTO of Ethereum

Despite presenting himself as a researcher, the above story clearly demonstrates that Vitalik has governance power that is fundamentally different from that of other researchers. So the question is: what role does Vitalik play in Ethereum governance?

Personally, I think it may not be inappropriate to regard Vitalik as the CTO of a very, very large company (by the way, to be realistic, assuming Ethereum as this “company” has no CEO).

If you’ve ever worked in a tech company with over 50 employees, you’ll know that the CTO can’t be involved in every technical decision. As the company grows, the decision-making process for various technical solutions inevitably becomes decentralized - typically, each area of the company’s product/business has a dedicated team that can freely decide on the details of the solutions.

In addition, the CTO is not necessarily the top expert in all (or any) topics. There may be some engineers in the company who are better than the CTO in specific areas. Therefore, in the discussion of technical details, it is often the individual engineers who make the final decisions.

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

Although this is not a perfect analogy, I think it reasonably summarizes Vitalik’s role in the Ethereum ecosystem. Vitalik does not participate in every technical decision - nor could he. He is also not the top expert in every field. But he has overwhelming influence over the roadmap for all key Ethereum initiatives (scaling, AA, POS, etc.), not just because of his technical expertise but also because he is the ultimate judge of whether the roadmap aligns with the Ethereum vision (his vision).

Every successful product starts with a vision

If I don’t think Vitalik is controversial enough as the CTO of Ethereum, the most controversial part is coming: we should embrace Vitalik as the CTO.

As a founder of a startup, I believe that behind every successful product, there must be 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 formulated by a few people, such as the founder of a startup, and usually only one founder.

The beauty of Ethereum lies in the fact that, despite being a very complex system with so many components, each component perfectly combines to form a well-functioning decentralized computer that settles billions of dollars’ worth of transactions every day.

We have come to this day not through the design of some committee’s plan, but because Vitalik has played an active leadership role with his vision and insight, allowing us to create the coherent and beautiful Ethereum we have today. Ethereum was conceived by Vitalik in 2015 and remains so to this day.

Of course, this is not to belittle the contributions of other researchers and engineers, who have made the majority of the contributions to Ethereum’s achievements today. However, this is not contradictory, because Ethereum is the realization of Vitalik’s vision, which is several orders of magnitude larger than anyone else’s vision.

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

How to solve Decentralization?

But, you might ask, what about decentralization? How can we say that Ethereum is decentralized if one person has such overwhelming power over Ether?

To answer this question, we must review this classic article on the meaning of decentralization, written by Vitalik. The key insight of the article is that decentralization comes in three types:

• Decentralized architecture: How many nodes need to fail for the system to stop running?
• Logical Decentralization: Can each subsystem of the system develop independently while ensuring the normal operation of the system as a whole? Or does it need to be closely coordinated?
• Political decentralization: How many people or organizations ultimately control the system?

According to these definitions, Ethereum is clearly decentralized in its architecture, and it can be said that it is also logically decentralized because its components lack strong coupling (such as 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 Ethereum’s level of political decentralization is not as high as imagined, as Vitalik has played 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 really “froze” into an almost immutable blockchain like Bitcoin, Vitalik might just retire. But before we reach that final step, it is crucial to have an authority that is respected by all parties, trustworthy, and capable of making technical decisions not only based on the superiority of the proposed technical solutions, but also on whether these decisions align with Ethereum’s vision.

If there were no figures like Vitalik, then only two results would be possible, vividly illustrating these two results around the story of 01928374656574839201.

• The Ethereum governance process may fall into an endless deadlock, with both conflicting parties unwilling to compromise and no one making progress, just as the 3074 debate stalled before Vitalik intervened.
• Alternatively, Ethereum could become a design-inconsistent “Frankenstein” (translator’s note: a monster depicted in the science fiction novel “Frankenstein”, created by a scientist piecing together parts from different corpses to form a “person”). The previously mentioned 3074 and 4337 may be mutually exclusive, ultimately causing the AA ecosystem to completely split into two incompatible parallel spaces.

Role of the Community

After the above thinking, we are about to outline a complete Ethereum governance mindset, but so far, there is a clear omission in our discussion - the community.

If Vitalik defines the vision of Ethereum, researchers define the roadmap, and core developers implement the roadmap, then what role does the community play? Definitely not doing nothing, right?

Fortunately, the community actually plays the most important role. The reason is that there are values before there is a vision. 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.

The entire Ethereum community believes that having a decentralized computer that is accessible to everyone, uncensored, and trustworthy is beneficial to the world. We maintain and affirm these values every day through our work on Ethereum, lending legitimacy to the vision, roadmap, and code set by Vitalik, researchers, and core developers.

Ethereum Governance VVRC Model

Therefore, here is the complete conceptual model of Ethereum governance, values⇒vision⇒roadmap⇒client, referred to as VVRC:

• V==Values==Community；
• V==Vision==Vitalik;
• R==Roadmap==Researchers;
• C==Client==core developers；

They worked together to play the following roles:

• The community coalesces around certain specific values. *Vitalik expressed a vision consistent with these values.
• Researchers develop roadmaps based on vision.
• The core developers implement the client according to the roadmap.

Of course, reality is much more complex than any simple model can capture. In fact, Ethereum core developers are the only ones who can truly “vote” on any proposal by making changes to the client code. Vitalik and other researchers only act as advisors, and sometimes their opinions are not accepted by core developers, which is exactly why EIP-3074 was approved.

However, I believe that the VVRC model reasonably captures the usual operation of Ethereum’s governance model, and we need to “debug” this process to prevent accidents like EIP-3074 from happening again.

How to Improve the Governance Model of Ethereum

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

• The visibility of the discussion progress of the EIP under review must be improved. The entire community should not be “surprised” by the acceptance of the EIP, and unexpected approval methods like 3074 should not occur again.

Currently, the “status” of the EIP on the EIP website does not reflect its status in the ACD process. That’s why it still says that EIP 3074 is in the “under review” status, even though the core developers have already voted to approve it, and there is no indication that it was considered for approval from the beginning.

Ideally, when EIP is about to be accepted, the Ethereum Foundation should make a clear announcement on social media to increase community awareness.

• Sometimes core developers may underestimate the impact of certain EIPs on downstream projects and users, as is the case with the 3074 and 4337 communities. Due to the limited time of the ACD meeting and the need for cross-time zone coordination, only “relevant personnel” can speak at the meeting.

However, occasionally allocating some speaking time to community members and commenting on the impact of certain EIP proposals on downstream after their approval is also meaningful.

If researchers feel that their opinions are not being accepted by core developers, as in the case of 01928374656574839201, they can engage community members to strengthen their advocacy.

• It is essential that core developers and researchers must acknowledge each other. Despite different strengths, they are both part of the Ethereum governance. Core developers have the sole power to make changes and updates to Ethereum clients, and the ability to “vote” through changes to the protocol itself. Researchers usually have more public support for changes and interpretations of the roadmap, thanks to their active discussions and documentation of their ideas.

When these two major forces clash, core developers may tend to directly overturn the opinions of researchers, such as core developers overturning the opposition of team 4337. However, such overturning may lead to conflicts, as instability occurs when the two major forces clash, as dramatic events following the approval of 3074 suggest.

Similarly, when facing resistance, researchers may tend to give up cooperation with core developers. In my opinion, this is also one of the reasons for creating the RIP process, and why the native AA (7560) is now mainly promoted as RIP rather than EIP.

Although there are benefits to experimenting with controversial protocol updates on L2 for L1, we cannot consider RIP as a substitute for participating in the EIP governance process. Researchers must continue to collaborate with core developers until both sides’ values align with the roadmap.

Conclusion

The 3074/7702 incident revealed the true operation of Ethereum governance - in addition to the explicit governance power of the EIP/ACD process driven by core developers, there is also the implicit governance power of the roadmap driven by researchers. When these powers are misaligned, we will see deadlock and prodding, and another force - Vitalik - may be needed to somehow break the balance.

Then, we propose that Vitalik represents a unique force, namely the “vision” of Ethereum, which is the foundation 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 innovative pace, preventing Ethereum from degenerating into a “Frankenstein” stitched monster.

Finally, we propose a VVRC model to describe the Ethereum governance model: Values (Community) ⇒ Vision (Vitalik) ⇒ Roadmap (Researchers) ⇒ Client (Core Developers). Then, we propose various methods to fix the “errors” in this model.

Ethereum governance is the “machine that makes machines” - to make Ethereum work correctly, we must govern it reasonably. Therefore, 3074 has provided a valuable case for governance accidents, and I hope that the Ethereum community can learn some useful lessons from it to improve the future Ethereum governance process.

Original text: 原文链接 Translated text: Original Text Link