深入探讨 Vitalik 及各种路线图对以太坊治理的影响

原文标题： 《 Reflecti on s on E the reum Governance Following the 3074 Saga》

作者： Derek Chiang ， ZeroDev 创始人

编译： Faust ，极客 web3

摘要：本文是 ZeroDev 的 CEO Derek Chiang 在 V 神提出 EIP -7702 以平衡 ERC -4337 和 EIP -3074 矛盾后，对此事发表的看法。该文以一个 AA 生态内项目创始人的切身体验，客观的指出了以太坊目前的治理模式及其痛点，一针见血的指出：

以太坊各种治理矛盾之一在于研究员确定的路线图，与 Geth 等客户端开发团队的看法存在分歧，而 Vitalik 以类似于 CTO 的身份成为了最终一锤定音的角色。

Derek 在对 Vitalik 的作用给出肯定评价后，指出了以太坊应该在治理模型上做出哪些改进，这对于以太坊社区和比特币社区都具有很好的参考意义。

正文：如果你此前并不了解以太坊 AA （账户抽象）的相关事件，这里有一个简短回顾：

几周前， EIP -3074 提案获得了以太坊核心开发人员的批准，将纳入下一次硬分叉「 Pectra 」。该提案将为 EVM 带来两个新的操作码，让以太坊 EOA 账户获得近乎原生的 AA 体验。

从那时起， ERC -4337 社区中的许多人，尤其是 4337 的提出者们一直在强烈反对 EIP -3074，理由是担心该提案会带来许多安全隐患，而且与以太坊的 AA 路线图不兼容。在以太坊此前的路线图中，明确指出以 ERC-4337 及相似提案 7560（又名「nativeAA」）为中心。

5 月初， Vitalik 提出了 EIP -7702 作为 EIP -3074 的替代品，在 4337 和 3074 之间达成了平衡——既能为 EOA 用户带来 AA 的体验，但在某种程度上与 ERC-4337 更加兼容，并且与「AA 最终方案」7560 兼容。

目前，以太坊核心开发人员正在考虑 EIP-7702 的事宜，目前的初步讨论结果和社区情绪表明， EIP -7702 很有可能取代上文中提到的 EIP -3074。

就我个人而言，我对这个结果非常满意：EOA 用户很快就能体验到 ERC-4337 生态内的各种产品，享受 AA 带来的大部分好处。但是，我不禁觉得，我们可以有更好的方式来实现上述结果，过去几周内许多人都指出了这一点。我觉得，如果有更好的治理流程，我们本可以节省大量的精力，并更快地实现预期效果。

在这篇文章中，我想：

· 确定治理流程中出了什么问题

· 提出一个思考以太坊治理的思维模型

· 提出改进建议，以避免未来出现类似的治理事故

EIP -3074 事件的总结与反思

前文提到的故事让很多人不高兴，原因如下：

EIP-3074 花了数年时间才获得批准。在 3074 最终获得批准后，以太坊核心开发人员才受到来自 4337 社区的强烈反对。

另一方面， ERC -4337 的作者们多次向以太坊核心团队表达自己对 EIP -3074 的担忧，但无济于事。现在以太坊正计划取消批准 3074，并用另一个 EIP（7702）替代它。

上述流程中任何一点，本质上都没有错：

· 关于一个 EIP 的讨论可能需要几年时间，这是正常的。

· EIP 在获得批准后遭到拒绝是正常的。

· 如果发现新问题，可以在 EIP 被批准后撤销批准。

然而，事情本来可以更顺利的解决。让我们想象一下，如果事情这样发展：

在讨论 3074 时，4337 社区积极与以太坊核心开发人员互动。如果这个前提假设成立，接下来只有两种结果：

· 在考虑了 4337 社区反馈后，3074 提案得到批准（并可能被修改），在这种情况下，4337 社区会接受 3074，而以太坊核心团队也不必撤销 3074。

· 亦或是，3074 从未被批准，但 4337 社区和以太坊核心团队共同提出了让所有人都满意的提案，就像 7702 一样。

每个人的声音都能被听到，而且没有戏剧性的逆转。这本来会很好——那么事实为何不是这样呢？

什么地方出了错？

回顾整个过程，事件双方都在互相指责对方。

