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

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

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）上有关客户端多样性问题的提案。

如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 团队将调查对这一提案进行原型设计，并提供有关区块验证延迟的基准数据。

郑重声明：本文版权归原作者所有，转载文章仅为传播信息之目的，不构成任何投资建议，如有侵权行为，请第一时间联络我们修改或删除，多谢。