提案：网络升级元线程 - 魔法师 / 流程改进

随着 Shanghai/Capella 的范围确定，焦点已经开始转移到 Cancun/Deneb。但是，在我们深入计划升级之前，重要的是退后一步，考虑改进我们的流程。

以太坊在过去一年中发生了很大的演变，无论是在技术方面还是在人为方面。 我们现在拥有一个统一的网络，同时运行着信标链和执行层，两组客户端团队必须相互协调（以及与研发、开发运维、安全等领域的客户端相关贡献者），并且越来越多的非客户端团队正在倡导以太坊改进提案 (EIP) 并为协议变更做出贡献。当然，更广泛的以太坊社区关于协议方向的意见在数量和质量上都有所增长。

为了让协议开发者、研究人员和更广泛的社区能够就以太坊的宏伟路线图达成一致并实现它，良好的协调至关重要。在这方面，我想提出引入 网络升级元主题，以帮助促进对升级总体范围的更高层次的讨论。让我来解释一下！

TL;DR

• 我建议在 Ethereum Magicians 上引入 网络升级元主题，作为社区讨论网络升级的最佳高级范围/目标/规模的地方

• 这些主题，连同 EIP 的 discussion-to 和 $UPGRADE-candidate（示例）主题，将作为 AllCoreDevs 电话会议的输入。这有望提高我们规划过程的质量

  • $UPGRADE-candidate 主题应作为编目社区对某些 EIP 的支持/反对的规范场所
• 我建议我们为 Cancun/Deneb 试用此流程，并在升级后重新评估是否值得重复

背景

如今，网络升级的范围是在 AllCoreDevs 电话会议期间决定的。客户端开发人员会考虑各种 EIP，辩论它们的技术优点，并最终达成一组他们认为技术上合理、相对于其复杂性提供足够价值并且可以在单个网络升级中一起实现的 EIP。

虽然这通常运行良好，但在某些情况下，ACD 做出决定（更不用说最佳决定）具有挑战性，例如：

• 当不同的社区成员对 EIP 有不同的偏好，但没有强烈的技术理由支持一种 EIP 而反对另一种 EIP 时；
• 当提议的更改是朝着更长期的路线图项目迈出的“第一步”时，该项目可能会也可能不会更改；
• 当一组候选更改对于单个升级来说太大时，必须将它们分散到多个升级中。

这部分是由于 ACD 的性质，其中“关注单位”是 EIP。电话会议上的大多数讨论都是关于提案的技术优点、潜在问题、如何最好地测试它们等等。这既是好事（我们不希望不良提案进入升级），也是不足为奇的（这些领域是大多数常规与会者的专长）。

当讨论必须转移到更高的层次时，例如提案的相对优先级、升级时机的机会成本等等，ACD 电话会议没有提供理想的环境。这不仅是从讨论技术权衡的重大背景切换，而且这些对话通常必须快速进行（由于电话会议的时间限制），有时甚至没有所有相关的利益相关者（因为他们可能不是常规与会者）。

也就是说，客户端开发人员_是_那些最终必须编写这些升级代码的人，因此必须是关于范围的最终决策的核心。本提案希望提供一种提高此决策过程输入质量的方法。

当前流程

如今，网络升级的计划大致如下：

