作者：Derek Chiang，CEO of ZeroDev

原文标题：Reflections on Ethereum Governance Following the 3074 Saga

编译：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。文章的关键见解是去中心化有三种类型：
  • 架构去中心化：有多少个节点故障后系统会停止运转？
  • 逻辑上的去中心化：系统的各个子系统能否在让系统整体正常运转的同时独立发展？还是必须紧密协调？
  • 政治分权：最终有多少人或组织控制这个系统？
根据这些定义，以太坊显然在架构上是去中心化的，而且可以说它在逻辑上也是去中心化的，因为它的各个组件之间缺乏强耦合（例如共识层与执行层）。
就政治去中心化而言，好消息是没有任何个人或组织能够关闭以太坊，甚至Vitalik也不行。然而，有人可能会认为，以太坊的政治去中心化程度并不像人们想象的那么高，因为Vitalik在制定以太坊愿景和路线图方面发挥了重要作用。
然而，我认为，如果我们希望以太坊继续创新，就必须接受Vitalik担任事实上的CTO，即使这意味着牺牲一些政治上的去中心化。
如果以太坊真的像比特币一样“僵化”成几乎不可改变的区块链，那么Vitalik可能直接退休。但在我们达到那最终一步前，至关重要的是要有一个各方都尊重的权威，这个权威值得信赖，能够对技术决策做出判断，不仅基于提出的技术方案是否优越，还基于这些决策是否符合以太坊的愿景。
如果没有Vitalik这样的人物，那么就只可能出现两种结果，围绕3074的故事生动地说明了这两种结果：
·以太坊治理流程可能会陷入无休止的僵局，矛盾双方都不愿意妥协，也没有人能够取得进展，正如3074辩论在Vitalik介入之前陷入僵局所表明的那样。
·或者，以太坊可能会变成一个设计不连贯的“弗兰肯斯坦”（译者注：科幻小说《科学怪人》中描绘的一个怪物，由科学家在不同死人尸体上各取一部分拼凑成了一个“人”）。前面提到的3074和4337可能互不相让，最后让AA生态彻底割裂出两个不兼容的平行空间。

社区的作用

经过了上述思考，我们快要勾勒出一个完整的以太坊治理思维模型了，但到目前为止，我们的讨论中有一个明显的遗漏——社区。
如果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流程的原因之一，也是为什么原生AA(7560)现在主要作为RIP而不是EIP进行推广的原因。

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

结论

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

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

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

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