6 月 27 日，以太坊所有核心开发人员参加了第 136 次 All Core Developers Consensus(ACDC) 电话会议。

撰文：Christine Kim

编译：Luccy，BlockBeats

编者按：以太坊所有核心开发者共识电话（ACDC）每两周举行一次，主要讨论和协调对以太坊共识层（CL）的更改。本次为 ACDC 第 136 次电话会议，本次会议涵盖了客户端多样性数据收集、多客户端区块验证等新研究，及 Pectra 升级进展等多个议题。

会议期间，开发者们审议了 Pectra 升级的准备情况，并探讨了关于 PeerDAS 实现的一些未解问题和提案。此外，Nimbus 开发者 Etan Kissling 还分享了 EIP 7688 和 EIP 6493 的实施工作进展，强调了这些提案对以太坊数据序列化方法升级的重要性。

Galaxy Digital 研究副总裁 Christine Kim 对本次会议要点做了详细记录，BlockBeasts 将原文编译如下：

2024 年 6 月 27 日，以太坊开发人员齐聚 Zoom 参加了 All Core Developers Consensus (ACDC) call #136 会议。ACDC 电话会议是一个每两周举行一次的系列会议，由以太坊基金会研究员 Alex Stokes 主持，开发人员在会上讨论和协调对以太坊共识层（CL，也称为信标链）的更改。开发者们讨论了关于客户端多样性数据收集和多客户端区块验证的新研究。

他们还分享了 Pectra 升级的最新进展。Pectra Devnet 1 已经接近发布准备就绪。以太坊基金会的开发运维（DevOps）团队正在等待执行层（EL）客户端的准备情况。Teku 开发者 Mikhail Kalinin 分享了 EIP 6110 规范的更新。PeerDAS Devnet 1 已经上线，并且有三种不同的共识层客户端实现。SSZ 代码更改、EIP 7688 和 EIP 6493 的工作正在进行中，尽管开发者们尚未决定是否将这两个额外的 EIP 包括在 Pectra 中。

新研究

Nethermind 的研究员 Jorge Arce-Garro 分享了他团队最近在改进节点运营者报告客户端多样性数据方式方面的研究。该研究得到了以太坊基金会的资助。研究提出了三种不同的方法，以促进验证者节点运营者传达客户端类型，并根据方法的复杂性、安全性和保护节点运营者匿名性的能力进行评估。Arce-Garro 请求对他团队的研究提供反馈，这些研究已经发布在 Ethresearch 上。

接下来，Geth 开发者 Péter Szilágyi 分享了他团队在支持执行层（EL）交叉验证方面的最新工作进展。这一想法最初由 Szilágyi 在 2023 年 11 月提出，旨在提高以太坊在主要客户端出现重大错误时的弹性。EL 交叉验证旨在使多个客户端能够验证区块。如果一个客户端的区块验证结果与另一个不同，节点运营者可以拒绝接受或证明该区块，从而防止一个客户端故障时可能引发的链分裂。

自去年 11 月以来，Geth 团队详细探讨了这一想法，并在他们的软件中实现了一个版本。虽然这一功能在所有客户端的实现并不需要硬分叉，Szilágyi 强调了为了实现 EL 交叉验证，Engine API 需要进行重大更改。他还分享了区块导入延迟增加的基准测试数据。「区块导入的性能影响大约是 20%。所以，如果导入大约需要 100 毫秒，那么创建见证可能会额外增加 20 毫秒。我认为这是非常非常小的开销，这是我们已经高度优化的唯一组件，」Szilágyi 说，并补充道，仍需要进一步的测试和基准测试。

由于提出的更改比较复杂，会议上的开发者如 Guillaume Ballet、Lukasz Rozmej 和 Ahmad Mazen Bitar 提出了关于其优先级的问题，尤其是相对于即将进行的 Pectra 升级和随后的 Verkle 代码更改。开发者们讨论了如何从较小的部分开始，而不是承诺整个项目，例如更新 Engine API 的 JSON 和二进制编码，Szilágyi 强调这是这个软件长期需要努力的方向。关于该项目没有做出具体决定。Szilágyi 重申了在 GitHub 上分享了关于它的全部细节，并且欢迎反馈。

Electra 更新

以太坊基金会的 DevOps 工程师 Parithosh Jayanthi 表示，他的团队正在等待执行层（EL）客户端团队启动 Pectra Devnet 1。Teku 开发者 Mikhail Kalinin 表示，他已经完成了 EIP 6110 的规范更改，该更改在共识层（CL）上增加了一个队列机制，用于处理来自执行层的新验证者存款请求。Kalinin 请求开发者对他提出的更改提供反馈。

以太坊基金会的 DevOps 工程师 Barnabas Busa 分享了 PeerDAS 开发的最新情况。他提到 PeerDAS 的第二个开发网已经上线，并且有三种不同的共识层客户端实现。Busa 补充说，他的团队已经开始对开发网进行压力测试，并且已经发现了一些客户端实现中的问题，客户端团队正在努力修复这些问题。

Stokes 指出，关于 PeerDAS 的实现还有一些未解的问题，包括 blob gas 限制应该如何在执行层（EL）和共识层（CL）之间传递，以及 blob 基础费用的计算应该如何处理。开发者们正在权衡多种提案来解决这些问题。Stokes 要求开发者在接下来的几周内更仔细地审查这些提案，以便在未来的会议上达成共识。

然后，Nimbus 开发者 Etan Kissling 分享了 EIP 7688 和 EIP 6493 的实施工作进展。这两个代码更改涉及升级以太坊的数据序列化方法，虽然尚未正式被纳入 Pectra 升级，但一些开发者急于尽快包含它们。Kissling 表示，他希望在 Pectra Devnet 2 中包含 EIP 7688，这引起了一些客户端团队代表和以太坊基金会 DevOps 团队的关注。Stokes 建议开发者在稍后重新评估 EIP 7688 在 Pectra 开发网中的准备情况。

关于 EIP 6493 的进展，Kissling 分享说，EthereumJS 执行层客户端已经有了一个工作实现，他正在努力为该提案制作一个客户端演示。