Author: derek, ZeroDev CEO Source: ZeroDev official website Translation: Shan Ouba, Golden Finance

Missed the AA proposal storm? Here is a quick review for you:

• A few weeks ago, core developers approved the EIP-3074 proposal, which will bring many of the benefits of AA to EOA users and enter Ethereum's next hard fork "Pectra".

• Since then, many in the ERC-4337 community, especially the 4337 authors themselves, have been vehemently opposed to 3074, citing centralization issues and its incompatibility with Ethereum's AA roadmap, which is centered around 4337 and its cousin 7560 (aka "native AA").

• Last week, Vitalik proposed EIP-7702 as a replacement for 3074. It achieves largely the same goal — bringing many of the benefits of AA to EOA users — but in a way that’s more compatible with today’s 4337, and forward compatible with the “AA endgame” that is 7560.

• EIP-7702 is currently under deliberation by core developers, but initial discussions and community sentiment indicate that it will likely replace EIP-3074 in Pectra.

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

However, I can’t help but feel that the way we got to this outcome was far from optimal, a sentiment expressed by many over the past few weeks. I feel that with a better process, we could collectively save a lot of effort and headache, and get to the desired outcome more quickly.

In this blog post, I want to:

• Identify what went wrong in the process.

• Propose a mental model for thinking about Ethereum governance.

• Propose improvements to avoid similar governance failures in the future.

The whole episode has made a lot of people unhappy for the following reasons:

• It took years for 3074 to get approved.

• It was not until after 3074 was finally approved that the core developers faced a lot of resistance from the 4337 community.

• On the other hand, the authors of 4337 themselves have expressed their concerns about 3074 to the core developers many times, but to no avail.

• We are now unapproving 3074 and replacing it with another EIP (7702).

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

• It is acceptable for discussions to take years.

• It is acceptable for an EIP to receive delays after it has been approved.

• After an EIP has been approved, it can be unapproved if new problems are discovered.

However, we might agree that things could have gone more smoothly. Imagine if things had gone something like this:

• The 4337 community was actively involved as the core developers discussed 3074. Now, only one of two outcomes is possible:

• Either 3074 is approved (and possibly modified) after consideration of 4337 community feedback, in which case the 4337 community would support 3074 and we would not withdraw 3074.

• Or, 3074 was never approved, but the 4337 community and core developers worked together to produce a proposal that everyone was happy with, just like 7702.

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

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

The core developers (and the authors of EIP-3074) believe that it was the fault of “4337 people” who did not actively participate in the All Core Developers (ACD) process, and that EIPs were deliberated for a long time before being published and ultimately accepted by the client teams and thus implemented into the protocol.

Some argue that at any point during the deliberations, the "4337ers" could have come in and voiced their concerns, rather than waiting until 3074 had been approved. After all, the ACD process is well documented, meetings are open to everyone, and there are people like Tim Beiko who actively tweet summaries after every ACD meeting. So if 4337ers cared so much about this issue, why didn't they take the time to participate?

On the other hand, the AA team (the 4337 authors) noted that they had been attending ACD meetings and taking every opportunity they could to delay 3074, but the core developers didn't listen. As for the 4337 community, they were mostly caught off guard - most people thought 3074 was dead, and didn't even know that 3074 was being actively considered for inclusion.

Many also believe that the ACD process is too opaque and not friendly to the participation of people who have "real jobs" and cannot afford to keep up with all the ACD updates. Some also believe that it should be the ACD's responsibility to actively seek feedback from relevant stakeholders (in this case, the 4337 community).

However, I think both sides have missed the mark.  There is a deeper problem at work, and until we solve or at least acknowledge this problem, we will continue to encounter governance failures followed by futile finger-pointing.

The real reason for the governance failure is that, contrary to popular belief, the ACD is not the only governance power over protocol updates, and in this case it is overwritten by another governance power.

The problem is that the other governance power is rarely acknowledged, despite the fact that it has more influence on the most important matters of Ethereum (such as AA and scaling) than the ACD.

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

As I will argue, the entire 3074/7702 saga is just one example of the power of the roadmap overpowering the power of the ACD. If we are talking about governance, then we should be very worried whenever we notice invisible forces overpowering visible ones, because the invisible is irresponsible and therefore must be brought to light.

Anyone in the Ethereum community must have come across the term “roadmap” quite often, for example in the context of “Rollup-centric roadmap”, “ETH 2.0 roadmap”, or in this debate, “AA roadmap”.

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

• Core Dev Bob: I support EIP 1234, which proposes that we make block times 10x faster, increase block size 10x, and reduce fees 100x.

