EIP3074 事件后对以太坊治理的思考

感谢 Vitalik 和 Yoav 对这篇文章的友好审阅，但观点仅代表我个人。

如果你还没有关注 AA 的闹剧，这里有一个快速的回顾：

• 几周前，EIP-3074，一个将 AA 的许多好处带给 EOA 用户的提案，被核心开发者批准进入以太坊的下一个硬分叉 “Pectra”。
• 从那时起，ERC-4337 社区的许多人，尤其是 4337 的作者们，一直在 强烈反对 3074，理由是 中心化问题 以及它与以太坊 AA 路线图 的不兼容，该路线图以 4337 及其近亲 7560（又名 “原生 AA”）为中心。
• 上周，Vitalik 提出了 EIP-7702 作为 3074 的替代方案。它主要实现了相同的目标——将 AA 的许多好处带给 EOA 用户——但方式与今天的 4337 更兼容，并且与 7560 的 “AA 终局” 向前兼容。
• 目前，核心开发者正在讨论 EIP-7702，但初步讨论和社区情绪表明，EIP-7702 很可能会在 Pectra 中取代 EIP-3074。

就我个人而言，我对结果非常满意：EOA 用户很快就能使用为 ERC-4337 构建的工具和基础设施，享受 AA 的大部分好处。

然而，我还是忍不住觉得我们实现这一结果的方式远非最佳，这是许多人在过去几周表达的观点。我觉得如果有更好的流程，我们可以共同节省大量的精力和头痛，并更快地达到预期的结果。

在这篇博文中，我想：

• 找出流程中出了什么问题。
• 提出一个思考以太坊治理的思维模型。
• 提出改进建议，以避免未来出现类似的治理失败。

整个事件让很多人不高兴，原因有几个：

• 3074 花了数年时间才获得批准。
• 只有在 3074 最终获得批准之后，核心开发者才收到了来自 4337 社区的大量反对意见。
  • 另一方面，4337 的_作者_们曾多次向核心开发者表达他们对 3074 的担忧，但无济于事。
• 现在我们正朝着 取消批准 3074 并用另一个 EIP (7702) 替换它的方向发展。

现在，以上任何一点本身都没有什么问题：

• 一个讨论花费数年时间是可以的。
• 一个 EIP 在获得批准后收到反对意见是可以的。
• 如果发现了新的问题，那么在获得批准后取消批准一个 EIP 也是可以的。

但是，我们可能都会同意，事情_本可以_更顺利地进行。想象一下，如果事情是这样发展的：

• 4337 社区在核心开发者讨论 3074 时积极参与。现在，只有两种结果是可能的：
  • 要么 3074 在考虑到 4337 社区的反馈_后_获得批准（并可能被修改），在这种情况下，4337 社区会支持 3074，我们就不会撤销 3074。
  • 要么 3074 根本没有获得批准，但 4337 社区和核心开发者共同努力，朝着一个每个人都满意的提案迈进，就像 7702 一样。

每个人的声音都能被听到，也没有戏剧性的逆转。那会很好 —— 那么为什么没有发生呢？

回顾这个过程，辩论的双方都互相指责。

核心开发者（和 EIP-3074 的作者）认为，是 “4337 人” 的错，他们没有积极参与 所有核心开发者 (ACD) 流程，在该流程中，EIP 会经过长时间的审议，然后才能最终被客户端团队接受，从而实施到协议中。

他们认为，在这个审议过程中的任何时候，“4337 人” 都可以进来并表达他们的担忧，而不是等到 3074 已经被批准 之后。毕竟，ACD 流程有详细的文档记录，会议对所有人开放，并且有像 Tim Beiko 这样的人在每次 ACD 会议后积极发布摘要。因此，如果 4337 人如此关心这个问题，为什么他们不花时间参与呢？

