重构以太坊核心开发者会议 - 魔术师/流程改进

概要

• 我提议重新配置 AllCoreDevs，使 ACDE 和 ACDC 专注于确定下一个硬分叉的范围，而不是实施当前的分叉。除了欢迎现有参与者外，这些电话会议还可以更明确地征求更广泛的社区利益相关者的意见。
• 为了补充这一点，现有的测试/互操作性电话会议将正式成为“ACDT(esting)”，专注于当前分叉的实施细节，而不是设置其范围，确保解决技术问题不会与高级功能优先级排序相冲突。
• 随着 Pectra 即将上线，Fusaka 分叉范围计划很快完成，Glamsterdam 提供了一个测试此过程的好机会。在此之前，我建议进行审查和反馈期，目标是在 Pectra 主网发布后不久做出批准/不批准的决定。

背景

在以太坊的早期，AllCoreDevs 是唯一的正式治理场所，参与者数量相对较少。多年来，它不断发展，并涌现出许多分支，例如 ACDC、分组会议、社区电话会议等等。自从合并以来，我们已经更擅长并行处理多个分叉：当我们在发布 Shapella 时，Dencun 已经在 devnets 上线，而当我们接近 Pectra 的主网部署时，Fusaka 也处于类似的情况。

然而，我们现在有一个更复杂的过程，涉及越来越多的利益相关者，他们必须就一个雄心勃勃的路线图达成一致并交付。这导致了一些日益增长的痛苦，包括：

• 不明确的参与期望： 虽然在电话会议和人员较少的情况下，临时协调就足够了，但关于参与的隐含假设已不足以确保我们在做出决策时有合适的人员在场。
• 缺乏连贯的方向： 仅依赖“自下而上”的方法来得出实施计划可能会导致协议开发的重点与实际完成的工作之间可能不匹配。
• 社区困惑： 在 AllCoreDevs 之外，越来越多的外部利益相关者现在要么对结果感兴趣，要么渴望参与。如果该过程是隐含的且难以理解的，则会导致更广泛的社区产生摩擦和困惑。

这篇文章提出了对 AllCoreDevs 流程的更改，旨在解决这些问题，同时确保指导以太坊治理的核心原则——大致共识、开放性和强大的安全意识——得到保留。 它分为两个主要部分：流程设计和实施细节。

第一部分概述了高级期望，独立于它们如何适应现有结构。第二部分探讨了如何在实践中实施这一点，以及一些悬而未决的问题是什么。

流程设计

路线图设定

当前 AllCoreDevs 流程中最重要缺失的部分是关注高级路线图（“我们为什么要做事”），而不是单独的提案（“我们做什么”）。无论是在规划下一个分叉，还是在思考以太坊的长期方向时，这都是正确的。

短期

一项短期路线图规划工作应旨在为以太坊升级设置“头条功能”，即使尚未存在正式的 EIP，也要强烈说明其重要性。例如，如果 Fusaka 之前存在这样的流程，它可以将升级围绕“尽快将 blob 计数增加 2-5 倍”进行构建，并阐明为什么这对于防止 L2 转向替代 DA 是必要的。

目标是阐明某个功能对以太坊的重要性，谁从中受益以及受益程度，它增强了以太坊的哪些核心属性（例如，可扩展性、抗审查性、用户体验等），以及它是否会带来任何权衡。

也就是说，网络安全必须优先于交付新功能。以太坊最强大的独特优势之一是弹性。即使在有交付压力的前提下，我们也不应在这方面妥协。

另一个需要维护的核心属性是以太坊的开放路线图流程，该流程邀请社区参与塑造网络升级。更好地对齐分叉的高级功能并不意味着社区不能再Propose EIPs for Inclusion，而是将在具有分叉的更高层目标的情况下考虑这些 EIP。

这导致了以下优先级排序：

• P0：网络安全。解决安全问题优先于一切。
• P1：路线图“头条功能”。团队在网络升级期间将大部分时间和精力投入到其中的功能。
• P2：其他 EIP。根据对 P1 的任何潜在影响进行加权。如果出现延迟 P1 的意外问题，则默认将其从升级中删除。

长期

