社区共识、分叉领头羊与ACD工作组 - Magicians / 流程改进

以太坊治理中最重要的一项决策是为网络升级选择旗舰功能。从字面上看，这关系到数十亿美元。此外，我们做出的每一个决定都会限制我们未来的设计空间，而优柔寡断会带来实际成本，因为以太坊并非孤立存在。如果我们犹豫不决，优先考虑错误的事情或未能执行，我们就有可能将阵地让给具有截然不同价值观的生态系统。

因此，确保我们为硬分叉选择正确的“头条新闻”是 AllCoreDevs 优化过程中最重要的责任。 我们不应该仅仅评估提案是否有益，而应该证明它们相对于其他扩展、强化或简化以太坊的工作的价值。

这篇文章建立在我之前的提案重新配置 AllCoreDevs的基础上，通过这个视角评估以太坊治理，并就我们的决策过程提出一些实际改进建议，特别是围绕核心重点和硬分叉的头条功能达成一致。

请注意，这只是我个人的观点：不应将其视为“EF 观点”或“AllCoreDevs 共识”。我完全期待并欢迎来自以太坊社区的不同意见！

粗略（社区）共识

以太坊的治理理念受到互联网工程任务组 (IETF) 的启发，特别是“粗略共识”的概念，其微妙之处在 RFC 7282 中得到了很好的阐述。简而言之，粗略共识旨在务实地迭代至所有利益相关者都可以接受的解决方案，即使是不完美的解决方案，同时仔细考虑所有知情的意见。在最好的情况下，它通过合法的流程产生更高质量的解决方案，同时拒绝国王、总统和沙阿。

“同样，达成共识本身并不是目标。达成共识是我们在流程中为了获得最佳解决方案而做的事情。特别是，“宣布”共识不是最终目标。在讨论结束时为了说有共试图宣布共识往往会使我们回到我们试图避免的投票心态。”——RFC 7282

以太坊的方法历来以核心开发人员的共识为中心，这种共识隐含地假定了更广泛的社区一致性。然而，核心开发人员虽然负责编写保护以太坊网络的代码，但并不垄断它。以太坊的治理结构包括更多的利益相关者，从节点运营商到应用程序开发人员、用户等等。

为了保持合法性，尤其是在生态系统成熟之际，AllCoreDevs 的决策必须积极考虑并与更广泛的以太坊社区保持一致。如果我们未能实现并清楚地传达这种一致性，我们可能会面临利益相关者从“发声”到“退出”的风险，要么通过有争议的升级，要么逐渐迁移到竞争生态系统。

因此，核心开发人员之间的粗略共识虽然是必要的，但还不够……对于主要的协议更改，我们需要来自受影响的以太坊利益相关者的明确、有记录的共识。如果无法达成完全共识，我们至少应透明地记录不同意见，并清楚地解释我们为何接受某些权衡。

这样做将有助于确保以太坊继续通过合法的流程提供有意义的改进。

EOF & Fusaka

希望这种背景能够解释我非常规地从 Fusaka 中删除 EOF 的理由。

多年来，已经提出了不同变体的 EOF，包括在网络升级中，随后又将其删除（参见 上海、Dencun），这通常反映了人们对其相对于其他核心功能的紧迫性的不断变化的共识。去年，EOF 被安排在 Pectra 升级中，直到该分叉被拆分以尽量减少范围，将 PeerDAS 和 EOF 都移至 Fusaka 中。

虽然核心开发人员普遍支持 EOF，但即使在那时有些人也表示强烈反对。EOF 拥护者努力解决这些反对意见，扩展技术规范并模块化提案，以便更清晰地进行决策。与此同时，以太坊社区越来越清楚地认识到，发布 PeerDAS 应该是 Fusaka 的首要任务。

随着实施的继续，来自以太坊堆栈中多个利益相关者的复杂性问题重新浮出水面。核心开发人员在 ACDE 208 中重申了 EOF 包含在 Fusaka 中的决定，明确支持了最全面的 EOF 版本。然而，众多生态系统参与者 继续表达反对意见，理由从具体的设计选择到对复杂性、生态系统碎片化和稀缺工程资源分配的更广泛担忧。

在 ACDE#210 之前不久，一些核心开发人员意识到他们首选的 EOF 选项（选项 A）意外地对开发人员体验产生了重大负面影响。虽然之前已经标记了这些问题，但它们的严重性尚未得到充分认识。客户端团队同意紧急审查这些影响并在下一次 测试/互操作 #34 电话会议之前解决这些问题。

在这次电话会议中，客户端团队和生态系统参与者普遍同意推进不同的、不太全面的 EOF 版本（选项 D）。然而，在电话会议接近尾声时，人们越来越清楚地意识到该版本的影响仍然存在不确定性，Reth 团队在更好地理解与遗留合约的交互后变得强烈反对。在这个过程的后期出现的这种普遍的困惑和意见的极端转变是最终导致我取消 EOF 的 Fusaka SFI 资格的最终数据点。

