以太坊治理反思：为什么大家对 EIP-3074 事件感到不满？

作者： imToken

本文阐述了我对近期 EIP -3047 事件的思考，感谢 Vitalik 和 Yoav 对内容的审核。

如果你不清楚这个事件，这里简单回顾一下：

不久前， EIP -3074 提案获得核心开发者的绿灯，计划在以太坊下次硬分叉 Pectra 中实施。这个提案目的是让普通以太坊账户（ EOA ）用户也能享受到账户抽象（ Account Abstraction ，常见简称 AA ）的诸多便利。

但随后， ERC -4337 社区，特别是该提案的起草者们，对 EIP -3074 提案表达了强烈反对，理由主要是 EIP -3047 可能加剧中心化风险，且与以太坊账户抽象路线图不一致，该路线图的核心是 EIP -4337 及其近亲 EIP -7560（也叫原生抽象账户）。

上周， Vitalik 提出了 EIP -7702 作为 EIP -3074 的替代方案。它同样旨在为 EOA 用户带去账户抽象的好处，不过设计上更契合当前的 EIP -4337 标准，并能平滑过渡到最终形态 —— EIP -7560。

译者注： ERC -4337 和 ERC -7560 都是以太坊生态系统中与账户抽象相关的提案，旨在改进用户账户管理和交互方式，提升用户体验和安全性。

ERC -4337 允许用户通过代理合约（ Proxy Contract ）来管理他们的账户，减少了用户 DApp 交互时的复杂性和风险。 ERC -7560 则旨在将 ERC -4337 等提案中的理念直接融入以太坊的基础层，使得所有账户天然具备账户抽象的能力，从而提供更深层次的整合和优化。

ERC -4337 是向 ERC -7560 过渡的一个重要步骤，两者共同构成了以太坊账户抽象路线图的核心。

目前，核心开发者团队正对 EIP -7702 进行讨论，一些早期迹象和社区反馈表明， EIP -7702 很可能将在 Pectra 硬分叉中取代 EIP -3074。

对此结果，我个人感到十分满意： EOA 用户即将借助为 ERC -4337 打造的工具和基础设施，享受到账户抽象带来的多数益处。

然而，达成这一目标的过程却让我难以释怀，感觉远非最佳路径，这也是近期许多人的共同感受。我深信，若有更完善的流程，我们本可减少纷扰，更快达成共识。

在此文章中，我打算：

• 剖析过程中存在的问题
• 提出理解以太坊治理的思维框架
• 探讨如何改进，避免未来重蹈此次覆辙

为什么大家感到不满？ 

整个事件让很多人感到不满，原因有几点：

• 漫长的审批之路： EIP -3074 耗时数年才终获绿灯。
• 反馈滞后：核心开发者仅在 3074 通过后，才广泛听取到来自 ERC -4337 社群的反对声音。
• 预警未果：4337 提案的作者虽多次向核心开发者提出对 3074 的忧虑，却收效甚微。
• 改弦更张：如今，我们面临撤销 EIP -3074 并用 EIP -7702 取而代之的局面。

 客观而言，上述每个环节单独看并无不妥： 

• 长时间的讨论合情合理。
• 批准后遭遇反对亦属正常现象。
• 若有新问题浮现，调整甚至取消原决策，同样符合逻辑。

 然而，我们或许都认同，这一过程本可以更加顺畅。想象一下，如果事情这样发展：

 在核心开发者讨论 EIP -3074 期间， ERC -4337 社区积极参与其中。这样一来，只有两种可能的结果：

• 要么 EIP -3074 在考虑了 EIP -4337 社区反馈后被批准（可能有所修改），那么 EIP -4337 社区就会支持 EIP -3074，也就无需推翻 3074 的决定。
• 或者， EIP -3074 从未得到批准，但 EIP -4337 社区与核心开发者协作，共同推进一个大家都满意的提案，就像 EIP -7702 那样。

每个人的声音都被听到，也没有戏剧性的反转。这本应是个理想的结局——但为何未能实现呢？

问题出在哪？

回溯整个过程，争论双方都有所指责。

核心开发者（包括 EIP -3074 的作者）觉得，如果 EIP -4337 团队更积极地参与到以太坊核心开发者大会（ All Core Devs ，常见简称 ACD ）流程中来，问题就不会发生。

在这个流程里，提案需要长时间讨论，最终由客户端团队接受并融入协议。他们认为， EIP -4337 团队本可以在任何时候介入，提出他们的担忧，而不是等到 EIP -3074 已被批准后。毕竟，以太坊核心开发者大会流程公开透明，会议对外开放，像 Tim Beiko 等人还会在每次会议后发推总结。如果 EIP -4337 团队真的这么关心，为何不投入时间参与？