另一方面，AA 团队（4337 作者）指出，他们一直在参加 ACD 会议，并在每次机会都反对 3074，但核心开发者没有听取。至于 4337 社区，他们大多感到措手不及 —— 大多数人认为 3074 已经死了，甚至不知道 3074 正在被积极考虑纳入。

许多人还认为，ACD 流程过于不透明，对那些有 “真正工作” 并且无法跟上所有 ACD 更新的人来说不够友好。有些人还认为，ACD 应该主动寻求相关利益相关者（在本例中为 4337 社区）的反馈。

然而，我认为双方都没有抓住重点。 存在一个更深层次的问题，在我们解决或至少承认这个问题之前，我们将继续遇到治理失败，然后是不成效的互相指责。

治理失败的真正原因是，与普遍的看法相反，ACD 不是协议更新的唯一治理权力，并且在这种情况下，它被另一种治理权力所取代。

问题是，另一个治理权力很少被承认，尽管事实上 它对以太坊最重要的事项（例如 AA 和扩容）的影响甚至大于 ACD。

在本文中，我将这种权力称为 “路线图”。

正如我将要论证的那样，整个 3074/7702 事件 不过是路线图的力量压倒 ACD 的力量的一个例子。如果我们正在谈论治理，那么任何时候我们注意到一种无形的力量压倒了一种有形的力量，我们都应该非常关注，因为无形的东西是不负责任的，因此必须被揭示出来。

以太坊社区中的任何人都一定多次遇到过 “路线图” 这个术语，例如在 “以 Rollup 为中心的路线图”、“ETH 2.0 路线图” 中，或者在这次辩论中 “AA 路线图”。

在 Ethereum Magicians 上搜索 “路线图”

为了说明我的观点，让我们想象一个 ACD 会议，核心开发者正在讨论如何扩展以太坊：

• 核心开发者 Bob：我支持 EIP 1234，它建议我们 将区块时间提速 10 倍，将区块大小增加 10 倍，并将费用降低 100 倍。
• 其他核心开发者：……你是不是疯了？

让我们在这里思考一下。为什么核心开发者要驳回 Bob 的话？他只是提出了一种非常合理的扩展形式。Solana 和许多其他 L1 都在这样做，以实现巨大的扩展效果。

原因当然是，这个虚构的 EIP 违反了以太坊自己的 “以 Rollup 为中心” 的扩展路线图，该路线图表示，除其他事项外，对于区块链去中心化来说，普通用户能够运行一个节点至关重要，因此这个虚构的 EIP 是不可能的，因为它会大大增加运行节点的门槛。

我想通过这个例子说明的是，参与 ACD 流程并决定协议更新的核心开发者，受到一种我称之为_路线图_的更高力量的指导。有扩展路线图、AA 路线图、MEV 路线图，等等 —— 它们共同构成了核心开发者做出决定的以太坊路线图。

由于路线图不是治理的正式组成部分，因此无法保证核心开发者与它们保持一致。特别是，由于没有正式的 “批准” 路线图的流程，并非所有路线图都被认为具有同等的合法性。这取决于路线图背后的研究人员努力向核心开发者和更大的社区宣传他们的路线图，以获得合法性，从而获得核心开发者的支持。

就 AA 而言，Vitalik 本人曾多次推动以 4337 为中心的 AA 路线图，多次 场合，但总的来说，主要是 4337 团队（尤其是 Yoav 和 Dror）在会议、在线论坛和 ACD 会议上宣传以 4337 为中心的 AA 路线图。

然而，尽管做出了这些努力，但一些核心开发者强烈反对以 4337 为中心的 AA 路线图。他们认为 7560（客户端最终必须实施的 4337 的原生版本）过于复杂，并且不是 “AA 终局” 的唯一可行候选者。最终，ACD 决定批准 3074，尽管 4337 团队反对它会通过创建一个替代性的 去中心化程度较低 的 AA 技术堆栈来分裂 AA 生态系统。

