2024 年 3 月 21 日，以太坊开发人员齐聚 Zoom 参加了 All Core Developers Consensus (ACDC) call #130 会议。ACDC 电话会议是一个每两周举行一次的系列会议，由以太坊基金会研究员 Danny Ryan 主持，开发人员在会上讨论和协调对以太坊共识层（CL）的更改。本周，开发者们讨论了与 Dencun 升级相关的未完成任务、Pectra 升级的提案以及以太坊网络层的改进。开发者们同意在 Pectra 中包含 EIP 7251「增加 MAX_EFFECTIVE_Balance」，并继续评估 EIP 7547「Inclusion lists」，以便在升级中潜在地加以包含。
Dencun 行动项目
以太坊基金会雇佣的社区协调员 Trenton Van Epps 分享了一份关于导致 Dencun 升级的多年开发的以太坊协议开发者情感汇编，该汇编已在 Mirror 上发布。这份名为「Dencun 日记」的汇编收录了超过 45 位以太坊开发者的声音，以及他们对准备 Dencun 的成功和挑战的看法。
Van Epps 谈到这个项目时表示：「我认为这是一个非常有用的资源。如果大家一直关注的话，你们会知道我之前为 Merge 升级和 Beacon Chain 的启动做过类似的事情。所以，这只是为历史记录增加了一份。希望我们开始建立机构记忆，了解以太坊核心开发者和围绕它的社区是如何运作的。所以，感谢所有提交的人。我认为这是对情感的一个很好的快照，希望我们在不断学习中前进。」
他还表示，对于为 Dencun 升级做出贡献的以太坊开发者来说，现在仍然有机会将他们的意见添加到 Dencun 日记中，并直接与他联系。
接着，以太坊基金会协议支持主管 Tim Beiko 向所有 Dencun EIP 作者发出呼吁，要求他们在 GitHub 上更新他们的提案，将状态更新为「Final」，以表示他们的代码更改现在已在以太坊主网上实施。需要此状态更新的完整 EIP 列表可在此处找到。
关于升级对以太坊的影响，Prysm 开发者 Terence Tsao 提到他注意到重新组织的区块数量有所增加，意味着在网络上提出但未包含在以太坊区块的规范链中的区块。Tsao 说他正在进一步调查这种行为的原因，并且他推测原因与 MEV 构建者规范有关。
以太坊基金会开发者运营工程师 Parithosh Jayanthi 表示，根据他团队对 Dencun 的分析，他们注意到有少量数据块延迟到达网络，延迟了四秒进入一个时隙。时隙是以太坊上选择验证者提出区块的 12 秒间隔。尽管慢到达数据块的数量不高，Jayanthi 表示重要的是要密切关注这种行为。Prysm 开发者「Potuz」提到，升级中对证明包含时间线的更改之一可能会加剧节点跟踪资源使用的指标。Teku 开发者 Enrico Del Fante 表示，他的团队意识到了有关 CPU 和带宽使用率高于正常水平的问题，并将在 Teku 客户端的下一个版本中包含修复此问题的解决方案。
最后，Lodestar 开发者加 Gajinder Singh 提出了一个微小的改名建议，将操作码「BLOBBASEFEE」改为「BLOBBASEFEEPERGAS」。Singh 表示：「基本上是为了确保单位更符合其所传达的含义。」Ryan 鼓励电话会议上的开发者，特别是 EIP 4844 的作者，即引入数据块提案的作者，审查 Singh 的变更。
审查抗性代码更改
以太坊基金会安全研究员 Fredrik Svantes 分享了一项提案，旨在通过客户端实现「get_Payload」请求来提高本地构建块的价值 10%。开发者们在 2022 年底通过「get_Payload」请求在引擎 API 中添加了对块价值的计算。这样做是为了使验证者能够轻松比较本地构建块的价值与第三方区块构建者构建的块的价值。据 Svantes 称，64% 的构建者正在主动审查块中的交易。为了鼓励验证者提出本地构建的块，Svantes 建议将本地块的价值提高 10%。他补充说，他正在与以太坊基金会的测试团队合作，确保这些更改在测试客户端软件时不会触发任何虚假警报或破坏现有的测试基础设施。
Potuz 反对了 Svantes 的建议，表示块价值应由客户端配置。「我们应该停止指定这些东西。我们应该停止以协调的方式这样做，」Potuz 说，并补充道：「我认为客户端应该自由地设置这些东西。它们可以由用户进行配置，我们不应该对实际行动感到害怕以实现我们的信念。」其他电话会议上的开发者，包括 Lodestar 开发者 Phil Ngo 和 Lighthouse 开发者「Sean」，都同意了 Potuz 的看法。
「不将其设置为 10% 的一个原因可能是，这将是一种意外情况，有点像利用用户可能不知道此功能的事实。而一个更好的方法，也许在 Lighthouse 中，是要求用户在使用构建器时设置该值。这样一来，可以提高标志的意识，而不是对其应该设置为何种值给出建议，」Sean 说道。
随后，开发者们讨论了什么样的边际会鼓励验证者选择本地块而不是由构建器构建的块。由于电话会议时间有限，Ryan 建议继续进行其他会议议程。
Pectra 代码更改
Ryan 开始了关于在 Electra 中包含的重大代码更改的讨论，重点介绍了两个最主要的提案，即 EIP 7251 和 EIP 7547，它们在竞选中处于领先地位。"我们已经来回讨论过了。我们曾经认为其中一个或另一个被埋没了，它们在不同时间又浮出水面，但我们肯定已经到了如果我们不做决定，我们确实需要尽快做出决定的时候。有意在五月份某个时间点拥有 Electra 的功能原型和开发网络，我们在三月底要关闭了。所以，我只是想让大家明白，这些是中等大小的项目，如果不是大项目的话，我们可以继续讨论，但我们不能再继续把这个问题拖得太久了。否则，我认为默认情况就是'不'。我想犹豫不决本身就是一种决定，"Ryan 说道。
包含列表
随后，Ryan 将发言权交给以太坊基金会研究员 Mike Neuder，他正领导着准备 EIP 7547，即包含列表（ILs），用于 Pectra 的工作。Neuder 分享了最近关于 ILs 的分组会议的更新。该会议的摘要可以在这里找到。Singh、Sean 和其他电话会议上的人表示支持在 Pectra 中同时包含 ILs 和 EIP 7251，也被称为 MaxEB。Potuz 提到的有关 IL 规范的突出问题之一是它对铭记的账户抽象（AA）的影响。未来，以太坊开发者计划为用户控制的以太坊账户，也称为外部拥有的账户（EOAs），引入增强的灵活性，而 ILs 的当前设计可能会使这一过程变得复杂。开发者讨论了更新 IL 规范的方式，使其更加兼容未来的 AA 代码更改。开发者还讨论了他们首次尝试在自己的客户端中实现 ILs 的初步工作，以及在某些情况下使用引擎 API 的权衡之间的权衡。Neuder 和 Terence 建议在下一次 IL 分组会议上讨论与 IL 规范相关的问题，而不是在电话会议上讨论 ILs 的技术细节。
MaxEB
开发者们还讨论了 MaxEB 在 Pectra 中实施的准备情况。Ngo 分享了最新的 MaxEB 分组会议的更新，该会议于 3 月 20 日星期三举行。可以在这里找到此次会议的摘要。Lighthouse 开发者「ethDreamer」表示，他的团队更倾向于优先考虑 MaxEB，但也愿意在 Pectra 中同时包含两者。基于他同事对 MaxEB 的评估，Potuz 表示，Prysm 团队确信 MaxEB 可以在年底之前实现，这是开发者们试图完成 Pectra 升级的时间范围内。
Ryan 提醒电话会议上的开发者，在 Pectra 升级的同时，他们已经承诺着着手进行 peerDAS 的工作，这是一项着眼于通过引入数据可用性采样和提高每个块中数据块数量来安全增加以太坊数据可用性容量的代码更改。Ryan 说：「我直觉上认为 MaxEB 或 IL 之一进入 Electra 可能不会对能够进行 peerDAS 研发的并行性造成很大影响，但如果两者同时存在，我们现在开始权衡，可能真的无法同时处理这三件事情。」
然而，电话会议上的开发者们，如 Sean、Singh、Ngo、Lighthouse 开发者 Age Manning 等人，纷纷表示支持在 Pectra 中同时包含 MaxEB 和 ILs。如果开发者们仍然计划在年底之前在主网上推出 Pectra，Potuz 则强烈反对同时包含两者。在 ILs 的话题上，Ryan 问道，它的实施是否也给 EL 客户端团队带来了沉重的工作负担。Geth 开发者「Lightclient」表示，从他的观点来看，实施 ILs 的工作负担在 CL/EL 客户端团队之间是 80/20 的分配比例。在开发者们对这两项代码更改进行了更多讨论之后，Beiko 建议继续在 Pectra 中包含 MaxEB，同时继续在 EL 和 CL 客户端团队之间进一步讨论后，对 ILs 进行进一步的范围界定，以便在升级后可能包含 ILs。这意味着开发者们优先考虑 MaxEB 而不是 ILs。最终，开发者们同意采纳 Beiko 的策略，在 Pectra 中包含 MaxEB，并在一到四周内重新讨论 ILs。
「我个人认为，这两件事情加在一起，使我们进入了比过去几个月讨论的升级更为复杂的领域。所以要有所知晓。此时此刻，我还要说，我们总是非常有信心和兴奋地应对复杂性，并且还有很多工作要做，」Ryan 在关于 Pectra 范围的最后警告中说道。正如在ACDC＃129中提到的，本周的会议结束后，Ryan 将休假三个月。以太坊基金会研究员 Alex Stokes 将代表他主持 ACDC 电话会议。
Blob gas 增加
在讨论了 maxEB 和 ILs 之后，开发者们讨论了以太坊基金会研究员 Ansgar Dietrichs 起草的一项提案，该提案旨在在 Pectra 升级后的四个月内，逐步将每个块中的 blob 数量增加到最多 16 个，从而使其从 6 个增加到 16 个。这种增加将进一步降低数据可用性的成本以及建立在以太坊上的 Layer 2 rollups 的成本。Ryan 表示支持该提案，前提是满足以下三个关键条件：
· 关于 blob 性能的可靠数据。
· 在 Pectra 中激活 EIP 7623，该提案限制了最大块大小。
· 进一步讨论关于时间增加 blob 数量的确切机制。
Ryan 鼓励开发者们在未来几周内发表他们对该提案的看法。
轻客户端开发
Nimbus 开发人员 Etan Kissling 分享了两份与影响 CL 规范的轻客户端开发相关的草案提案。同步委员会的惩罚和轻客户端数据回填是轻客户端路线图的两个组成部分，开发人员正在与 Pectra 升级同时进行。Kissling 要求 CL 客户端团队就这些组成部分提供意见，特别是 maxEB 对参与同步委员会的大型验证者的惩罚条件会产生什么影响。关于同步委员会的背景，请阅读以太坊基金会的这篇文章。
网络更新
在正在进行的研究项目方面，Manning 分享了一种新的对注释子网（attnets）的处理方法，这是一种使验证者能够发送和接收注释的网络层。尽管目前实施并不紧急，但这种向后兼容的提案似乎在 peerDAS 生效后为网络提供了优化。
Manning 还提出了向网络对等体发送新控制消息的实施，该消息将「显着减少」节点带宽。Manning 表示，他的团队已经开始测试「IDONTWANT」控制消息，并且可以独立发布，但需要整个网络的协调才能开始看到此更改的好处。他请求电话会议上的开发者审查该提案，并看看他们是否考虑一起发布该更改。
最后，Manning 提出了在 libp2p 库中废弃 mplex 的问题。Mplex 是一种流复用器，用于通过一个通信链路发送多个数据流。由于 mplex 的废弃，Manning 表示，他的团队和其他客户端团队正在升级到另一种称为 yamux 的不同流复用器。Manning 询问了客户端团队的迁移状态，以及是否还在使用 mplex。来自 Teku 和 Lodestar 团队的代表表示，他们正在努力开发他们的 yamux 实现，但还没有准备好从 mplex 切换过来。