原文标题：《Ethereum All Core Developers Consensus Call #120 Writeup》

原文作者：Christine Kim

原文编译：Luccy，BlockBeats

上一次会议

在 10 月 19 日，以太坊开发人员齐聚 Zoom 参加了 All Core Developers Execution (ACDE) Call #120 会议。ACDE 电话会议是一个每两周举行一次的系列会议，由以太坊基金会研究员 Danny Ryan 主持，开发人员在会上讨论和协调对以太坊共识层（CL）的更改。本周，开发者们主要关注以下议题的进展：

1. CL 规范的 1.4.0-beta.3 版本；

2. Devnet-10 的启动条件；

3. Gajinder Singh 对 blob 延迟进行分析，他是一位维护 Lodestar 和 EthereumJS 客户端的软件开发者。

召唤（The Summoning）

Danny Ryan 宣布发布了 Cancun/Deneb（Dencun）升级的新 CL 代码规范，被称为「召唤」。这个版本在 CL GitHub 仓库中被正式标记为 1.4.0-beta.3 版本，主要包含两个变更：

1. 主网 KZG 配置：完成了以太坊可信设置仪式输出所需的格式化工作，并将其包含在最新的 CL 规范发布中。

2. 新的八卦规则：Teku 开发者 Enrico Del Fante 创建了一个新的八卦规则，以确保 CL 节点不会传播超过每个区块最大 blob 数量的 blob，目前规范中定义的每个区块的 blob 数量为六个。这将确保验证者不能用超过每个区块六个 blob 的无效消息垃圾邮件网络。

Devnet-10

CL 规范 1.4.0-beta.3 版本的更改将在下一个开发网络 Devnet-10 上进行测试。然而，Devnet-10 的启动还有一些障碍。以太坊基金会的 DevOps 工程师 Barnabas Busa 表示，他仍在等待客户端团队发布新的软件版本。一旦这些准备就绪，Busa 希望在 10 月 20 日（周二）的某个时候启动下一个开发网络。

使用化名「Potuz」的 Prysm 客户端的开发者指出，最新的 CL 规范中包含的主网 KZG 配置在对「go-kzg」进行更改之前无法合并到 Geth 和 Prysm 中。「go-kzg」是一个单独的代码仓库，将 KZG 承诺方案实现到 Go 编程语言中。开发者们在电话会议上对 go-kzg、Geth 和 Prysm 仓库之间的依赖关系表示了失望。这并非 Potuz 和其他开发者第一次提出关于使用 KZG 库进行 EIP 4844 的挑战。

以太坊基金会的 DevOps 工程师 Parithosh Jayanthi 表示，开发者可以在没有主网 KZG 配置和新客户端发布的情况下启动 Devnet-10，但这意味着开发者不会在 Devnet-10 上测试任何新代码，而是在 Devnet-9 上重新测试发布的代码。

本周，在 Devnet-9 上，开发者们发现了 CL 客户端实现中的一个问题。以太坊基金会测试团队的 Mario Vega 解释称，验证者未能正确处理无效的数据块（blob）。Vega 介绍说，如果验证者恶意地将有效的数据块广播给部分节点，而将无效的数据块广播给其他节点，那么接收到无效数据块的节点将无法追踪链的头部。为了解决这个问题，已经创建了一个 hive 测试，以便轻松复制这些条件并针对新的客户端发布进行测试。这将使开发者能够立即了解他们针对该问题的修复是否有效。

关于这个问题，Enrico Del Fante 提到，当某个区块包含一个或多个与区块中现有 blob 承诺不匹配的索引的 blob 时，在特定情况下，Teku 客户端将不会导入这个区块。以太坊基金会研究员 Dankrad Feist 指出，故意提议包含无效 blob 的区块的验证者除了可能增加以太坊点对点网络的计算负担并导致接收区块的部分验证者与网络失去同步之外，并没有其他好处。Feist 强调，这种行为没有经济收益，即使验证者这样做，以太坊点对点层的额外计算负担也将受到每个区块最大 blob 数量的限制。