然而，一旦 3074 获得批准，整个 4337 社区就做出了强烈的反应，迫使核心开发者重新参与 3074 的辩论。然后，辩论 陷入僵局，4337 作者和 3074 作者都无法说服对方，直到 Vitalik 在最后一刻 介入并提出 EIP-7702 作为 3074 的替代方案，该方案明确与以 4337 为中心的 “AA 终局” 兼容，从而推动冲突朝着 AA 路线图的方向发展。

尽管 Vitalik 给人的印象是一位研究人员，但这个事件清楚地表明，Vitalik 为以太坊治理带来了与其他研究人员截然不同的治理权力。因此，这引出了一个问题 —— Vitalik 在以太坊治理中扮演什么角色？

就我个人而言，我发现将 Vitalik 视为 一家非常非常大的公司的 CTO 很有帮助。

（顺便说一句，为了便于类比，这家公司没有 CEO。）

如果你在任何一家员工超过 50 人的科技公司工作过，你就会知道 CTO 不可能参与每一个技术决策。在一定的规模上，技术决策_必然_会变得去中心化 —— 通常公司的每个产品领域都有一个子团队，并且该子团队可以自由地做出关于特定实施细节的决策。

此外，CTO 也不一定是每个（或任何）主题领域的专家。公司里很可能有一些工程师在特定领域比 CTO 更出色。因此，在技术辩论中，通常是工程师做出最终决定。

然而，CTO 设定了公司的技术愿景。愿景的执行留给开发者。

虽然这不是一个完美的类比，但我认为它合理地概括了 Vitalik 在生态系统中的角色。Vitalik 不参与每一个技术决策 —— 他不可能做到。他也不是每个领域的顶级专家。但是，他对以太坊所有关键方面（扩展、AA、权益证明……）的路线图的设定产生了巨大的影响，这不仅是因为他的技术专长，还因为他是判断路线图是否与以太坊的愿景（他的愿景）一致的最终仲裁者。

如果我将 Vitalik 视为以太坊的 CTO 的看法还不够有争议，那么最具有争议的部分来了：我们应该接受 Vitalik 作为 CTO。

作为一名创业公司的创始人，我认为每一个成功的产品（是的，以太坊也是一种 “产品”，因为它为真实的人解决了实际问题）背后都必须有一个连贯的愿景。连贯的愿景必须由少数人来设定，例如创业公司的创始人，而且通常只有一位创始人。

以太坊的优点在于，尽管它是一个如此复杂的系统，有如此多的移动部件，但这些部件完美地组合在一起，形成了一个每天移动价值数十亿美元的功能性去中心化计算机。我们走到今天这一步_不是_通过委员会设计。正是因为 Vitalik 通过他的愿景进行的积极领导，我们才能够获得一个连贯而美丽的产品，即今天的以太坊。以太坊是 Vitalik 在 2015 年的心血结晶，今天仍然如此。

当然，这并不是要贬低其他研究人员和工程师的贡献，他们为以太坊今天的成就做出了最大的贡献。然而，这与以太坊是 Vitalik 愿景的实现这一事实并不矛盾，而且比任何其他人都要多几个数量级。

说实话，你能抱怨吗？当你被以太坊生态系统的开放性、抗审查性和创新步伐所吸引时 —— 你有没有抱怨它始于 Vitalik 的愿景？也许你没有，因为你没有那样考虑 —— 但现在你这样考虑了，你_真的_介意吗？

但是，你会说，去中心化呢？如果一个人对以太坊拥有如此巨大的权力，我们怎么能声称它是去中心化的？

要回答这个问题，我们必须回到 这篇关于去中心化的含义的经典文章，这篇文章是由 Vitalik 撰写的。这篇文章的关键见解是，去中心化有三种类型：

• 架构去中心化：在系统停止运行之前，有多少个节点可以被破坏？
• 逻辑去中心化：系统的子系统是否可以独立演进，同时保持系统运行？还是必须密切协调？
• 政治去中心化：最终有多少人或组织控制这个系统？

