A deep dive into the impact of Vitalik and various roadmaps on Ethereum governance

Original title: Reflections on Ethereum Governance Following the 3074 Saga
Original author: Derek Chiang, founder of ZeroDev

Original translation: Faust, geek web3

Abstract: This article is the opinion of ZeroDev CEO Derek Chiang on the matter after Vitalik proposed EIP-7702 to balance the contradiction between ERC-4337 and EIP-3074. Based on the personal experience of a founder of a project in the AA ecosystem, the article objectively points out the current governance model and pain points of Ethereum, and points out incisively:

One of the various governance contradictions in Ethereum is that the roadmap determined by the researchers is at odds with the views of client development teams such as Geth, and Vitalik has become the final decision-maker in a similar capacity as a CTO.

After giving a positive evaluation of Vitalik's role, Derek pointed out what improvements Ethereum should make in the governance model, which is of great reference significance to both the Ethereum community and the Bitcoin community.

Text: If you don't know about the events related to Ethereum AA (account abstraction) before, here is a brief review:

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

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

In early May, Vitalik proposed EIP-7702 as a replacement for EIP-3074, striking a balance between 4337 and 3074 - bringing the AA experience to EOA users, but in a way that is more compatible with ERC-4337 and compatible with the "AA final solution" 7560.

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

Personally, I am very satisfied with this 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, which many people have pointed out in the past few weeks. I feel that if there was a better governance process, we could have saved a lot of energy and achieved the desired results faster.

In this post, I want to:

· Identify what went wrong in the governance process

· Propose a mental model for thinking about Ethereum governance

· Propose improvements to avoid similar governance accidents in the future

Summary and reflection on the EIP-3074 incident

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

It took years for EIP-3074 to be approved. After 3074 was finally approved, Ethereum core developers received strong opposition from the 4337 community.

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

There is nothing inherently wrong with any of the above processes:

· It is normal for discussions about an EIP to take several years.

· It is normal for an EIP to be rejected after it is approved.

· Approval can be revoked after an EIP is approved if new problems are discovered.

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

When discussing 3074, the 4337 community actively interacted with Ethereum core developers. If this premise is true, there are only two outcomes:

· 3074 is approved (and possibly modified) after taking into account 4337 community feedback, in which case 3074 is accepted by the 4337 community and the Ethereum core team does not have to withdraw 3074.

· Or, 3074 is never approved, but the 4337 community and the Ethereum core team come up with a proposal that satisfies everyone, just like 7702.

Everyone’s voice is heard, and there are no dramatic reversals. This would have been great — so why didn’t it happen?

What went wrong?

Looking back on the whole thing, both sides of the incident blamed each other.

Ethereum core developers (and the authors of EIP-3074) believe that this is the fault of "4337 supporters" because they did not actively participate in the All Core Developers (ACD) discussion process, in which EIPs need to undergo long deliberations before they are finally accepted and implemented by Ethereum client development teams such as Geth.

Some people believe that "4337 supporters" could have participated and expressed their views during the deliberation of the 3074 proposal, rather than waiting until 3074 was approved. After all, the entire ACD process is well documented, the meetings are open to everyone, and people like TimBeiko actively post summary tweets after each ACD meeting. So if 4337 supporters care so much about this topic, why don't they actively and promptly participate in relevant meetings?

On the other hand, 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, most of them felt that it was unexpected - many people thought that 3074 was dead, and did not even know that 3074 was likely to be approved.

Many people pointed out that the entire process of the ACD meeting was very opaque, which was not friendly to those who "did things seriously" in the Ethereum community but could not keep up with the progress of ACD updates in a timely manner. Some people also believed that ACD should actively seek feedback from stakeholders (here referring to the 4337 community).

However, I think both sides missed the point. There is a deeper problem behind this. Unless we solve or at least acknowledge this problem, we will continue to fall into governance accidents, and then the conflicting parties will blame each other, but this is meaningless.

The root cause of the governance incident: the roadmap

