原文标题：《Ethereum All Core Developers Consensus Call #129 Writeup》原文作者：Christine Kim原文编译：Luccy，BlockBeats
编者按：以太坊所有核心开发者共识电话（ACDC）每两周举行一次，主要讨论和协调对以太坊共识层（CL）的更改。本次为 ACDC 第 129 次电话会议，会议上，开发人员分享了有关 Dencun 升级准备工作的最后更新，并讨论了下一次以太坊升级 Pectra 的范围和 EIP。
Galaxy Digital 研究副总裁 Christine Kim 对本次会议要点做了详细记录，BlockBeasts 将原文编译如下：

2024 年 3 月 7 日，以太坊开发人员齐聚 Zoom 参加了 All Core Developers Consensus (ACDC) call #129 会议。ACDC 电话会议是一个每两周举行一次的系列会议，由以太坊基金会研究员 Danny Ryan 主持，开发人员在会上讨论和协调对以太坊共识层（CL）的更改。本周，开发人员分享了有关 Dencun 升级准备工作的最后更新，该升级计划于 3 月 13 日星期三在主网上激活。他们还讨论了下一次以太坊升级 Pectra 的范围，以及一些研究主题，其中之一是 CL 客户端之间的区块值标准化。

Deneb

Ryan 在电话会议开始时提醒大家，Dencun 升级将在不到一周的时间内在以太坊上线。他还提到，对于许多美国人来说，将在 DST 时间 3 月 10 日这个周末开始。鉴于所有 ACD 电话会议以及升级都是根据不实行 DST 的协调世界时（UTC）来安排的，那些位于美国之外的开发者和收听电话会议的人将需要相应地调整他们的日程安排。

电话会议上的一些客户端团队也分享了他们将在未来几天发布推荐版本的软件以适应 Dencun 升级，Prysm、Lighthouse 和 Teku 团队都预计将在本周末之前发布新版本。鉴于这些版本并非升级所必需，EF（以太坊基金会）协议支持负责人 Tim Beiko 在 Zoom 会议聊天中提到，汇编所有与 Dencun 兼容版本的以太坊基金会博客文章将不会更新。

Flashbots 团队的 Chris Hager 分享了关于 MEV-Boost 软件准备情况的快速更新。Hager 确认，上周发布的 MEV-Boost 版本 1.7 是稳定的，验证节点操作员可以使用。他说，为 Deneb 准备的 Flashbots 构建器软件仍在开发中，预计将在本周的某个时候完成并合并。关于验证器为升级做好准备的情况，Hager 表示担心似乎还没有足够多的验证器更新了他们的 MEV-Boost 软件以适应 Dencun 升级。在仔细核对他的数据后，Hager 说，大约 50% 连接到 Flashbots 中继的验证器正在使用最新的 MEV-Boost 版本，即 v1.7。

Beiko 补充说，他的信息来源，Metrika和Ethernets，都显示大约 50% 的以太坊节点似乎已经为 Dencun 升级做好了准备。Beiko 还表达了他对一个数据工具的渴望，这个工具能够追踪验证节点为升级做好准备的情况，而不仅仅是所有以太坊节点。

Electra

以太坊开发人员讨论了与 Pectra 升级相关的四项代码更改。

EIP 7459

第一个是以太坊改进提案 (EIP) 7549，它使 CL 客户端能够更有效地聚合区块的投票（也称为证明）。开发人员同意之前的建议，将 EIP 7549 纳入 Pectra。Teku 开发人员 Mikhail Kalinin 分享了关于如何在以太坊上实施 EIP 7549 的进一步分析，并提出了一些因代码更改而可能引入的权衡或「负面影响」。Ryan 建议 Kalinin 直接在 GitHub 上总结他对 CL 规范提出的更改，以供进一步反馈和审查。

Prysm 开发人员 Terence Tsao 表示，他同意 Kalinin 提出的 EIP 7549 实施方案，但建议为 Beacon API 更改提供进一步的文档和规范，这与此 EIP 是必要的。「如今，如果同一个槽中有 10 个聚合器，则需要签署 10 个证明，然后通过此更改，您只需发送一条消息，因此，您可能需要进行一些 Beacon API 更改，」Tsao 说道，并补充道，「我认为这部分可能需要更多地思考如何改变 Beacon API 验证器集成来解决这个问题。」作为背景，Beacon API 是 CL 的规范，使节点能够查询网络并获取有关网络状态的信息。

降低发行量

然后，EF 研究员 Ansgar Dietrichs 分享了他关于通过降低网络发行量来减少质押奖励的提案的快速更新。他表示，自上次 ACDC 电话会议提出该提案以来，「社区的反馈意见不一」。他重申，该提案将是一个小的代码更改，假设主网在 10 月进行硬分叉，在 6 月或 7 月之前可能会在最后一刻包含在 Electra 升级中。然而，Dietrichs 也表示，对话是「正在进行的」，这意味着在做出决定之前需要对这个想法进行进一步讨论。

EIP 7547

第三，EF 研究员 Mike Neuder提出了 EIP 7547，包含列表，以供进一步讨论。他表示，讨论 EIP 设计的「确切特征」的第二次分组会议将会很有用，他正在考虑在下周五（即 3 月 15 日）组织一次分组会议。他还提到，EIP 有一个专门的 Discord 频道，名为「包含列表」，有兴趣了解更多有关提案或提出问题的人应该使用。Tsao 还表示，自 2 月 16 日第一次包含清单分组会议以来，该提案的规范已基本充实。Tsao 表示：「我认为该规范可能已完成 75% 左右。」他补充说，规范中还有一些其他组件需要改进，例如执行 API 的更改和有关诚实验证器的规范。

