Reflections on Ethereum Governance Following the 3074 Saga

From zerodev by derek

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:

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:

Why the process made people unhappy

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

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

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

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 “ 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:

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  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  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  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:

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:

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:

Together they work like this:

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.

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.