2024 年 2 月 1 日，以太坊开发人员齐聚 Zoom 参加了 All Core Developers Execution (ACDE) call #180 会议。ACDE 电话会议是一个每两周举行一次的系列会议，由以太坊基金会协议支持主管 Tim Beiko 主持，开发人员在会上讨论和协调对以太坊执行层（EL）的更改。本周，开发者主要讨论了三个重要的代码变更：Verkle、以太坊虚拟机对象格式（EOF）和历史失效。他们决定将 Verkle 安排在 Prague 升级之后，即 Osaka 升级的 EL 升级中实施。同时，他们还同意在 Prague 升级的同时继续努力开发历史失效所需的并行网络，被称为Portal Network。关于下一个即将到来的以太坊升级 Dencun，开发者表示他们将在下周四的 ACDC 电话会议上讨论升级的主网激活日期。

Besu 1 月 6 日主网事件

Besu 的开发者 Matt Nelson 详细介绍了今年初在以太坊上发生的大约 70% Besu 节点故障的情况。Besu 团队在他们的博客上分享了该事件的详细事后分析。Nelson 解释说，故障是由于 Besu 的 Bonsai 状态存储格式中的一个错误引起的，具体来说，是 Bonsai 如何编码状态更改的问题。已经推出了对 Besu 客户端的紧急修复，Nelson 强调了他对 1 月 6 日事件中 EL 客户端多样性的赞赏。由于以太坊节点运营商还运行了其他客户端，如 Geth、Nethermind 和 Erigon，Besu 节点的故障并没有在实质上影响网络健康或干扰网络活动。

Dencun 更新

以太坊基金会（EF）的开发者运维工程师 Parithosh Jayanthi 分享了关于 Sepolia 硬分叉的最新动态，该分叉于 1 月 30 日星期二发生。Jayanthi 表示：「这是一次平稳的分叉。我们看到了网络的最终确认，数据块也准确地出现在我们希望的位置。」Beiko 提醒团队，Holesky 硬分叉计划在下周三，即 2 月 7 日激活。Holesky 将是最后一个在以太坊主网之前升级的公共以太坊测试网。

关于 Dencun 升级除了 Holesky 分叉之外需要进一步测试的问题，Nethermind 开发者Łukasz Rozmej 表示，他们的团队正在调查他们客户端中导致 blob 内存池增长超出指定限制的一个错误。在对 Devnet-12 进行进一步调查时，Nethermind 团队向网络发送了大量的 blob 交易，注意到由于这个 bug，验证者参与率下降了超过 20%。该团队计划在接下来的步骤中向 Goerli 测试网络发送 blob 交易。以太坊基金会（EF）的开发者运维工程师 Barnabas Busa 要求 Nethermind 团队在进行 blob 垃圾邮件之前等待在 Goerli 上测试 churn 限制的增加。

除了 Nethermind 的错误外，Prysm 开发者「Potuz」表示，他的团队正在调查有关 Sepolia 的一个晚期区块提案的异常活动，该提案没有包含任何 blob 交易。

由于开发者需要调查与 Dencun 相关的这两个未解决的问题，他们同意在下一次 ACD 电话会议之前暂时不确定升级的主网激活日期，该电话会议计划于下周四，即 2 月 8 日举行。Potuz 补充说，他希望在主网激活之前从 Layer2 Rollup 团队那里得到更多关于 Dencun 升级的反馈。Beiko 表示同意。

Prague 提案

在通话的大部分时间内，开发者们讨论了三个主要代码变更的实现细节：Verkle、EOF 和历史失效。

· Verkle：以太坊基金会的研究员 Joshua Rudolf 和 Guillaume Ballet 展示了他们在 Verkle 上的最新工作，这是对以太坊数据存储和检索方式进行的重大改革。他们强调了升级中仍需研究的领域，如 Verkle 同步和 gas 计划更新。基于初步测试，他们估计转换到 Verkle 将耗时大约两周，并使交易执行时间变慢约 10%。Rozmej 评论说，这些初步测试应该「持保留态度」，因为它们尚未通过更完整的主网影子分叉进行测试。

由于 Verkle 的复杂性以及对其实施需要更多研究，Rozmej 和其他开发者对在 Prague 升级中承诺发布代码变更表示了担忧。Ballet 同意 Verkle 可能不会在 Prague 中准备好实施，但他担心如果不将 Verkle 计划为升级，无论是 Prague 还是 Osaka，客户端团队都将没有太大的动力去开发它。Ballet 表示，以太坊状态每年大约增长 25%，开发者等待在主网上执行 Verkle 的时间越长，在 Verkle 过渡期间需要彻底改进的旧数据就越多。

「在我看来，要交付还需要超过一年的时间，」Rozmej 说道。

