以太坊核心开发者最新会议摘要：Devnet 12启动，升级规划流程

原文标题：《Ethereum All Core Developers Consensus Call #123 Writeup》

原文作者：Christine Kim

原文编译：Luccy，BlockBeats

编者按：

以太坊所有核心开发者共识电话（ACDC）每两周举行一次，主要讨论和协调对以太坊共识层（CL）的更改。本次为 ACDC 第 123 次电话会议，会议主要涵盖了对 Cancun/Deneb 和 Devnet #12 测试更新的评估，以及对 Devnet #11 中出现的验证者退出问题的解决。此外，开发者还就网络规范澄清、升级计划流程和 EIP 状态进行了深入讨论。

在对 Cancun/Deneb 的讨论中，开发者强调了稳定性，并讨论了是否启动 Goerli 影子分叉。然而，由于 Prysm 客户端尚未准备好测试，决定等待其准备就绪。对于测试工具和链重组的讨论强调了对更全面测试覆盖的需求，并提出了使用 Hive 和 Kurtosis 测试套件的建议。在 EIP 状态和 CFI 标签的问题上，Beiko 提出了是否应该保留这些标签的疑虑，开发者们尚未就此问题达成明确的共识。

Galaxy Digital 研究副总裁 Christine Kim 对本次会议要点做了详细记录，BlockBeasts 将原文编译如下：

2023 年 11 月 30 日，以太坊开发人员齐聚 Zoom 参加了 All Core Developers Consensus (ACDC) call #122 会议。ACDC 电话会议是一个每两周举行一次的系列会议，由以太坊基金会研究员 Danny Ryan 主持，开发人员在会上讨论和协调对以太坊共识层（CL）的更改。本周，开发者们聚焦讨论 Cancun/Deneb 测试的最新进展，具体包括：

· Devnet #12 的启动：目前正在对 Devnet #12 上 Teku、Lodestar 和 Lighthouse 客户端软件以及所有执行层（EL）客户端软件进行测试。Prysm 团队预计将在最新的 Devnet 上两到三周内准备好他们的软件进行测试。

· Devnet #11 上的验证器退出问题：在 Devnet #11 上，开发者们发现了与验证器退出有关的问题，目前由 Nimbus 客户端团队解决中。在问题解决之前，Devnet #11 将继续正常运行。

· 网络规范澄清：开发者们讨论了对「BlockByRoot」和「BlobSidecarsByRoot」请求的规范进行澄清，明确共识层（CL）节点是否应按特定顺序响应这些请求。

除了对 Cancun/Deneb 的更新之外，开发者们还讨论了以太坊基金会协议支持负责人 Tim Beiko 提出的一些流程问题，以提升对以太坊升级的协调。

2023 年 11 月 30 日星期三，Cancun/Deneb 升级在 Devnet #12 上正式启动。以太坊基金会测试团队的 Mario Vega 表示，目前在测试网络上运行的三个 CL 客户端中「迄今为止没有发现重大问题」。基金会的 DevOps 工程师 Barnabas Busa 提到，在 Lighthouse、Teku 和 Lodestar 之间，总共有 225 个验证者分布在三个节点上。由于 Devnet #12 的稳定性，基金会的 DevOps 工程师 Parithosh Jayanthi 询问开发者是否应该开始计划进行 Goerli 影子分叉以进一步测试 Cancun/Deneb。然而，考虑到目前最流行的 CL 客户端 Prysm 尚未加入 Devnet #12，开发者们决定在 Prysm 客户端软件准备好进行测试之前暂时搁置计划进行 Goerli 影子分叉。Beiko 建议在年底之前的某个时候着手进行 Goerli 影子分叉。由于 Devnet #12 的稳定性，暂时搁置计划，直到 Prysm 客户端软件准备好进行测试。

网名「Dustin」的 Nimbus 开发者介绍了他的团队正在解决的 Devnet #11 的问题细节。这些问题在开发者将 Devnet #11 的三分之一验证者退出，以在 Devnet #12 上使用时首次发现。Ryan 询问 Dustin 是否可以通过额外的测试来发现这些问题。Dustin 回应称，在他看来，这些错误的性质是由共识规范范围之外的实现细节引起的。然而，他也承认在为了测试覆盖的好处而严格按照 CL 规范编写客户端软件与为了获得更好的节点性能而涉足规范的灰色区域之间存在「明显的紧张关系」。

「我是说更多的测试总是好的，但更系统地找出如何将更多的客户端功能纳入运行的测试中，也许是更多的自动化方式，无论是使用 Hive 还是 Kurtosis 或其他什么方式。如果这些问题能够解决或者事情能够很好地被分解，以便能够纳入更多这些任务，我认为那肯定是有用的，」Dustin 还补充道，CL 开发者应该考虑解决的另一个挑战是弄清楚 CL 规范应该规定和标准化节点行为的详细级别。「这里的另一个挑战是，标准化的程度，这实际上不仅仅是一个软件工程问题，行为应该有多标准化吗？」Dustin 问道。所有的 CL 客户端都通过了检查基本行为的测试，但是这些测试范围之外的行为是模糊的。「这些是有意留下的模糊的东西吗？什么应该由规范真正明确规定，而什么应该故意保持模糊？」Dustin 问道。

