以太坊核心开发者共识会议#149记录

• 在 Twitter 上分享
• 在 Facebook 上分享
• 在 Linkedin 上分享
• 邮箱

研究 • 2025 年 1 月 23 日

以太坊全体核心开发者共识会议 #149 纪要

2025 年 1 月 23 日，以太坊开发者通过 Zoom 召开了 全体核心开发者共识（ACDC）#149 会议。本次会议由以太坊基金会（EF）研究员 Alex Stokes 主持。ACDC 会议是一个双周会议系列，开发者在会上讨论和协调以太坊共识层（CL）（也称为信标链）的变更。

在 ACDC #149 会议上，开发者讨论了 Pectra Devnet 5 上新发现的错误，并同意在升级公共测试网之前启动另一个 devnet。他们详细制定了 Pectra 主网激活的暂定时间表，这将要求客户端团队在 2 月 3 日之前发布更新的软件，以便有望在 2 月 12 日和 2 月 19 日分别在 Sepolia 和 Holesky 测试网上激活 Pectra。此后，开发者计划发布最终的 Pectra 软件，以便有望在 2025 年 3 月 11 日升级主网。

Pectra Devnet 5 & 6

一个 gas 预估错误导致 Pectra Devnet 5 上出现三向链分叉。根据 EF DevOps 工程师 Rafael Matias 的说法，该网络仍然没有最终确定。Nethermind、Reth、Erigon 和 Besu 客户端团队正在修复错误。Matias 补充说，最近在 Pectra Devnet 5 上运行的 hive 测试也失败了，所以他的团队正在调查发生了什么。

基于 Pectra 规范的待定更改以及 Pectra Devnet 5 上最近的网络故障，开发者同意他们应该在升级公共测试网之前启动另一个 devnet，即 Devnet 6。Matias 说，客户端团队应该首先修复错误，并且一旦针对更新后的客户端运行了 hive 测试，他的团队就可以启动 Devnet 6。Stokes 强调说，EIP 7702 还有一些规范变更需要在 GitHub 上最终确定。Geth 开发者 “Lightclient” 说他会做这件事。Stokes 还指出，Pectra 有一个新的 CL 规范发布，版本 1.5.0-beta.1，但其中没有实质性的更改，使其与之前的版本有很大不同。

Stokes 询问客户端团队对启动 Devnet 6 的信心有多大。开发者同意争取在下周初启动 devnet。EF DevOps 工程师 Parithosh Jayanthi 在 Zoom 聊天中写道，与此同时，开发者还可以开始计划 一个影子分叉 来测试 Pectra。作为背景，影子分叉是通过分叉一个活跃的测试网或主网而创建的 devnet。与常规 devnet 不同，影子分叉保留了被分叉网络的相同状态和历史记录，因此来自被分叉网络的交易可以在影子分叉上重放。

Pectra 公共测试网和主网分叉时间

然后，开发者讨论了升级以太坊公共测试网和主网的时间。EF 协议支持负责人 Tim Beiko 建议争取在 3 月 11 日激活主网，因为这意味着 Pectra 在以太坊上的激活时间距离其之前的升级 Dencun 不到一年，Dencun 发生在 2024 年 3 月 13 日。在 3 月 11 日有望激活主网意味着公共以太坊测试网 Sepolia 和 Holesky 必须分别在 2 月 19 日和 24 日之前升级。理想情况下，这两个测试网更早地在 2 月 12 日和 19 日升级，以便最终用户和更广泛的以太坊生态系统有更多时间为升级主网做好充分准备。

没有人反对 Beiko 提出的时间表，但很明显，该时间表是暂定的，因为开发者尚未修复 Devnet 5 上的错误并启动 Devnet 6。Beiko 说，他将跟进具体的区块号以配合建议的日期，并将这些区块号放在下一次 ACD 会议上进行讨论。他强调说，如果客户端团队认真对待拟议的时间表，那么接近最终的客户端版本必须在 2025 年 2 月 3 日之前准备好。

PeerDAS