· EOF：Swirlds Labs 的首席软件工程师 Danno Ferrin 分享了关于 EOF 开发的最新进展，这是对以太坊虚拟机（EVM）的一系列代码更改，开发者们曾推迟将其纳入之前的 Shanghai 和 Cancun 升级。「我们已经进入『交付』模式。我们正在试图尽可能关闭所有存在的规范可能性的大门，」Ferrin 表示。负责 EOF 开发的团队已开始制定一个实施矩阵，评估与 EOF 相关的以太坊改进提案（EIPs）的最终状态，并完成相应的参考测试。

他们计划在 2024 年第三季度在测试网络上激活 EOF，希望在 2024 年第四季度的 Devcon 期间激活主网。「我认为，在未来几年内，对于解决 EVM 的许多技术债务来说，这些基本变更是至关重要的。所有关于『我们无法增加代码大小』等问题的抱怨，在 EOF 的工作方式中都得到了解决，」Ferrin 表示。Erigon 开发者 Andrew Ashikhmin 表示支持在 Prague 中包括 EOF。Ballet 表示，他首先想要看到 EOF 在 Verkle 激活的测试网络上运行，以了解这两个升级将如何相互影响。Reth 开发者 Dragan Rakita 表示，他并不认为两者之间一定存在依赖关系，并补充说：「总体而言，EOF 似乎更适合于 Verkle 跟踪而不是传统的 EVM。」

· 历史失效（History Expiry）： 以太坊基金会开发者 Kolby Moroz Liebl 介绍了历史失效。根据EIP 4444的定义，历史失效意味着执行层（EL）客户端在一定时期后，例如一年后，将停止在点对点层提供历史区块头、区块体和收据。相反，这些数据将通过一种名为 Portal Network 的替代去中心化网络为用户提供服务。Liebl 已发布了有关 Portal 的FAQ 文档。

关于启动历史失效所需的工具，Geth 开发者「Lightclient」表示：「我们真的只需要继续执行规范并开始尝试让提供商提供这些数据，因为规范本身，导出数据，验证数据，导入数据都很好，但在数据可用之前，我们实际上无法继续通过 P2P 网络删除数据。」Lightclient 补充说，一旦数据在 Portal 上可用并由网络上的数据提供商提供服务，开发者应该等待大约一年才停止在以太坊的 P2P 层中提供这些数据的服务。虽然更新在 P2P 层上提供历史区块数据不需要硬分叉，但这将是客户端团队希望一致完成的更新，最有可能是通过对以太坊 Wire Protocol的升级来实现。

在讨论完三个主要的代码更改后，开发者们讨论了如何在主网上安排它们的实施。Lightclient 鼓励客户端团队立即开始研究 EIP 4444，因为它不需要对以太坊的核心协议进行重大更改，并且对减轻以太坊节点的数据负载具有重大益处。Lightclient 表示，他将与 Nethermind 和 Besu 客户端团队合作，启动历史失效的初步工作。

Ashikhmin 指出，从 Erigon 团队的角度来看，历史失效的实施将不得不等待几个月，直到他们的 Erigon V3 版本发布，因为他们的客户端目前会重新执行从以太坊起源开始的区块，因此需要访问所有历史区块数据来完成此过程。Ashikhmin 补充说，他更倾向于在 Prague 中包含 EOF，但如果它与 Verkle 存在兼容性问题，他将从升级中删除它。

Beiko 询问是否有人反对将 Verkle 安排在 Osaka 升级中。没有反对意见。以太坊基金会研究员 Ansgar Dietrichs 建议，在可能超过一年的情况下，对 Osaka 升级的范围保持灵活，对 Verkle 仍然需要进一步的研究，以正确评估其在主网实施上的准备情况。

其他事项

在通话的最后几分钟，Beiko 简要介绍了 ACDE＃180 的最后三个议程事项。

在引擎 API 执行指定客户端版本 #517：这是一个旨在改进验证人节点运营商使用的执行层（EL）客户端跟踪的开放 PR。目前，由于大多数验证人使用 MEV-Boost 软件，无法通过分析区块数据来确定节点运营商使用的 EL 客户端类型。因此，准确报告 EL 客户端多样性需要节点运营商自行报告。该 PR 建议在节点的「graffiti」字段中默认嵌入用于运行节点的客户端和版本。这是一些 CL 客户端已经实施的做法。Beiko 鼓励客户端团队查看此 PR，并发表他们的意见。

EIP-7523 空帐户弃用：正如在ACDE＃173上讨论的那样，有一个 EIP 旨在减少由空帐户引起的以太坊测试网络的技术债务。以太坊基金会开发者 Paweł Bylica 对此 EIP 的下一步提出了问题。Beiko 鼓励 Bylica 在 Ethereum R&D Discord 频道中分享这些问题。

EIP-7587 为 RIP 保留预编译地址范围：正如在ACDE＃178上讨论的那样，开发者们计划为 Layer-2 rollup 团队保留一组预编译地址。为 rollups 保留预编译地址范围的 EIP 正在进入「最后通话」阶段。Beiko 鼓励开发者在这一阶段提出任何最后一刻的评论或对 EIP 的反对意见。

对于下一次 ACDE 通话，Beiko 表示，开发者将专注于进一步确定 Prague 升级的范围。