Vitalik and Yoav kindly reviewed this post, but opinions are my own.

If you haven’t been following the AA drama, here’s a quick recap:

• Several weeks ago, EIP-3074, a proposal that would bring many of the benefits of AA to EOA users, was approved by the core devs to go into “Pectra,” Ethereum’s next hard fork.
• Ever since then, many in the ERC-4337 community, especially the 4337 authors themselves, have been strongly pushing back on 3074, on the grounds of @yoav/3074-implications">centralization concerns and its incompatibility with Ethereum’s @yoav/AA-roadmap-May-2024">AA roadmap, which is centered around 4337 and its cousin 7560 (aka “native AA”).
• Last week, Vitalik proposed EIP-7702 as an alternative to 3074. It mostly achieves the same goal — bringing many benefits of AA to EOA users — but in a way that’s more compatible with 4337 today, and forward-compatible with the “AA endgame” that is 7560.
• At this time, the core devs are deliberating on EIP-7702, but preliminary discussions and community sentiments suggest that EIP-7702 will most likely replace EIP-3074 in Pectra.

Personally, I was very happy with the outcome: EOA users will soon be able to enjoy most of the benefits of AA, using the tooling and infra built for ERC-4337.

And yet, I cannot help but feel that the way in which we achieved this outcome was far from optimal, a view that many had expressed in the past few weeks. I feel that with a better process, we could’ve collectively saved a tremendous amount of energy and headache, and arrived at the desired outcome much sooner.

In this blog post, I want to:

• Identify what went wrong with the process.
• Propose a mental model for thinking about Ethereum governance.
• Suggest improvements for avoiding similar governance failures in the future.

Why the process made people unhappy

This whole saga made a lot of people unhappy for several reasons:

• It took years for 3074 to be approved.
• Only after 3074 was finally approved, did the core devs get a huge ton of pushbacks from the 4337 community.
  • The 4337 authors themselves, on the other hand, had repeatedly voiced their concerns with 3074 to core devs, to no avail.
• Now we are on track to un-approve 3074 and replace it with another EIP (7702).

Now, there’s nothing inherently wrong with any of the above:

• It’s OK for a discussion to take years.
• It’s OK for a EIP to receive pushbacks after it’s approved.
• It’s OK to un-approve a EIP after it’s approved, if new issues are identified.

However, we can probably agree that things could’ve gone more smoothly. Imagine if this is how it went:

• The 4337 community actively engaged the core devs as they were debating 3074. Now, only one of two outcomes is possible:
  • Either 3074 was approved (and possibly modified) after taking the 4337 community feedback into account, in which case the 4337 community would’ve been onboard with 3074 and we wouldn’t be reversing 3074.
  • Or, 3074 was never approved, but the 4337 community and core devs worked together towards a proposal that everyone is happy with, à la 7702.

Everyone’s voice is heard, and there’s no dramatic reversals. That would’ve been nice — so why didn’t it happen?

What went wrong?

Reflecting on the process, both sides of the debate have pointed fingers at each other.

The core devs (and authors of EIP-3074) felt that it was the “4337 people”’s fault that they didn’t actively engage with the All Core Devs (ACD) process, where EIPs are deliberated for a long time before they are finally accepted by the client teams, and thereby implemented into the protocol.

At any point during this deliberation, the argument goes, the “4337 people” could’ve come in and expressed their concerns, as opposed to waiting until after 3074 had already been approved. After all, the ACD process is well-documented, the meetings are open to all, and there are people like Tim Beiko that actively tweet out summaries after every ACD meeting. So if the 4337 people cared so much about this issue, why didn’t they spend the time to engage?

On the other side, the AA team (4337 authors) pointed out that they had been attending ACD meetings and pushed back on 3074 every chance they could, but the core devs didn’t listen. As for the 4337 community, they mostly felt blindsided — most people were under the impression that 3074 was dead, and were not even aware that 3074 was being actively considered for inclusion.

Many people also felt that the ACD process was too opaque and not friendly for participations from people who have “real jobs” and couldn’t afford to keep up with all the ACD updates. Some also felt that it should be the ACD’s responsibility to actively seek feedback from relevant stakeholders, in this case the 4337 community.

It’s my opinion, however, that both sides missed the mark. There’s a much deeper issue at work, and until we fix or at the very least acknowledge the issue, we will keep running into governance failures followed by unproductive finger-pointings.

The Root Cause

The real cause of the governance failure was that, contrary to popular beliefs, the ACD is NOT the only governance power for protocol updates, and in this instance it was overridden by another governance power.