EIP 7251

最后，Lighthouse 开发者 Mark Mackey 表达了对 EIP 7251 的支持，增加了最大有效余额（maxEB）。「我们几乎已经在 Lighthouse 中对其进行了原型设计。规范上仍然需要完成一些工作，但实际上看起来工作量并不大，而且考虑到验证器集的大小有点像定时炸弹，我们提出了发行调整建议，发行变更是总是有争议，因此不能保证社区会接受它。如果他们不喜欢，那么我们实际上唯一能做的就是 maxEB，」Mackey 说。Ryan 表示，将 maxEB 纳入 Electra 的主要阻力是由于代码更改的复杂性，正如 Prysm 团队之前的电话中所表达的那样。Prysm 团队的匿名开发人员「Potuz」在 Zoom 会议聊天中表示，他的团队将再次审查 EIP 并重新评估提案的复杂性。Ryan 要求客户团队为两周后的下一次 ACDC 电话会议做好准备，以便就 EIP 7547 和 7251 做出「坚定的决定」。

密钥管理器 API 标准化

EF 开发人员运营 (DevOps) 工程师 Barnabas Busa 解释说，所有 CL 客户端生成验证器密钥的方法似乎都略有不同，验证器密钥是操作和撤回验证器所需的加密密钥。有一些称为「密钥管理器 API」的 API 可以帮助验证器节点操作员进行密钥管理以及加入和退出验证器。Busa 解释说，在返回此 API 的值时，客户端之间的细微差异确实使测试 API 端点变得困难。他还提到，他的团队已经开始对混合验证器进行基本测试，这意味着验证器节点运营商为其信标节点使用与验证器客户端不同的客户端。信标节点是维护 CL 状态的客户端，但不管理验证者参与共识所需的密钥对。验证者客户端是利用密钥对生成区块并在链上签署证明的客户端。Ryan 建议 Busa 启动一个文档或拉取请求，以提出标准化密钥管理器 API 的建议。参加电话会议的开发人员还支持进一步测试，以确保混合验证器可以在所有 CL 客户端组合上工作。

区块价值信标 API 标准化

一位网名为「Dustin」的 Nimbus 开发人员也对 Beacon API 端点「productBlockV3」和「getBlockRewards」的 CL 标准化表示担忧。Dustin 解释说，Beacon API 的某些领域未明确规定，并且在客户端之间「未普遍实施」。具体来说，当涉及到应该返回区块值的端点时，计算至少应该包括提议区块之前和之后验证者余额的变化。然而，规范没有详细说明客户是否应该包括因另一个验证者的行为而导致的验证者余额变化的奖励和处罚。例如，其中包括同步委员会职责奖励或处罚、提议者或证明者自我削减以及举报人奖励。Ryan 同意应在 Beacon API 中添加说明。然而，参加电话会议的其他开发人员（包括来自 Prysm 团队的 Radosław Kapka 和 Potuz）却没有那么自信。Potuz 表示担心，使用这些端点的人数量很少，并且能够使用自己的工具标准化来自不同 CL 客户端的块值。「我甚至不明白，如果消费者受到限制，我们为什么还要同意支持这一点。我会尝试研究这些市场，看看我们是否真的可以将这项工作发送给使用这些端点的人而不是我们自己，」Potuz 说。

Nimbus 开发人员 Jacek Sieka 反驳了这种观点，他表示，由于「productBlockV3」端点存在，开发人员需要解决客户端之间的不一致问题，或者弃用该端点，转而使用「V4」。此外，Sieka 补充道：「我认为这个端点只是非常基本的功能。如果我们设想未来有多个块源，并且您需要对它们进行比较，那么这是有意义的。就这么简单。」Ryan 建议 Dustin 创建一个提案来标准化 V3 和「getBlockRewards」端点，提案创建后，客户团队将重新讨论是否要继续支持它们。

其余事项

Potuz 标记了两个项目，以供开发人员进一步反馈和讨论。第一个是关于当前未在引擎 API 中指定的后期块的执行层 (EL) 客户端行为，该 API 规定 EL 和 CL 之间的通信。「如果这可以在引擎 API 中指定，这将使我们在重组后期区块时变得更加轻松，」Potuz 说。Potuz 标记的第二项是关于他对提议者构建者分离（ePBS）有效负载提升的分析，这一升级将消除以太坊上对可信中继的需求。Potuz 要求提供有关分析和其他 ePBS 设计限制的更多反馈。

最后，来自以太坊 Cat Herder 小组的 Pooja Ranjan 宣布一个名为「以太坊协议中的女性」（WiEP）的新工作组成立。WiEP 是以太坊基金会的一个新组织，致力于鼓励和培养更多女性以太坊协议开发人员。Ranjan 表示，该小组将于 3 月 8 日举办长达一小时的网络研讨会，与多位女性以太坊协议贡献者进行讨论。

然后，Ryan 指出，他将从 4 月 1 日开始休息三个月。在他缺席的情况下，EF 研究员 Alex Stokes 将主持 ACDC 电话会议。

「原文链接」