在改进我们的短期路线图流程的同时，我们应该改进我们如何协调以太坊的长期路线图。为此，我们必须就主要的权衡是什么、哪些解决方案值得探索以及需要哪些具体research and development举措来验证或否定它们达成一致。这项工作面临的最大挑战之一是在快速变化的环境中平衡可选项与对未来更具体承诺的渴望。

高质量的研究是此过程的必要但不充分的输入。为了充分设定以太坊的长期发展轨迹，我们需要清晰的讨论和辩论场所，其中既要有技术代表，也要有具有商业、产品和战略思维的利益相关者。

理想情况下，它会产生清晰的当前前进方向及其基本原理的记录——以及引导我们到那里的决策树。这是我们对自己提出的技术决策的标准，即使是那些微不足道的决策，也应适用于以太坊的最高级别战略规划。

虽然实施短期路线图流程所需的许多组件今天已经存在，并且主要需要“调整”，但长期路线图并非如此。为了实现这个目标，我们可以尝试不同的方法，并迭代到一个既高效又合法的流程。

利益相关者意见

路线图流程需要来自以太坊社区各个部分的高质量输入才能做出最佳决策。虽然核心开发人员擅长评估实施风险，但仅凭这种观点是不够的。为了补充这一点，我们还必须评估对用户的好处以及某个功能如何与以太坊协议的长期演进对齐。

对于更广泛的社区而言，参与 AllCoreDevs 可能会令人望而却步、耗时且容易出现不透明的反馈循环。目前尚不清楚正确的切入点是什么、何时何地需要关注，以及所提供的意见最终是否被视为决策的一部分。

应用和协议开发人员之间也存在“翻译”问题，用户的需求可能无法以反映协议开发约束的方式表达。不能指望应用程序开发人员拥有深入的协议专业知识才能有效地参与该过程。理想情况下，他们会用自己的术语表达需求，然后 AllCoreDevs 流程将负责提出技术解决方案来满足这些需求。如果应用程序开发人员的一个子集随后想要参与开发特定的解决方案，那么该流程将像往常一样对他们保持开放。

在研究方面，主题可能需要数年才能正确探索，并且一些最重要的考虑因素与实施复杂性无关。以太坊的发行曲线就是这方面最极端的例子。此外，可能已经确定了紧急且重要的问题，但没有解决方案，因此以太坊的主要任务应该 是制定实施计划。合并就是这样发生的。

因此，路线图流程应明确征求这些群体的意见。 除了邀请他们定期参与电话会议外，我们还可以创建一些方法，允许他们以比 EIP 更高的抽象级别提出正式提案。

例如，可以有一个“模板”，各种利益相关者可以使用该模板来传达他们的偏好，作为路线图流程的一部分，该模板会提供以下问题的答案：

• 该小组希望对以太坊提出什么更改？
  • 该提案目前的开发状态如何？
  • 为什么现在是将此作为以太坊主要优先事项的合适时机？
• 为什么此更改对他们以及整个社区产生影响？
  • 从数量和质量上讲，这将如何改善以太坊？
  • 还有谁明确支持该更改，他们在以太坊社区中的角色是什么？
  • 目前没有进行此更改会导致哪些问题（例如，错误、缺少用户功能等）？
• 关于此更改的最大权衡和悬而未决的问题是什么？

另一个考虑因素是如何对利益相关者进行分类。分组会议倾向于关注特定主题，但通常由同一批核心开发人员参加……相反，社区通常被细分为“类型”项目（L2、DeFi、钱包、LST 等），而最重要的研究考虑因素通常跨越多个领域。

时间安排是另一个重要问题。是主动询问所有利益相关者的优先级更好，还是征求他们对特定提案的意见更好？哪些利益相关者最适合为主要的短期和长期优先级提供意见？这会如何影响核心开发人员在该过程中的当前角色？

如果设计不当，此流程可能会导致 AllCoreDevs 遭受拒绝服务攻击。例如，Fusaka 升级目前有超过 20 个 EIP Proposed for Inclusion，几乎与 Considered 或 Scheduled for Inclusion 的一样多。