相反，账户抽象团队（即 EIP -4337 的作者）强调，他们其实有参加以太坊核心开发者大会，并抓住每个机会反对 EIP -3074，只是没有被核心开发者采纳。而 EIP -4337 社区的成员普遍感到意外，很多人以为 EIP -3074 已被放弃，甚至不知道 EIP -3074 还在考虑中。

此外，也有意见指出以太坊核心开发者大会流程太过复杂，对于有全职工作、无法紧跟每一步更新的人来说难以参与。还有人认为，主动征求关键利益相关者（如 EIP -4337 社区）的意见应该是以太坊核心开发者大会的责任。

在我看来，两边都没完全抓住问题的核心。有一个更深层次的问题在起作用，除非我们解决它，或者至少正视它，否则我们将反复遇到治理失效，并陷入无意义的互相指责中。

症结所在

治理失败的真正症结，在于大家普遍误解了以太坊核心开发者大会。以太坊核心开发者大会其实并非是协议更新唯一的决策力量，在这个案例中，另一种治理力量实际上凌驾于以太坊核心开发者大会之上，发挥了决定性作用。

问题在于，这种至关重要的治理力量虽然在以太坊的重大事务上，比如账户抽象和扩展性问题上影响力巨大，但却鲜少被正式认可。 

我在这里将这种力量称作「路线图」。 

简而言之，整个 3074 转至 7702 的风波，就是「路线图」力量压过了以太坊核心开发者大会决策力量的一个典型案例。 

从治理的角度看，当一种看不见的力量盖过了一种看得见的力量，我们就应该警觉起来，因为看不见意味着不受监督，因此必须揭露并审视这一隐形力量。

什么是路线图？

在以太坊圈子里，路线图这个词想必耳熟能详，比如，以 Rollup 为核心的路线图、 ETH 2.0 路线图，或是这次讨论焦点的账户抽象路线图。 

想象一下，在一个以太坊核心开发者会议上，大家正在讨论如何扩大网络规模： 

核心开发者 Bob 提议：我支持 EIP -1234，它主张将区块时间加快 10 倍，区块容量增大 10 倍，交易费降低 100 倍。

其他开发者回答：你认真的吗？ 

想一想，为什么 Bob 的提议会被迅速否决？他的确提出了一个有效的扩容方案， Solana 等其他公链就这么操作的，效果显著。 

原因在于， Bob 的提议与以太坊坚持的以 Rollup 为核心的扩容路线图背道而驰。这条路线图强调，为了维护区块链的去中心化特性，普通用户能够轻松运行节点至关重要。因此， Bob 的提议因大幅提高了运行节点的难度，与路线图不符，自然被排除在外。 

通过这个例子，我想展示的是，参与以太坊核心开发者大会会议、负责协议更新的核心开发者们，实际上遵循着一个更高的指导原则，即我所说的路线图。这里有各种路线图，如扩容路线图、账户抽象路线图、 MEV 路线图等，它们共同构成了以太坊的整体路线图，是核心开发者做决策的依据。

当核心开发者与路线图不一致时

因为路线图不属于正式治理的一部分，核心开发者不一定总能与之保持一致。特别是，由于没有「批准路线图」这样一个官方流程，不是所有路线图都享有相同的认可度。这就需要路线图背后的策划者积极向核心开发者和广大社区推广，以赢得认可，进而获取核心开发者的认同和支持。 

以账户抽象为例， Vitalik 多次推崇以 EIP -4337 为中心的路线图，但实际上主要是 EIP -4337 团队，特别是 Yoav 和 Dror ，他们在会议、线上论坛及以太坊核心开发者大会中积极倡导这一路线图。 

然而，即便如此，部分核心开发者仍对以 EIP -4337 为中心的路线图持反对意见，他们认为 EIP -7560（即 EIP -4337 的原生版本，未来客户端需实现）过于复杂，不是实现账户抽象最终形态的唯一途径。最终，尽管 EIP -4337 团队反对 EIP -3074 会因引入另一套较为中心化的账户抽象技术栈而分裂抽象账户生态，以太坊核心开发者大会还是批准了 EIP -3074。 

但在 EIP -3074 获得批准后，整个 EIP -4337 社群的强烈反对促使核心开发者重新审视 EIP -3074。双方争执不下，直至 Vitalik 在关键时刻提出 EIP -7702 作为 EIP -3074 的替代方案，它明确支持以 EIP -4337 为中心的账户抽象方案，这才推动局势向着遵循账户抽象路线图的方向发展。

Vitalik 的角色

尽管 Vitalik 自视为一名研究员，但从这次事件可以看出，他在以太坊的治理中发挥着与众不同的独特作用。这引出了一个问题： Vitalik 在以太坊的治理中究竟扮演着怎样的角色呢？ 

我们可以把 Vitalik 想象成一家大型公司的 CTO 。 