我意识到后期删除会对我们当前治理流程的感知合法性产生负面影响。然而，严格遵循我们当前方法的“字面意思”，即尽管存在重大未解决的担忧，仍然保留 EOF，将违反我们希望演变成为的更具包容性的治理的精神。

换句话说，仅考虑最终删除 EOF 的电话会议所描绘的情况与更全面地看待该过程所描绘的情况截然不同，在这个过程中：

• 关于升级头条新闻的决策是 AllCoreDevs 最关键的输出；
• 以太坊的不可变性意味着更改本质上是永久性的，需要保守的谨慎态度，以防止包含可能令人遗憾的复杂性；
• EOF 反复难以在更广泛的社区内获得强大的“粗略共识”，即使核心开发人员的立场随着时间的推移而发生变化；
• 社区共识认为 PeerDAS 应该是头号优先事项，这一点非常明确且一致；
• 一个更具包容性、结构化的治理流程可能会更早地突出这些问题，从而防止最后一刻的反转。

我们的流程最终在许多方面都失败了。它辜负了核心开发人员，他们投入时间和资源来开发 EOF。它辜负了更广泛的社区，他们觉得他们无法有效地表达他们的担忧或对最终的优先级排序决策发表意见。它还未能充分沟通何时以及如何做出某些决定，从而给已经复杂的情况增加了不必要的动荡，影响了开发人员的士气和对更广泛的 EVM 改进的推动。

展望未来，至关重要的是，我们达成一致，就如何更好地为网络升级设定优先级，从而明确且持续地使我们的决策与以太坊扩展、强化和简化协议的更广泛目标保持一致。如果 EOF 确实是以太坊的首要任务，那么这种演进的流程应该有助于它以更清晰、更强大的共识出现。如果不是，改进的优先级排序将阐明什么是真正重要的，从而使核心开发人员和更广泛的社区能够自信地将其资源投入到以太坊未来最具杠杆作用的计划中。

选择硬分叉的重点和头条新闻

再次强调，为网络升级选择旗舰功能是以太坊最高风险的治理决策。尽管如此，我们当前的方法仍然缺乏明确的结构来评估这些关键功能的优先级。因此，我们需要一个更严格、更透明且与社区保持一致的流程。

下面，我提出了一种方法，使头条新闻的选择更加周到和集中，明确欢迎来自整个以太坊社区的结构化输入，而不仅仅是核心开发人员，同时维护 AllCoreDevs 对保持以太坊安全的承诺。

定义分叉重点

在每个升级周期开始时，AllCoreDevs 应该清楚地定义即将到来的分叉的战略重点或“分叉重点”。这提供了一个共享的、与社区保持一致的目标，指导候选头条功能的评估。

定义此分叉重点应明确邀请来自整个以太坊生态系统的结构化输入。虽然不一定形式化为独立的工件，但这个共同目标应提供战略清晰性，并围绕优先级提前达成一致。

潜在分叉重点的说明性示例包括：

• 可扩展性和更低的费用：有意义地提高吞吐量，降低交易成本，并解锁新的用例。

• 开发人员和用户体验：简化协议复杂性，增强智能合约安全性，并减少开发摩擦。

• 安全性和弹性：加强网络的安全态势，提高抗攻击能力，并在不损害去中心化或抗审查性的情况下减轻新兴威胁。

应积极寻求围绕分叉重点的社区共识，尤其是在受结果影响最大的利益相关者中。虽然 AllCoreDevs 最终拥有实施细节，但明确定义分叉重点应该反映来自社区的广泛、可信的输入，直接解决以太坊的最高优先级需求。

趋同于头条新闻

一旦确定了分叉重点，我们就可以就具体的头条功能达成一致。在实践中，这将经常是一个迭代的过程，其中最初的提案进一步澄清和完善总体重点。最终，AllCoreDevs 每次升级必须只选择一个或最多两个（每层一个）旗舰功能。

现有的 PFI → CFI → SFI 框架仍然适用于此。与直觉相反的是，我们对旗舰功能 CFI/SFI 状态的技术门槛可能低于常规 EIP，但这仅当它们与所选择的分叉重点强烈一致并享有强大的社区支持时。某些功能（例如，The Merge）非常重要，值得全力以赴，尽管最初的规范不完善。其他功能，例如 EOF，可以作为一组 EIP 呈现，甚至是非核心 EIP，例如与 gas 限制相关的那些。

一旦某个功能被拒绝作为潜在的头条新闻，它就不能在同一个分叉周期内作为常规 EIP 返回，以防止后门重新排序。