尽管如此，为了阻止验证者采取这种行为，开发者们正在讨论可能添加一个新的削减条件。新的削减条件将试图监控区块中无效 blob 的包含情况，以阻止验证者故意给点对点层带来压力。然而，由于改变以太坊验证者经济学所需的研究和分析成本很高，Ryan 建议在 Dencun 之后的下一个升级 Prague/Electra 的背景下进一步讨论这个提议。

Ryan 补充指出，开发者可以在 Dencun 的 CL 规范中为这种情况设定适当的行为，即使 blob 索引与区块承诺不匹配，验证者仍应导入区块。他认为，由于验证者没有经济动力去以 Del Fante 描述的方式传播含有无效 blob 的区块，这种非理性行为可能导致的网络负担最大程度地受到每个区块最大 blob 数量的限制。因此，对 CL 规范进行微小修改应该足以在短期内解决问题，同时开发者可以考虑未来升级的更持久性解决方案，如新的削减条件。

Jayanthi 与 Ryan 再次确认，在开发者在客户端设置主网 KZG 配置并解决 Mario Vega 提出的问题之前，Prysm 客户端上至少不会启动 Devnet-10。Ryan 强调，关于新的削减条件的讨论仅在 Prague/Electra 升级的背景下进行，而不是 Dencun，并且关于导入包含无效 blob 的区块的 CL 规范的更改不应成为启动 Devnet-10 的障碍。Prysm 和 Lighthouse 客户端团队的代表表示，他们将在 10 月 20 日（明天）为他们的软件发布更新。

区块延迟分析

在 10 月 14 日（星期六）的一次分享中，以太坊客户端 Lodestar 和 EthereumJS 的维护者 Gajinder Singh 分享了关于基于八卦传播的 blob 数量与区块导入延迟之间关系的新分析。Singh 指出，在他对 Devnet-9 的实验中，验证者接收到的 blob 数量越多，区块的延迟就越明显地增加。

下表总结了 Singh 的发现。第一列列出了完整区块到达的百分比，而表格中的数值表示导入区块所需的秒数。

区块导入延迟（以秒为单位）与区块中包含的 blob 数量之间的关系。图源: Gajinder Singh, Twitter

Singh 在推特上表示，虽然每个区块中只有一个 blob 产生的延迟可以忽略不计，但任何高于两个的数字都会引入显著的延迟。Dankrad Feist 表示，Singh 的分析数据与他在以太坊主网上传播大区块的实验结果非常不同。Feist 断言：「看起来这些数据不可能是正确的」，并补充说，由于 blob 是与区块并行处理的，所以将 blob 处理的延迟加到区块时间上是一种不准确的方式来预测主网上区块传播时间。Singh 关于带有 blob 的区块传播的预测可以在

Singh 在 Twitter 上表示，尽管每个区块中只有一个 blob 产生的延迟可以忽略不计，但任何高于两个的数字都会引入显著的延迟。然而，Dankrad Feist 指出，Singh 的分析数据与他在以太坊主网上传播大区块的实验结果有很大差异。Feist 断言：「这些数据看起来不可能是正确的」，并补充说，由于 blob 是与区块并行处理的，因此将 blob 处理的延迟加到区块时间上来预测主网上区块传播时间是一种不准确的方式。Singh 关于带有 blob 的区块传播的预测可以在这里找到。Feist 称 Singh 的分析「过于悲观」。

尽管存在分歧，Feist 和 Ryan 都认为 Singh 的分析确实值得其他客户端团队借鉴。Ryan 鼓励其他 CL 团队尝试在 Devnet-9 上重现 Singh 的实验，看看他们是否能得到相似的数据和结果。如果有关于引入 blob 后区块延迟的新数据，Ryan 建议在下周的 ACDE 电话会议上重新讨论这个议题。

「原文链接」