一位屏幕名为 “Manu” 的开发者分享了有关 PeerDAS 进展的更新。除了 Lighthouse 和 Prysm 之外，其他客户端团队正在实施最新的 PeerDAS 规范。Lighthouse 和 Prysm PeerDAS 实现的测试正在进行中。Manu 说，开发者正在调试两个客户端之间客户端互操作性的问题。

作为背景，PeerDAS 是以太坊的下一个主要扩展改进，暂定计划在 Pectra 之后的升级 Fusaka 中激活。PeerDAS 将在以太坊上启用 “数据可用性采样”，以便以太坊节点具有更大的容量来处理区块中包含的 blob 交易。EF 研究员 Ansgar Dietrichs 说，参加会议的开发者应该预计 PeerDAS 会将以太坊的 blob 吞吐量提高 8 倍。

Stokes 提出了 OP Labs 工程师 “protolambda” 的一项提案，即通过实施仅 blob 参数（BPO）分叉来加速以太坊的扩展路线图。在 Protolambda 的一篇文章中，他们 解释说，“BPO 分叉是简单的以太坊分叉，仅更改两个参数：blob 目标和 blob 限制。BPO 分叉使以太坊能够灵活地以更小、更规律的增量安全地扩展 blob，并且它们使构建者确信以太坊将不断增长其容量。”

Prysm 开发者 Terence Tsao 警告说，通过 PeerDAS 将 blob 吞吐量提高 8 倍可能“比我们想象的要困难一些”，并且在开发者确定最佳的采样相关代码更改推出方式之前，需要进行更多的研究和测试。Beiko 在 Zoom 聊天中说，支持 BPO 分叉的另一种可能性可能是“将验证者的 blob 目标转移到控制中”，就像验证者控制区块 gas 限制一样。

Lightclient 说，关于 BPO 分叉的讨论似乎为时过早，因为 Pectra 已经将 blob 容量增加到网络可以安全处理的程度，并且鼓励以任何方式增加超出此限制的 blob 限制可能是不安全的。Dietrichs 赞同 Lightclient 的担忧。Nethermind 开发者 Ben Adams 说，与区块 gas 限制不同，节点运营商可能更难以投票和微调 blob gas 限制的更改，因为区块中的每个额外 blob 最多携带 128kB 的额外数据。

Protolambda 说，他欢迎继续就他的 BPO 分叉想法提供反馈。

Fusaka 分叉规划流程

Beiko 询问开发者对以太坊分叉规划流程的看法、其优缺点以及考虑到 Pectra 的规划方式以及为规划下一次升级 Fusaka 所做的准备，哪些方面可以改进。“正如你们中的一些人可能已经注意到的那样，人们对全体核心开发者有意见，我认为 Pectra 在协调和规划方面有点像一个疯狂的分叉。” Beiko 说。Stokes 对 Beiko 关于 Pectra 的观点表示赞同，并表示他支持花时间“反思”治理流程并为 Fusaka 升级改进它。

Besu 开发者 Justin Florentine 说，开发者应该澄清他们所说的 Pectra 是一个 “疯狂” 的分叉是什么意思，并提供更多关于他们为准备 Pectra 所面临的困难或挑战的具体细节。Lodestar 开发者 Gajinder Singh 在 Zoom 聊天中写道，“重要的是在愿景上保持一致，以便在观点和 ACD 流程中产生共鸣。” Dietrichs 在聊天中写道，“我个人真的认为我们对 maxeb [EIP 7251] 做出了过早的决定。我认为如果我们立即优先考虑 peerdas，它本可以包含在此次分叉中。”

Beiko 说，他将创建一个以太坊魔法师论坛，以继续讨论以太坊治理和 ACD 流程的改进。他鼓励客户端团队和更广泛的以太坊社区发表他们的想法。Stokes 提醒客户端团队注意 1 月 27 日星期一的 Pectra 测试电话会议，EF 研究员 Piper Merriam 在 Zoom 聊天中提醒客户端团队，距离自行设定的 2025 年 5 月 1 日 截止日期还有不到 100 天，该截止日期是为了从客户端中删除 pre-Merge 历史记录。

• 原文链接： galaxy.com/insights/rese...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～