Contrary to popular belief, the root cause of the governance incident is that the ACD is not the only source of governance power for Ethereum protocol updates, and it is replaced by another source of governance power. The problem here is that this other governance power is rarely acknowledged, even though it has more influence than the ACD on core Ethereum issues such as AA and scalability.

In this article, I will call this power "the roadmap".

As I will point out below, the entire "3074-4337-7702" governance failure incident is a case of the power of Ethereum's existing roadmap overwhelmed the power of the ACD. If we are talking about governance, when we notice that there is an invisible force overwhelmed by the visible force, we should be extremely worried about it, because invisible things are often difficult to explain and cannot be noticed by too many people, so they must be exposed.

What is a roadmap?

Anyone in the Ethereum community must have seen the term “roadmap” often, such as in “rollup-centric roadmap”, “ETH2.0 roadmap”, or in this case, “AA roadmap”.

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

· Bob, a core developer: I support EIP-1234, which proposes that we speed up block generation 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 just proposed a seemingly very reasonable way to expand capacity. Solana, Aptos, Sui and many other public chains have done so and achieved high TPS.

The reason is that this fictitious EIP-1234 violates Ethereum's "rollup-centric" expansion roadmap, which points out that it is crucial for decentralization that ordinary users can run nodes at low cost, so the fictitious EIP-1234 cannot be accepted because it will greatly increase the cost of running Ethereum nodes.

I want to use this example to illustrate that core developers who participate in the ACD governance process and decide on protocol updates are guided by a higher power, which I call the "roadmap". Currently, there are "scaling roadmaps", "AA roadmaps", "MEV roadmaps", etc. around Ethereum. Together, they form the overall roadmap of Ethereum, and core developers must make decisions based on this.

When the views of core developers are inconsistent with the roadmap

Since the roadmap is not a formal part of the Ethereum governance process, there is often no guarantee that the core team will adhere to the roadmap. Moreover, there is no formal process for "approving" roadmaps, so not all roadmaps have the same "legitimacy". The researchers behind the Ethereum roadmap must work hard to promote their roadmaps to the core developers and the community in order to gain "legitimacy" and thus gain the support of the Ethereum core development team.

In terms of AA and account abstraction, Vitalik himself has pushed for a 4337-centric AA roadmap on several occasions, but overall it was mainly the team behind 4337, especially Yoav and Dror, who advocated for a 4337-centric AA roadmap in forums and ACD meetings.

However, despite these efforts, some Ethereum core developers still strongly opposed the 4337-centric AA roadmap. They believed that 7560 (the native version of 4337 to be implemented by Ethereum clients in the future) was too complex and was not the only viable solution for "AA finality". In the end, ACD decided to approve proposal 3074, despite opposition from the 4337 team, who believed that 3074 would fragment the entire AA ecosystem.

After 3074 was approved, the entire 4337 community reacted strongly, forcing Ethereum core developers to re-engage in the discussion of 3074. The discussion then reached a stalemate, with neither the author of 4337 nor the author of 3074 able to convince the other, and Vitalik proposed EIP-7702 as an alternative to 3074 at the last minute, which was explicitly compatible with the "AA endgame" centered on 4337, thereby resolving the conflict and making the final result fit the AA roadmap.

Vitalik’s Role: Ethereum’s De Facto CTO

Although Vitalik considers himself a researcher, the above story clearly shows that Vitalik has governance powers that are very different from other researchers. So the question is: what role does Vitalik play in Ethereum governance?

Personally, I think it’s probably okay to think of Vitalik as the CTO of a very, very large company (assuming, by the way, that Ethereum “company” has no CEO for the sake of reality)

If you’ve ever worked at a tech company with more than 50 employees, you know that the CTO can’t be involved in every technical decision. When a company reaches a certain size, the decision-making process for various technical solutions must become decentralized - usually each area of the company’s product/business has a dedicated team, and this team is usually free to decide the details of the solution.

Also, the 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 areas, so it is often the individual engineers who make the final decision on the technical details of the plan.

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

