提议：网络升级元线程 - Magicians / 流程改进

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

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

为了使协议开发者、研究人员和更广泛的社区能够就以太坊雄心勃勃的路线图达成一致并实现它，良好的协调至关重要。在这方面，我想建议引入 网络升级 Meta 线程，以帮助促进关于升级的整体范围的更高级别的讨论。让我解释一下！

TL;DR

• 我建议在 Ethereum Magicians 上引入 网络升级 Meta 线程，作为社区讨论网络升级的最佳高级范围/目标/规模的场所

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

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

背景

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

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

• 当不同的社区成员对 EIP 有不同的偏好，但没有强有力的技术理由支持一个反对另一个；
• 当提议的更改是朝着可能更改或可能不更改的长期路线图项目的“第一步”时；
• 当一组候选更改太大而无法进行单次升级时，并且必须将其分散到多个升级中。

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

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

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

当前流程

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

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

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

网络升级 Meta 线程

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

这些 网络升级 Meta 线程 将：

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

与 Ethereum Magicians 上的所有其他内容一样，这些线程将开放给所有人分享他们的观点。ACD151 议程 有很好的例子，说明了哪些评论适合这样的线程：

• \ 1856×1452 549 KB

• \ 1862×1308 342 KB

希望通过在最终确定升级范围之前的几周/几个月而不是几天/几小时内开放这样的线程，我们可以提高我们的优先级排序的质量。

关于 $UPGRADE-candidate 标签/线程的说明

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

这是通过将 shanghai-candidate 标签添加到 Ethereum Magicians 上 EIP 的 discussion-to 线程，或者通过打开一个新线程来讨论 EIP 是否包含在 fork 中来完成的，例如 EIP-1153。

\ 1580×890 137 KB

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

整合在一起

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

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

下一步

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

• Cancun 网络升级 Meta 线程

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