至少，开发者们同意在未来的 Devnets 和测试网络上为 Cancun/Deneb 的大量验证者退出增加更多的测试。Ryan 还承认，在涉及 CL 客户端和 CL 规范实施时，还有更严格和全面的测试覆盖的空间。Vega 建议 Dustin 创建一个 HackMD 帖子详细说明他的关切，并在下一次 Cancun/Deneb 测试电话会议上讨论这个话题。Jayanthi 补充道，基于在 Cancun/Deneb Devnets 上最近发现的一些问题，开发者明显需要能够系统执行一定数量的链上集成相关行为的工具，比如质押 ETH 提取、验证者退出等。为此，Jayanthi 建议使用 Hive 和 Kurtosis 测试套件的混合来构建这样的工具。

谈到 Cancun/Deneb 升级的新测试工具，Jayanthi 指出，开发者们正在研发一种可靠地在 Devnets 和测试网络上激活链重组的工具。为了确保这个工具正常工作，Jayanthi 要求开发者分享在以太坊上触发链重组的已知 bug 的详细信息。Jayanthi 解释说，他将使用这些 bug 来测试该工具，并确保它能够可靠地识别重组何时发生以及何时解决。

开发者们简要讨论了以太坊基金会研究员 Justin Traglia 提出的一个关于 CL 客户端在收到「BlockbyRoot」或「BlobSidecarsByRoot」请求时应该返回的响应顺序的开放拉取请求。Ryan 询问不同 CL 客户端团队已经如何实现这个功能。电话会议上没有任何开发者回答这个问题。Ryan 建议在以太坊研究与开发 Discord 频道上重新引起这个讨论，让更广泛的客户端开发者参与。Ryan 承认这两个请求的规范存在歧义，「可能是问题和奇怪边缘情况的原因」「值得澄清和整理，」Ryan 肯定道。

Ryan 还提到他将在接下来的几天发布新版本的 CL 规范。最新版本显著增加了关于 CL 客户端何时可以通过「byRoot」RPC 请求提供块和块的规范。有关关于通过「byRoot」RPC 请求检索缺失的块和块的讨论的更多背景，请参考此前的通话记录。Ryan 强调，最新版本中包含的 CL 规范的新添加不会对已在 Devnet #11 或 #12 上运行的验证者产生任何影响代码的破坏性更改。

接着，开发者们讨论了 Beiko 提出的各种流程事项。Beiko 表示，警告 Goerli 测试网用户在 Cancun/Deneb 升级在 Goerli 上激活后的 3 个月内，或者在以太坊主网上激活升级后的 1 个月内（以后者为准）即将弃用的博客文章将于 11 月 30 日在以太坊基金会博客上发布。自电话会议结束以来，上述博客文章已经发布，可以在这里阅读。

Beiko 建议在以太坊「pm」存储库下创建升级专用文件夹，将与特定升级相关的各种文件整理到一个文件夹中以备后用。电话会议上的开发者们同意了 Beiko 的建议。

Beiko 提出的第二个流程事项是关于创建一个「Meta EIP」文档，以跟踪以太坊上已经完成的网络升级的全部范围。「目前没有一个好的地方可以在部署和在博客文章中宣布之前跟踪网络升级的全部范围，」Beiko 在一篇关于他关于 Meta EIP 提案的帖子中写道。「对于 Dencun，我们在一个难以找到的 markdown 文件 7 中有 EL EIPs，而 CL EIPs 是 Beacon Chain 规范 3 的一部分。这并不是很好，因为这两者都有点难以找到，它们各自使用不同的『格式』，而且会导致重复。由于 ERC 和 EIP 现在是分开的，我建议（回到）使用 Meta EIPs 来跟踪包含在网络升级中的 EIPs。」开发者们赞成创建这些文档。Beiko 表示，他将在本周起草一个供 Cancun/Deneb 升级审查的文档。

最后，Beiko 提出了一个关于将拟议的代码更改，以太坊改进提案（EIPs）标记为「考虑包含」（CFI）的实用性的问题。据 Beiko 称，CFI 是开发者们历史上用作「软信号」的状态，表示 EIP 的作者应该继续为可能包含在未来硬分叉中的提案而努力工作。它仅用于 EL-focused 的代码更改和升级。「[CFI] 高于来自随机人的随机想法，但在分叉中被接受之前，」Beiko 说。

过去，标签 CFI 在指示 EL 上的哪些 EIP 将在升级中实施或何时实施方面几乎没有起到任何效果。它已被应用于具有不同程度的代码准备度和客户端团队支持的各种 EIPs。在 EVM Object Format（EOF）提案的情况下，开发者们使用这个标签表明他们致力于在下一个即将到来的升级 Cancun/Deneb 中实施 EOF。然而，EOF 以及其他几个也被标记为 CFI 的提案都被从 Cancun/Deneb 中拒绝，目前尚不清楚这些被标记为 CFI 的 EIP 在下一个升级 Prague/Electra 中的状态。

Beiko 表示，如果这个状态没有帮助，开发者们应该将其移除，但如果他们打算保留这个状态，CL 开发者们也应该在考虑在 CL 升级中实施的代码更改上采用相同的标签。目前尚不清楚 CL EIP 审查过程在多大程度上反映了 EL EIP 审查过程，以及它们在未来是否应该以相同的方式发展。通常，对 CL 规范的拟议代码更改在 ACDC 电话会议上进行讨论，而对 EL 规范的拟议 EIP 则在 ACDE 电话会议上进行讨论。

Swirlds Labs 的 Danno Ferrin 还提出了一个想法，即为所有 EIPs，无论是 CL 还是 EL 相关，创建一个占位符字段，用于标识它们在审查过程中的状态，包括 CFI 状态。在这个电话会议上，关于 EIP 状态和 CFI 标签的话题没有明确的决定。