作者：derek，ZeroDev CEO 来源：ZeroDev官网 翻译：善欧巴，
错过 AA 提案风波？这里为你快速回顾：
几周前，核心开发人员批准了 EIP-3074 提案，该提案将为 EOA 用户带来 AA 的许多好处，并进入以太坊的下一个硬分叉“Pectra”。
从那时起，ERC-4337 社区中的许多人，尤其是 4337 作者本身，一直强烈反对3074，理由是中心化问题以及它与以太坊的AA 路线图不兼容，该路线图以 4337 及其表亲 7560 为中心（又名“本地 AA”）。
上周，Vitalik 提出EIP-7702作为 3074 的替代品。它主要实现了相同的目标——为 EOA 用户带来 AA 的许多好处——但在某种程度上与今天的 4337 更兼容，并且向前兼容“AA 残局” ” 那是 7560。
目前，核心开发人员正在审议 EIP-7702，但初步讨论和社区情绪表明 EIP-7702 很可能会取代 Pectra 中的 EIP-3074。
几周前，核心开发人员批准了 EIP-3074 提案，该提案将为 EOA 用户带来 AA 的许多好处，并进入以太坊的下一个硬分叉“Pectra”。
从那时起，ERC-4337 社区中的许多人，尤其是 4337 作者本身，一直强烈反对3074，理由是中心化问题以及它与以太坊的AA 路线图不兼容，该路线图以 4337 及其表亲 7560 为中心（又名“本地 AA”）。
上周，Vitalik 提出EIP-7702作为 3074 的替代品。它主要实现了相同的目标——为 EOA 用户带来 AA 的许多好处——但在某种程度上与今天的 4337 更兼容，并且向前兼容“AA 残局” ” 那是 7560。
目前，核心开发人员正在审议 EIP-7702，但初步讨论和社区情绪表明 EIP-7702 很可能会取代 Pectra 中的 EIP-3074。
就我个人而言，我对结果非常满意：EOA 用户很快就能够使用为 ERC-4337 构建的工具和基础设施享受 AA 的大部分好处。
然而，我不禁感到，我们实现这一成果 的方式 远非最佳，这是许多人在过去几周表达的观点。我觉得通过更好的流程，我们可以共同节省大量的精力和头痛，并更快地达到预期的结果。
在这篇博文中，我想：
确定流程中出了什么问题。
提出一个思考以太坊治理的心理模型。
提出改进建议，以避免将来出现类似的治理失败。
确定流程中出了什么问题。
提出一个思考以太坊治理的心理模型。
提出改进建议，以避免将来出现类似的治理失败。
为什么这个过程让人不高兴
整个事件让很多人感到不高兴，原因如下：
3074花了数年时间才获得批准。
直到3074 最终获得批准 后 ，核心开发人员才遭到 4337 社区的大量抵制。
现在我们正在 取消批准 3074 并将其替换为另一个 EIP (7702)。
3074花了数年时间才获得批准。
直到3074 最终获得批准 后 ，核心开发人员才遭到 4337 社区的大量抵制。
另一方面，4337 的 作者本人也多次向核心开发者表达了他们对 3074 的担忧，但没有结果。
另一方面，4337 的 作者本人也多次向核心开发者表达了他们对 3074 的担忧，但没有结果。
现在我们正在 取消批准 3074 并将其替换为另一个 EIP (7702)。
现在，上述任何内容本质上都没有问题：
讨论花费数年时间是可以接受的。
EIP 在获得批准后收到推迟是可以接受的。
EIP 获得批准后，如果发现新问题，可以取消批准。
讨论花费数年时间是可以接受的。
EIP 在获得批准后收到推迟是可以接受的。
EIP 获得批准后，如果发现新问题，可以取消批准。
然而，我们可能会同意事情本来 可以 进展得更顺利。想象一下如果事情是这样的：
4337 社区在核心开发者讨论 3074 时积极参与其中。现在，只有以下两种结果之一是可能的：
4337 社区在核心开发者讨论 3074 时积极参与其中。现在，只有以下两种结果之一是可能的：
要么在考虑 4337 社区反馈后 批准（并可能修改）3074，在这种情况下，4337 社区将支持 3074，我们不会撤销 3074。
或者，3074 从未获得批准，但 4337 社区和核心开发人员共同努力制定了一个每个人都满意的提案，就像 7702 那样。
要么在考虑 4337 社区反馈后 批准（并可能修改）3074，在这种情况下，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 更新的人们的参与并不友好。一些人还认为，积极寻求相关利益相关者（在本例中为 4337 社区）的反馈应该是 ACD 的责任。
然而，我认为双方都没有达到目标。工作中存在一个更深层次的问题，在我们解决或至少承认这个问题之前，我们将不断遇到治理失败，然后是徒劳的指责。
根本原因
治理失败的真正原因是，与普遍的看法相反，ACD 并不是协议更新的唯一治理权力，在这种情况下，它被另一个治理权力所覆盖。
问题在于，其他治理权力很少被承认，尽管事实上它对以太坊最重要的事务（例如 AA 和扩容）的影响力比 ACD 更大。
在本文中，我将这种力量称为“路线图”。
正如我将要论证的那样，整个 3074/7702 传奇只不过是路线图的力量压倒 ACD 的力量的一个例子。如果我们谈论治理，那么每当我们注意到无形的力量压倒有形的力量时，我们都应该非常担心，因为无形的东西是不负责任的，因此必须将其公之于众。
什么是路线图？
以太坊社区中的任何人都一定经常遇到“路线图”这个术语，例如在“以 Rollup 为中心的路线图”、“ETH 2.0 路线图”或在这场辩论中的“AA 路线图”。
为了说明我的观点，让我们想象一次 ACD 会议，核心开发人员正在讨论如何扩展以太坊：
Core Dev Bob：我支持 EIP 1234，它建议我们将区块时间加快 10 倍，将区块大小增加 10 倍，并降低费用 100 倍。
其他核心开发人员：……你疯了吗？
Core Dev Bob：我支持 EIP 1234，它建议我们将区块时间加快 10 倍，将区块大小增加 10 倍，并降低费用 100 倍。
其他核心开发人员：……你疯了吗？
让我们想一下。为什么核心开发人员直接否决了鲍勃所说的话？他刚刚提出了一种非常合法的扩展形式。Solana 和许多其他 L1 都这样做，从而产生了巨大的扩展效果。
当然，原因是这个虚构的 EIP 违背了以太坊自己的“以 Rollup 为中心”的扩展路线图，该路线图除其他外表明，让普通用户能够运行节点对于区块链去中心化至关重要，因此想象中的 EIP 是不可能的，因为它会大大增加运行节点的障碍。
我想用这个例子来说明的是，参与 ACD 流程并决定协议更新的核心开发人员受到我称之为 路线图 的更高力量的指导。有扩展路线图、AA 路线图、MEV 路线图，凡是你能想到的——它们共同构成了核心开发人员决策的 以太坊路线图。
当核心开发人员与路线图不一致时
由于路线图不是治理的正式组成部分，因此无法保证核心开发人员与路线图保持一致。特别是，由于没有“批准”路线图的正式流程，因此并非所有路线图都被认为具有同等的合法性。路线图背后的研究人员需要努力向核心开发人员和更大的社区宣传他们的路线图，以获得合法性，从而获得核心开发人员的支持。
就 AA 而言，Vitalik 本人曾多次推动以 4337 为中心的 AA 路线图，但总体而言，主要是 4337 团队，尤其是 Yoav 和 Dror，他们在会议、在线论坛、和 ACD 会议。
然而，尽管做出了这些努力，一些核心开发者还是强烈反对以 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 在以太坊治理中扮演什么角色？
就我个人而言，我发现将 Vitalik 视为一家非常非常大的公司的首席技术官很有帮助。
（顺便说一下，出于这个类比的目的，这家公司没有首席执行官。）
如果您曾在任何一家员工超过 50 人的科技公司工作过，您就会知道 CTO 不可能参与每项技术决策。在一定规模上，技术决策 必然会 变得分散——公司产品的每个领域通常都有一个子团队，并且子团队基本上可以自由地就具体实施细节做出自己的决策。
此外，首席技术官也不一定是每个（或任何）主题的最重要的专家。公司中很可能存在在特定领域比 CTO 更好的工程师。因此，在技术争论中，做出最终决定的往往是工程师。
然而，首席技术官制定了公司的技术愿景。愿景的执行留给了开发人员。
虽然这不是一个完美的类比，但我认为它合理地体现了 Vitalik 在生态系统中的作用。Vitalik 并不参与所有技术决策——他不可能参与其中。他也不是每个领域的顶级专家。但他在制定以太坊所有关键方面的路线图（扩容、AA、权益证明……）方面具有压倒性的影响力，不仅因为他的技术专长，还因为他是路线图是否可行的最终评判者。与以太坊的愿景一致—— 他的愿景 。
每个成功的产品都始于一个愿景
如果我对 Vitalik 是以太坊 CTO 的看法对你来说还不够有争议，那么最具争议的部分来了：我们应该接受 Vitalik 作为 CTO。
作为一名初创公司创始人，我认为每一个成功的产品背后——是的，以太坊是一个“产品”，因为它为现实的人们解决了实际问题——必须有一个连贯的愿景。一致的愿景必须由少数人制定，例如初创公司的创始人，而且通常只有一位创始人。
以太坊的美妙之处在于，尽管它是一个如此复杂的系统，有如此多的移动部件，但这些部件完美地组合成一台功能齐全的去中心化计算机，每天都在移动价值数十亿美元的价值。我们走到这一步并不是 通过 委员会的设计。正是 由于 Vitalik 通过他的愿景积极领导，我们才能够实现一个连贯且美丽的产品，这就是今天的以太坊。以太坊是 Vitalik 在 2015 年的创意，至今仍然如此。
当然，这并不是要淡化其他研究人员和工程师的贡献，他们应该为以太坊取得今天的成就而获得大部分功劳。然而，这与以太坊是 Vitalik 愿景的实现这一事实并不矛盾，而且比其他任何人的愿景都要实现几个数量级。
说实话，你能抱怨吗？当您被以太坊生态系统的开放性、抗审查性和创新步伐所吸引时，您是否抱怨它始于 Vitalik 的愿景？也许你不这样做是因为你不这么想——但现在你这样做了，你 真的 介意吗？
那么去中心化呢？
但是但是但是，你说，去中心化怎么样？如果一个人对以太坊拥有如此压倒性的权力，我们怎么能说它是去中心化的呢？
要回答这个问题，我们必须回到咳咳Vitalik写的这篇关于去中心化意义的经典文章。这篇文章的主要观点是，权力下放分为三种类型：
架构去中心化：在系统停止运行之前有多少节点可以受到损害？
逻辑去中心化：系统的子系统能否在保持系统正常运行的同时独立演化？或者说它们必须密切协调？
政治分权：有多少人或组织最终控制这个系统？
架构去中心化：在系统停止运行之前有多少节点可以受到损害？
逻辑去中心化：系统的子系统能否在保持系统正常运行的同时独立演化？或者说它们必须密切协调？
政治分权：有多少人或组织最终控制这个系统？
鉴于这些定义，以太坊在架构上显然是去中心化的，并且考虑到其各个组件之间缺乏强耦合（例如共识与执行），可以公平地说，它在逻辑上也是去中心化的。
就政治去中心化而言，好消息是没有任何个人或组织可以关闭以太坊，甚至 Vitalik 也不能。然而，有人可能会说，鉴于 Vitalik 在设定其愿景并从而定义其路线图方面发挥着重要作用，以太坊在政治上并不像人们想象的那样去中心化。
然而，我认为，如果我们希望以太坊不断创新，我们就必须接受 Vitalik 作为事实上的 CTO，即使这意味着牺牲一些政治权力下放。
如果以太坊“僵化”成像比特币这样几乎不可变的区块链，那么 Vitalik 可能会退休。但在我们到达最后阶段之前，至关重要的是有一个各方都尊重的权威，人们相信他不仅可以根据技术优点对技术决策做出 判断，而且还可以根据它们是否与以太坊的愿景一致来做出判断。
如果没有像 Vitalik 这样的人物，只有两种结果是可能的，这两种结果都在 3074 传奇中得到了生动的说明：
以太坊治理可能会陷入无休止的 僵局 ，双方都不愿意妥协，也没有人能够取得任何进展，正如 3074 辩论在 Vitalik 介入之前一直处于僵局一样。
或者，以太坊最终可能会成为 设计不连贯的弗兰肯斯坦怪物 ，正如我们非常接近将 3074 和 4337 作为两个基本上不兼容的并行 AA 堆栈所表明的那样。
以太坊治理可能会陷入无休止的 僵局 ，双方都不愿意妥协，也没有人能够取得任何进展，正如 3074 辩论在 Vitalik 介入之前一直处于僵局一样。
或者，以太坊最终可能会成为 设计不连贯的弗兰肯斯坦怪物 ，正如我们非常接近将 3074 和 4337 作为两个基本上不兼容的并行 AA 堆栈所表明的那样。
社区的作用
我们非常接近拥有一个完整的以太坊治理心智模型，但迄今为止我们的讨论中有一个明显的遗漏——社区。
如果 Vitalik 定义了愿景，然后是研究人员定义的路线图，而路线图又由核心开发人员实施——社区扮演什么角色？肯定不是什么都没有？？
幸运的是，社区实际上扮演着最重要的角色。原因是，在有愿景之前，先有 价值观 。我们作为一个社区聚集在一起，因为我们围绕某些价值观团结在一起，最终 Vitalik 的愿景必须与之保持一致，否则就会失去社区。
也许这是你的成长经历。也许这是你上一份工作中发生的事情。但在某一时刻，以太坊社区的所有人都认为，拥有一台所有人都可以访问、无法受到审查、可信中立的去中心化计算机对世界来说是一件 好事 。我们每天通过在以太坊上所做的工作来维护和确认这些价值观，并以此为 Vitalik、研究人员和核心开发人员生成的愿景、路线图和代码提供 合法性。
以太坊治理的VVRC模型
那么，这里是以太坊治理的完整心智模型，我将其称为价值观⇒愿景⇒路线图⇒客户模型，简称为VVRC：
V == 价值观 == 社区
V == 愿景 == 维塔利克
R == 路线图 == 研究人员
C == 客户端 == 核心开发人员
V == 价值观 == 社区
V == 愿景 == 维塔利克
R == 路线图 == 研究人员
C == 客户端 == 核心开发人员
他们一起工作是这样的：
社区围绕某些 价值观聚集在一起。
Vitalik 阐述了与这些价值观一致的 愿景 。
研究人员 根据愿景制定了 路线图 。
核心开发人员 根据路线图实施 客户端 。
社区围绕某些 价值观聚集在一起。
Vitalik 阐述了与这些价值观一致的 愿景 。
研究人员 根据愿景制定了 路线图 。
核心开发人员 根据路线图实施 客户端 。
当然，现实比任何简单模型所能捕捉到的都要混乱得多。例如，现实中的核心开发人员是唯一可以通过实现客户端对任何决策进行“投票”的人。Vitalik 和其他研究人员仅起到咨询作用，有时他们的意见不会被核心开发人员接受，这就是 3074 获得批准的原因。
也就是说，我认为 VVRC 模型合理地捕捉了以太坊治理在良好情况下的工作方式，并且由我们来“调试”该过程，以便它不会像 3074 那样失败。
我们如何改善以太坊治理
现在我们已经有了以太坊治理应该 如何运作的心智模型，这里有一些改进治理流程的想法，以便我们可以避免我们在 3074/7702 中经历的那种鞭打。
那些正在积极考虑纳入的生态产业园必须有更多的知名度。整个社区永远不应该对 EIP 被接受感到“惊讶”，3074 就是这种情况。
有时核心开发人员可能会低估特定EIP对下游项目和用户的影响，3074和4337社区就是这种情况。由于 ACD 会议时间有限且必须跨时区协调，因此强调只有“相关人员”才能在会议上发言是可以理解的。也就是说，每隔一段时间分配一些时间让社区成员对某些 EIP 提案的下游影响发表评论 可能是 有意义的。
至关重要的是，核心开发人员和研究人员之间必须相互认识到他们都是治理权力，尽管实力不同。核心开发者的“客户端权力”是唯一能够通过实现客户端来真正“投票”的权力。由于研究人员积极谈论和撰写他们的路线图，研究人员的“路线图力量”通常会获得更多公众支持。
那些正在积极考虑纳入的生态产业园必须有更多的知名度。整个社区永远不应该对 EIP 被接受感到“惊讶”，3074 就是这种情况。
与您的预期相反，EIP 站点上 EIP 的“状态”并不反映其在 ACD 流程中的状态。这就是为什么它仍然说 3074 正在“审查”中，尽管核心开发人员已经投票批准了它，而且几乎没有迹象表明它曾经被考虑纳入其中。
理想情况下，当 EIP 即将被接受时，EF 会在社交媒体上大声而清晰地发布信息，以提高社区意识。
与您的预期相反，EIP 站点上 EIP 的“状态”并不反映其在 ACD 流程中的状态。这就是为什么它仍然说 3074 正在“审查”中，尽管核心开发人员已经投票批准了它，而且几乎没有迹象表明它曾经被考虑纳入其中。
理想情况下，当 EIP 即将被接受时，EF 会在社交媒体上大声而清晰地发布信息，以提高社区意识。
有时核心开发人员可能会低估特定EIP对下游项目和用户的影响，3074和4337社区就是这种情况。由于 ACD 会议时间有限且必须跨时区协调，因此强调只有“相关人员”才能在会议上发言是可以理解的。也就是说，每隔一段时间分配一些时间让社区成员对某些 EIP 提案的下游影响发表评论 可能是 有意义的。
如果研究人员认为核心开发人员没有接受他们的意见（就像 4337 团队的情况一样），他们可以让社区成员参与进来以强化他们的观点。
如果研究人员认为核心开发人员没有接受他们的意见（就像 4337 团队的情况一样），他们可以让社区成员参与进来以强化他们的观点。
至关重要的是，核心开发人员和研究人员之间必须相互认识到他们都是治理权力，尽管实力不同。核心开发者的“客户端权力”是唯一能够通过实现客户端来真正“投票”的权力。由于研究人员积极谈论和撰写他们的路线图，研究人员的“路线图力量”通常会获得更多公众支持。
当两种权力发生冲突时，核心开发人员很容易简单地推翻研究人员的意见，例如当核心开发人员推翻 4337 团队的反对意见时。然而，这样的凌驾可能会导致权力冲突，因为权力在冲突时是不稳定的，正如3074获得批准后接下来的戏剧性事件所示。
同样，当面临阻力时，研究人员很容易放弃与核心开发人员的接触，在我看来，这是创建RIP 流程的原因之一，也是为什么原生 AA (7560) 现在主要作为 RIP 而非 RIP 来推动的原因之一。一个EIP。虽然帮助 L2 尝试协议更新确实有好处，但我们不能将 RIP 视为参与 EIP 治理流程的替代品。研究人员必须继续与核心开发人员合作，直到他们完全符合路线图。
当两种权力发生冲突时，核心开发人员很容易简单地推翻研究人员的意见，例如当核心开发人员推翻 4337 团队的反对意见时。然而，这样的凌驾可能会导致权力冲突，因为权力在冲突时是不稳定的，正如3074获得批准后接下来的戏剧性事件所示。
同样，当面临阻力时，研究人员很容易放弃与核心开发人员的接触，在我看来，这是创建RIP 流程的原因之一，也是为什么原生 AA (7560) 现在主要作为 RIP 而非 RIP 来推动的原因之一。一个EIP。虽然帮助 L2 尝试协议更新确实有好处，但我们不能将 RIP 视为参与 EIP 治理流程的替代品。研究人员必须继续与核心开发人员合作，直到他们完全符合路线图。
结论
3074/7702 的传奇揭示了以太坊治理的 真正运作 方式——除了由核心开发人员驱动的 EIP/ACD 流程的显性治理权力之外，还有由研究人员驱动的路线图的隐性治理权力。当这些力量失去平衡时，我们就会看到僵局和鞭打，可能需要另一种力量——维塔利克——来扭转平衡。
然后我们证明Vitalik 代表了一种独特的力量，即以太坊的“愿景”，这是任何路线图合法性的基础。我们将 Vitalik 与一家大公司的 CTO 进行比较，并承认他作为伪 CTO 的角色对于以太坊保持创新步伐是必要的，同时又不会退化为设计不连贯的弗兰肯斯坦系统。
最后，我们提出了一个将以太坊治理视为VVRC 的思维模型：价值观（社区）⇒ 愿景（Vitalik）⇒ 路线图（研究人员）⇒ 客户（核心开发人员）。然后，我们建议各种方法来修复有时会导致流程在实践中偏离此模型的“错误”。
以太坊治理是“构建机器的机器”——为了让以太坊正确，我们必须让治理正确。因此，3074 为治理出错时提供了一个宝贵的案例研究，我希望我能够从中吸取一些有用的教训，以便我们能够在未来改进以太坊治理。
微信里点“发现”，扫一下二维码便可将本篇文章分享至朋友圈