以太坊核心开发者最新会议摘要：Pectra 升级启动、PeerDAS 实现进展探讨

原文标题：《Ethereum All Core Developers Consensus Call #138 Writeup》
作者：Christine Kim
编译：Ladyfinger，BlockBeats

编者按：
以太坊所有核心开发者共识电话（ACDC）每两周举行一次，主要讨论和协调对以太坊共识层（CL）的更改。本次为 ACDC 第 138 次电话会议，本次会议涵盖了 Pectra Devnet 1 的启动、信标区块体和引擎 API 结构的变更、将稳定容器以太坊改进提案（EIPs）纳入 Pectra，即 EIP 7688 和 EIP 7495 以及 PeerDAS 的更新等多个议题。会议期间，开发者们审议了 Pectra 升级的准备情况，并探讨了关于 PeerDAS 实现的一些未解问题和提案。此外，Nimbus 开发者 Etan Kissling 还分享了 EIP 7688 和 EIP 7495 的实施工作进展，强调了这些提案对以太坊数据序列化方法升级的重要性。Galaxy Digital 研究副总裁 Christine Kim 对本次会议要点做了详细记录，BlockBeats 将原文编译如下：

2024 年 7 月 25 日，以太坊开发者通过 Zoom 举行了第 138 次全核心开发者共识（ ACDC ）会议。 ACDC 会议是每两周举行一次的会议系列，开发者们在这些会议上讨论并协调对以太坊共识层（ CL ），也称为信标链的变更。本周的会议由以太坊基金会（ EF ）研究员 Alex Stokes 主持。开发者们讨论了以下内容：

· Pectra Devnet 1 的启动

· 信标区块体和引擎 API 结构的变更

· 将稳定容器以太坊改进提案（ EIP s ）纳入 Pectra ，即 EIP 7688 和 EIP 7495

· PeerDAS 的更新及其在主网上的实施时间表

Pectra Devnet 1 Pectra

Devnet 1 于 7 月 23 日星期二上线。然而，网络并不稳定。以太坊基金会开发运维工程师 Parithosh Jayanthi 表示， Erigon 客户端在 devnet 启动后不久遇到了问题。接着，一个在 devnet 上广播的 EIP 7702 交易导致网络分裂成三个状态。开发者们正在调试客户端并解决链分裂问题。

引入 ExecutionPayloadEnvelope 

Prysm 开发者 Potuz 提出了对信标链区块执行负载结构的重大改进，以及对引擎 API 的相应调整。这一提议旨在简化共识层（ CL ）客户端存储和处理状态转换数据的过程。随着 Pectra 升级的实施， CL 客户端需要访问执行负载的特定部分来正确执行状态转换。然而，现有设计导致这些客户端忽略了执行负载中的一些非必要信息。

Pectra 升级将要求 CL 客户端要么从执行层（ EL ）请求必要的状态转换数据，要么在本地存储区块的关键部分。为了提高 Pectra 升级后 CL 客户端的效率， Potuz 建议引入名为「 binded _ execution _ payload _ envelope 」的新结构，集中存储执行状态转换所需的关键信息。这样的改进将显著提升 CL 客户端在计算状态转换时的速度和效率。他还强调，这些调整将确保与未来的网络升级，如简单序列化（ SSZ ）格式的兼容性。

Lighthouse 项目的开发者 Mark Mackey 提出警告，如果不实施这些变更， CL 客户端在 Pectra 测试网的性能可能会受到影响。 Teku 项目的开发者 Mikhail Kalinin 对此表示谨慎，他质疑是否真有必要通过改变协议来解决 Pectra 中 EIPs 实现的复杂性。 Potuz 则坚持认为，现有的协议设计存在根本性问题，需要修正。他指出：「目前的设计在理念上就存在缺陷，它将对 CL 状态转换至关重要的数据与完全无关的数据混合在同一级别、同一消息中。因此，我认为当前的设计是错误的，我们正在努力纠正这一错误。」

Stokes 鼓励开发者在GitHub上继续讨论这个提议。

Devnet 2 的引擎 API 更新

与上述讨论相关， Geth 开发者「 Lightclient 」提出了对引擎 API 的另一个变更。这个变更旨在使 EL 客户端更容易进行区块转换。 EL 客户端通过解释区块中的空字段和空字段来确定区块版本。然而，由于 Prague 的 EIP 7685，如果没有分叉时间表， EL 客户端将无法根据这些字段区分区块版本。为了避免引用过去升级的时间表的开销， Lightclient 提议将所有请求统一为引擎 API 中的单一类型， EL 可以将其传递给 CL 进行解释。

Lightclient 指出，区块的解释在 EL 和 CL 之间有所不同，而在这种情况下， CL 更适合表示请求数据。「当我们处理区块本身时，区块没有概念，『这是 Bellatrix 区块。』，就像在 CL 上一样。我认为你们在区分不同类型的分叉区块方面做得很好。但在 EL 上，我认为这就是几乎所有客户端实现的方式，我们有一个区块代表所有区块类型，我们使用存在的，比如一个值的空值，来确定那个 [分叉] 是否活跃。」

Nimbus 开发者「 Dustin 」反对这个提议，说 Lightclient 的提议并没有充分解决 EL 和 CL 上区块解释的复杂性。「这只是将复杂性和混乱从 EL 转移到 CL ，而且两个地方都是可行的。将其移到 CL 并没有解决问题。……它只是移动了问题，」 Dustin 说。