同样，鉴于所有这些都存在高度不确定性，尝试不同的方法是收敛到允许利益相关者感到被倾听、不会损害以太坊的任何核心属性并高效运行的流程的关键。

网络升级时间表

以下是使用这些新流程进行网络升级的暂定时间表。为了确保将研发不确定性考虑在内，每个步骤都依赖于上一个步骤，而不是固定的时间表。

\ acd-color1761×421 72.5 KB

描述，从确认“头条”功能开始（图表上的 ）：

1. Fork N 的“头条”已达成一致

   • Fork N 的路线图流程就升级的主要功能达成一致。

     1. 这应该在之前的分叉 Fork N-1 准备好部署的几个月前发生。
   • 开始审查 Fork N 的其他提案。
   • 所有团队开始将资源分配给 Fork N 头条功能的实施。
2. Fork N-1 客户端测试网发布和测试网部署
3. Fork N EIP 提案的截止日期
   • 预计大多数提案已经共享和审查。
4. Fork N-1 客户端主网发布和主网部署
5. Fork N 范围最终确定
   • 在 Fork N-1 在主网上线后的几周内，就 Fork N 范围的任何新增内容达成一致。在此之后，只能考虑对 SFI 的 EIP 进行更改，以及对安全至关重要的 EIP。
6. Fork N+1 路线图讨论开始
   • 一旦下一个升级的范围最终确定，就应该开始讨论下一个升级的优先级。
   • Fork N 的实施与此并行发生。
7. Fork N+1 的“头条”已达成一致
   • … 循环重新开始！

实施细节

以下是调整现有流程以适应上述结构的提案。一个核心假设是，从今天已有的流程迭代到新流程比放弃一切而支持新方法更有可能成功。

AllCoreDevs 电话会议

AllCoreDevs 是以太坊治理中最高调的场所。它既可以用于就升级范围达成一致，也可以用于完成它们的实施。通过尝试同时做这两件事，它最终在这两件事上都没有做得像它可能做的那样好。自从合并以来，我们还一直在为客户端运行每周一次的测试/互操作性电话会议，该会议更侧重于分叉的实施细节。

我们可以利用这种区别，使 AllCoreDevs 成为下一个分叉的规划场所，并使现有的测试电话会议成为讨论当前分叉实施细节的场所。 以下是一些关于我们如何重新构建电话会议以实现此目标的想法。

ACD{E|C}

• ACD{E|C} 电话会议的主要输出变成了网络升级的 Meta EIP
  • 今天的 Meta EIP 主要用作指向各个 EIP 的指针，几乎没有实质性内容。相比之下，以路线图为导向的 ACD 可以生成 Meta EIP，这些 EIP 彻底阐明了网络升级的优先级，并清楚地解释了这种优先级背后的基本原理。
  • Meta EIP 可能会在不同的阶段进行细化，例如：
    • 升级的高级重点提案
    • 就升级的高级重点达成一致
    • 为升级选择特定的“头条 EIP”
    • 开放关于包含在升级中的其他 EIP 的提案
    • 升级的最终范围被冻结
    • TBD 允许 CFI 但未 SFI 的 EIP 有多大的空间。
  • 在网络升级中确定某些内容优先级的基本原理不应完全取决于 EIP 是否已经存在。换句话说，“技术准备情况”是决策的输入之一，但不是唯一的（或主要的）输入。
  • 上述阶段必须考虑到当前分叉的当前实施状态。例如，虽然可以与上一个分叉的实施并行设置下一个升级的优先级，但 EIP 的公开征集应该在客户端开发人员实际上有带宽审查提案的时候进行。
