最新的以太坊核心开发人员会议摘要:Blob 更新Sidecar网络,解决EL客户端多样性问题

AR EC ID IDE 以太 2023-11-19 53

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

编者按:以太坊所有核心开发者的共识电话(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 团队将调查该提案的原型设计,并提供相关块验证延迟的基准数据。

相关推荐