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

· Pectra Devnet 1 的启动

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

· 将稳定容器以太坊改进提案（EIPs）纳入 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 devnets 尚未纳入许多 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 中发现的问题，并在启动新的 devnet 之前确保实现的稳定性。Lodestar 和 EthereumJS 的开发者 Gajinder Singh 表示，根据最近一次 PeerDAS 实现者会议的反馈，社区有意向在下一个 Pectra devnet 中集成 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上分享他们的看法和建议。

「原文链接」