如果你曾在有一定规模的科技公司工作过，比如超过 50 人的，你会明白 CTO 不可能参与每一个技术决策。随着公司规模的增长，技术决策自然而然地分散开来，各个产品领域的子团队一般都能自主决定其具体实施细节。 

而且， CTO 也不一定是所有领域的顶尖专家。公司里可能有在某些方面比 CTO 更厉害的工程师。所以在技术争论中，往往是工程师们做出最后的决定。 

不过， CTO 负责制定公司的技术愿景，而具体的执行则交给开发者。 

虽然这个比喻不完美，但它相当准确地描绘了 Vitalik 在以太坊生态系统中的角色。 

Vitalik 不会参与到每一个技术决策中去——他不可能这么做，他也不是所有领域的顶尖高手。但他对以太坊所有关键方面（如扩容、账户抽象、权益证明等）的路线图有着巨大的影响，这不仅仅是因为他的技术知识，更是因为他能最终判断一个路线图是否与以太坊的愿景——也就是他自己的愿景——相符。

每个成功产品背后的驱动力是愿景

作为一个创业者，我认为每一个成功的产品，其背后都有着清晰的愿景。而这样的愿景往往需要少数人，通常是创始团队，甚至常常只有一位关键创始人来确立。 

以太坊的魅力在于，这样一个结构复杂、涉及多层面的系统，竟能协同运作，成为每日流转巨额价值的去中心化计算机。这不是靠委员会式的决策达成的，而是得益于 Vitalik 以其愿景的引领，我们才拥有了今天这样协调且高效的以太坊。从 2015 年的构想到今天，以太坊一直是 Vitalik 智慧的体现。 

这并不是贬低其他研究者和工程师的贡献，他们为以太坊的发展立下了汗马功劳。但同时，不可否认，以太坊是 Vitalik 愿景的极致展现，远远超越了任何其他个人的影响。 

诚实地问自己，当你因以太坊的开放性、抗审查性以及创新活力而加入时，你是否在意过这一切起源于 Vitalik 的最初构想？ 

或许之前没细想，但明白了这一点后，你真的介意吗？ 

以太坊因一个清晰的愿景而生，也在持续实现这个愿景的过程中不断成长，而这正是其魅力所在。

那去中心化呢？

你或许会问，如果一个人对以太坊拥有如此重大的影响力，我们怎能说它是去中心化的呢？ 

为解答这个问题，我们可以参考 Vitalik 写的一篇经典文章，它阐述了去中心化的多重含义。文章的关键点是，去中心化包含三个方面： 

架构上的去中心化：多少节点失效，系统才会停止运作？

逻辑上的去中心化：系统各部分能否独立演化而不影响整体功能？

政治上的去中心化：多少人或实体控制着这个系统？ 

以太坊在架构和逻辑上无疑是去中心化的，因为它能在众多节点间分布，并且不同组件（比如共识机制和执行层）可以相对独立发展。 

至于政治去中心化，好消息是没有任何单一实体能关闭以太坊，包括 Vitalik 。但不可否认， Vitalik 在设定以太坊愿景和路线图中的重要地位意味着在政治去中心化上可能存在妥协。 

我的看法是，为了让以太坊持续创新，我们应当接受 Vitalik 作为实质上的 CTO 角色，即便这在某种程度上减少了政治去中心化。在以太坊尚未成熟到像 Bitcoin 那样稳定不变之前，需要有这样一位广受尊敬的权威人士，他不仅基于技术优劣作出决策，还要确保这些决策符合以太坊的长远愿景。 

没有 Vitalik 这样的角色，以太坊可能会面临两种情景，这次 EIP -3074 事件就是一个鲜活的例子： 

• 决策僵局：各方不愿妥协，项目停滞不前，就像 EIP -3074 的辩论直到 Vitalik 介入才打破僵局。
• 设计混乱：系统可能变成不协调的拼凑体，就像险些发生的 EIP -3074 与 EIP -4337 平行而不兼容的情况。

因此，在以太坊仍在快速演进的阶段， Vitalik 的领导对于维持一个既去中心化又不失方向感的生态系统至关重要。

社区的重要性

到此，我们几乎构建起了对以太坊治理的全面理解框架，但至今讨论中还有一个关键部分没有提及——社区的作用。

如果 Vitalik 设定愿景，研究者据此规划路线图，核心开发者随后实施，那么社区在其中扮演什么角色呢？肯定不是无足轻重吧？ 

事实上，社区扮演着最为核心的角色。因为在愿景成型之前，存在着一种更基础的东西——价值观。我们因共享某些价值观而聚集成社区，这些价值观是 Vitalik 愿景的基石，必须与之相匹配，否则社区将不复存在。

可能是成长背景的影响，或是过往经历的启发，以太坊社区中的每一个人，都在某个时刻意识到建立一台人人可及、无法被审查、真正去中心化的计算机对世界的价值。我们每天在以太坊上的工作，都是对这些价值观的实践和肯定，正是通过这些行动，我们赋予了 Vitalik 、研究者和核心开发者们所提出的愿景、路线图及代码以生命和正当性。

