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