原文标题：《 Ethereum All Core Developers Consensus Call #139 Writeup
作者： Christine Kim
编译： Ladyfinger ， BlockBeats
编者按：
以太坊所有核心开发者共识电话（ ACDC ）是每两周举行一次的系列会议，专注于讨论和协调以太坊共识层（ CL ），也就是信标链的变更。第 139 次 ACDC 电话会议由以太坊基金会（ EF ）研究员 Alex Stokes 主持，会议内容涵盖了 Pectra Devnet 2 的修复、 Devnet 3 的准备、 PeerDAS 实施进展以及以太坊节点分布的新数据。
在会议期间，开发者们审议了 Pectra Devnet 2 的稳定性和存在的问题，讨论了即将到来的 Devnet 3 的准备工作，并就 PeerDAS 的实施进展进行了深入探讨。此外， EIP 7688 的提案也引起了与会者的广泛讨论，这一提案旨在引入一种向前兼容的数据结构，以支持以太坊数据序列化方法的潜在变更。 Galaxy Digital 研究副总裁 Christine Kim 对本次会议进行了详细记录， BlockBeats 将原文编译如下：
2024 年 8 月 8 日，以太坊开发者们通过 Zoom 举行了第 139 次核心开发者共识电话会议（ ACDC ）。 ACDC 电话会议是每两周举行一次的系列会议，开发者们在此讨论并协调对以太坊共识层（ CL ），也称为信标链的变更。本周的电话会议由以太坊基金会（ EF ）研究员 Alex Stokes 主持。开发者们讨论了 Pectra Devnet 2 的修复、 Devnet 3 的准备、 PeerDAS 实施进展以及以太坊节点分布的新数据。
Pectra 更新
Stokes 宣布， EF 的研究员 Hsiao Wei Wang 即将推出 Pectra 共识层（ CL ）规范的官方更新版本 alpha .4，该版本包含了对前一版的多项改进，并计划在近期发布。
关于 Pectra Devnet 2 的话题， EF 开发者运营工程师 Barnabas Busa 表示，网络稳定，并已达到 85% 的网络参与度。在执行层（ EL ）客户端中还有一些需要解决的小问题，主要是 EthereumJS 和 Erigon 。大多数 CL 客户端在 Devnet 2 上是稳定的。然而， Busa 提到了 Prysm 客户端需要进一步调查的小问题。 EF DevOps 工程师 Parithosh Jayanthi 补充说，还需要客户端团队调查 Lighthouse 、 Teku 和 Besu 节点之间的问题。
随后，开发者们讨论了如何改善 devnet 启动的通讯流程。 Prysm 的开发者 Kasey Kirkham 在 Zoom 聊天中指出了自己对 Devnet 2 启动时间的不知晓。为确保 Devnet 3 的启动信息能准确传达给所有客户端团队，开发者们决定设立一个定期的周会议，用于更新 Pectra 的测试进展。尽管具体时间尚未确定，但这些会议预计将在每周一举行，类似于 Dencun 升级前的测试电话会议。 Jayanthi 提出，这些会议将简短高效，时长控制在 15 至 30 分钟之间，专注于讨论 Pectra 相关的 devnet 测试更新，涵盖 PeerDAS 和 EOF devnet s 等议题。
在讨论 Pectra Devnet 3 的议题时，开发者们重申了它将沿用与 Devnet 2 一致的 EIP 配置。此外， Devnet 3 将首次集成最新设计的 EIP 7702，团队将对其进行细致的测试，以确保其与 Pectra 核心 EIP s 的兼容性。 Lodestar 团队的 Gajinder Singh 提到，在 Devnet 2 中发现的 EIP 7251，即 MaxEB 提案中的问题，尽管已经进行了调试，但仍需在接下来的 Pectra devnet 上进行更深入的测试以验证解决方案。
正如在 ACDE #193 上讨论的，有一个新的 Engine API 规范，它允许 CL 客户端从 EL blob 交易内存池中获取 blob s。该方法称为「 getBlobsV1 」。为了避免滥用， Teku 开发者 Enrico del Fante 提出了一些对 CL 规范的澄清。 Stokes 建议开发者们审查这些澄清，并计划在 Pectra Devnet 3 上测试这种方法的使用。
开发者们就 mplex 协议的弃用进行了讨论。 Mplex 曾是 CL 客户端用于单一通信链接多数据流传输的协议，但目前已遭其维护者废弃。客户端团队正计划转向如 yamux 这样的新型数据流复用技术。 Lodestar 的 Phil Ngo 宣布，他们已完成 yamux 的集成和测试工作，并倾向于直接过渡到新协议，而非长期维护两个协议，因为这将增加客户端的运营成本。 Nimbus 的 Etan Kissling 也透露，他们团队正在对 yamux 进行测试。开发者们达成共识，将继续关注其他 CL 客户端团队在协议过渡方面的进展，并计划在未来几个月内再次评估从 mplex 到新复用器的迁移策略。
Etan Kissling 在 Pectra 议题上提出了关于 EIP 7688 的讨论，该提案旨在引入一种向前兼容的数据结构，以便智能合约开发者能够在以太坊执行层（ EL ）的数据序列化方法从 RLP 过渡到 SSZ 时继续使用。尽管 Pectra 升级本身不会完全实现 SSZ ，但 EIP 7688 的提出是为了确保 Pectra EIP s 在数据变更方面的前向兼容性。
Alex Stokes 对于在 Pectra 升级中加入 EIP 7688 持谨慎态度，认为升级规模已经相当庞大。 Parithosh Jayanthi 在会议中提到， EIP 7688 最早可能在 Devnet 5 中进行测试。 Lodestar 、 Prysm 、 Teku 和 Lighthouse 等团队的代表对此提案表示支持。 Stokes 和 Beiko 建议，在所有现有 Pectra EIP s 达到稳定状态之前，应避免向 Pectra 添加新的 EIP s。 Kissling 接受了这一建议，并询问了何时重新讨论此议题的最佳时机。尽管没有得到具体答复，但团队普遍认为应在 Pectra Devnet 5 启动前对 EIP 7688 进行再次评估。
PeerDAS 更新
Prysm 客户端团队的代表在会议上汇报了他们关于 PeerDAS 实施的最新进展，并引发了对「 blob sidecar 」 Engine API 请求必要性的讨论。 Alex Stokes 建议在下一次 PeerDAS 小组会议中深入讨论 PeerDAS 对 Engine API 所需进行的调整。他同时指出，一位 EF 研究员已经草拟了正式规范，提议从 PeerDAS 中移除抽样机制，目的是降低升级过程的复杂度。然而，在最近一次的 PeerDAS 小组会议上，与会者担心此举可能会增加未来通过硬分叉重新引入抽样的难度。此外，抽样机制的移除对 Pectra 中 blob gas limit 安全增加的影响尚不明确。一项提议将执行层（ EL ）和共识层（ CL ）中的 blob gas limit 解耦的提案， EIP 7742，在本周的电话会议上再次被提出。 Stokes 表示他将更新该 EIP ，并计划在下一次的 CL 电话会议上讨论其纳入的可能性，以及与 Pectra 中 blob gas limit 调整相关的议题。
研究更新
在本周的电话会议中，开发者们集中讨论了三项研究议题。首先，他们探讨了 EIP 7251 下，验证者在合并质押 ETH 余额时可能遇到的边缘情况。 Etan Kissling 提出，验证者余额在合并期间可能长时间未更新，这可能导致协议错误地分配同步委员会职责。对此， Alex Stokes 回应称，这一问题与协议处理验证者退出的情况相似，并建议在共识层（ CL ）规范中记录这一边缘情况，而不改变现有合并设计。
然后，开发者们讨论了以太坊网络层的变更，特别是引入了「 quic ENR entry 」。 Quic 代表快速 UDP 互联网连接，它帮助节点发送和接收数据。 Stokes 建议在 GitHub 上创建一个拉取请求（ PR ），以进一步详细说明 quic ENR entry 的具体变更。
最后， ProbeLab 分享了他们对以太坊网络的节点运行情况的持续分析。报告显示，目前有 8335 个节点在以太坊网络上运行，其中 42% 使用的是 Lighthouse 客户端。在美国运营的节点占总数的 36%，且约一半的节点部署在数据中心。 Prysm 的开发者「 Potuz 」对于数据中心托管的 Lighthouse 节点数量超过自托管节点的现象表示好奇。 Stokes 推测，这可能是因为 Lighthouse 客户端的主要用户群体包括机构和专业的节点运营商。
在会议的尾声， Potuz 敦促团队审查他所提交的关于调整执行有效载荷结构的 PR 。该提案在上一届 ACDC 电话会议中首次被提出。 Potuz 强调了迅速决策的重要性，指出尽管这些变更在概念上简单易懂，但要将它们整合进共识层（ Consensus Layer , CL ）规范却颇具挑战。他建议开发者们尽早着手这一工作。