鉴于这些定义，以太坊显然是架构去中心化的，并且考虑到其各个组件（例如共识与执行）之间缺乏强耦合，说它也是逻辑去中心化的可能是公平的。

就政治去中心化而言，好消息是没有个人或组织可以关闭以太坊，即使是 Vitalik 也不行。但是，鉴于 Vitalik 在设定其愿景从而定义其路线图中发挥的突出作用，有人可能会争辩说，以太坊的政治去中心化程度不如人们想象的那么高。

但是，我认为 如果我们希望以太坊继续创新，我们必须接受 Vitalik 作为事实上的 CTO，即使这意味着牺牲一些政治去中心化。

如果以太坊像比特币一样 “僵化” 为一个基本上不可变的区块链，那么 Vitalik 就可以退休了。但在我们达到终局之前，至关重要的是，要有一个各方都尊重的权威，并且信任他能对技术决策做出判断，而这些判断不仅仅基于技术优点，还基于它们是否与以太坊的愿景一致。

如果没有像 Vitalik 这样的人物，只有两种结果是可能的，这两种结果都通过 3074 事件得到了生动的说明：

• 以太坊治理可能会陷入无休止的僵局，双方都不愿意妥协，也没有人能够取得任何进展，正如在 Vitalik 介入之前 3074 辩论陷入僵局的情况所见。
• 或者，以太坊可能会最终成为一个由不连贯的设计组成的科学怪人，正如我们已经接近在 3074 和 4337 作为两个基本上不兼容的并行 AA 堆栈的情况下所表明的那样。

我们非常接近拥有一个完整的以太坊治理的思维模型，但到目前为止，我们的讨论中有一个明显的遗漏 —— 社区。

如果 Vitalik 定义了愿景，研究人员遵循这些愿景定义了路线图，而核心开发者又实施了这些路线图 —— 那么社区扮演什么角色？当然不是什么都不做吧？？

幸运的是，社区实际上扮演着最重要的角色。原因是，在有愿景之前，就有价值观。我们聚集在一起成为一个社区，因为我们围绕着某些价值观团结在一起，最终 Vitalik 的愿景必须与这些价值观保持一致，否则它将失去社区。

也许是你的成长经历。也许是你上一份工作中发生的事情。但在某个时候，我们以太坊社区的所有人都认为，拥有一个所有人都可以访问的、无法被审查的、可信中立 的去中心化计算机对世界来说是好事。我们通过我们在以太坊上所做的工作每天都在断言和确认这些价值观，并且通过这样做，我们为 Vitalik、研究人员和核心开发者产生的愿景、路线图和代码提供合法性。

因此，这里有一个完整的以太坊治理思维模型，我称之为 价值观 ⇒ 愿景 ⇒ 路线图 ⇒ 客户端模型，或简称 VVRC：

• V == 价值观 == 社区
• V == 愿景 == Vitalik
• R == 路线图 == 研究人员
• C == 客户端 == 核心开发者

它们一起工作如下：

• 社区 围绕着某些 价值观 团结在一起。
• Vitalik 阐明一个与这些价值观一致的 愿景。
• 研究人员 根据愿景提出 路线图。
• 核心开发者 基于路线图实施 客户端。

由新的 GPT-4o 绘制，画得很糟糕。

由于 “内容政策”，它拒绝绘制 “Vitalik” 这个词。

当然，现实比任何简单的模型所能捕捉到的都要混乱得多。例如，事实上，核心开发者是唯一可以通过实施客户端来对任何决策进行 “投票” 的人。Vitalik 和其他研究人员仅起到咨询作用，有时他们的意见不被核心开发者接受，这就是 3074 获得批准的原因。

也就是说，我认为 VVRC 模型合理地捕捉了以太坊治理在理想情况下是如何运作的，并且我们需要 “调试” 该过程，以便它不会像 3074 那样失败。

