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