编者按：

以太坊所有核心开发者共识电话（ACDC）每两周举行一次，主要讨论和协调对以太坊共识层（CL）的更改。本次为 ACDC 第 122 次电话会议，会上指出多数 CL 客户端团队计划在近期完成对 Deneb 规范的更新实现，并讨论了新的开发网络的启动计划。此外，开发者们着重改进 blob 传播条件，以简化相关复杂性，并在 RPC 请求中检索缺失块和 blob 的条件上进行讨论。

另一方面，会议提到 Geth 开发者 Szilágyi 提出了解决执行层（EL）上的客户端多样性问题的提案。该提案旨在通过交叉验证解决客户端错误，产生了有关构建无状态以太坊客户端和区块生成过程的深入讨论。讨论中涉及了 EL 客户端团队的不同立场，以及提案可能对网络健康和用户动机的影响。问题的复杂性要求进一步研究和原型设计，而此提案将由 Geth 和其他 EL 客户端团队深入研究。

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

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

大多数 CL 客户端团队表示，它们的目标是在本周或下周完成对 Deneb 规范的更新实现。开发者们同意在下周四的所有核心开发者执行（ACDE）电话会议上开始讨论启动 Devnet #12。然后，开发者们详细讨论了 Geth 开发者 Péter Szilágyi 提出的解决执行层（EL）上有关客户端多样性问题的提案。

Blob Sidecar 网络更新

如ACDC＃121所讨论的，CL 客户端团队正在对 blob 传播条件进行改进，以显著减少与过去 11 个开发网络观察到的 blob 传播相关的复杂性和问题。以下是各个 CL 客户端团队自上一次 ACDC 以来的进展更新：

Lighthouse：开发基本完成。需要到下周末进行新代码的审查和测试。

Teku：实施了新的传播验证。正在进行构建工作流的开发。

Lodestar：计划在本周末完成实施。

Prysm：计划在下周末完成实施。之后需要另一个星期来整理构建工作流。

基于 CL 客户端的更新，Ryan 建议在下一次 ACD 电话会议期间计划启动 Devnet #12。以太坊基金会（EF）的 DevOps 工程师 Barnabas Busa 表示，下一个 Cancun/Deneb 开发网络的「合理」目标启动日期可能是 11 月 29 日或 30 日。EF 的另一位 DevOps 工程师 Parithosh Jayanthi 询问了有关 hive 测试的最新情况。EF 测试团队的 Mario Vega 确认，升级的基本 hive 测试已经准备就绪。他的团队将在接下来的几周内为 hive 测试套件添加用于构建和「blobber」工作流的新测试用例。

接着，Teku 开发者 Enrico Del Fante 提出了一个问题，关于 CL 客户端在 Cancun/Deneb 后使用「byRoot」RPC 请求检索缺失的块和 blob 的适当条件是什么，Del Fante 关于这些问题做出详细解释。通话中的其他开发者支持在 CL 规范中明确说明，即当通过 RPC 请求导入时，客户端应何时接收块和 blob，如果客户端没有通过八卦协议接收到它们。开发者还讨论了其他客户端需要满足的条件，以回答有关块和 blob 的 RPC 请求。Prysm 开发者 Terence Tsao 指出，基本上有「三个层次」来解决这些条件。客户端可能通过以太坊的点对点网络层收到一个 blob 或块。第二个层次是客户端通过八卦接收这个 blob 或块，并通过状态转换功能验证消息。第三个也是最终的层次是客户端接收有关块及其相关 blob 的所有必要信息。开发者们就在 Cancun 规范中关于 Del Fante 的问题需要满足哪个层次进行了辩论。

Ryan 建议 Del Fante 在 GitHub 上创建一个拉取请求，以正式化此问题的语言，并在下周最终确定。

解决 EL 客户端多样性问题

在 ACDC＃122 上讨论的最后一个话题是 Szilágyi 提出的「Making EL Diversity Moot」提案。Geth 开发者 Marius van der Wijden 在通话中分享了该提案的摘要，解释说这个提案试图解决的「最坏情况」是，如果大多数客户端存在错误，导致以太坊上的大多数验证者被削减并被强制退出网络。Szilágyi 的提案建议的方法是，不是鼓励运行大多数客户端的用户切换到少数客户端，而是鼓励用户通过与其他少数客户端进行交叉验证来解决问题。

「与其要求人们运行少数客户端（可能不方便），或要求他们运行多个客户端（可能很贵）；我们可以让他们使用他们喜欢的任何客户端，而只是要求他们与其他客户端进行无状态的交叉验证，」Szilágyi 建议道。为了使这一提案奏效，Geth 和其他 EL 客户端团队将不得不致力于构建其客户端的轻量版本，以用于交叉验证以太坊区块。用于交叉验证区块的客户端版本将无法与网络同步、提出区块，或以其他方式执行 EL 客户端的全部功能。Van der Wijden 提到，构建「无状态」以太坊客户端的工作将对未来以太坊的 Verkle Trie 升级有所帮助。

Nethermind 开发者Łukasz Rozmej 表示，他对该提案持否定态度，因为 EL 客户端为了与其他客户端进行交叉验证，需要额外的工作，这将给区块生成过程引入延迟。此外，Rozmej 表示，他更愿意等待在 Verkle Trie 升级完成之后再进行构建可投产的无状态以太坊客户端的工作。Rozmej 还提问，如果与其他客户端的交叉验证失败，客户端将如何处理区块生成。为解决这个问题，Ryan 建议采取「n of m」的方式。如果对区块的交叉验证在 6 个客户端中至少有 3 个成功，验证者将继续对区块进行验证，否则将停止验证。

Ryan 还提出了一个担忧，即这一提案可能进一步降低用户从使用像 Geth 这样的大多数客户端切换到少数客户端的动机，特别是如果通过 Szilágyi 的交叉验证提案减少了由于 Geth 中的错误而导致的削减风险。「我认为这对于网络的健康是正确的事情，」对于 Ryan 的担忧，Van Der Wijden 回应道。「最重要的是我们不会最终确定任何无效状态。这比 Geth 是否占据 50% 或 60% 的网络更为重要。」Van Der Wijden 还指出，该提案不需要得到所有 EL 客户端团队的支持才能继续推进。至少，Van Der Wijden 表示 Geth 团队将调查对这一提案进行原型设计，并提供有关区块验证延迟的基准数据。