Problematically, the other governance power is rarely acknowledged, despite the fact that it has an even larger influence than ACD on the most important matters of Ethereum, such as AA and scaling.

In this article, I’m going to call this power “roadmaps”.

This whole 3074/7702 saga, as I will argue, is no more and no less than an instance of the power of roadmaps overwhelming the power of ACD. And if we are talking about governance, then any time we notice an invisible power overwhelming a visible power, we should be very concerned, for what’s invisible is unaccountable, and therefore must be brought to light.

What is a roadmap?

Anyone in the Ethereum community must’ve come across the term “roadmap” a lot, such as in the “rollup-centric roadmap,” “ETH 2.0 roadmap,” or in this debate “@yoav/AA-roadmap-May-2024">the AA roadmap.”

A search of “roadmap” on Ethereum Magicians

To illustrate my point, let’s imagine an ACD meeting where the core devs are discussing how to scale Ethereum:

• Core Dev Bob: I support EIP 1234 which proposes that we speed up block time 10X, increase block size 10X & drop fee 100X.
• Other core devs: …are u out of ur * mind?

Let’s think for a second here. Why did the core devs just shot down what Bob said? He just proposed a very legit form of scaling. Solana and many other L1s do it, to great scaling effects.

The reason, of course, is that this imaginary EIP is against Ethereum’s own “rollup-centric” scaling roadmap, which says, among other things, that it’s crucial for blockchain decentralization for regular users to be able to run a node, and therefore the imaginary EIP is out of the question since it would vastly increase the barrier to running a node.

What I wanted to illustrate with this example is that the core devs, who participate in the ACD process and decide on protocol updates, are guided by a higher force that I’m calling the roadmaps. There’s the scaling roadmap, the AA roadmap, the MEV roadmap, you name it — and collectively they form the Ethereum roadmap that the core devs base their decisions off.

When core devs are misaligned with a roadmap

Since roadmaps are not a formal part of governance, there’s no guarantee that core devs are aligned with them. In particular, since there’s no formal process for “approving” a roadmap, not all roadmaps are perceived to have equal legitimacy. It’s up to the researchers behind the roadmaps to diligently champion their roadmaps to the core devs and the larger community, in order to gain legitimacy and therefore buy-in from the core devs.

In the case of AA, Vitalik himself has pushed for a 4337-centric AA roadmap on @vbuterin/account_abstraction_roadmap">multiple occasions, but overall it has mostly been the 4337 team, notably Yoav and Dror, who champion the 4337-centric AA roadmap at conferences, online forums, and ACD meetings.

However, despite these efforts, there were strong oppositions from some core devs against the 4337-centric AA roadmap. They felt that 7560, the native version of 4337 that clients would eventually have to implement, is overly complex and not the only viable candidate for the “AA endgame.” Eventually the ACD decided to approve 3074 despite the 4337 team’s objections that it would fragment the AA ecosystem by creating an alternative and @yoav/3074-implications">less decentralized AA tech stack.

Once 3074 was approved, however, there was a strong reaction from the entire 4337 community, which forced core devs to re-engage in the 3074 debate. The debate then became a stalemate where neither the 4337 authors nor the 3074 authors could convince one another, until Vitalik came in at the eleventh hour and proposed EIP-7702 as an alternative to 3074 that is explicitly compatible with the 4337-centric “AA endgame,” and thereby pushing the conflict in favor of the AA roadmap.

The role of Vitalik

Even though Vitalik carries himself as a researcher, this saga clearly shows that Vitalik brings a qualitatively different governance power to the table than other researchers. So it begs the question — what role does Vitalik play in Ethereum governance?

Personally, I find it helpful to think of Vitalik as the CTO of a very, very large company.

(For the purpose of this analogy, there’s no CEO at this company, by the way.)

If you have worked at any technology company with more than, say, 50 people, you know that the CTO cannot possibly be involved in every technical decision. At a certain scale, technical decisions necessarily become decentralized — there’s typically a sub team for each area of the company’s product, and the sub team is mostly free to make their own decisions regarding specific implementation details.

Furthermore, the CTO is also not necessarily the foremost expert in every (or any) subject matter. There could very well be engineers at a company that are better than the CTO in specific areas. Therefore, in matters of technical debates, it’s frequently the engineers that make the ultimate decisions.

The CTO, however, sets the company’s technical vision. The execution of the vision is left to the devs.