While this is not a perfect analogy, I think it reasonably summarizes Vitalik's role in the Ethereum ecosystem. Vitalik will not participate in every technical decision - nor can he participate. He is not a top expert in every field. But he has an overwhelming influence on the roadmap for all key solutions of Ethereum (scaling, AA, POS...), not only because of his technical expertise, but also because he is the final judge of "whether the roadmap is in line with the Ethereum vision (his vision)".

Every successful product starts with a vision

If my belief that Vitalik is the CTO of Ethereum isn’t controversial enough, here comes the most controversial part: We should embrace Vitalik as CTO.

As a startup founder, I believe that every successful product must have a coherent long-term vision behind it — yes, Ethereum is a “product” because it solves real problems for real users. And a coherent vision must be developed by a small number of people, such as the founders of a startup, and usually only one founder.

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

We didn’t get to where we are today through some committee scheme, but it was because of Vitalik’s active leadership with his vision that we were able to build the coherent and beautiful Ethereum that it is today. Ethereum was Vitalik’s idea in 2015, and it remains so today.

Of course, this is not to discount the contributions of other researchers and engineers who have contributed much of what makes Ethereum what it is today. However, it is not a contradiction, as Ethereum is the realization of Vitalik’s vision, orders of magnitude greater than anyone else’s.

Honestly, can you complain about that? While you are attracted to the openness, censorship resistance, and speed of innovation of the Ethereum ecosystem, have you ever complained that it started with Vitalik’s vision? Maybe you didn’t complain because you didn’t think about it that way – but now you have, do you really mind this question?

How about decentralization?

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

To answer this question, we have to go back to this classic article on the meaning of decentralization, written by Vitalik. The key insight of the article is that there are three types of decentralization:

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

· Logical decentralization: Can the various subsystems of the system evolve independently while still allowing the system as a whole to function properly? Or do they have to be tightly coordinated?

· Political Decentralization: How many people or organizations ultimately control the system?

By these definitions, Ethereum is clearly architecturally decentralized, and it can be argued that it is also logically decentralized due to the lack of strong coupling between its components (e.g. consensus layer vs. execution layer).

In terms of political decentralization, the good news is that no single person or organization can shut down Ethereum, not even Vitalik. However, one could argue that Ethereum is not as politically decentralized as people think, given Vitalik’s role in developing the Ethereum vision and roadmap.

However, I believe that if we want Ethereum to continue to innovate, we must accept Vitalik as the de facto CTO, even if it means sacrificing some political decentralization.

If Ethereum really "ossifies" into a nearly immutable blockchain like Bitcoin, then Vitalik may simply retire. But before we reach that final step, it is crucial to have an authority that all parties respect, and that is trusted to make judgments on technical decisions based not only on whether the proposed technical solutions are superior, but also on whether these decisions are consistent with the vision of Ethereum.

Without a figure like Vitalik, there are only two possible outcomes, and the story around 3074 vividly illustrates both of these outcomes:

· The Ethereum governance process may fall into an endless deadlock, with neither side willing to compromise and no one able to make progress, as the 3074 debate was deadlocked before Vitalik intervened.

· Or, Ethereum may become a Frankenstein with an incoherent design. The aforementioned 3074 and 4337 may not give in to each other, and finally let the AA ecosystem be completely split into two incompatible parallel spaces.

The role of the community

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

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

Fortunately, the community actually plays the most important role. The reason is that before there is a vision, there are values. We come together as a community because we unite around certain values, and Vitalik's vision must ultimately align with those values, or it will fall out of favor with the community.

All of us in the Ethereum community believe that having a decentralized computer that is accessible to everyone, uncensorable, and trustworthy and neutral is good for the world. We uphold and affirm the above values every day through the work we do on Ethereum, and in doing so provide legitimacy to the vision, roadmap, and code set by Vitalik, the researchers, and the core developers.

The VVRC Model of Ethereum Governance

So here’s the full mental model of Ethereum governance, Values ⇒ Vision ⇒ Roadmap ⇒ Clients, or VVRC for short:

· V==Values==Community;

· V==Vision==Vitalik;

· R==Roadmap==Researchers;

· C==Clients==Core Developers;

Together they work as follows:

· The community coalesces around certain specific values.

· Vitalik expresses a vision that aligns with those values.

· Researchers develop 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. In reality, Ethereum core developers are the only ones who can actually “vote” on any proposals through changes to the client code. Vitalik and other researchers only act as advisors, and sometimes their opinions are not accepted by the core developers, which is exactly how EIP-3074 was approved.

That being said, I think the VVRC model reasonably captures how Ethereum’s governance model works in general, and we need to “debug” the process so that it does not recur to accidents like EIP-3074.

How to Improve Ethereum’s Governance Model

Now that we have a mental model of how Ethereum’s governance process works, here are a few ideas to improve it.

Visibility into the progress of discussions on EIPs under consideration must be improved. The community should not be “surprised” that an EIP is accepted, and proposals approved in a way that surprises people like 3074 should not happen again.

The current "status" of an EIP on the EIP website does not reflect its status in the ACD process. This is why it still says 3074 is in "under review" even though the core developers have voted to approve it and there is no indication that it was even considered for approval in the first place.

Ideally, when an EIP is about to be accepted, the Ethereum Foundation would announce the result loudly and clearly on social media to increase community awareness.

Sometimes core developers may underestimate the impact of a particular EIP on downstream projects and users, as was the case with the 3074 and 4337 communities. Since ACD meetings are limited in time and must be coordinated across time zones, meetings are often limited to “relevant people” speaking.

That being said, it makes sense to occasionally allocate some speaking time for community members to comment on the downstream impact of certain EIP proposals if they are passed.

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

It is crucial that core developers and researchers recognize each other that they are all part of the Ethereum governance power despite their different power levels. The core developers’ power to change and update the Ethereum client is the only power that can give a “vote” by making changes to the protocol itself. Researchers’ power to change and interpret the roadmap often has more public support, thanks to researchers actively talking and writing about their ideas.

When these two forces conflict, core developers may be tempted to simply overrule researchers, such as when core developers overruled the 4337 team’s objections. However, such overruling can lead to conflict, as two forces can become unstable when they conflict, as the drama that followed the approval of 3074 demonstrated.

Similarly, when faced with resistance, researchers may be tempted to abandon collaboration with core developers, which in my opinion is one of the reasons the RIP process was created and why native AA(7560) is now primarily promoted as a RIP rather than an EIP.

While there are certainly benefits to experimenting with protocol updates on L2 that are controversial for L1, we cannot view RIPs as a substitute for participating in the EIP governance process. Researchers must continue to work with core developers until both parties’ values are fully aligned with the roadmap.

Conclusion

The 3074/7702 incident reveals how Ethereum governance really works - 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 misplaced, we see deadlock and whipsaws, and another force - Vitalik - may be needed to somehow break the balance.

We then propose that Vitalik represents a unique force, the "vision" of Ethereum, which is the basis for the legitimacy of any roadmap. We compare Vitalik to the CTO of a large company and acknowledge that his role as a pseudo-CTO is necessary for Ethereum to maintain its pace of innovation, which can prevent Ethereum from degenerating into a "Frankenstein"-like patchwork monster.

Finally, we proposed a VVRC model that describes the Ethereum governance model: Values (community) ⇒ Vision (Vitalik) ⇒ Roadmap (researchers) ⇒ Clients (core developers). We then proposed various ways to fix the "bugs" of this model.

Ethereum governance is the "machine that makes the machine" - for Ethereum to work correctly, we must have reasonable governance. Therefore, 3074 provides a valuable case for governance accidents, and I hope that the Ethereum community can learn some useful lessons from it in order to improve the future Ethereum governance process.

Original link

欢迎加入律动 BlockBeats 官方社群：

Telegram 订阅群： https://t.me/theblockbeats

Telegram 交流群： https://t.me/BlockBeats_App

Twitter 官方账号： https://twitter.com/BlockBeatsAsia