• Other Core Devs: …are you crazy?

Let’s think about that for a second. Why did the core developers just outright veto what Bob said? He had just proposed a very legitimate form of scaling. Solana and many other L1s do this to great scaling effect.

The reason, of course, is that this imaginary EIP goes against Ethereum’s own “Rollup-centric” scaling roadmap, which among other things states that enabling regular users to run nodes is essential for blockchain decentralization, and therefore the imaginary EIP is impossible because it would greatly increase the barrier to running a node.

What I’m trying to illustrate with this example is that the core developers who participate in the ACD process and decide on protocol updates are guided by a higher power that I call a roadmap. There are scaling roadmaps, AA roadmaps, MEV roadmaps, you name it — together they make up the Ethereum roadmap of core developer decisions.

Since the roadmap is not a formal part of governance, there is no guarantee that the core developers are in line with the roadmap. In particular, since there is no formal process for "approving" a roadmap, not all roadmaps are considered to have equal legitimacy. The researchers behind the roadmap need to work hard to promote their roadmap to the core developers and the larger community to gain legitimacy and thus support from the core developers.

In the case of AA, Vitalik himself has pushed for a 4337-centric AA roadmap on several occasions, but in general, it has been primarily the 4337 team, especially Yoav and Dror, who have spoken out at conferences, online forums, and ACD meetings.

However, despite these efforts, some core developers have strongly opposed a 4337-centric AA roadmap. They believed that 7560 (the native version of 4337 that clients would eventually have to implement) was too complex and not the only viable candidate for the "AA endgame". Ultimately, the ACD decided to approve 3074, despite opposition from the 4337 team because it would fragment the AA ecosystem by creating an alternative and less decentralized AA technology stack.

However, after 3074 was approved, the entire 4337 community reacted strongly, forcing the core developers to re-engage in the 3074 debate. The debate then reached a stalemate, with neither the 4337 author nor the 3074 author able to convince the other, until Vitalik intervened at the last minute to propose EIP-7702 as an alternative to 3074 that was explicitly compatible with the “AA endgame” centered around 4337, thereby pushing the conflict in favor of the AA roadmap.

Although Vitalik positions himself as a researcher, the saga makes it clear that Vitalik brings very different governance powers than other researchers. This then 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.

(This company, by the way, has no CEO for the purposes of this analogy.)

Also, the CTO isn’t necessarily the foremost expert on every (or any) topic. There are likely engineers in the company who are better at specific areas than the CTO. So in technical debates, it’s often the engineers who make the final call.

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

While this isn’t a perfect analogy, I think it captures Vitalik’s role in the ecosystem fairly well. Vitalik

If my opinion on Vitalik being Ethereum CTO wasn’t controversial enough for you, here comes the most controversial part: we should accept Vitalik as CTO.

As a startup founder, I believe that behind every successful product — yes, Ethereum is a “product” because it solves real problems for real people — there must be a coherent vision. 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, despite being such a complex system with so many moving parts, those parts fit together perfectly into a fully functioning decentralized computer that is moving billions of dollars worth of value every day. We didn’t get here through design by committee. It was because of Vitalik’s active leadership through his vision that we were able to achieve a coherent and beautiful product that is Ethereum today. Ethereum was Vitalik’s brainchild in 2015, and it remains so today.

Of course, this is not to downplay the contributions of other researchers and engineers, who should get most of the credit for getting Ethereum to where it is today. However, it does not contradict the fact that Ethereum is the realization of Vitalik’s vision, and is orders of magnitude further than anyone else’s vision.

Honestly, can you complain? When you are drawn to the openness, censorship resistance, and pace of innovation of the Ethereum ecosystem, do you complain that it started with Vitalik’s vision? Maybe you didn’t do it because you didn’t think so — but now that you do, do you really mind?

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

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

• Architectural decentralization: How many nodes can be compromised before the system stops functioning?

• Logical decentralization: Can the subsystems of a system evolve independently while keeping the system functional? Or do they have to be closely coordinated?

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

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

In terms of political decentralization, the good news is that no single 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 Vitalik’s prominent role in setting its vision and thereby defining its roadmap.

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