While this is not a perfect analogy, I think it reasonably captures Vitalik’s role in the ecosystem. Vitalik isn’t involved in every technical decision — he can’t possibly be. Nor is he the top expert at every area. But he has an overwhelming influence on setting the roadmaps for all critical aspects of Ethereum (scaling, AA, Proof-of-Stake…), not just because of his technical expertise, but also because he is the ultimate judge for whether a roadmap is consistent with Ethereum’s vision — his vision.

Every successful product starts with a vision

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

It’s my opinion as a startup founder that behind every successful product — and yes Ethereum is a “product” in the sense that it solves real problems for real people — there must be a coherent vision. And a coherent vision must necessarily be set by a small number of people, such as the founders of a startup, and oftentimes just one founder.

The beauty of Ethereum is that, despite it being such a complex system with so many moving parts, the parts fit beautifully together into a functioning decentralized computer that’s moving billions of dollars worth of value every day. And the way we got here was not through design by committees. It is precisely because of Vitalik’s active leadership through his vision that we are able to arrive at a coherent and beautiful product that is Ethereum today. Ethereum was a brainchild of Vitalik in 2015, and it remains so today.

This is not, of course, to downplay the contributions of other researchers and engineers, who deserve most of the credits for getting Ethereum to where it is today. However, that’s not incompatible with the fact that Ethereum is a realization of Vitalik’s vision, orders of magnitude more so than anyone else’s.

And truthfully, can you complain? When you were attracted into the Ethereum ecosystem by its openness, censorship-resistance, and pace of innovation — did you complain that it started with Vitalik’s vision? Maybe you didn’t because you didn’t think of it that way — but now that you do, do you really mind?

What about decentralization?

But but but, you say, what about decentralization? If one person has such overwhelming power over Ethereum, how can we claim that it’s decentralized?

To answer this question, we must go back to @VitalikButerin/the-meaning-of-decentralization-a0c92b76a274">this classic article about the meaning of decentralization, written by, cough cough, Vitalik. The key insight of the article is that there are three types of decentralization:

• Architectural decentralization: how many nodes can be compromised before the system ceases to function?
• Logical decentralization: can the subsystems of the system evolve independently while keeping the system functioning? Or must they be closely coordinated?
• Political decentralization: how many people or organizations ultimately control this system?

Given these definitions, Ethereum is clearly architecturally decentralized, and it’s probably fair to say that it’s also logically decentralized, given the lack of strong coupling between its various components (e.g. consensus vs execution).

In terms of political decentralization, the good news is that no individual or organization can shut down Ethereum, not even Vitalik. However, one could argue that Ethereum is not as politically decentralized as one might think, given the prominent role that Vitalik plays in setting its vision and thereby defining its roadmaps.

However, it’s my opinion that if we want Ethereum to keep innovating, we must embrace Vitalik as the de facto CTO, even if it means sacrificing some political decentralization.

If Ethereum ever “ossifies” into a mostly immutable blockchain like Bitcoin, then Vitalik could retire. But before we reach that endgame, it’s critical that there’s an authority that all sides respect, who is trusted to make judgements on technical decisions not based on technical merits alone, but also on whether they are consistent with Ethereum’s vision.

Without a figure like Vitalik, only two outcomes are possible, both vividly illustrated by this 3074 saga:

• Ethereum governance could dissolve into endless gridlocks where neither side is willing to compromise and no one could make any progress, as seen by how the 3074 debate was at a stalemate until Vitalik came in.
• Or, Ethereum could wound up becoming a Frankenstein monster of incoherent designs, as indicated by how close we were to having 3074 and 4337 serving as two parallel AA stacks that are largely incompatible.

The role of the community

We are very close to having a complete mental model of Ethereum governance, but there’s one glaring omission from our discussion so far — the community.

If Vitalik defines the vision, which are followed by roadmaps defined by researchers, which are in turn implemented by core devs — what role does the community play? Surely not nothing??

Fortunately, the community actually plays the most important role of all. The reason is that before there’s even a vision, there are values. We all came together as a community because we rallied around certain values, which ultimately Vitalik’s vision must be consistent with, or it’d lose the community.

Perhaps it was your upbringing. Perhaps it was something that happened in your last job. But at one point or another, all of us in the Ethereum community decided that it would be good for the world to have a decentralized computer that is accessible to all, that cannot be censored, that is credibly neutral. We assert and affirm these values everyday with the work we do on top of Ethereum, and in doing so we provide legitimacy to the vision, roadmaps, and code produced by Vitalik, researchers, and core devs.

The VVRC model of Ethereum governance

