以太坊核心******新会议摘要：Pectra 升级或将分成两个硬分叉

撰文：Christine Kim

(WEEX交易所官网：www.weex.com)

编译：Luccy，BlockBeats

编者按：以太坊所有核心***共识电话（ACDC）每两周举行一次，主要讨论和协调对以太坊共识层（CL）的更改。本次为 ACDC 第 134 次电话会议，本次会议上，***们探讨了多个关键 EIP 的实现细节和技术挑战，包括 EIP 7549、EIP 7251、EIP 6110、EIP 7688 等。

此外，***们还深入讨论了 PeerDAS 的实施，这项数据可用性采样技术预计将显著提升以太坊网络支持 Rollups 及其数据可用性需求的能力。会议中提出了将 Pectra 分成两个硬分叉进行升级的建议，并讨论了不同 EIP 的激活时间和相互依赖关系的问题。

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

2024 年 5 月 30 日，以太坊开发人员齐聚 Zoom 参加了 All Core Developers Consensus (ACDC) call #134 会议。ACDC 电话会议是一个每两周举行一次的系列会议，由以太坊基金会研究员 Alex Stokes 主持，开发人员在会上讨论和协调对以太坊共识层（CL，也称为信标链）的变更。本周，***们讨论了 Pectra Devnet 0 启动后的经验和未解决的问题。他们还辩论将 Pectra 升级的范围扩大到包括 peerDAS 和 SSZ 容器代码更改的可行性。

Devnet 0 回顾

根据 Pectra 在 Devnet 0 上的启动情况，客户端团队已同意在硬分叉激活期间保持 EIP 7549 影响的验证行为不变。在之前的一次 ACDC 会议上，***们曾考虑过多种方案，以确保在分叉期间 EIP 7549 的影响不会导致大量无效验证。为了避免使升级变得更加复杂，客户端团队决定在与其他 Pectra EIP 相同的纪元激活 EIP 7549，且在分叉前后不改变验证行为。

关于 EIP 7251，***们仍然不确定是否应该允许从执行层（EL）触发质押 ETH 的合并。这对于像 Lido 这样的质押池来说将是一个理想的功能，这样质押的合并就不必依赖于节点操作员，而是可以通过智能合约来实现。Stokes 建议在几周后检查客户端实现验证者质押合并的进展，然后再确定它们应该是 EL 操作还是 CL 操作。

然后，***们讨论了关于 EIP 6110 下验证者存款***终确认的一些未解问题。Teku *** Mikhail Kalinin 在会议前的一条 GitHub 评论中总结了这些问题的解决方向。Lighthouse ***「sean」提出了一个关于 Engine API 中「GetPayloadBodies」请求的版本控制的问题。Stokes 建议***们在 GitHub 上针对这个问题创建的 pull request 中发表他们的意见。

EIP 7549 变化

Nimbus *** Etan Kissling 建议对 EIP 7549 的实现进行一个小改动。「这是关于泛化索引的稳定性问题。当我们在容器中间添加一个新字段时，后续字段会被分配一个新的索引，这会打破基于 EIP 4788 在执行层（EL）的证明，并且有些误导性。……因此，我建议将新字段移动到末尾，以避免这两个问题。」Kissling 解释道。对此改动没有人提出反对意见。Stokes 建议***在 GitHub 上查看 Kissling 提出的 pull request。

另一个对 EIP 7549 的改动是在会议上提出的，将请求和其他由 EL 触发的请求设计为 EL 区块的附加程序。关于这个改动，Kalinin 表示：「在我看来，这是一个非常不错的设计方案，它简化了 EL……而且这基本上是对执行层区块中泛化请求的一种替代方案。」Stokes 建议在下次 CL 会议上再次讨论这个话题，以便***有更多时间审查 GitHub 上的这个提案。

Pectra 范围讨论

