以太坊核心开发者最新会议摘要：Pectra修复与筹备、PeerDAS进展

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 提到了 Pry** 客户端需要进一步调查的小问题。EF DevOps 工程师 Parithosh Jayanthi 补充说，还需要客户端团队调查 Lighthouse、Teku 和 Besu 节点之间的问题。

随后，开发者们讨论了如何改善 devnet 启动的通讯流程。Pry** 的开发者 Kasey Kirkham 在 Zoom 聊天中指出了自己对 Devnet 2 启动时间的不知晓。为确保 Devnet 3 的启动信息能准确传达给所有客户端团队，开发者们决定设立一个定期的周会议，用于更新 Pectra 的测试进展。尽管具体时间尚未确定，但这些会议预计将在每周一举行，类似于 Dencun 升级前的测试电话会议。Jayanthi 提出，这些会议将简短**，时长控制在 15 至 30 分钟之间，专注于讨论 Pectra 相关的 devnet 测试更新，涵盖 PeerDAS 和 EOF devnets 等议题。

在讨论 Pectra Devnet 3 的议题时，开发者们重申了它将沿用与 Devnet 2 一致的 EIP 配置。此外，Devnet 3 将**集成**设计的 EIP 7702，团队将对其进行细致的测试，以确保其与 Pectra 核心 EIPs 的兼容性。Lodestar 团队的 Gajinder Singh 提到，在 Devnet 2 中发现的 EIP 7251，即 MaxEB 提案中的问题，尽管已经进行了调试，但仍需在接下来的 Pectra devnet 上进行更深入的测试以验证解决方案。

正如在ACDE #193上讨论的，有一个新的 Engine API 规范，它允许 CL 客户端从 EL blob 交易内存池中获取 blobs。该方法称为「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 EIPs 在数据变更方面的前向兼容性。

Alex Stokes 对于在 Pectra 升级中加入 EIP 7688 持谨慎态度，认为升级规模已经相当庞大。Parithosh Jayanthi 在会议中提到，EIP 7688 最早可能在 Devnet 5 中进行测试。Lodestar、Pry**、Teku 和 Lighthouse 等团队的代表对此提案表示支持。Stokes 和 Beiko 建议，在所有现有 Pectra EIPs 达到稳定状态之前，应避免向 Pectra 添加新的 EIPs。Kissling 接受了这一建议，并询问了何时重新讨论此议题的**时机。尽管没有得到具体答复，但团队普遍认为应在 Pectra Devnet 5 启动前对 EIP 7688 进行再次评估。

PeerDAS 更新

Pry** 客户端团队的代表在会议上汇报了他们关于 PeerDAS 实施的**进展，并引发了对"blobsidecar" 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%，且约一半的节点部署在数据**。Pry** 的开发者「Potuz」对于数据**托管的 Lighthouse 节点数量超过自托管节点的现象表示好奇。Stokes 推测，这可能是因为 Lighthouse 客户端的主要用户群体包括机构和专业的节点运营商。

在会议的尾声，Potuz 敦促团队审查他所提交的关于调整执行有效载荷结构的 PR。该提案在上一届 ACDC 电话会议中**被提出。Potuz 强调了迅速决策的重要性，指出尽管这些变更在概念上简单易懂，但要将它们整合进共识层（Consensus Layer, CL）规范却颇具挑战。他建议开发者们尽早着手这一工作。

本文 巴适财经 原创，转载保留链接！网址：/article/522222.html