So here, then, is a complete mental model for Ethereum’s governance, which I’m calling the values ⇒ vision ⇒ roadmaps ⇒ clients model, or VVRC for short:

• V == Values == Community
• V == Vision == Vitalik
• R == Roadmaps == Researchers
• C == Clients == Core Devs

Together they work like this:

• The community rallies around certain values.
• Vitalik articulates a vision consistent with these values.
• Researchers come up with roadmaps in accordance with the vision.
• Core devs implement clients based on the roadmaps.

Poorly drawn by the new GPT-4o.
It refused to draw the word “Vitalik” due to “content policy.”

Of course, the reality is way messier than any simple model can capture. For example, core devs in reality are the only people who can “vote” on any decisions, by virtue of implementing the clients. Vitalik and other researchers only serve an advisory role, and sometimes their input is not accepted by the core devs, which was why 3074 was approved.

That said, I think the VVRC model reasonably captures how Ethereum governance works in the happy case, and it’s up to us to “debug” the process so that it doesn’t fail like it did with 3074.

How can we improve Ethereum governance

Now that we have a mental model for how Ethereum governance should work, here are a few ideas for improving the governance process so that we can avoid the kind of whiplash we experienced with 3074/7702.

• There must be more visibility for EIPs that are actively being considered for inclusion. The community at large should never be “caught by surprise” that an EIP is accepted, which was the case with 3074.
  • Contrary to what you might expect, the “status” of a EIP on the EIPs site does not reflect its status in the ACD process. That’s why it still says 3074 is in “Review” even though the core devs had already voted to approve it, and there was even less indication that it was ever being considered for inclusion in the first place.
  • Ideally, EF would make it loud and clear on social media when an EIP is about to be accepted, to increase community awareness.
• Sometimes the core devs can underestimate the impact a particular EIP has for downstream projects & users, which is the case with 3074 and the 4337 community. Since ACD meetings are limited in time and must coordinate across timezones, understandably there’s an emphasis that only “relevant people” should speak at the meetings. That said, it could make sense to allocate some time, every once in a while, for community members to comment on the downstream impact of certain EIP proposals.
  • If researchers feel that their input is not being received by core devs, as was the case with the 4337 team, they could bring community members into the call to strengthen their case.
• Crucially, there must be a mutual recognition between core devs and researchers that they are both governance powers, albeit with different strengths. The “client power” of core devs is the only power that can actually “vote” by virtue of implementing clients. The “roadmap power” of researchers typically enjoys more public support thanks to the researchers actively speaking and writing about their roadmaps.
  • When the two powers are at odds, it can be tempting for the core devs to simply override the researchers, such as when the core devs overrode objections from the 4337 team. However, overriding as such may result in whiplash since the powers are unstable when they are in conflict, as seen from the ensuing drama after 3074 was approved.
  • Similarly, when faced with resistance, it can be tempting for researchers to simply give up engaging with core devs, which IMO is one reason why the RIP process was created and why native AA (7560) is now primarily being pushed as an RIP, not a EIP. While there are real benefits to helping L2s experiment with protocol updates that are too controversial for L1, we cannot view RIPs as a substitute to engaging with the EIP governance process. Researchers must keep on engaging with core devs until they are fully aligned with the roadmaps.

Conclusion

The 3074/7702 saga sheds light on how Ethereum governance really works — that besides the explicit governance power that is the EIP/ACD process driven by core devs, there’s also the implicit governance power of roadmaps driven by researchers. When these powers become misaligned, we see gridlocks and whiplash, and it could take another power — Vitalik — to tip the balance one way or the other.

We then make the case that Vitalik represents a distinct power that is the “vision” of Ethereum, which is the basis of legitimacy for any roadmaps. We compare Vitalik with the CTO at a large company, and acknowledge that his role as a pseudo-CTO is necessary for Ethereum to keep up its pace of innovation, without degenerating into a Frankenstein system of incoherent designs.

Finally, we present a mental model for thinking about Ethereum governance as VVRC: values (community) ⇒ vision (Vitalik) ⇒ roadmaps (researchers) ⇒ clients (core devs). We then suggest various ways to fix the “bugs” that sometimes cause the process to deviate from this model in practice.

Ethereum governance is “the machine that builds the machine” — to get Ethereum right, we must get governance right. As such, 3074 provided an invaluable case study for when governance went wrong, and I hope I was able to draw some helpful lessons from it so we can improve Ethereum governance for the future.

Disclaimer：

1. This article is reprinted from [zerodev]. All copyrights belong to the original author [derek]. 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.