头条新闻提案（从 PFI 开始）应通过以太坊魔法师线程明确构建，这些线程遵循一个清晰的模板，例如：

头条新闻提案模板

• 摘要 (ELI5)：简洁、通俗易懂地解释提案、为什么重要以及谁直接受益。

• 详细理由：

  • 主要和次要好处是什么，最好由数据或具体的理由支持？

  • 清楚地阐明“为什么是现在？”——为什么这个功能应该在今天优先考虑？

  • 证明这种特定方法与替代解决方案相比的合理性（更低的风险，更高的价值）。

• 利益相关者影响：

  • 积极：清楚地识别受益者并记录明确的支持。

  • 消极：识别可能受到负面影响的人员，概述反对意见，并描述缓解措施或解释接受的权衡。

• 技术准备情况： 清楚地评估技术成熟度，并链接到规范、测试、客户端实现等。

• 安全性和未解决的问题： 明确记录已知的安全风险、未解决的问题或不明确的方面。包括威胁模型、初步审计计划或后续步骤。

这种结构化的选择过程明确针对主要的协议改进。较小的、增量的 EIP 应该继续通过现有的轻量级治理流程，保持敏捷性并尽量减少开销。

社区输入和迭代审查

对于核心开发团队以外的利益相关者来说，了解何时以及如何深入参与以太坊治理可能具有挑战性。为了解决这个问题，我提出了一个两阶段的社区输入流程——一种“杠铃”策略：在开始时进行明确的、结构化的社区参与，并在实施周期接近尾声时使用社区测试网进行验证。

最初，我们应该积极地从整个以太坊生态系统中征集头条新闻提案，清楚地表明何时社区输入最有价值。使用上面概述的“头条新闻提案模板”，这种结构化的早期输入确保核心开发人员的注意力集中在与以太坊战略优先级明确一致的提案上。在实施周期结束时，一个专门的临时测试网为更广泛的社区提供了一个明确的机会来实际验证拟议的更改，主要保留后期反对意见用于关键实施或安全问题。

审查和决策机制

硬分叉头条新闻的选择应明确地与重新配置 AllCoreDevs 帖子中阐述的更广泛的以太坊升级计划周期集成。通过将头条新闻的选择锚定在已建立的 PFI → CFI → SFI 框架内， 并清楚地定义其与重组后的 AllCoreDevs 电话会议（ACD{E|C} 和 ACDT）的关系，我们可以提供一个清晰、可预测的治理流程。

以下是此流程每个周期如何明确展开：

• 公开征集提案： 在每个升级周期开始时，随着上一个分叉接近最终实施，AllCoreDevs 清楚地宣布公开征集头条新闻提案。倡导者在以太坊魔法师上异步提交结构化提案，明确将其提案与已建立的分叉重点保持一致。

• 集中的社区参与： 核心开发人员、基础设施团队、Layer2项目、应用程序开发人员和其他利益相关者提供结构化反馈，明确强调他们的支持或担忧。清楚地标记此审查窗口可确保利益相关者准确地知道何时他们的输入最有影响力，从而激励高质量、条理清晰的响应。

• 异步和同步审查： 提案最初会进行异步审查，允许倡导者根据结构化的社区输入来完善他们的想法。然后，在专门的 ACD{E|C} 路线图规划电话会议期间，同步呈现和讨论这些经过完善的提案，从而实现直接澄清和集中的辩论。

• 迭代完善和最后征求意见： 在同步讨论之后，倡导者会根据反馈进一步迭代他们的提案。正式的“最后征求意见”异步审查提供了明确的最终机会，以进行全面的社区评估。

• 最终选择和粗略共识： 最终，AllCoreDevs 在专门的同步呼叫中选择头条新闻，清楚地考虑利益相关者的输入，这些输入与每个群体的影响程度和与以太坊声明的分叉重点的对齐程度成正比。例如，以 DeFi 为中心的更改应明确权衡来自 DeFi 团队和用户的反馈。

社区测试网

在选择头条新闻和初始实施之后，会启动一个专门的临时测试网（类似于 湄公河 测试网），为社区提供实施测试平台。这应该是生态系统参与功能和提出规范更改的“最后征求意见”。在此阶段之后，预计只有重大的安全问题或严重的意外问题才会延迟或停止部署。

明确地对决策进行排序并在每个步骤中清楚地传达期望有助于避免不必要的动荡并提高合法性。正如“重新配置 AllCoreDevs”帖子中所强调的那样，大多数这种迭代规划和测试将与上一个分叉的实施并行发生，从而使以太坊能够逐步提供升级，而不会出现长时间的延迟。

正式化 ACD 工作组

以太坊最大的升级（如 EIP-1559、The Merge 和 EIP-4844）需要在主网上发布之前进行多年的专门工作。这些努力中的大多数都来自重复出现的分组讨论室和集中的社区讨论，通常没有明确地从 AllCoreDevs 那里获得协调或明确的检查点。虽然这种非正式方法提供了灵活性，但它也冒着大量资源被花费在停滞不前或偏离以太坊核心优先事项的想法上的风险。

