[币圈小飞侠]以太坊Pectra升级或将分成两个硬分叉

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

原文作者：Christine Kim

原文编译：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 关于这个问题的pullll 在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 电话会议。