3074事件后以太坊治理现状分析与未来展望

Vitalik 和 Yoav已经审阅过这篇文章，不过文中的观点仅代表我个人看法。

对于近期没有关注账户抽象（AA）进展的读者，这里简单梳理下背景：几周前，EIP-3074提案获得核心开发者批准，该提案旨在为外部账户（EOA）用户带来诸多AA优势，并计划纳入以太坊下一次硬分叉”Pectra”。然而自那以后，ERC-4337社区成员，特别是该标准的作者们，开始强烈反对3074，主要担忧其可能导致的<a href="https://notes.ethereum.org/@yoav/3074-implications”>中心化风险以及与以太坊<a href="https://notes.ethereum.org/@yoav/AA-roadmap-May-2024″>AA发展路线图的兼容性问题。上周Vitalik提出了EIP-7702作为替代方案，它在保持3074核心目标的同时，更兼容现有的4337标准，并为未来的7560标准（原生AA）预留了空间。目前核心开发者正在评估7702，从初步讨论和社区反馈来看，7702很可能会取代3074成为Pectra的一部分。

从个人角度，我对这个结果感到欣慰：EOA用户很快就能通过ERC-4337构建的工具和基础设施享受到AA的主要优势。但必须承认，整个决策过程存在明显优化空间。通过更完善的流程，我们本可以避免大量精力的浪费，更早达成理想方案。

本文将重点探讨三个问题：首先分析当前治理流程的不足，然后提出一个理解以太坊治理的思维框架，最后给出改进建议以避免类似情况再次发生。

争议背后的治理困境

整个事件引发诸多不满的原因值得深思：EIP-3074历经多年讨论才获批准，但批准后却突然收到4337社区的强烈反对。虽然4337团队曾多次向核心开发者表达担忧，但收效甚微。现在我们又面临撤销3074批准，转而采用7702的局面。

从原则上说，这些操作都无可厚非：重大提案需要长期讨论，批准后接受反对意见也属正常，发现问题后调整决策更是负责任的表现。但所有人都认同这个过程本可以更顺畅。理想情况下，4337社区应该在核心开发者讨论3074时就积极参与，这样可能出现两种更好结果：要么3074在充分考虑反对意见后获批（可能经过修改），获得4337社区支持；要么从一开始就共同寻找像7702这样各方都满意的替代方案。

问题根源分析

复盘整个过程，双方各执一词。核心开发者和3074作者认为责任在于4337社区未能积极参与全核心开发者（ACD）流程，该流程通过长期审议才最终决定协议更新。他们认为ACD流程完全开放，有详细记录，会议对所有人公开，还有Tim Beiko等人在会后积极发布摘要。如果4337社区如此关注这个问题，为什么不投入时间参与？

AA团队（4337作者）则反驳称他们一直参加ACD会议并反复表达反对意见，但核心开发者未予采纳。至于4337社区多数成员，他们完全措手不及——很多人以为3074已被放弃，根本不知道它正在被积极考虑。不少人还认为ACD流程透明度不足，对需要兼顾日常工作的人不够友好，建议ACD应该主动征求相关利益方（如4337社区）的反馈。

我认为双方都忽略了更深层的问题：与普遍认知不同，ACD并非协议更新的唯一治理主体，在这个案例中，它实际上被另一个治理力量所取代。问题在于这个隐性力量很少被正式承认，尽管它在以太坊重大事务（如AA和扩容）上的影响力往往超过ACD。我将其称为”路线图”力量。

路线图的隐性权力

任何关注以太坊的人都会频繁听到”路线图”这个词，比如”rollup中心化路线图”、”ETH 2.0路线图”或本文讨论的”<a href="https://notes.ethereum.org/@yoav/AA-roadmap-May-2024″>AA路线图”。

以太坊Magicians论坛上的”路线图”搜索结果

举例说明：假设ACD会议上，核心开发者Bob提议通过大幅提升区块速度和容量来扩展以太坊，其他开发者会立即反对，因为这个想法违背了以太坊”rollup中心化”的扩展路线图——该路线图强调保持节点可访问性对去中心化的关键价值。这个例子说明，核心开发者的决策实际上受到更高层路线图的指导。

Vitalik的独特角色

尽管Vitalik自称只是研究员，但这次事件清晰展现了他独特的治理影响力。在我看来，Vitalik的角色类似于超大型公司的CTO（顺便说一句，这家公司没有CEO）。在技术公司中，CTO虽然不参与每个具体决策，但负责制定技术愿景。同样，Vitalik对以太坊关键领域（扩容、AA、权益证明等）的路线图拥有巨大影响力，不仅因为他的专业能力，更因为他是判断路线图是否符合以太坊愿景的最终仲裁者。

作为创业者，我认为每个成功产品背后都需要连贯的愿景，而这样的愿景必然由少数人（有时甚至是一个人）确立。以太坊的独特之处在于，尽管系统极其复杂，但各个组件完美协同，形成了如今处理数十亿美元价值的去中心化计算机。这种成就不是委员会设计的产物，而是Vitalik通过其愿景持续引领的结果。当然，这绝不否定其他研究者和开发者的重要贡献，但以太坊本质上仍是Vitalik最初愿景的具现化。

治理改进建议

基于上述分析，我们提出以下改进建议：

首先需要提升EIP审议过程的透明度。整个社区不应该”突然”发现某个EIP已被接受——这正是3074的情况。建议以太坊基金会在社交媒体明确公告即将批准的EIP，提高社区知晓度。

其次，核心开发者有时会低估某些EIP对下游项目的影响。考虑到ACD会议时间有限且需跨时区协调，可以理解需要控制发言人数。但仍建议定期安排时间听取社区对重要EIP的反馈。当研究者感觉意见未被重视时（如4337团队的情况），可以邀请社区代表参会以增强说服力。

最关键的是，核心开发者和研究者需要相互承认各自是不同的治理力量。核心开发者的”客户端权力”是唯一能通过代码实现来”投票”的力量；研究者的”路线图权力”则通常获得更多社区支持。当这两种力量冲突时，如果核心开发者单方面推翻研究者意见（如批准3074那样），可能导致剧烈反复。同样，研究者也不应回避与核心开发者的持续沟通——这也是为什么我认为RIP流程的创建值得商榷，虽然它有助于L2尝试那些对L1过于激进的更新，但不能完全替代与核心开发者的直接互动。

构建更完善的治理模型

综上所述，我们提出一个以太坊治理的VVRC模型：价值观（社区）⇒ 愿景（Vitalik）⇒ 路线图（研究者）⇒ 客户端（核心开发者）。这个模型虽然简化了复杂的现实（比如核心开发者始终掌握最终实施权），但较好地描述了理想状态下的治理流程。3074事件为我们提供了宝贵的案例研究，通过分析其中的”故障”，我们可以持续优化这台”制造机器的机器”，使以太坊治理更加健康高效。