为了解决这个问题，我建议将现有的分组结构正式化为明确定义的工作组 (WG)：明确授权协调长期协议改进的团队，并定期与 AllCoreDevs 接触以获取反馈和保持一致。

工作组提案

寻求正式化现有分组讨论室或启动新工作组的团队将提交一份轻量级提案，该提案密切遵循头条新闻提案模板。与头条新闻提案不同，WG 提案明确地针对未来的网络升级，而不是立即包含在下一个硬分叉中。

这些提案为工作组提供了一个重要的机制，可以从 AllCoreDevs 那里获得早期的战略对齐，而不会限制未经正式认可的独立实验或开发。

AllCoreDevs 认可

AllCoreDevs 将在每次选择头条新闻后不久审查活跃的工作组，以确保持续对齐。此认可充当“轻量级 CFI”，清楚地表明 WG 与以太坊的战略优先级保持一致。罕见的明确拒绝将表明某个工作不一致或为时过早。

实际上，获得认可的工作组将在以太坊的协议日历上获得可见性，并在 GitHub /pm 存储库中获得专用空间。未明确拒绝或认可的工作可以非正式地继续进行，但没有正式的日历表示或 ACD 可见性。

定期检查

获得认可的工作组将向 AllCoreDevs 提供简洁的定期更新，理想情况下是在每次叉子的头条新闻选择之后。这些检查确认持续对齐，验证方法，并提供早期纠正机会。

检查应保持轻量级和战略性，而不是官僚主义。工作组简要分享进度更新，突出重大里程碑，并明确提出关键问题或风险。ACD 的作用只是重申战略对齐，提供有针对性的反馈，或建议必要的调整。

明确的信号和社区信心

通过清楚地正式化工作组，提供战略对齐的明确信号，并保持定期的轻量级检查，我们可以减少围绕以太坊长期路线图的歧义。完全鼓励独立研究和实验，但正式认可的工作组可以自信地分配资源，因为他们知道他们有社区支持和明确地与以太坊的优先级保持一致。

这种平衡的方法解决了以前的缺点，而没有牺牲以太坊灵活的、社区驱动的文化。

我们何去何从

以太坊治理决策具有独特的高风险。数十亿美元、网络的安全以及我们整个生态系统的一致性都取决于我们部署的每次升级。我们需要明确的保护措施来管理这些不可逆转的更改，还需要足够的灵活性来维持以太坊务实的、社区驱动的精神。

EOF 经验清楚地突出了我们当前流程中的差距：围绕升级的核心目标存在歧义，早期结构化反馈不足，以及主要功能的检查点不明确。如果我们不改进我们的方法，即使每个人都出于善意，我们也有可能重复类似的问题。

为了解决这个问题，我建议我们明确加强围绕这些核心领域的流程：

• 建立明确的分叉重点： 在每个升级周期开始时，AllCoreDevs 应该定义和传达一个由社区输入告知的明确战略优先级，从而为升级的核心目标提供共享的清晰度。

• 每层最多选择一个头条新闻： 使用结构化的模板和现有的 PFI → CFI → SFI 方法，我们确保严格的早期审查，并明确防止先前被拒绝的提案作为低风险的 EIP 返回。

• 实施社区审查的“杠铃”方法： 在最早的阶段（当更改仍然灵活时）进行结构化的社区输入，并通过社区测试网作为最终检查点进行实际验证，从而将后期反对意见限制为安全和关键实施问题。

• 正式化工作组： 为现有的分组讨论室和专门的工作组提供正式但轻量级的结构，包括与 AllCoreDevs 的定期检查点，以确保长期工作与以太坊的战略优先级保持一致。

• 记录完整的治理方法： 在一个权威的地方清楚地记录整个流程，并明确定义反馈渠道，消除利益相关者如何提供有意义输入的歧义。

这个框架不能保证完美的结果。但是，它可以有意义地减少不确定性，加强问责制，并保持以太坊在不牺牲使以太坊独一无二的特性的情况下自信地前进的能力。

感谢大家对这篇文章的内容提供的直接和间接的反馈。提炼这些内容需要花费大量精力，但你们的观点非常有帮助！:heart_on_fire:

• EIP-7773：Glamsterdam 网络升级元线程
• 所有核心开发人员 - 执行 (ACDE) #211，5 月 8 日
• 对于 ACD 平台
• 所有核心开发人员 - 共识 (ACDC) #157，2025 年 5 月 15 日
• 所有核心开发人员 - 执行 (ACDE) #212（2025 年 5 月 22 日）

• 原文链接： ethereum-magicians.org/t...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～