2023 年 12 月 7 日，以太坊开发人员齐聚 Zoom 参加了 All Core Developers Execution (ACDE) call #176 会议。ACDC 电话会议是一个每两周举行一次的系列会议，由以太坊基金会协议支持主管 Tim Beiko 主持，开发人员在会上讨论和协调对以太坊执行层（EL）的更改。本周，开发者们讨论了在 Devnet #12 上进行的 Cancun/Deneb 升级的测试工作。他们同意在假期结束后的一月初，在以太坊 Goerli 测试网络上协调升级的激活日期。此外，他们计划在一月初开始讨论下一个以太坊升级 Prague/Electra 应包含哪些代码更改。

Devnet #12 更新

Cancun/Deneb 升级在 Devnet #12 上的测试进展顺利。基金会的 DevOps 工程师 Parithosh Jayanthi 透露，目前已在两个客户端 Reth 和 Lighthouse 中发现了一些错误，两个客户端团队正在紧急修复中。为了更全面地测试 MEV 工作流，DevOps 团队正在更多专注于在 Devnet #12 上的更多验证器上启用 MEV-Boost 软件。Jayanthi 表示，他的团队至少发现了 Flashbots 的 MEV 中继实现中的一个错误。以太坊基金会研究员 Danny Ryan 强调，为了确保在中继失败时验证器能够切换到本地区块构建，还需要进行额外的测试来检查备用机制。

对于特定客户端团队的升级，Prysm 客户端的开发者 Terence Tsao 表示，他的团队正在研究ACDC #122中讨论的 blob 传播的更新设计。Tsao 确认，Prysm 客户端将准备好在下周，可能是下下周加入 Devnet #12 进行测试。Besu 客户端的开发者 Justin Florentine 表示，Besu 已准备好从 Devnet #12 迈进。Nethermind、Erigon、Lodestar 和 Teku 客户端团队的代表也表示已准备好继续在公共以太坊测试网络上进行升级测试。

基于客户端的准备情况，Beiko 建议在开发者们结束假期后尽快协调一个硬分叉的日期。假设在 Prysm 客户端加入后的未来几周内在 Devnet #12 上没有发现重大错误，Beiko 表示 Cancun/Deneb 在 Goerli 上的激活可能在一月中旬左右进行。来自 Teku 团队的 Ben Edgington 询问开发者们是否对将每个区块的 blob 数量从两个更改为三个的变更感到有信心。Ryan 建议在大规模阴影分叉和 Cancun/Deneb 在 Goerli 上激活期间对增加的 blob 目标进行额外测试。Beiko 确认在 Goerli 上进行的升级激活将是对每个区块三个 blob 目标的「最后一次重要测试」。假设没有问题被发现，开发者将继续使用增加的 blob 数量进行主网激活。

总的来说，Beiko 表示开发者将在现在和假期结束之间继续在 Devnet #12 上测试升级。DevOps 团队计划在 12 月底之前至少启动一个 Goerli 阴影分叉，为一月份的 Goerli 真正硬分叉做准备。如若开发者在新年集结，他们将讨论 Goerli 硬分叉激活的日期。

Builder 覆盖标志

接着，Tsao 询问了客户端团队在实现 Builder 覆盖标志方面的进展。Builder 覆盖标志是 Cancun 升级中的一个新的布尔字段，执行层客户端可以使用它来向共识层客户端指示，当 Builder 检测到审查活动时，验证者应该回退到本地区块生成，而不是使用第三方 Builder。正如 Tsao 所强调的，关于如何检测 Builder 的审查活动的实现细节是主观的，并且故意留给客户端团队设计。有关 Builder 覆盖标志的更多信息，请参考ACDC#112和ACDE#165 的会议记录。

网名「Lightclient」的 Geth 客户端团队开发者表示，他的团队已经实现了该标志，但在「不久的将来」内不会在官方发布中合并。Besu 和 Nethermind 团队的代表表示，他们的客户端中尚未实现这个可选标志。Tsao 强调该标志可能是一个有用的工具，最好尽早实现，以阻止和打击质押池或大型验证者节点运营商参与某些「时间游戏」。Tsao 解释说，验证者可以通过延迟区块传播来获得更多的 MEV（最大可提取价值），而在 Cancun 升级后引入 blobs 之后，将会产生对区块传播的延迟。在这些延迟期间，验证者可能选择在区块中包含更具利润的 MEV 交易，这对及时的 blob 传播来说是次优的。

确认 blob 交易将不得不与常规交易竞争，Prysm 团队的一位化名开发者，以 Potuz 为屏幕名的开发者补充道：「Blobs 不仅需要与费用竞争，而且还需要与延迟本身以及通过延迟区块获得的所有 MEV 竞争。在设计 blobs 的费用机制时，我认为这是一个没有被阻止或考虑到的市场。」Tsao 表示他将在 Ethereum Research Discord 中再次提出这个问题进行进一步讨论。此外，Ryan 强调了 Ethereum Foundation 研究员 Caspar Schwarz-Schilling 和 Mike Neuder 在 Ethresearch 网站上关于「timing games」的最新帖子。

项目进展

接下来，Beiko 分享了与以太坊升级规划过程相关的三个更新。首先，正如在ACDC #123上讨论的那样，Beiko 已经为 Cancun/Deneb 升级创建了一个 Meta EIP 文档，该文档列出了已包含在 Cancun/Deneb 中的所有以太坊改进提案（EIPs）。它已经在 GitHub 上创建，EIP 编号为 7569。此外，Beiko 还创建了 EIP 7568，作为所有先前升级的 Meta EIP 文档，开发者没有创建专门的文档来跟踪升级中包含的 EIP 列表。EIP 7568 将链接到升级代码规范。

其次，Beiko 宣布他已在 Ethereum Magicians 网站上创建了一个新的讨论主题，以确定下一个网络升级，即 Prague/Electra。他要求开发者在是否像过去两次硬分叉一样将执行层（EL）和共识层（CL）的升级捆绑在一起方面进行批判性思考。某些代码更改的激活，如 EIP 7002，将需要对 EL 和 CL 都进行更改，因此将需要同时协调 Prague 和 Electra 升级。然而，对于其他代码更改，如 Verkle 树，有方法重新设计实现，只需要对 CL 进行升级。

Ryan 指出，与 Verkle 树同时进行的共识层（CL）开发者也正在进行支持数据可用性抽样的代码更改。Beiko 建议开发者不要在 Prague/Electra 升级中详细讨论所有他们希望看到的 EIPs 的细节，而是建议他们在假期期间审查所有候选代码更改，并在一月份准备好认真讨论这些更改。Potuz 同意这种观点，并补充说，一个旨在解决以太坊验证者集大小增长问题的 EIP 将是 Prague/Electra 中的一个重要代码更改。基于代码更改的复杂性，Beiko 建议对于某些 EIPs，如 Verkle 或数据可用性抽样，开发者在假期之后组织专门的会议，详细讨论这些更大的协议更改。