原文标题：《Ethereum All Core Developers Consensus Call #124 Writeup》
原文作者：Christine Kim
原文编译：Luccy，BlockBeats
编者按：
以太坊所有核心开发者共识电话（ACDC）每两周举行一次，主要讨论和协调对以太坊共识层（CL）的更改。本次为 ACDC 第 124 次电话会议，会议主要涵盖了 Devnet #12 的更新、Cancun/Deneb 升级的进展结果以及与 Slashable 信息传播相关议题。在会议中，开发者们积极讨论了 Libp2p 网络协议的微小更改，以减少大消息对节点的放大效应。
Galaxy Digital 研究副总裁 Christine Kim 对本次会议要点做了详细记录，BlockBeasts 将原文编译如下：
2023 年 12 月 14 日，以太坊开发人员齐聚 Zoom 参加了 All Core Developers Consensus (ACDC) call #124 会议。ACDC 电话会议是一个每两周举行一次的系列会议，由以太坊基金会研究员 Danny Ryan 主持，开发人员在会上讨论和协调对以太坊共识层（CL）的更改。本周，开发者们聚焦讨论 Devnet #12 测试网络上对 Cancun/Deneb 升级的测试进展。自上周的全核心开发者执行（ACDE）会议以来，所有执行层（EL）和共识层（CL）客户端组合都已接入 Devnet #12，其中包括 Prysm 客户端。已启用 MEV-Boost 软件，但不包括带有 Prysm 的客户端组合。开发者表示他们正按计划进行，计划在接下来的一到两周内启动 Goerli 阴影分支，以测试 Cancun/Deneb 升级，并包括所有客户端。此外，开发者还讨论了 Slashable 信息传播的规则，以及接下来两周的通话日程。
Devnet #12 更新
以太坊基金会的 DevOps 工程师 Barnabas Busa 表示，所有 EL/CL 客户端组合，包括那些使用 Prysm 作为 CL 客户端的组合，都已成功接入 Devnet #12。使用 Prysm 的客户端组合尚未进行 MEV-Boost 软件测试。然而，在 Devnet #12 上，MEV 工作流程正在测试其他 CL 客户端。最近，Lighthouse 客户端已进行补丁更新，以解决与 MEV 相关的错误。此外，基金会的另一位 DevOps 工程师 Parithosh Jayanthi 表示，他们注意到在 Devnet #12 上的 Besu 节点存在问题，他们仍在努力确定其根本原因。作为下一步，开发者们将故意通过网络发送恶意区块，测试区块生成器，并为新添加的 Prysm 客户端运行 hive 测试，对 Devnet 上的客户端组合进行压力测试。Jayanthi 在通话期间在公开的 Discord 消息中表示，开发者们仍然计划在年底之前在 Goerli 测试网上启动阴影分支。
Slashable 信息更新
接着，开发者们简要讨论了与 Cancun/Deneb 升级后在以太坊上 Slashable 信息的传播和时机有关的几个问题。作为背景，Slashable 信息包括重复或无效区块和 blob 的传播。Lodestar 客户端的匿名开发者 Dapplion 通过 GitHub 提出了一个拉取请求（PR），旨在向 Beacon Chain API 添加新事件，使节点操作员能够更快地了解 Slashable 事件，尤其是在存在大量 Slashable 信息的情况下，这将特别有用。Dapplion 在他的 PR 中提到：「对于大型操作者而言，切割事件的总成本在很大程度上取决于他们的响应时间。如果有许多密钥涉及操作错误，那么这些 Slashable 信息可能需要一些时间才能被包含在链上。」Dapplion 的 PR 在通话之前已经被合并到 Beacon Chain API 的规范中，并正由各个 CL 客户端团队实施，例如 Prysm 和 Lighthouse。
Dapplion 还提出了一个与测量区块传播时间有关的 PR。他指出，由于 Cancun/Deneb 升级和 blob 交易的引入，测量区块传播时间将变得更加困难。Dapplion 在他的 PR 中详细说明了他提出的解决方案。正如在 PR 主题线程中开发者们所注意到的那样，他们倾向于通过在现有相关的 Beacon Chain API 事件中添加一个时间戳字段来解决这个问题。
开发者们讨论的第三个与 Cancun/Deneb 升级后 Slashable 信息传播有关的主题是 blob 的传播条件。Lighthouse 开发者「sean」（或 GitHub 上的「realbigsean」）指出，现有的 blob 传播规则导致了意外的后果。Sean 在通话中表示：「如果您使用 Beacon API 进行广播验证，那么以 gossip 的方式可能导致消息的有效和无效是出乎意料的。原因在于，从技术上讲，可以传播两个具有与其相关的 Slashable 头部的不同 blob 索引的 blob。您被允许传播这些，但不被允许传播那些具有相同 blob 索引的。」
Sean 补充说，当涉及到 blob 的 Slashable 信息传播时的奇怪行为对网络的健康没有实质性的影响，除了对节点操作员来说只是一个「奇怪」的结果需要理解和解析。因此，虽然对于 Cancun/Deneb 的激活来说并不紧急，但他建议开发者在未来的升级中考虑对处理 Slashable 信息传播规则的规定进行修改。Danny Ryan 同意这种看法，表示开发者应该花时间「全面」考虑解决这个问题的方法。Ryan 建议在一月份重新讨论这个话题，让开发者有时间设计一个全面的计划来更新 Slashable 的 blob 和区块传播规则。
接下来，开发者们讨论了对 libp2p 网络协议的微小更改，以减少对节点发送大消息（例如具有大量 blob 的区块）的放大效应。Sean 强调了新增的「IDONTWANT」控制消息，可以用于通知 libp2p 对等节点暂停发送大消息。Ryan 表示他将尝试联系 libp2p 团队来合并这个 PR，如果有进一步的延迟，将在下周的 ACDE 电话会议中重新讨论这个问题。
