2024 年 6 月 13 日，以太坊开发人员齐聚 Zoom 参加了 All Core Developers Consensus (ACDC)Call #135 会议。ACDC 电话会议是一个每两周举行一次的系列会议，由以太坊基金会研究员 Alex Stokes 主持，开发人员在会上讨论和协调对以太坊共识层（CL，也称为信标链）的更改。本周，开发者们讨论了 Pectra Devnet 1、PeerDAS Devnet 1 以及一个用于 Simple Serialize（SSZ）以太坊改进提案（EIPs）的第三个专用测试网络的准备工作。
公告
开发者们以两个公告开始了会议。以太坊基金会开发运维（DevOps）工程师 Parithosh Jayanthi 表示，ethPandaOps 团队，这是一组在以太坊基金会开发运维（EF DevOps）工作的工程师团队，将接管ethereum-package Kurtosis 模块的维护和开发。这个软件包过去被开发者用来启动以太坊测试网络和相关工具，例如用于监控和测试各种客户端实现的 Grafana 数据仪表板。该软件包从 Kurtosis 技术团队迁移到 ethPandaOps 团队的过程中，可能会影响用户，因为某些链接将重定向到由 ethPandaOps 团队管理的 GitHub 存储库，而不再是 Kurtosis 团队。Jayanthi 建议用户更新他们的软件链接，并关注 ethPandaOps 团队发布的新版本。
第二个公告由以太坊基金会协议支持主管 Tim Beiko 发布。Beiko 表示，他正在努力引入新的流程，以分阶段将 EIPs 纳入以太坊的升级中。他已经创建了一份草案 EIP，定义了「Proposed for Inclusion」（提议包含）、「Considered for Inclusion」（考虑包含）和「Scheduled for Inclusion」（计划包含）这些标签。他希望开发者们审阅该文件并提供反馈。他希望在下次 ACD 会议前完成这份文件。
Electra
下一个 Electra 主要版本v1.5.0-alpha.3的代码规范即将完成。开发者们同意将共识规范 GitHub 仓库中的拉取请求（PR）#3768合并到下一个版本。这份拉取请求由 Nimbus 开发者 Etan Kissling 创建，他指出，「committee_bits」字段应该附加到「Attestation」的末尾，而不是数据的中间，以避免数据序列化问题。除了 PR #3768，Stokes 问是否还有其他需要在下一个 Electra 规范主要版本发布前解决的未决问题。Jayanthi 在 Zoom 聊天中提到，通过执行层（EL）触发的验证器整合存在一些未决问题。Stokes 记录了在会议后跟进 EL 触发的验证器整合状态的事项。
关于最新的 Electra 规范的实施进展，会议上的大多数共识层（CL）客户端团队表示，他们能够在v1.5.0-alpha.3最终确定后一到两周内准备好新版本进行测试。开发者们同意在几周后重新讨论下一个 Pectra 开发网络 Pectra Devnet 1 的时间安排。
PeerDAS
接下来，开发者们讨论了 PeerDAS 的实施进展。PeerDAS 是以太坊的一个网络改进，将增强节点处理和验证用户通过 blob 交易提交的大量任意数据的能力。Stokes 回顾了上次 ACDC 会议上的决定，即开发者们将在其他 Pectra EIPs 的同时，平行开发 PeerDAS，通过在开发网络上激活 PeerDAS 的单独激活周期来实现。
Lodestar 开发者 Gajinder Singh 表示，根据最近一次关于 PeerDAS 的分组会议的讨论，开发者将在 Deneb 升级的基础上，并在与其他 Pectra EIPs 分开的开发网络上激活 PeerDAS。Teku 开发者 Enrico Del Fante 表示，开发者更容易在已经在先前以太坊升级 Deneb 中确定的稳定代码规范上构建 PeerDAS，而不是在不断变化的 Pectra 代码规范上。Jayanthi 同意现在将 PeerDAS 实施与其他 Pectra EIP 实施合并可能会在测试过程中引起复杂问题，尤其是在尝试找出错误来源时。他建议将这两个工作流程分开，然后在两者的实现更稳定后再进行合并。Stokes 表示同意，并说开发者们可以在大约一个月后重新讨论合并 PeerDAS 和其他 Pectra EIP 实施的事宜。
关于启动 PeerDAS Devnet 1 的话题，客户端团队对于何时准备好测试网启动没有明确估计。会议上的个人估计大致在 2 周到 1 个月之间。Stokes 建议在几周后，客户端团队有更多时间进行 PeerDAS 实施时，重新讨论开发网络的时间安排。
然后，Beiko 指出，虽然 PeerDAS 是一个网络改进，而不是以太坊核心协议的变化，但他仍然希望将代码变化包含在 Pectra 升级的元 EIP 中。元 EIP 文档是列出以太坊升级中包含的所有核心协议变化的公共文件。Beiko 指出，PeerDAS 是 Pectra 中「最大的特性」，尽管不需要硬分叉激活，但仍应包含在文档中，以表明开发者们认真准备在 Pectra 主网激活时及时准备好它。对此没有异议。
提高 blob gas 限制
PeerDAS 改变了节点通过以太坊对等网络层处理和传播数据的方式。为了让用户，特别是 Layer-2 rollups，受益于这些变化，开发者必须将当前每块六个 blobs 的限制提高到更高的阈值，这将允许更高的 blob（任意数据）吞吐量。更改 blob 限制需要对以太坊核心协议进行更改，如开发者在本周会议上讨论的那样，这可能涉及比简单调整协议技术栈中的一个常量值更复杂的工程工作。
Stokes提议，在更改 blob gas 限制时，解耦执行层（EL）和共识层（CL）之间的依赖关系。目前，任何对 blob gas 限制的更改都需要更改 EL 和 CL 协议。Stokes 提出了一些方法，可以打破这些依赖关系，使开发者能够安全地从 EL 中删除硬编码的 blob gas 限制，并完全由 CL 决定。以太坊基金会（EF）研究员 Dankrad Feist 指出，除了 EL 和 CL 之间的依赖关系问题外，更改 blob gas 限制对区块的 gas 计算的连锁反应也很重要。Feist 说：「最好的方法是改变计算方式。gas 价格计算发生在 EL 中可能是个错误。那应该在 CL 中，但现在改变起来更难。……这并不容易。」
开发者们同意继续调查对 blob gas 限制和区块中 gas 计算进行更改的最佳途径。开发者们还同意继续讨论在 Pectra 中激活 PeerDAS 时是否会伴随着 blob gas 限制的增加。开发者们对这些更改是应该结合在一起还是分多个硬分叉进行分阶段实施存在分歧。
Jayanthi 表示，结合这些更改是一个「有风险」的决定，因为开发者在 PeerDAS 在主网上激活之前不会知道它的具体功能表现。以太坊基金会（EF）DevOps 工程师 Barnabas Busa 补充说，Pectra 硬分叉的范围已经非常大了，不需要再增加额外的代码更改。Busa 说：「关键是我们已经有很多 EIP 了，我觉得我们不断地添加更多内容，这样永远不会结束。所以，我们必须在某个地方画一条线，这就是我们的终点。我认为在未来一年半的测试时间里，发布 PeerDAS 并增加 blob 数量是不可能的。」
一位屏幕名为「Francesco」的开发者建议，如果网络变化不会伴随 blob 数量的增加，可以移除 PeerDAS 来「降低 Pectra 的风险」。Francesco 问：「如果没有增加 blob 数量，Pectra 的 PeerDAS 到底有什么好处？」
为了进一步说明测试 PeerDAS 的困难，Jayanthi 指出，测试引入 blobs 到以太坊的 EIP 4844 并没有完全模拟 blobs 在以太坊主网上的实际表现和影响。Jayanthi 说：「问题在于测试网络非常困难。我们确实进行了很多与 4844 相关的出色测试，但 blobs 在主网上的表现与在测试中的表现并不是完全一致。我们确实看到较弱的节点出现问题。我们确实看到时间上的挑战等类似情况，这就是为什么即使我们能在开发网络中模拟出 PeerDAS 和增加 blob 数量都能正常运作的完美情况，但这对主网来说并没有任何实际意义，这也是我认为我们应该一步一步来而不是一次性完成的主要原因。」
EF 研究员 Ansgar Dietrichs 评论说，把增加 blob 数量和 PeerDAS 关联起来是错误的，因为仅仅是 PeerDAS 就已经要求开发者选择一个 blob 数量值。虽然开发者可以选择与以太坊主网上相同的数字，但关于 PeerDAS 应该使用什么数字的决定必须做出。唯一选择相同数字的理由是开发者增加了 PeerDAS 的复杂性，使其在出现错误时能够回退到当前 Deneb 规范中的 blob 传播机制。Dietrichs 补充说，关于测试复杂性的担忧进一步加强了他认为 Pectra 应该通过两个硬分叉激活的观点，而不是一个，但这并不意味着他认为 PeerDAS 应该与 blob 数量的更改分离。
SSZ 更新
Kissling 分享了三个与 SSZ 相关的 EIP的进展更新。他指出，这些 EIP 的实现工作已经在多个客户端上展开，包括 Teku、Grandine 和 Lighthouse。他说，开发者可以开始讨论这些 SSZ EIP 的开发网络时间表，并可能在下一个 ACDC 会议上将它们纳入 Pectra 升级的范围。
F-Star 命名
有一篇在 Ethereum Magicians 上的帖子，讨论了 Electra 之后的下一个以太坊共识层（CL）升级名称。开发者已经为 Prague 之后的执行层（EL）升级确定了名称：大阪（Osaka）。候选的 CL 升级名称有：Fulu、Felis、Formosa 和 Funi。这些名称都遵循以「F」开头的主要恒星命名惯例，适用于 Beacon Chain 的第六次全网升级。Stokes 请在通话中的开发者在 Magicians 帖子上发表对此话题的看法。