• ACD{E|C} 必须保持开放参与，同时扩展到协议贡献者之外，并提高路线图讨论的质量标准。
  • EIP 对此既不是必要的也不是充分的。 我们需要一个新的“模板”来评估潜在的更改，该模板既要足够灵活以适应不同类型的功能，又要以一种可以过滤掉低质量提案的方式进行结构化。要求人们提供“一份书面材料或演示文稿”并保持开放可能就足够了。与侧重于“什么”的 EIP 不同，此资源应侧重于“为什么”。
  • 应邀请来自社区不同部分的代表参与和互动。 以太坊网络升级的范围应该围绕着为整个社区提供最大价值的内容来设置，而不仅仅是客户端团队希望从事的工作。归根结底，客户端团队是必须就编写哪个代码达成共识的人，但从社区引入更多的输入来源可以帮助为这些决策提供信息。
  • 异步输入源对于高质量的公开辩论至关重要。 通话时间有限，直播辩论通常效率低下，无法发现对齐或争议最高的领域。我们需要规范的异步论坛来收集输入，而不是仅仅依靠同步通话作为信息来源。这并不意味着将最终决定移到通话之外，但可以帮助确保参与者带着高度的背景知识和对需要解决的关键权衡的理解而来。
• ACD{E|C} 继续存在，倾向于 EL/CL，但每个客户端团队至少应每周派出一名了解路线图的代表参加。
  • 目标是解决任一次通话中的任何时间敏感型主题，但非紧急项目可以根据其领域默认为 EL 或 CL 通话。
  • 这意味着所有客户端团队都派出 O(1) 名了解路线图流程的代表参加 ACD{E+C}，但可能有 O(N) 名代表参加其各自层的通话。
  • 仅关心一层的外部利益相关者应主要参加该通话，但在路线图规划的最后阶段除外。
• ACD{E|C} 仍然是做出关于网络升级中 EIP 包含（和排除）的决策的地方
  • 即使当前分叉的实施不再是 ACD{E|C} 范围的一部分，如果一旦实施开始，必须对 EIP 集进行更改，则应在 ACD{E|C} 上最终确定此决策。对已包含的 EIP 进行的更改不必经过此过程，除非它们非常重要以至于改变了 EIP 的性质，或者以任何方式影响了交付“头条 EIP”的能力。

ACDT(esting)

• 现有的每周测试/互操作性电话会议更名为“AllCoreDevs Testing”，成为讨论当前分叉实施的主要场所。
  • 粗略地说，ACDT 会将网络升级 Meta EIP 作为“输入”，并将生产就绪的客户端实施作为“输出”。
• 所有实施者都应该参加 ACDT——每个客户端团队每周应该有 O(N) 名与会者。
  • 客户端团队可以派不同的代表参加 ACDT 和 ACD{E|C} 电话会议，但我们应该有足够的技术代表来解决分叉周期中出现的几乎所有实施问题。
• 当升级处于实施高峰期，或者出现与安全相关或紧急问题时，ACDT 会“溢出”到 ACD{E|C} 中。
  • 发布当前分叉是发布下一个分叉的先决条件。在此过程中，选择务实地实现此目标，而不是在通话之间进行“完美”的概念划分

时间线视图

重新使用上面共享的时间线，白色框中的主题属于 ACD{E|C}；彩色框中的主题转移到 ACDT。

\ acd-ref-21761×421 86.5 KB

描述，从确认“头条”功能开始（图表上的 ）：

• 当 ACDT 致力于 Fork N-1 的实施时，ACD{E|C} 会讨论并确认 Fork N 的头条
  • 开放性问题： 在 Fork N-1 发布之前，仍然应该在 ACD{E|C} 中跟踪头条功能的实施吗？
• 到 Fork N-1 发布时，ACD{E|C} 已经最终确定了 Fork N 的范围，该范围转移到 ACDT
• 当 Fork N 的范围最终确定时，关于 Fork N+1 的潜在头条的讨论在 ACD{E|C} 中开始

其他杂项 ACD 改进

• 提前 ~3 天冻结议程： 对于 ACD{E|C}，任何非紧急事项都会在（周四）通话前的周一添加到议程中。
• EIP PFI 提案的模板： 在这种新结构下，“头条 EIP”预计将经过严格的审查过程。其他 EIP 也应该有强烈的纳入理由，即使该过程更轻量级。理想情况下，这意味着默认情况下不需要在 ACD{E|C} 上展示 PFI 的 EIP。
• DFI，无需理由： 开放的 EIP 流程可能会变成客户端团队注意力的拒绝服务攻击。为了平衡这一点，客户团队应该自由地使用 Declined for Inclusion 状态。不得期望提供拒绝的理由。另一方面，DFI 仅适用于特定分叉。EIP 倡导者可以为未来的升级重新提出 DFI 的 EIP。
• 更好的“协议弹性”指标： 我们提高发布能力的愿望绝不能以牺牲以太坊的长期可持续性为代价。我们应该有明确的关于性能和安全的指标，以帮助我们在交付新功能的紧迫性与构建弹性软件的重要性之间取得平衡。

