2024 年 2 月 8 日，以太坊开发人员齐聚 Zoom 参加了 All Core Developers Consensus (ACDC) call #127 会议。ACDC 电话会议是一个每两周举行一次的系列会议，由以太坊基金会研究员 Danny Ryan 主持，开发人员在会上讨论和协调对以太坊共识层（CL）的更改。本周，开发者们安排了 Dencun 升级在 2024 年 3 月 13 日激活主网。他们还讨论了主网上一个导致 9 个错过验证机会的事件的教训。该事件发生在 2024 年 2 月 6 日星期二，重新引发了关于通过一项名为 enshrined 提案者构建分离（ePBS）的升级来消除验证器对可信中继的依赖的讨论。此外，开发者们还同意重新考虑 Electra 升级中的 maxEB 和包含列表等代码变更。
Dencun 测试
以太坊基金会开发者运营工程师 Parithosh Jayanthi 表示，2 月 7 日星期三在 Holesky 测试网上激活 Dencun 升级进展顺利。Jayanthi 说：「至少在 Holesky 上我们没有注意到任何问题。」他补充道：「我们已经通过了 Goerli 的 blob 事务的过期窗口，因此我们运行了一堆节点，正在进行创世同步以及检查点的同步测试。」
Prysm 开发者 Terence Tsao 提到，在 Holesky 升级期间错过了分叉过渡块。虽然这「不是什么大问题」，但 Tsao 表示，该事件导致了他的节点出现了 11 秒的区块延迟。他建议客户端团队仔细检查，看看他们的实现是否在升级期间某种方式导致了这种延迟。
Lighthouse 开发者「Sean」表示，Lighthouse 团队已经在他们的客户端中实现了与节点恢复相关的逻辑，即当链尚未完成 blob 事务时，节点可以通过依赖于一个未完成检查点的检查点同步来恢复。然而，Sean 表示，实现这一逻辑比他的团队预期的要复杂，并鼓励 CL 客户端团队在遇到类似困难时寻求帮助。
Nethermind 开发者 Marcin Sobczak 表示，他的团队正在继续调查上周四ACD 电话会议中提到的他们客户端中的潜在 bug。Sobczak 表示，他的团队已经开始向 Goerli 网络发送大量的事务，到目前为止，没有发现任何问题。他说，在 Goerli 上的测试应该在几个小时内完成。
Dencun 主网激活
以太坊基金会协议支持负责人 Tim Beiko 分享了以下 Dencun 升级的主网激活日期和时间：
Beiko 提到，他已经联系了 L2Beat.com 上排名前 10 的以太坊 Rollups 团队，以评估他们对 Dencun 的准备情况。「所有团队基本上都处于各种测试阶段。我认为，L2 方面的团队将在 3 月初到中旬左右准备好在主网上使用 4844，」Beiko 说道。「我认为我们不应该基于 L2 团队的准备情况来阻止任何事情。」
Tsao 表示，从 Prysm 方面来看，他的团队希望有两周时间准备 Dencun 升级的最终主网发布版。代表 Lighthouse 客户端团队的 Sean 同意这个时间表。其他 CL 客户端团队，如 Teku 和 Lodestar，表示他们也可以在两周内准备好最终的主网客户端发布版。
基于这种情绪，Beiko 最初建议将主网升级日期定在 3 月 8 日星期四或 3 月 12 日星期二。然而，开发者们在 Zoom 会议聊天中反对了最终客户端发布和提议的硬分叉日期之间紧张的周转时间。开发者们同意在最终客户端软件版本发布和升级日期之间留出三周的时间。开发者们将在下一次 ACDC 电话会议之前准备好最终的客户端发布版，即 2024 年 2 月 22 日星期四。然后，Beiko 将于次日，即 2024 年 2 月 23 日星期五，正式发布一篇博客文章，宣布 Dencun 的主网激活。主网节点运营商将从那时起大约有三周的时间来升级他们的软件，Dencun 硬分叉将在 2024 年 3 月 13 日发生。
主网错过区块事件
在 2024 年 2 月 6 日星期二，Bloxroute Max Profit 中继向验证者交付了 9 个未能添加到以太坊区块链上的区块。这是由于中继中的一个错误导致的，该错误未能正确降级提交有问题区块的区块生成者。Bloxroute 随后修补了他们的中继，并对验证者因丢失区块奖励而进行了补偿。
此事件重新激发了关于如何最好减轻验证者对于包含 MEV 的区块的依赖性的讨论。Prysm 开发者「Potuz」表示，解决问题的一个即时方案可能是向验证者的断路器功能添加一个新的启发式，用于检查无效区块，并在中继连续发送两个或三个无效区块时回退到本地区块生成。以太坊基金会的研究人员 Danny Ryan 和 Dankrad Feist 担心，这种启发式的添加可能会被精明的 MEV 参与者轻易利用，他们可能会故意触发断路器，以暂时将所有区块中的 MEV 收入归自己所有。Lighthouse 的 Sean 指出，启发式的精确实现可能会因客户端而异，从而使恶意参与者更难利用，但对此，Ryan 建议这种启发式仍然可能会有一个大多数客户端实现遵循的标准。
随后，Ryan 提出了一个「八卦频道」（gossip channel）的想法，验证者可以在其中收听并提供关于区块生成者的区块签名的信息，以更快地向整个网络通知有问题的生成者，而无需依赖中继。然而，Potuz 反对了这个想法，表示开发者应该将资源投入到交付 ePBS 上，这是一个代码更改，将完全消除对受信任的中继的需要，并支持区块生成者和验证者之间的直接交互。在深入讨论是否应该将 ePBS 优先于短期解决方案（如专用八卦频道用于区块验证）之前，Danny Ryan 建议先评估一下已经提出的 Electra 的几个其他代码更改。
Electra 提案
简单提要，Ryan 询问开发者是否支持将「Pectra」作为 Prague/Electra 的合并升级名称。电话会议上的开发者似乎对这个合成词没有强烈的意见。Ryan 继续讨论了哪些代码更改应该优先考虑用于 Electra 的问题。
Electra EIP 7549
在ACDC＃126期间，开发者们同意在 Electra 升级中包含 EIP 7549。EIP 7549 是一项仅影响以太坊 CL 的代码更改，旨在使验证者证明的聚合更加高效。开发者们已经同意采用 EIP 7549 的最简设计以包含在 Electra 中。然而，根据 GitHub 上开发者之间对代码更改的更多讨论，有人希望增加代码更改的复杂性，以便它对网络产生更广泛的影响。Teku 开发者 Mikhail Kalinin 解释说：「这是在 EIP 7549 最初提出的基础上的进一步。正如 Danny 所说，它允许我们在链上紧密打包证明。它的好处在于，考虑到当前的验证者集大小，我们可以将证明的区块空间增加多达四倍。目前，如果它们理想地聚合，我们可以保留两个插槽的证明。这个改变将允许我们在不增加字节块大小的情况下将此数增加到八个插槽。」
Danny Ryan 同意这是对 EIP 的一个很好的改变，但建议仔细权衡它可能给协议带来的影响。Ryan 表示：「你增加了容量，但你减少了该容量的潜在多样性，这似乎是一个合理的权衡，但需要考虑风险。」Kalinin 表示同意，并表示他将进一步进行一些分析，并在相同的 EIP 编号下提供新的规范更改。
Electra SSZ
如在ACDC＃126上讨论的，开发者们正在考虑包括与 SSZ 格式相关的五个 EIP。来自 Lighthouse 的 Sean 表示，他需要更详细地评估代码更改，但从他的角度来看，这些代码更改「是一个好事」。据报道，另一位开发者在 Zoom 聊天中写道，他们希望将 SSZ 格式更改作为一个大的更改捆绑到协议中，而不是分阶段实施。Ryan 建议客户端团队对 Nimbus 开发者 Etan Kissling 提出的 SSZ 更改进行更多尽职调查，并在下一次 ACDC 电话上重新讨论这个话题。
Electra ePBS
Prysm 开发者「Potuz」在下一个主要的以太坊升级中提出了 ePBS 的理由。「我认为我们在主网上遇到的问题并不是一个即时问题或一个次要问题。九个区块消失或验证者是否被退款并不是问题的关键，真正的问题是我们需要信任中继。我们甚至不知道检查是什么。我们甚至不知道修复是什么。这是封闭源软件，这个开发是在一个黑盒子里进行的，」Potuz 说，并补充说：「这些是五个中继正在转发我们所有的区块或 90% 的区块，以及最多 10 个玩家正在构建这些区块。我认为我们需要做的是决定这是一个优先事项，我们在以太坊中不应该有一个受信任的玩家使用闭源软件做出决策，负责支付或不支付，为验证者退款，甚至决定哪些交易被审查或不被审查。一旦我们把这个当作优先事项，那么我们就可以讨论是否存在 ePBS 的可行设计。」
Potuz 敦促开发者考虑将 Electra fork 推迟到 2025 年，而不是 2024 年，并利用「Interop event」，这很可能是 2024 年 5 月发生的以太坊核心开发者见面会，来完善 ePBS 的最终设计。Tsao 表示，ePBS 只是「解决问题的一种方案。」他强调说，构建器 API 是一项重要的软件，它与以太坊协议不「保持激励一致」，需要更新。来自 Lighthouse 的 Sean 鼓励开发者考虑 ePBS 之外的解决方案，这些解决方案将中继固定在以太坊协议中，以解决信任中继的问题。以太坊基金会研究员 Dankrad Feist 表示，在他看来，ePBS 是一个非常重大的变化，不应该仓促进行。他对移除中继的主要担忧之一是打开了验证者窃取构建器 MEV 的可能性。目前，中继不仅受到验证者的信任，还受到构建器的信任。构建器信任中继不会提前运行他们的交易，他们对验证者也可能没有同样程度的信任，没有协议中的适当防护栏。
Potuz 对 ePBS 是一个大型代码更改的看法提出了异议，他认为目前的 ePBS 设计与包含列表或 maxEB 的工程变化程度不大。Danny Ryan 插话说：「每当我看到这个话题被提出时，就会有很多关于我们到底在优化什么的问题。这是一个正确的最终目标是什么的问题？似乎有很多不同的意见。首先包含这个决定是为了弄清楚设计是什么。」为此，Ryan 建议进行一次分组讨论，讨论 ePBS 的设计，并看看开发者是否能就其复杂性和对其他代码更改的依赖达成一致意见。
ePBS 的分组讨论将于美东时间 2 月 13 日上午 9:00（世界时 14:00）举行。
Electra 包含列表（Inclusion Lists）
接着，开发者讨论了EIP 7547，即包含列表。在ACDC＃126期间，开发者并不热衷将该提案纳入 Electra。然而，Ryan 表示自上一次 ACDC 电话会议以来，开发者希望再次讨论该提案。以太坊基金会研究员 Mike Neuder 表示已经创建了包含列表的简化设计。他还指出了一个新文件，详细介绍了客户端可能的包含列表规范。Ryan 表示已经审查了这些规范，并同意这并不像他最初想象的那么复杂。Sean 同意包含列表可能是可以纳入 Electra 的，但在他看来，maxEB 是一个更重要的代码更改。「我认为现在我倾向于尝试同时包括 maxEB 和包含列表，而不是完整的 ePBS，」Sean 说。他补充说，数据可用性采样（DAS）可以与这些其他更改并行进行。
与 ePBS 类似，开发者同意在单独的分组电话会议上更详细地讨论包含列表。包含列表的分组会议将于美东时间 2 月 16 日上午 9:00（协调世界时 14:00）举行。
Electra peerDAS 和 maxEB
开发者讨论的最后两个可能纳入 Electra 的提案是 peerDAS 和 maxEB。在 peerDAS 的话题上，Danny Ryan 表示，许多客户端团队表示他们打算在 Electra 升级的同时并行进行这个代码更改。由于 peerDAS 并不严格要求硬分叉，因此可以独立于 Pectra 升级进行部署。在没有硬分叉升级的情况下，peerDAS 不会导致 blob 事务的最大数量增加，即每个块的 blob 事务的最大数量。然而，Ryan 提到，一旦 peerDAS 准备就绪，就可以安排一个只更改 blob 事务最大数量的小型硬分叉。因此，Ryan 建议开发者同时进行 peerDAS 和 Electra 的工作。然而，Sean 表示，他认为 peerDAS 准备实施的速度可能比 Electra 升级更快，并希望最迟在 Electra 分叉时实施。对此，Ryan 随后建议在 Electra 升级中暂时包含 peerDAS，并在该代码更改最终成为 Electra 分叉中其他项目的阻碍时将其移除。开发者未能就此提案达成一致意见。Ryan 建议在 ePBS 和包含列表分组电话会议结束后重新讨论这个问题。对于在 Electra 中包含 maxEB 的讨论，Ryan 也建议同样做法。开发者同意在两周后的下一次 ACDC 电话会议上重新讨论这些问题。
