编译：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 电话会议。
APP 
