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

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

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

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

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

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

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

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

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

在这篇文章中，我想：

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

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

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

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 并不是以太坊协议更新的**治理权来源，它被另一种治理权来源所取代。而这里的问题就在于，尽管另一种治理权力在以太坊核心问题（如 ** 和扩展性）上的影响力比 ACD 还大，但它却很少被承认。

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

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

什么是路线图？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

去**化怎么解决？

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

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

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

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

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

根据这些定义，以太坊显然在架构上是去**化的，而且可以说它在逻辑上也是去**化的，因为它的各个组件之间缺乏强耦合（例如共识层与执行层）。

就政治去**化而言，好消息是没有**个人或组织能够关闭以太坊，甚至 Vitalik 也不行。然而，有人可能会认为，以太坊的政治去**化程度并不像人们想象的那么高，因为 Vitalik 在制定以太坊愿景和路线图方面发挥了重要作用。

然而，我认为，如果我们希望以太坊继续创新，就必须接受 Vitalik 担任事实上的 CTO，即使这意味着牺牲一些政治上的去**化。

如果以太坊真的像比特币一样「僵化」成几乎不可改变的区块链，那么 Vitalik 可能直接退休。但在我们达到那**一步前，至关重要的是要有一个各方都尊重的权威，这个权威值得信赖，能够对技术决策做出判断，不仅基于提出的技术方案是否优越，还基于这些决策是否符合以太坊的愿景。

如果没有 Vitalik 这样的人物，那么就只可能出现两种结果，围绕 3074 的故事生动地说明了这两种结果：

· 以太坊治理流程可能会陷入无休止的僵局，矛盾双方都不愿意妥协，也没有人能够取得进展，正如 3074 辩论在 Vitalik 介入之前陷入僵局所表明的那样。

· 或者，以太坊可能会变成一个设计不连贯的「弗兰肯斯坦」（译者注：科幻小说《科学怪人》中描绘的一个怪物，由科学家在不同死人尸体上各取一部分拼凑成了一个「人」）。前面提到的 3074 和 4337 可能互不相让，**让 ** 生态**割裂出两个不兼容的平行空间。

社区的作用

经过了上述思考，我们快要勾勒出一个完整的以太坊治理思维模型了，但到目前为止，我们的讨论中有一个明显的遗漏——社区。

如果 Vitalik 定义了以太坊的愿景，研究员们定义了路线图，核心开发人员又实施了路线图，那么社区又扮演了什么角色呢？肯定不是什么都不做吧？

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

以太坊社区的所有人都认为，拥有一台所有人都可以访问、不受审查、可信中立的去**化计算机对世界有益。我们每天通过在以太坊上所做的工作，来维护和肯定上述价值观，并通过这样做为 Vitalik、研究员和核心开发人员制定的愿景、路线图和代码提供正统性。

以太坊治理的 VVRC 模型

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

· V==价值观==社区；

· V==愿景==Vitalik；

· R==路线图==研究人员；

· C==客户端==核心开发人员；

它们一起发挥了如下作用：

· 社区凝聚在某些特定的价值观周围。

· Vitalik 表达了与这些价值观一致的愿景。

· 研究人员根据愿景制定路线图。

· 核心开发人员根据路线图实现客户端。

当然，现实比**简单模型所能捕捉到的要复杂得多。事实上，以太坊核心开发人员是**能够通过对客户端代码的改动，对任意提案真正「投票」的人。Vitalik 和其他研究员只起到顾问的作用，有时他们的意见不被核心开发者接受，而这正是 EIP-3074 获得批准的原因。

话虽如此，我认为 VVRC 模型合理地捕捉了以太坊的治理模式在通常情况下的运转方式，而我们需要「调试」该过程，使其不会再出现 EIP-3074 那样的事故。

如何改善以太坊的治理模型

现在我们已经对以太坊治理流程如何运作有一个心理模型，这里有几个改进治理流程的想法。

必须提高正在被审议的 EIP 的讨论进度可见性。整个社区不应该对 EIP 被接受感到「意外」，像 3074 这种让人感到意外的提案批准方式不该再出现。

目前 EIP 网站上的 EIP「状态」并不反映其在 ACD 流程中的状态。这就是为什么它仍然说 3074 处于「被审核」状态，尽管核心开发人员已经投票批准了它，甚至没有迹象表明它从一开始就被考虑批准。

理想情况下，当 EIP 即将被接受时，以太坊基金会要在社交媒体上大声明确地宣布该结果，以提高社区的认知度。

有时核心开发人员可能会低估特定 EIP 对下游项目和用户的影响，3074 和 4337 社区就是这种情况。由于 ACD 会议时间有限，并且必须跨时区协调，会议往往只有「相关人员」才能发言。

话虽如此，偶尔为社区成员分配一些发言时间，对某些 EIP 提案通过后对下游的影响发表评论，也是有意义的。

如果研究员觉得他们的意见没有被核心开发人员接受，就像 4337 的情况一样，他们可以请社区成员参与进来以强化他们的主张。

至关重要的是，核心开发人员和研究人员必须相互承认，尽管实力不同，但他们都是以太坊治理权力的一部分。核心开发人员对以太坊客户端的改动与更新权，是**能通过对协议本身进行变更，而给出「投票」的权力。研究人员对路线图的变更和解释权通常有更多的公众支持，这要归功于研究员积极谈论和撰写他们的构想。

当这两大势力发生冲突时，核心开发人员可能会倾向于直接**研究人员的意见，例如核心开发人员**了 4337 团队的反对意见。然而，这种**可能会导致冲突，因为两大势力发生冲突时会变得不稳定，3074 获得批准后发生的戏剧性事件表明了这点。

同样，当面临阻力时，研究员可能会倾向于放弃与核心开发人员的合作，在我看来，这也是创建 RIP 流程的原因之一，也是为什么原生 **(7560) 现在主要作为 RIP 而不是 EIP 进行推广的原因。

虽然在 L2 上试验那些对 L1 来说有争议的协议更新确实有好处，但我们不能将 RIP 视为参与 EIP 治理流程的替代品。研究人员必须继续与核心开发人员合作，直到双方的价值观都**符合路线图。

结论

3074/7702 事件揭示了以太坊治理的真正运作方式——除了核心开发人员推动的 EIP/ACD 流程的显性治理权力之外，还有由研究员推动的路线图的隐性治理权力。当这些权力错位时，我们会看到僵局和鞭策，而可能需要另一种力量——Vitalik——来以某种方式打破平衡。

然后，我们提出 Vitalik 代表着一种独特的力量，即以太坊的「愿景」，这是**路线图正统性的基础。我们将 Vitalik 与一家大公司的 CTO 进行比较，并承认他作为伪 CTO 的角色对于以太坊保持创新步伐是必要的，这可以防止以太坊退化为「弗兰肯斯坦」式的的缝合怪。

**，我们提出了一个描述以太坊治理模型的 VVRC 模型：价值观（社区）⇒愿景（Vitalik）⇒路线图（研究员）⇒客户端（核心开发人员）。然后，我们提出了各种方法来修复此模型的「错误」。

以太坊治理是「制造机器的机器」——要让以太坊正确运作，我们必须合理的治理。因此，3074 为治理事故供了一个宝贵的案例，我希望以太坊社区能够从中吸取一些有用的教训，以便改善未来的以太坊治理流程。