摘要：另一方面，会议提到Geth开发者Szilágyi提出了解决执行层（EL）上的客户端多样性问题的提案。接着，Teku开发者EnricoDelFante提出了一个问题，关于CL客户端在Cancun/Deneb后使用「byRoot」RPC请求检索缺失的块和blob的适当条件是什么，DelFante关于这些问题做出详细解释。...

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 团队将调查该提案的原型设计，并提供相关块验证延迟的基准数据。