以太坊治理简化模型： VVRC 框架

想象一下以太坊的治理像一台精心设计的机器，我们将其简化为四个关键部分：价值观（ Values ）、愿景（ Vision ）、路线图（ Roadmaps ）和客户端（ Clients ），简称 VVRC 模型。

• 价值观（ Values ）：一切始于以太坊社区共享的一套基本原则和信念
• 愿景（ Vision ）： Vitalik 作为创始人，基于社区的价值观，描绘出以太坊未来发展的愿景。
• 路线图（ Roadmaps ）：有了清晰的愿景，研究团队就会着手制定实现这些梦想的具体步骤。他们设计出一步步迈向目标的技术路径。
• 客户端（ Clients ）：最后，核心开发者团队依据路线图，编写代码并维护客户端软件，确保所有技术规划能够变成现实，让用户和开发者能够实际使用。

这个流程听起来很流畅，但现实中会更复杂。比如，核心开发者实际上握有最终的决策权，因为他们负责实际的软件实现。 Vitalik 和其他研究员更多的是提供建议，有时候他们的提议可能不会被采纳，正如 EIP -3074 事件所示。

总的来说， VVRC 模型帮助我们理解以太坊如何在理想状况下推进治理，同时也提醒我们需要不断调整和完善这个过程，避免再次出现类似 EIP -3074 的问题。

如何改善以太坊治理

为优化以太坊治理结构，确保避免重蹈 EIP -3074/ EIP -7702 事件覆辙，这里提出几点改进建议：

提高 EIP 透明性：确保正在考虑中的 EIP 对社区更加公开透明，避免类似 EIP -3074 被突然接受的情况让大家感到意外。实际上， EIP s 网站上标注的 EIP 状态并未同步以太坊核心开发者大会的审议进度，因此即使核心开发者已同意 EIP -3074，其状态仍显示为「审核中。建议可以通过以太坊基金会的社交媒体平台，提前通知社区即将被采纳的 EIP 。

增强社区参与：为社区成员设置特定时段在以太坊核心开发者大会会议中讨论 EIP 对下游项目的影响，这样可以防止像 EIP -3074 对 EIP -4337 社区造成的意外影响。同时，若研究人员发现其反馈未获核心开发者重视，如同 EIP -4337 团队遭遇的困境，可邀请社群成员加入讨论以增强自身立场。

相互理解，持续沟通：核心开发者和研究人员必须相互理解，他们都是治理的关键力量，只是侧重点不同。核心开发者通过实施客户端拥有「执行权」，相当于拥有「投票权」。而研究人员通过积极分享和讨论他们的路线图，获得了更广泛的社区支持，形成了「路线图影响力」。

当双方意见不合时，核心开发者可能倾向于直接推翻研究人员的想法，就像他们对 EIP -4337 团队所做的那样。但这样做容易引发反弹，因为双方冲突时权力平衡会被打破， EIP -3074 通过后引发的混乱就是例证。

反之，研究人员遇到阻力时，可能选择不再与核心开发者合作，这也是 RIP （ Rollup Improvement Proposal ）流程诞生和原生账户抽象（ EIP -7560）主要作为 RIP 推进而不是 EIP 的原因之一。

虽然 RIP 帮助 L2 实验那些 L1 难以直接采纳的协议更新是有益的，但它不能替代参与 EIP 治理过程。研究人员必须坚持与核心开发者沟通，直到路线图获得一致认同。

通过以上这些措施，可以提升治理的透明度、增强社区参与度，并促进核心开发者与研究人员间的有效合作，减少未来可能出现的治理问题。

总结

以太坊的 EIP -3074/ EIP -7702 事件揭示了其治理结构的复杂性：除了正式的治理流程（由核心开发者根据 EIP 和以太坊核心开发者大会提案推动）外，研究者提出的非正式路线图也拥有巨大影响力。当这两股力量不协调时，可能会导致决策僵局或突然转向，此时， Vitalik 的角色尤为关键，他能凭借其对以太坊愿景的把握来协调各方，类似于一个项目的精神领袖。

我们将以太坊的治理简化为一个模型：社区的价值观 → Vitalik 的愿景 → 研究团队的路线图 → 核心开发者的实施（ VVRC 模型）。这个链条显示了决策如何从广泛的理念逐步细化为具体的技术实现。

为了改善治理效率，需要针对实际操作中偏离这一理想模型的问题进行修正。毕竟，良好的以太坊治理是推动项目前进的核心机制。 EIP -3074 事件作为一个实例，暴露了治理中的弱点，为我们提供了学习和改进的机会，确保未来能更好地应对类似挑战，促进以太坊持续健康发展。