If Ethereum “ossifies” into a nearly immutable blockchain like Bitcoin, then Vitalik might retire. But before we get to that final stage, it’s critical that there is an authority that all parties respect, who people trust to make judgments about technical decisions not only on their technical merits, but also on whether they align with Ethereum’s vision. Without a figure like Vitalik, only two outcomes are possible, both of which are vividly illustrated by the 3074 saga: Ethereum governance could end up in an endless stalemate, with neither side willing to compromise and no one able to make any progress, just as the 3074 debate remained in a stalemate until Vitalik stepped in. Or, Ethereum could end up being an incoherently designed Frankenstein’s monster, as our very close approach to 3074 and 4337 as two fundamentally incompatible parallel AA stacks indicates.

We are very close to having a complete mental model of Ethereum governance, but there is one glaring omission from our discussions so far - the community.

If Vitalik defines the vision, then the researchers define the roadmap, and the roadmap is in turn implemented by the core developers - what role does the community play? Surely not 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 as a community because we unite around certain values, and ultimately Vitalik's vision must align with those, or the community is lost.

Maybe it was your upbringing. Maybe it was something that happened at your last job. But at some point, all of us in the Ethereum community agreed that having a decentralized computer that is accessible to everyone, cannot be censored, and is trusted to be neutral is a good thing for the world. We uphold and affirm these values ​​every day through the work we do on Ethereum, and in doing so, we provide legitimacy to the vision, roadmap, and code generated by Vitalik, researchers, and core developers.

Here, then, is the full mental model of Ethereum governance, which I call the Values ​​⇒ Vision ⇒ Roadmap ⇒ Clients Model, or VVRC for short:

• V == Values ​​== Community

• V == Vision == Vitalik

• R == Roadmap == Researchers

• C == Clients == Core Developers

They work together like this:

• The community comes together around certain values

Of course, reality is much messier than any simple model can capture. For example, in reality the core developers are the only ones who can "vote" on any decision by implementing a client. Vitalik and other researchers only play an advisory role, and sometimes their opinions are not accepted by the core developers, which is why 3074 was approved.

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

Now that we have a mental model of how Ethereum governance shouldwork, here are some 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 those EIPs that are being actively considered for inclusion. The community at large should never be “surprised” that an EIP is accepted, which was the case with 3074.

• Contrary to what you might expect, the "status" of an EIP on the EIP site does not reflect its status in the ACD process. That's why it still says 3074 is "under review," even though the core developers have voted to approve it, and there's little indication that it was ever considered for inclusion.

• Ideally, when an EIP is about to be accepted, the EF posts loud and clear on social media to raise community awareness.

• Sometimes core developers can underestimate the impact a particular EIP will have on downstream projects and users, which was the case with the 3074 and 4337 communities. Since ACD meetings are limited in time and must be coordinated across time zones, it's understandable that only "relevant people" should speak at the meetings. That said, it might make sense to allocate some time every once in a while for community members to comment on the downstream impacts of certain EIP proposals.

• If researchers feel that the core developers are not receptive to their opinions (as was the case with the 4337 team), they can engage community members to reinforce their views.

• It is critical that core developers and researchers recognize each other that they are both governance powers, albeit with different strengths. The core developers’ “client power” is the only power that can truly “vote” by implementing a client. Researchers’ “roadmap power” often garners more public support as they actively talk and write about their roadmaps.

• When the two powers conflict, it is easy for core developers to simply overrule researchers, such as when core developers overruled the 4337 team’s objections. However, such overriding can lead to power conflicts because power is unstable when in conflict, as shown by the drama that followed after 3074 was approved.

• Similarly, it is easy for researchers to abandon engagement with core developers when faced with resistance, which in my opinion is one of the reasons the RIP process was created and one of the reasons why native AA (7560) is now being driven primarily as a RIP rather than an EIP. While there are certainly benefits to helping L2 experiment with protocol updates, we cannot view RIPs as a substitute for participating in the EIP governance process. Researchers must continue to work with core developers until they are fully aligned with the roadmap.

The 3074/7702 saga reveals how Ethereum governance really works - in addition to the explicit governance power of the EIP/ACD process driven by core developers, there is the implicit governance power of the roadmap driven by researchers. When these forces are out of balance, we see gridlock and whiplash, and it may take another force - Vitalik - to tip the balance.

We then make the case 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 pseudo-CTO is necessary for Ethereum to maintain the pace of innovation while not degenerating into an incoherently designed Frankenstein system.

Finally, we proposed a mental model for viewing Ethereum governance as a VVRC: Values ​​(community) ⇒ Vision (Vitalik) ⇒ Roadmap (researchers) ⇒ Customers (core developers). We then suggested 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” — in order to get Ethereum right, we must get governance right. 3074 thus provides a valuable case study for when governance goes wrong, and I hope I was able to draw some useful lessons from it so that we can improve Ethereum governance in the future.