Stokes 断言，CL 更适合处理请求的解释，并建议开发者更仔细地查看 Potuz 和 Lightclient 在GitHub上提出的引擎 API 变更。

Pectra 中的 EIP 7688 和 7495

Nimbus 开发者 Etan Kissling 一直在推动以太坊序列化方法更新为 SSZ 。为了 Pectra 的目的，他确定了两个中间 EIPs ，7688 和 7495，以引入智能合约开发者可以依赖的数据结构，以与未来的 SSZ 相关变更兼容。 Kissling 指出，他已经得到了像 Rocketpool 这样的流动质押池的支持，以及 Teku 和 Lodestar 等其他客户端团队的支持。

Stokes 警告 CL 客户端团队不要在 Pectra 中添加新的 EIPs 。「 Pectra 已经非常大了，特别是如果我们最终在分叉中有了 PeerDAS 。在某个时候，我们需要非常现实地看待分叉的大小以及它所带来的风险。再说一次，我同意 Etan 给出的这个功能在真空中是有价值的理由，但我认为这是我们做过的最大的硬分叉之一，或者就是最大的，这不应该被轻视，」他说。

开发者们对这些 EIP 何时可以实际添加到 Pectra devnet 提出了一些担忧，因为 Pectra devnet s 尚未纳入许多 EIP ，如 PeerDAS 和 EOF 。对此， Jayanthi 建议首先明确决定开发者是否应该在升级中包括这些 EIP 。 Jayanthi 还警告说，在测试 CL 和 EL EIP 一起在一个 devnet 上时存在瓶颈。他在 Zoom 聊天中写道：「10 个直接的 EIP 一起发货，会使得分叉在组合中测试变得非常复杂。而我们不仅有直接的 EIP 。」

Mackey 分享说，像 EigenLayer 团队这样的应用开发者正在试图弄清楚 Pectra 中计划激活的内容，以及这些两个 EIP 的持续缺乏清晰度是他们工作的障碍。 Lighthouse 开发者 Sean Anderson 建议从以太坊上的应用开发者那里获取更多关于这些 EIP 的意见，以确定它们对应用程序有多关键。

Stokes 建议稍后再重访这个讨论，以便开发者集中精力解决 Pectra Devnet 1 的问题。

PeerDAS 更新

开发者们就 PeerDAS 的最新进展进行了深入讨论。 Anderson 报告称，共识层（ CL ）客户端团队正在积极修复在上一轮 PeerDAS 的 devne 中发现的问题，并在启动新的 devne t 之前确保实现的稳定性。 Lodestar 和 EthereumJS 的开发者 Gajinder Singh 表示，根据最近一次 PeerDAS 实现者会议的反馈，社区有意向在下一个 Pectra devne t 中集成 PeerDAS 。

Stokes 提出，根据与以太坊基金会（ EF ）研究团队及其他开发者的讨论，初步在主网上激活 PeerDAS 时可能需要省略抽样功能，以降低实现的复杂性。他阐释说， PeerDAS 的完整实现涉及分发、抽样和重建三个关键功能。「目前， PeerDAS 在 Pectra 中的规范涵盖了这三个任务。我的直觉告诉我，抽样功能可能是实现过程中最大的复杂点。如果抽样确实带来了难以克服的挑战，我们可以考虑在 Pectra 中增加 blob 的数量，同时减少或调整 PeerDAS 的范围，」 Stokes 解释道。

Stokes 承诺，他将就此想法制定一个正式的提议，并与开发者社区进一步探讨。 Singh 对此表示支持。 Stokes 还建议在 Pectra 升级中正式纳入 PeerDAS 。对此， Jayanthi 询问这是否意味着要在 Pectra 规范的基础上重新定义 PeerDAS 规范，并指出合并 PeerDAS 和 Pectra devnets 可能会因两者都不稳定而使调试工作复杂化。他建议在规范稳定之前，应保持两个工作流程的独立性。 Teku 的开发者 Enrico Del Fante 也赞同 Jayanthi 的看法。

Stokes 注意到，许多专注于 PeerDAS 实现的开发者未能参加此次会议。他提议在下一次 PeerDAS 实现者会议上继续探讨 PeerDAS 的未来步骤。

添加 BeaconBlocksByRange V3

Lighthouse 项目的开发者「 Dapplion 」提出了一项改进方案，旨在帮助客户端在发生长时间链分裂的情况下，能够更有效地同步至主链。他指出，现有的 [ BeaconBlocksByRange V2 ] RPC 协议存在一定的局限性：「当你需要同步一个长分叉的区块，而不确定哪个分支是主链时，按照当前的协议，你只需提交一个插槽范围，节点便会返回它认为正确的区块。尽管你可以通过状态消息查询这些信息，但这一过程存在异步性，可能会引发一些问题。虽然目前主网上尚未出现严重的分叉情况，但如果未来发生类似事件，这将是一个需要解决的问题。」

Dapplion 进一步说明，他提出的解决方案相对简单，甚至有可能被纳入即将到来的 Pectra 升级中。尽管这些改进并非迫在眉睫，Stokes 还是鼓励与会的开发者们仔细审查这一提议，并在GitHub上分享他们的看法和建议。