0. EIP 作者编写核心 EIP： 有人编写一个 EIP，其中包含对以太坊共识规则的拟议更改。关于 EIP 的讨论通常发生在 EthMagicians 上。
1. 发起人在 AllCoreDevs 上展示 EIP： EIP 发起人（通常是 EIP 作者）参加 AllCoreDevs 电话会议来展示他们的 EIP。在大多数情况下，这会导致来自客户端团队的反馈，并对 EIP 进行多轮迭代。
2. 发起人请求将 EIP 纳入升级： 在计划升级时，EIP 发起人表示他们希望考虑他们的 EIP。自 Shanghai 以来，此过程已迁移到 EthMagicians。
3. 客户端团队辩论应考虑哪些 EIP： 团队可以就包含 EIP 达成“弱”共识（“考虑纳入”）或“强”共识（“已纳入”）。
4. 原型设计/测试等等： 随着团队研究升级的候选 EIP 并更深入地了解它们的含义，范围会得到改进。随着更多实现和测试套件的可用，当出现问题时，客户端团队可以确定是修复 EIP 的问题更好，还是为了更快地推出其他 EIP 而将其删除更好。
5. 测试网部署： 一旦团队对一组 EIP 的实现和测试覆盖率感到满意，就会将它们捆绑在一起进行测试网络升级。
6. 主网部署： 假设测试网部署顺利进行，现在就可以安排升级到主网。

如前所述，此过程非常以 EIP 本身为中心。虽然这不是每个分叉的计划方式的完美准确说明（例如，The Merge 非常不同），但这是该过程的粗略草图。

网络升级元主题

为了更好地为升级规划过程提供输入，并为更广泛的社区提供正式场所来表达他们的偏好，我认为我们应该引入专门的 Ethereum Magicians 主题，重点关注升级的“范围”和“大小”，而不是 EIP 的技术细节。

这些 网络升级元主题 将：

• 在我们开始计划新升级时在 EthMagicians 上创建（即 Cancun 的升级可能应该已经启动）；
• 作为讨论主题的场所，例如：
  • 升级的主要优先级应该是什么；
  • 大致应该在什么时间进行升级，以及包括边缘功能与延迟的权衡；
  • 如何在 >1 个升级中拆分多升级功能，以及在特定升级中包含这些功能的子集的影响；
• 用作 AllCoreDevs 电话会议的 输入，但不用作关于升级范围的最终决策的场所。ACD 仍然是做出决策的地方。

与 Ethereum Magicians 上的其他内容一样，这些主题将向所有人开放以分享他们的观点。ACD151 议程 有一些适合此类主题的评论的好例子：

• \ 1856×1452 549 KB

• \ 1862×1308 342 KB

希望通过在最终确定升级范围之前的几周/几个月（而不是几天/数小时）开放这样一个主题，我们可以提高我们优先级的质量。

关于 $UPGRADE-candidate 标签/主题的说明

通过 Shanghai 升级，我们尝试让 EIP 发起人在 Ethereum Magicians 上表示他们希望考虑他们的 EIP 进行网络升级（提案）。

这是通过将 shanghai-candidate 标签添加到 Ethereum Magicians 上 EIP 的 discussion-to 主题，或通过打开一个新主题来讨论 EIP 包含在分叉中来实现的，例如 EIP-1153。

\ 1580×890 137 KB

对于强大的社区支持很重要的 EIP，后一种选择可能是编目对 EIP 的支持和反对的好方法，讨论可以在任何地方进行。转向在 Ethereum Magicians 主题中执行此操作可以帮助避免 EIP 不得不重新发明轮子来记录此信息。这些帖子的一个好的论坛模板可以作为完整 EIP 网站的替代方案，例如 eip4844.com。

将它们放在一起

随着网络升级元主题的引入，升级过程将依赖于以下组件：

• EIP： 更改的技术规范（与可执行规范结合）
• discussion-to 主题： 异步讨论 EIP 技术细节
• $UPGRADE-candidate 标签/主题： 考虑将 EIP 用于升级的异步提案，编目支持、反对、状态更新等。
• 网络升级元主题： 异步讨论网络升级范围/大小/相对优先级
• AllCoreDevs 电话会议： 同步讨论 EIP 和网络升级范围，依赖于以上所有内容作为输入

后续步骤

首先，我想在这里和 AllCoreDevs 上获得关于引入这些主题是否有益的反馈。假设是这种情况，那么我建议我们为 Cancun 试用该流程，并在之后重新评估。

• Cancun 网络升级元主题

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