有一些聚焦于共识层（CL）的 EIP 尚未正式包含或排除在 Pectra 升级之外。本周会议上，***们讨论了是否在 Pectra 中加入 EIP 7688 和 PeerDAS。EIP 7688 采用了「StableContainer」SSZ 数据结构的一部分，以确保 EIP 7549 对证明的更改具备向前兼容性。作为背景介绍，SSZ 是一种在 CL 中使用的数据结构，***希望在执行层（EL）中也使用它。有关 SSZ 转变的更多信息，请参阅之前的会议记录。PeerDAS 是以太坊上数据可用性采样的实现，预计将大大增强网络支持 rollups 及其数据可用性需求的能力。实际操作中，PeerDAS 预计将验证者可以附加到区块的 blob 交易数量从每个区块 3 个增加到 64 个或更多。

以太坊基金会***运营工程师 Barnabas Busa 表示，***已经在一个开发网络上启动了 PeerDAS 的早期迭代版本。「我认为很多客户端已经发现了很多问题，当我们有了实质性的进展时，随时都可以重新启动一个新的开发网络，」Busa 说。Stokes 询问***们是否愿意在可能导致升级延迟的情况下将 PeerDAS 添加到 Pectra 中。

一位昵称为「Nishant」的***重新提出了将 PeerDAS 激活与 Pectra 中其他 EIP 的激活分开的建议。虽然这是可行的，但另一位昵称为「atd」的***强调，如果***计划在短时间内依次激活这些升级，用户还是需要同时升级他们的软件。atd 说：「我认为，在另一次升级两个月后进行分叉是有点疯狂的。如果我们要协调所有人升级客户端，我们不想在两个月后再让所有人升级客户端。那样的话，甚***连一个发布周期都不够。」

atd 补充说，在他看来，PeerDAS 是 Pectra 中包含和讨论的 EIP 中***「有趣」的代码更改。Stokes 表示，即使这会导致升级延迟，他也希望将 PeerDAS 包含在 Pectra 中。Grandine 客户端*** Saulius Grigaitis 提议从 Pectra 中移除 EIP 7549 和 EIP 7688，以便支持 PeerDAS。这引发了对 EIP 7688 实施细节的讨论。***们未能就代码更改达成一致，并将在下一次 ACDC 会议上重新讨论这一提案。

关于 PeerDAS 的话题，***们继续权衡将 Pectra 分成两个硬分叉的想法。以太坊基金会***选项工程师 Parithosh Jayanthi 警告说，如果***将 Pectra 分成两个升级，他们必须小心不要在未来的 Pectra 第二部分中增加更多的 EIP。Jayanthi 说：「我想提到的一件事是，如果我们考虑分成两个分叉，我们必须非常小心，不要在接下来的分叉中加入更多的新 EIP。我不知道我们是否能够做到这一点。如果我们能够在一年或一年半之前承诺一些事情，因为我们总是在提出新的想法，优先级也在变化等等。」

继续讨论两个升级的想法，Lighthouse ***「sean」说，他没有预见到 PeerDAS 与当前 Pectra EIP 列表之间有很多相互依赖关系。因此，这两者可以分别进行，之后在***对它们的实现更加自信时轻松合并。Atd 同意这一观点，认为在分别开发和测试这些内容后，将 Pectra EIP、PeerDAS 和 EIP 7688 合并不会有太大风险。

Busa 建议继续测试 Pectra EIP 和 PeerDAS，但将代码更改设计成 PeerDAS 在开发网络和测试网络上比 Pectra EIP 晚一个 epoch 激活。他指出，这已经是在 Devnet 0 上进行 Pectra EIP 和 PeerDAS 测试的方式。Busa 说：「实际上没有什么需要改变」，他补充说，如果 PeerDAS 在其他 Pectra EIP 准备好时还未准备好，***可以将该代码更改从升级中删除。这引发了几个关于 PeerDAS 不同激活 epoch 如何影响客户端团队工作的疑问。***终，***们同意继续开发 PeerDAS 及 Pectra EIP，但前提是 PeerDAS 将在开发网络和测试网络上在不同的 epoch 激活。

如前文所述，***们同意将 EIP 7688 是否包含在 Pectra 中的讨论留到下一次 ACDC 电话会议。