以太坊核心开发人员（以及 EIP -3074 的作者）认为这是「4337 支持者」的错误，因为他们没有积极参与全体核心开发人员 ( ACD ) 讨论流程，在此流程中，EIP 需要经过长时间的审议，最终才会被 Geth 等以太坊客户端开发团队接受并实现。

有人认为，在 3074 提案被审议期间，「4337 支持者」完全可以参与进来，并表达他们的看法，而不是等到 3074 已经获得批准后才马后炮。毕竟， ACD 整个流程都有据可查，会议对所有人开放，而且像 TimBeiko 在每次 ACD 会议后都会积极发布总结性的推文。那么，如果 4337 支持者如此关心这个话题，为什么他们不积极且及时参与相关会议呢？

另一方面，4337 的核心成员指出，他们一直在参加 ACD 会议，并尽可能地反对 3074，但以太坊核心开发人员不听。至于 4337 社区成员，他们大多感到突如其来——很多人都以为 3074 已经凉透了，甚至不知道 3074 正大概率被批准。

许多人指出， ACD 会议的全流程很不透明，对那些在以太坊社区里「认真做事」，但无法及时跟进 ACD 更新进度的人而言并不友好。一些人还认为，ACD 应该主动积极的向利益相关者（这里指 4337 社区）征询反馈。

然而，我认为双方都没有切中要害。这背后还有更深层次的问题，除非我们解决或至少承认这个问题，否则我们将持续的陷入治理事故，然后矛盾双方互相指责对方，但这毫无意义。

治理事故的根本原因：路线图

与普遍看法相反，治理事故的根源在于， ACD 并不是以太坊协议更新的唯一治理权来源，它被另一种治理权来源所取代。而这里的问题就在于，尽管另一种治理权力在以太坊核心问题（如 AA 和扩展性）上的影响力比 ACD 还大，但它却很少被承认。

在本文中，我将这种力量称为「路线图」。

正如我下面要指出的，整个「3074-4337-7702」治理故障事件，是以太坊既有路线图的权力压倒 ACD 权力的一个案例。如果我们谈论的是治理，当我们注意到有一种无形力量压倒了有形力量，我们应该对此极其担心，因为无形的东西往往很难解释并无法被太多人注意到，因此必须将其揭露。

什么是路线图？

以太坊社区中的任何人都一定经常看到「路线图」一词，例如在「以汇总为中心的路线图」，「 ETH2 .0 路线图」中，或者和此次事件相关的「 AA 路线图」。

为了说明我的观点，让我们想象一下 ACD 会议中的场景，其中核心开发人员们正在讨论如何为以太坊扩容：

· 某核心开发人员 Bob ：我支持 EIP -1234，该提案建议我们将出块速度加快 10 倍，将区块大小增加 10 倍，将费用降低 100 倍。

· 其他核心开发人员：……你疯了吗？

让我们想一想。为什么以太坊核心团队会拒绝 Bob 说的东西？他只是提出了一种看起来非常合理的扩容方式， Solana 和 Aptos 、 Sui 等许多公链都这么做了，并取得了很高的 TPS 。

原因是，这个虚构的 EIP-1234 违背了以太坊的「以 rollup 为中心」的扩容路线图，该路线图指出，对于去中心化而言，普通用户能否低成本的运行节点至关重要，因此虚构的 EIP-1234 不可能被接受，因为它会大幅增加运行以太坊节点的成本。

我想用这个例子来说明，参与 ACD 治理流程并决定协议更新的核心开发人员，受到一种更高级力量的指导，我称之为「路线图」。目前围绕着以太坊的路线图，有「扩容路线图」、「AA 路线图」、「MEV 路线图」等等，它们共同构成了以太坊的整体路线图，核心开发人员必须以此为基础做出决策。

当核心开发人员的观点与路线图不一致

由于路线图不是以太坊治理流程中的正式组成部分，因此往往无法保证核心团队会遵守路线图。而且，并没有「批准」路线图的正式流程，所以并不是所有路线图都具有同等的「正统性」。以太坊路线图背后的研究人员必须努力向核心开发者和社区宣传他们的路线图，以此获得「正统性」，从而获得以太坊核心开发团队的支持。

就 AA 和账户抽象而言， Vitalik 本人曾多次推动以 4337 为中心的 AA 路线图，但总体而言，主要是 4337 背后的团队，尤其是 Yoav 和 Dror ，在论坛和 ACD 会议上倡导以 4337 为中心的 AA 路线图。

