Sobre el impacto de Vitalik y varias hojas de ruta en el proceso de gobernanza de Ethereum

Original article by Derek Chiang, CEO of ZeroDev

Original translation: Faust, Geekweb3

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

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

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

Content: If you don’t know about 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 near-native AA experience.

Since then, many people in the ERC-4337 community, especially the proposers of 4337, have been strongly opposing EIP-3074, citing concerns that the proposal would bring many security risks and be incompatible with Ethereums AA roadmap. In Ethereums previous roadmap, it was clearly stated that ERC-4337 and similar proposal 7560 (also known as nativeAA) were the centerpiece.

In early May, Vitalik proposed EIP-7702 as a replacement for EIP-3074, striking a balance between 4337 and 3074 – it can bring 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. The current preliminary discussion results and community sentiment indicate that EIP-7702 is likely to replace EIP-3074 mentioned above.

Personally, I am very happy with this result: EOA users will soon be able to experience various products within the ERC-4337 ecosystem and enjoy most of the benefits of AA. However, I cant help but feel that there are better ways to achieve the above results, which many people have pointed out in the past few weeks. I feel that if there were a better governance process, we could have saved a lot of energy and achieved the desired results faster.

In this article, I want to:

• Identify what went wrong in the governance process

• Proposing a mental model for thinking about Ethereum governance

• Provide suggestions for improvement to avoid similar governance incidents in the future

Summary and reflection on the EIP-3074 incident

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

It took years for EIP-3074 to be 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 repeatedly expressed their concerns about EIP-3074 to the Ethereum core team, but to no avail. Now Ethereum is planning to cancel the approval of 3074 and replace it with another EIP (7702).

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

• Discussions about an EIP may take several years, which is normal.

• It is normal for an EIP to be rejected after it has been approved.

• Approval can be revoked after an EIP has been approved if new issues are discovered.

However, things could have gone much more smoothly. Let’s imagine that 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 possible outcomes:

• After considering 4337 community feedback, proposal 3074 is approved (and may be modified), in which case the 4337 community will accept 3074 and the Ethereum core team will not have to withdraw 3074.

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

Everyone’s voice was heard, and there were no dramatic reversals. It would have been nice—so why wasn’t it?

What went wrong?

Looking back at the whole process, both parties were blaming 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 undergo long deliberations before being accepted and implemented by Ethereum client development teams such as Geth.

Some people think that 4337 supporters could have participated and expressed their opinions during the review of 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 Tim Beiko actively post summary tweets after each ACD meeting. So, if 4337 supporters care so much about this topic, why dont they actively and promptly participate in 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 the Ethereum core developers did not listen. As for the 4337 community members, most of them felt that it was sudden – many people thought that 3074 was already dead, and they didnt even know that 3074 was likely to be approved.

Many people pointed out that the entire process of the ACD meeting is not transparent and is not friendly to those who are serious in the Ethereum community but cannot keep up with the progress of ACD updates in a timely manner. Some people also believe that the ACD should proactively seek feedback from stakeholders (here referring to the 4337 community).

However, I think both sides are missing the point. There is a deeper problem behind this, and unless we address or at least acknowledge it, we will continue to have governance accidents, with both sides blaming each other, which is meaningless.

Addressing the root causes of incidents: A roadmap

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

In this article, I call this power a “roadmap.”

As I will point out below, the entire 3074-4337-7702 governance failure incident is a case of the power of Ethereums existing roadmap overriding the power of ACD. If we are talking about governance, when we notice that there is an invisible force overriding the visible force, we should be extremely worried about this, 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, for example in the “rollup-centric roadmap”, the “ETH 2.0 roadmap”, or in this case the “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 increase the block production speed by 10 times, increase the block size by 10 times, and reduce the fee by 100 times.

• Other core developers: …are you crazy?

Lets think about it. Why did the Ethereum core team reject what Bob said? He just proposed a 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 Ethereums rollup-centric expansion roadmap, which points out 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 because it will greatly increase the cost of running Ethereum nodes.

I would like to use this example to illustrate that the core developers who participate in the ACD governance process and decide on protocol updates are guided by a higher-level force, which I call the roadmap. Currently, there are scaling roadmaps, AA roadmaps, MEV roadmaps, etc., which together constitute the overall roadmap of Ethereum, and core developers must make decisions based on this.

When core developers’ opinions 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 support from the Ethereum core development team.

As far as AA and account abstraction are concerned, Vitalik himself has pushed for a 4337-centric AA roadmap on several occasions, but overall it has been mainly the team behind 4337, especially Yoav and Dror, who have advocated for a 4337-centric AA roadmap in forums and ACD meetings.

However, despite these efforts, some Ethereum core developers still strongly opposed the AA roadmap centered on 4337. They believed that 7560 (the native version of 4337 to be implemented by Ethereum clients in the future) was too complicated and was not the only viable solution for AA finality. In the end, ACD decided to approve the 3074 proposal, although it was opposed by the 4337 team, who believed that 3074 would split 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 being 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 describes himself as a researcher, the above story clearly shows that Vitalik has governance power that is 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 context)

If you’ve ever worked at a tech company with more than 50 employees, you know that it’s impossible for the CTO to 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.

Furthermore, the CTO is not necessarily the leading expert on all (or any) topics. There may be engineers in the company who are better than the CTO in specific areas, so when discussing technical details, it is often the individual engineers who make the final decision.

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 reasonably summarizes Vitalik’s role in the Ethereum ecosystem. Vitalik doesn’t participate in every technical decision—nor can he. He’s not a top expert in every field. But he has an overwhelming influence on the roadmap for all of Ethereum’s key solutions (scaling, AA, POS…), not just because of his technical expertise, but because he is the ultimate judge of whether the roadmap is in line with Ethereum’s vision (his vision).