利益相关者意见

如果我们有合适的利益相关者参与该过程，那么上述对 AllCoreDevs 的重新关注将会最成功。在实践中，这是客户端开发人员（有足够的背景知识来形成对更广泛的以太坊路线图的看法）、协议研究人员、来自社区各个领域的领域专家（例如 L2、钱包、DeFi 等）等的组合。后一组人最不可能参加定期电话会议，因此我们应该有其他方式来收集他们的意见，包括主动地（例如，跟踪链上遇到的最常见问题）和被动地（明确的论坛供他们分享问题或建议，然后将其反馈到 ACD 流程中）。

分组会议

虽然分组会议的风格与 AllCoreDevs 非常相似，但它们对于与更多利益相关者就特定问题进行互动非常有用，这些问题需要客户端开发人员以外的意见。从初始设计到实际实施时尤其如此，例如EIP-7702或FOCIL。

周期性协议电话会议

这些已经发生：周期性协议电话会议是与 AllCoreDevs 附近的领域专家沟通与他们相关的主题，并将他们的意见带回 ACD 的好方法。例如，RollCall对于获取 L2 的意见很有用。我们现在还有Beam Chain 电话会议和一个新推出的协议研究电话会议，他们有望发挥类似的功能。

社区电话会议

我们有时会举办社区电话会议，旨在面向比协议贡献者更广泛的受众（例如Shapella、Merge）。从历史上看，这些会议是在网络升级过程的最后阶段举行的，目的是传播信息（而不是收集意见）。在升级过程的早期举办此类电话会议（或将其作为 ACD{E|C} 电话会议的一部分）可能是从社区成员那里收集关于升级优先事项的意见的另一种方式。

以应用为中心的场所

如前所述，AllCoreDevs 流程已根据客户端开发人员关心的输入进行塑造。这有时会导致不属于这些类别的担忧被忽略。改进这种情况的一种潜在方法是创建一个开放场所，供应用程序开发人员分享他们的观点和协议级别的请求。这可以采取电话会议或更异步场所的形式（见下文），但将其定义为“应用程序开发人员的公开邀请”可能有助于发现 ACD 中遗漏的需求。

异步讨论主题

我们已经进行了一些实验，试图使用 EthMagicians 收集关于分叉优先级的意见（Prague、Dencun、Shanghai）。同样，客户端团队最近开始分享他们对网络升级优先事项的看法。虽然这两种方法都有助于缩小了可能的 EIP 列表，但它们有时会只见树木不见森林。

无论是在 Ethereum Magicians 还是在其他地方，我们都应该创建一个空间，用于异步讨论下一次升级的高级目标，重点是“为什么”而不是“如何”。这将是我们发送社区项目以阐明他们的需求和问题的地方，这将成为关于下一次升级的讨论的输入。

记录过程

需要考虑的最后一个问题是在何处以及如何呈现关于此新过程的信息。今天，这些信息分散在 pm 存储库、EIP、Ethereum Magicians 中，并且大量上下文仅存在于人们的脑海中。为了使事情更易于理解，一旦我们对总体前进方向达成共识，我们就应该明确地记录它。我们进行记录的地点和方式将取决于我们决策的具体内容，但pm 存储库感觉像是自然的默认“登陆页面”。

下一步

为了推进此提案，我建议明确规定一个“审查和评论”期限，以收集反馈并对此提案进行更改（约 2 周？）。一旦收集了异步输入，我们应该争取在下一次 ACD 上做出批准/不批准的决定。我们不需要在前进之前解决每一个细节，但我们应该争取在新结构上达成广泛的一致，然后再开始进行试验。

感谢你一直阅读到这里！

• All Core Devs - Execution (ACDE) #209
• Interop Testing #34 | April 28 2025

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