现在我们有了一个关于以太坊治理_应该_如何运作的思维模型，这里有一些改进治理过程的想法，以便我们可以避免像 3074/7702 那样经历的剧变。

• 对于正在积极考虑纳入的 EIP，必须有更高的可见性。整个社区绝不应该对 EIP 被接受感到 “措手不及”，就像 3074 的情况一样。
  • 与你可能期望的相反，EIP 网站 上 EIP 的 “状态” 并不能反映它在 ACD 流程中的状态。这就是为什么它仍然说 3074 处于 “审查中”，即使核心开发者已经投票批准了它，并且几乎没有迹象表明它曾经被考虑纳入。
  • 理想情况下，当一个 EIP 即将被接受时，以太坊基金会会在社交媒体上大声宣布，以提高社区的意识。
• 有时，核心开发者可能会低估一个特定的 EIP 对下游项目和用户的影响，3074 和 4337 社区就是这种情况。由于 ACD 会议的时间有限，并且必须跨时区进行协调，因此可以理解的是，只有 “相关人员” 才能在会议上发言。也就是说，_可能_有意义的是，偶尔分配一些时间，让社区成员评论某些 EIP 提案的下游影响。
  • 如果研究人员觉得他们的意见没有被核心开发者接受，就像 4337 团队的情况一样，他们可以将社区成员带入会议，以加强他们的论点。
• 至关重要的是，核心开发者和研究人员之间必须相互认识到他们都是治理权力，尽管他们的优势不同。核心开发者的 “客户端权力” 是唯一可以通过实施客户端来实际 “投票” 的权力。研究人员的 “路线图权力” 通常享有更多的公众支持，这要归功于研究人员积极地谈论和撰写关于他们的路线图的文章。
  • 当这两种权力发生冲突时，核心开发者可能会很想简单地否决研究人员，例如当核心开发者否决 4337 团队的反对意见时。然而，像这样的否决可能会导致剧变，因为当权力处于冲突状态时，它们是不稳定的，正如在 3074 获得批准后发生的闹剧所见。
  • 同样，当面临阻力时，研究人员可能会很想简单地放弃与核心开发者的互动，我认为这是创建 RIP 流程 的原因之一，也是为什么原生 AA (7560) 现在主要作为 RIP 而不是 EIP 被推动的原因。虽然帮助 L2 实验那些对 L1 来说过于有争议的协议更新确实有很多好处，但我们不能将 RIP 视为与 EIP 治理流程互动的替代品。研究人员必须继续与核心开发者互动，直到他们与路线图完全一致。

3074/7702 事件揭示了以太坊治理的真实运作方式 —— 除了核心开发者驱动的 EIP/ACD 流程这种明确的治理权力之外，还有研究人员驱动的路线图这种隐含的治理权力。当这些权力不一致时，我们会看到僵局和剧变，并且可能需要另一种权力 —— Vitalik —— 来将平衡向一方或另一方倾斜。

然后，我们认为 Vitalik 代表了一种独特的权力，即以太坊的 “愿景”，这是任何路线图合法性的基础。我们将 Vitalik 与一家大型公司的 CTO 进行比较，并承认 他作为准 CTO 的角色对于以太坊保持其创新步伐是必要的，而不会退化为由不连贯的设计组成的科学怪人系统。

最后，我们提出了一个关于将以太坊治理视为 VVRC 的思维模型：价值观（社区）⇒ 愿景（Vitalik）⇒ 路线图（研究人员）⇒ 客户端（核心开发者）。然后，我们提出了各种方法来修复有时会导致该过程在实践中偏离此模型的 “错误”。

以太坊治理是 “ 构建机器的机器” —— 要使以太坊正确，我们必须使治理正确。因此，3074 提供了一个关于治理出错时的宝贵案例研究，我希望我能够从中吸取一些有益的教训，以便我们能够在未来改进以太坊治理。

如果你喜欢这篇博文，你可以在 这里 放大它。

• 原文链接： docs.zerodev.app/blog/30...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～