Every successful product starts with a vision

If my opinion that Vitalik is the CTO of Ethereum wasn’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 founder of a startup, and usually only one founder.

The beauty of Ethereum is that even though 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 are here today not because of some committee scheme, but because of Vitalik’s visionary leadership, we are able to build the coherent and beautiful Ethereum that it is today. Ethereum was Vitalik’s idea in 2015, and it remains so today.

This is of course 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 this? While you were attracted to the openness, censorship resistance, and speed of innovation of the Ethereum ecosystem, did you complain about it starting with Vitalik’s vision? Maybe you didn’t complain because you didn’t think about it that way — but now you do, but do you really mind the problem?

How to solve 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 overall system to function properly, or must they be tightly coordinated?

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

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

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 people think, as Vitalik played a major role in developing the vision and roadmap for Ethereum.

However, I think if we want Ethereum to continue to innovate, we have to 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 just retire. But before we reach that final step, it is crucial to have an authority that all parties respect, that is trustworthy, and that can 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 Vitalik, there are only two possible outcomes, and the story surrounding 3074 vividly illustrates these two outcomes:

• The Ethereum governance process can become stuck in an endless stalemate, with neither side willing to compromise and no one able to make progress, as demonstrated by the 3074 debate that reached an impasse before Vitalik intervened.

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

The role of the community

After the above thinking, we are close to outlining a complete Ethereum governance thinking model, but so far there is a glaring omission in our discussion – the community.

If Vitalik defines the vision for Ethereum, the researchers define the roadmap, and the core developers implement the roadmap, then what is the role of the community? Surely it’s not 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 Vitaliks vision must ultimately align with those values, otherwise it will lose the support of the community.

All of us in the Ethereum community believe that having a decentralized computer that is accessible to everyone, censorship-resistant, and trustworthy is good for the world. We uphold and affirm these 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.

VVRC Model of Ethereum Governance

So here is the complete mental model of Ethereum governance, Values ⇒ Vision ⇒ Roadmap ⇒ Client, VVRC for short:

• V==Values==Community;

• V==Vision==Vitalik;

• R==Roadmap==Researchers;

• C==Client==Core developers;

Together they perform the following functions:

• Communities coalesce around certain values.

• Vitalik expressed a vision consistent with these values.

• Researchers develop a roadmap based on the vision.

• 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 through changes to the client code. Vitalik and other researchers only play an advisory role, and sometimes their opinions are not accepted by the core developers, which is why EIP-3074 was approved.

That being said, I think the VVRC model reasonably captures how Ethereum’s governance model works under normal circumstances, and we need to “debug” the process so that it doesn’t happen again like EIP-3074.

How to improve Ethereum’s governance model

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

• The visibility of the discussion progress of EIPs under consideration must be improved. The entire community should not be surprised that an EIP is accepted, and the surprising approval of proposals like 3074 should not appear again.

The current EIP status on the EIP website does not reflect its status in the ACD process. This is why it still says 3074 is in the under review status, 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 close to being accepted, the Ethereum Foundation would announce it loud and clear on social media to raise awareness in the community.

• Sometimes core developers may underestimate the impact of a particular EIP on downstream projects and users, which was the case with the communities 3074 and 4337. Because ACD meetings are limited in time and must be coordinated across time zones, meetings often only allow “relevant personnel” to speak.

That being said, it would make sense to occasionally allocate some speaking time for community members to comment on the downstream impacts of certain EIP proposals if they were passed.

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

• It is critical that core developers and researchers recognize each other as being part of Ethereum’s governance power, despite their different power levels. Core developers’ power to make changes and updates to the Ethereum client is the only power that can “vote” to make changes to the protocol itself. Researchers’ power to make changes and interpretations of the roadmap often has more public support, thanks to researchers actively talking about and writing about their ideas.

When these two forces conflict, core developers may be inclined to simply overrule the researchers, as was the case when core developers overruled the objections of team 4337. However, such overruling can lead to conflict, as the two forces become unstable when they conflict, as the dramatic events that occurred after 3074 was approved showed.

Likewise, 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 promoted primarily as a RIP rather than an EIP.

While there are real benefits to experimenting with protocol updates on L2 that are controversial for L1, we cannot view RIPs as a replacement 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.

en conclusión

The 3074/7702 incident revealed 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 whiplash, 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 fundamental to 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 the 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 properly, 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.

Enlace original

This article is sourced from the internet: On the impact of Vitalik and various roadmaps on the Ethereum governance process

Relacionado: Análisis macro de SignalPlus (20240506): Los activos de riesgo tienen la oportunidad de comenzar a subir lentamente nuevamente

Por primera vez este año, los datos de empleo fueron inferiores a lo esperado (sin un aumento sorprendente), con un cambio general en el empleo de +175.000 (el aumento promedio anterior fue de alrededor de 275.000), y la tasa de desempleo también aumentó inesperadamente de 3,83% a 3,87%. Otros indicadores del mercado laboral de mayor frecuencia también están comenzando a mostrar signos de desaceleración, como el reciente informe JOLTS que muestra una menor proporción de vacantes en relación con los desempleados, y las contrataciones y renuncias del sector privado en mínimos de varios años. Además, las tendencias de contratación entre las pequeñas empresas se debilitaron significativamente, ya que tanto los componentes de empleo del ISM como del PMI mostraron debilidad, y la proporción de empresas de servicios y manufactura que contratan cayó a niveles que suelen observarse en recesiones. El viernes pasado, señalamos que era más probable que los datos de nóminas no agrícolas…