然而，尽管做出了这些努力，一些以太坊核心开发者仍然强烈反对以 4337 为中心的 AA 路线图。他们认为 7560（以太坊客户端未来要实施的 4337 原生版本）过于复杂，并不是「AA 终局」的唯一可行方案。最终， ACD 决定批准 3074 提案，尽管这遭到了 4337 团队反对，后者认为 3074 会使得整个 AA 生态系统割裂开。

3074 获得批准后，整个 4337 社区都做出了强烈反应，迫使以太坊核心开发人员重新参与 3074 的讨论。讨论随后陷入僵局，4337 的作者和 3074 的作者都无法说服对方， Vitalik 在最后一刻提出 EIP -7702 作为 3074 的替代方案，该方案明确兼容以 4337 为中心的「AA 终局」，从而化解冲突并使得最终结果和 AA 路线图能够贴合。

Vitalik 的角色：以太坊实质上的 CTO

尽管 Vitalik 以研究员的身份自居，但上述故事清楚地表明， Vitalik 拥有与其他研究员截然不同的治理权力。因此，问题来了：Vitalik 在以太坊治理中扮演什么角色？

就我个人而言，我认为将 Vitalik 视为一家非常非常大的公司的 CTO 可能并无不妥（顺便说一下，为了贴合实际情况，假设以太坊这个「公司」没有 CEO ）

如果你曾经在一家拥有超过 50 名员工的科技公司工作过，你就会知道 CTO 不可能参与每一项技术决策。当公司规模达到一定程度后，各项技术方案的决策流程必然变得分散——通常公司产品 / 业务的每个领域都有一个专属团队，而该团队通常可以自由地决定方案细节。

此外， CTO 也不一定在所有（或任何）话题上都是顶尖专家。公司中可能有一些工程师在特定领域比 CTO 更优秀，因此，在技术细节的方案讨论上，往往是各个工程师做出最终决定。

然而， CTO 制定了公司的技术愿景。愿景的执行则留给开发人员。

虽然这不是一个完美的类比，但我认为它合理地概括了 Vitalik 在以太坊生态中的角色。Vitalik 不会参与每一项技术决策——他也不可能参与。他也不是每个领域的顶尖专家。但他对制定以太坊所有关键方案（扩容、 AA 、 POS ……）的路线图有着压倒性的影响力，这不只是因为他的技术专长，还因为他是「路线图是否符合以太坊愿景（他的愿景）」的最终判断者。

每一个成功的产品都始于一个愿景

如果我认为 Vitalik 是以太坊的 CTO 还不够引起争议的话，那么最具争议的部分来了：我们应该拥抱 Vitalik 担任 CTO 。

作为一名创业公司的创始人，我认为每一款成功的产品背后都必须有一个连贯的长期愿景——没错，以太坊也是一款「产品」，因为它能为真正的用户解决真正的问题。而连贯的愿景必须由少数人制定，比如创业公司的创始人，而且通常只有一位创始人。

以太坊的美妙之处在于，尽管它是一个非常复杂的系统，有如此多的组件，但各个组件却完美地组合在一起，形成了一台运转良好的去中心化计算机，每天结算着价值数十亿美元的交易活动。

我们之所以能走到今天，并不是通过某些委员会的方案设计，正是因为 Vitalik 凭借他的远见卓识发挥了积极的领导作用，我们才能够打造出今天连贯而美丽的以太坊。以太坊是 Vitalik 在 2015 年提出的创意，至今依然如此。

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

说实话，你能对此抱怨吗？当你被以太坊生态系统的开放性、抗审查性和创新速度所吸引时，你是否抱怨过它始于 Vitalik 的愿景？也许你没有抱怨，因为你没有这样想过——但现在你有了，但你真的介意这个问题吗？

去中心化怎么解决？

但是，你会说，去中心化又如何呢？如果一个人对以太坊拥有如此压倒性的权力，我们怎么能说它是去中心化的呢？

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

· 架构去中心化：有多少个节点故障后系统会停止运转？

· 逻辑上的去中心化：系统的各个子系统能否在让系统整体正常运转的同时独立发展？还是必须紧密协调？

· 政治分权：最终有多少人或组织控制这个系统？