原文标题：《Ethereum All Core Developers Execution Call #189 Writeup》原文作者：Christine Kim原文编译：Luccy，BlockBeats编者按：以太坊所有核心开发者执行电话（ACDE）每两周举行一次，主要讨论和协调对以太坊执行层（EL）的更改。本次为 ACDE 第 189 次电话会议，本次会议上，开发者们就 Pectra 升级中的一些重要议题展开了讨论，包括包含 EOF 和 EIP 7702 在内的改动、改进 Pectra 范围、以及准备 Verkle 过渡等方面。会议还讨论了如何将 EOF 和其他 Pectra EIPs 打包，以及如何测试这些代码变更。此外，还介绍了一些提议，旨在改进以太坊网络升级流程，包括对 ACD 电话会议议题讨论频率的调整，以及新的 EIP 标签提案。对于 EIP 4444 和 Portal Network 的集成进展也有所提及。Galaxy Digital 研究副总裁 Christine Kim 对本次会议要点做了详细记录，BlockBeasts 将原文编译如下：

2024 年 6 月 6 日，以太坊开发人员齐聚 Zoom 参加了 All Core Developers Execution (ACDE) call #189 会议。ACDE 电话会议是一个每两周举行一次的系列会议，由以太坊基金会协议支持主管 Tim Beiko 主持，开发人员在会上讨论和协调对以太坊执行层（EL）的更改。本周，开发者们同意将 EOF 和 EIP 7702 包含在 Pectra 升级中。为了避免由于这些代码变更而导致的多客户端测试升级延迟，开发者们同意在后期开发网络上激活 EOF，并可能在不同于其他 EIP 的激活周期内激活，就像开发者计划测试 PeerDAS一样。他们还讨论了在 Osaka 升级中如何停用 EIP 158 以准备 Verkle，并通过与 Portal Network 的集成来实施 EIP 4444 的下一步。最后，Beiko 和 EF 开发者运营（DevOps）团队分享了治理流程和规划以太坊升级的沟通渠道的最新更新。

Pectra 的范围

在本周的 ACD 会议之前，各个 EL 客户端团队和 EF DevOps 团队分享了他们对 Pectra 范围的看法。

根据会前分享的观点，显然大多数客户端团队都支持在 Pectra 中包含 EOF。唯一强烈反对 EOF 的客户端团队是 Geth。Geth 开发者 Guillaume Ballet 说：「我担心我们等得越久，Verkle 转换所需的时间就会越长。EOF 真的那么紧急吗？我不这么认为。我读了几篇关于在 Prague 发布 EOF 的论点。读得越多，我越意识到，没有什么真正能证明 EOF 是必要的。」对此，几位开发者提出了反对意见。

一位名叫「Kamil Sliwak」的开发者表示，从与以太坊智能合约编程语言 Solidity 的编译器交互的用户角度来看，EOF 将是「一项巨大的改进」。Reth 开发者 Dragan Rakita 补充说，认为 EOF 会显著延迟 Verkle 转换是不诚实的。「我们谈论的是 10% 到 20% 的转换时间延长。EOF 不会增加状态，额外的三个月来发布额外的部分分叉，不会显著延迟 Verkle」Rakita 说。关于 EOF 是什么以及它将如何改进以太坊虚拟机（EVM）的更多信息，请收听《无限丛林》播客的这一集。

Beiko 询问开发者是否更愿意将 EOF 与其他 Pectra 的 EIP 捆绑在一起，还是将 Pectra 的 EIP 分成两个硬分叉。Erigon 开发者 Andrew Ashikhmin 表示，他认为开发者应该尝试将所有 Pectra 的 EIP 一起发布，或者推迟 EOF 直到 Verkle 转换之后。「我最不希望的是，在 Pectra 和 Verkle 之间进行一次分叉以发布 EOF。因为我同意 Guillaume 的观点，即状态正在增长，我认为 Verkle 比 EOF 更重要。所以在我看来，这是最糟糕的结果，」Ashikhmin 说。Beiko 建议将所有 Pectra 的 EIP，包括 EOF，在一个客户端版本中发布。然而，为了测试的目的，他表示开发者应该考虑使用开发网络来分阶段实施这些代码更改。「使用开发网络作为我们在多客户端测试方面优先考虑的方式，然后如果我们看到 EOF 会长时间延迟事情，我们可以决定将其分开，」Beiko 说。

在这些关于如何将 EOF 纳入 Pectra 的讨论中，Geth 开发者在 Zoom 聊天和整个会议中继续表达了对是否应该将 EOF 包含在升级中的质疑。为了应对 Geth 团队对 EOF 的持续争论，Reth 开发者 George Konstantinopoulos 说：「让我们直接做吧。对话的走向有点令人困惑。我们不介意将 Verkle 转换延长几天。数据显示状态正在下降，所以这是一个令人困惑的论点，而且你有一堆应用程序告诉你这是一个好功能。既然大多数人都表示支持，我们为什么还要考虑不做呢，这很令人困惑。」

Beiko 同意这一观点，并重申 EOF 应该包含在 Pectra 中，但要在开发网络上分阶段测试，这意味着客户端团队应在 Devnet 1 上测试已经在 Devnet 0 上实现的 EIP。然后，在未来的开发网络上，再添加 EOF 进行测试。这一策略将确保客户端团队在相同的时间线上专注于发布一部分 Pectra 的 EIP，并能够在多客户端开发网络上继续取得进展。以太坊基金会（EF）DevOps 工程师 Mario Vega 表示，他预计在两个月内准备好 EOF 的执行层（EL）规范测试。EF DevOps 工程师 Parithosh Jayanthi 表示，EOF 可以与 Pectra 中的其他执行层（EL）EIP 分开测试。然而，他担心 Pectra 中的共识层（CL）EIP 之间的相互依赖性以及测试这些代码更改的复杂性。

Vyper 编译器开发者 Charles Cooper 表示，在他看来，EOF 并不像他提议的代码更改那样紧急，这些更改旨在使防止重入攻击的保护变得廉价和普遍。Beiko 提醒 Cooper，虽然对 EOF 的广泛共识是明确的，但不清楚客户端团队是否有足够的精力添加更多的代码更改，例如与重入攻击相关的更改。「我认为很清楚的是，如果我们推进 EOF，就几乎没有精力去做其他事情了。这已经将是迄今为止最大的分叉，」Beiko 说。

除了包含 EOF，开发者们还同意将 EIP 7702 作为 EIP 3074 的替代方案。开发者们仍在单独的小组会议中讨论 EIP 7702 的规范。Beiko 建议对 EIP 7702 采用与 EOF 类似的方法。「我会将它包含在分叉中，但如果我们对规范不太满意，就不将它作为 Devnet 1 或 2 的一部分，然后花下一个月的时间真正理清规范，这样我们就有了一个比现在提议的更好的撤销机制。稍后在过程中添加一个不算太大的 EIP，」Beiko 说。Geth 开发者「Lightclient」表示，如果客户端团队准备好了，他们应该尽快实施 EIP 7702。没有人反对在下一个紧急的 Pectra 开发网络 Devnet 1 中包含 EIP 7702。

Pectra 规范

随后，Teku 开发者 Mikhail Kalinin 分享了一些现有 Pectra EIP 规范的更新。第一个是建议通过侧车机制处理触发共识层（CL）请求，而不是直接在执行层（EL）块中处理。Prysm 开发者「Potuz」指出，这一策略会破坏未来代码更改所需的逻辑，即明确的提议者构建者分离（ePBS）。「信标块不应该依赖于有效负载已经存在。所以，无论是提款还是存款，你都不希望信标块依赖于有效负载中的内容，因为这会破坏 ePBS 的流程，」Potuz 说。由于这个问题，Kalinin 同意撤回他的建议并关闭 GitHub 上的拉取请求。

Kalinin 分享了几项关于 Pectra 的 EL 和引擎 API 规范的其他变更，其中之一是启用 EIP 7251 下的 EL 触发合并，增加 MAX_EFFECTIVE_Balance。Beiko 建议开发者在下一次 ACD 电话会议之前审查这些变更，以便它们可以在 Devnet 1 中进行测试前完成和准备好。

Verkle 准备

根据他为 Verkle 过渡所做的工作，Ballet 表示，EIP 158 将导致与已弃用的操作码 SELFDESTRUCT 类似的问题。为了在过渡后避免网络上的复杂情况，Ballet 建议在 Pectra 升级中停用 EIP 158。然而，他指出，如果在 Pectra 中对 EIP 7702 的实施进行了微调，那么停用 EIP 158 可能会被推迟，并与 Verkle 过渡同时发生。Beiko 建议 Guillaume 开始起草他的停用 EIP 158 的提案。

历史到期

除了 Pectra 和 Verkle，以太坊协议开发者还致力于 EIP 4444，历史到期。正如EIP 4444 计划和摘要文件所述，进行这种代码更改的原因是「区块历史占据了节点大量的空间，而一旦该区块已经完成，它只需要用于有限的非共识关键用例。」文件继续说明，「区块历史将不再由全节点永久存储。一段时间后，它将从节点中删除，并且需要它的实体将需要从其他地方查询。」Portal Network 是一个替代的、分散的网络，用于节点查询以太坊历史数据。

Merriam 重申他的团队愿意为 EL 客户团队提供与 Portal Network 的集成支持。他说，如果没有任何支持，集成大约需要 6 个月的时间来开发完毕。然而，通过指导和密切合作，他乐观地认为在接下来的两个月内可以在 EIP 4444 上取得有意义的进展。Jayanthi 询问是否对 Portal Network 规范进行了安全审计。Merriam 表示没有。以太坊基金会研究员 Ansgar Dietrichs 问客户团队是否可以自行决定如何与网络进行接口，包括将集成与现有客户端捆绑、构建新客户端，或者干脆不进行任何集成。Merriam 确认这一决定由客户团队自行决定。

Merriam 询问电话会议中的 EL 客户团队有关他们在 EIP 4444 上的进展和意图。Nethermind 开发者Łukasz Rozmej 表示：「总体而言，这是一个优先事项。我们甚至昨天与 Portal 团队开了一个会议。问题是有太多的优先事项。有时候很难正确地平衡所有事情。因此，与例如硬分叉相比，它是不那么紧急的优先事项，但 Nethermind 将会着手处理，并且我们将予以优先考虑。」Besu 开发者 Matt Nelson 表示他的看法是一样的。Geth 开发者 Guillaume Ballet 表示他的团队还没有讨论过 Portal Network 的集成。

ACD 流程改进

ACD 流程改进 接着，Beiko 分享了几项改进以太坊网络升级流程的建议。他首先建议减少 ACD 电话会议上讨论客户团队尚未详细审查的话题的频率。Beiko 建议，在允许开发者进行专业讨论之前，先在 ACD 电话会议上标记这些话题进行审查，然后根据需要在随后的 ACD 电话会议上更详细地讨论这些话题。

Beiko 提出的第二个建议涉及通常附加在考虑纳入硬分叉的以太坊改进提案（EIP）上的「考虑纳入」（CFI）状态。这个状态在历史上并没有有效地指示哪些 EIP 更有可能被纳入硬分叉中。Beiko 建议创建另一个标签「拟纳入」（PFI），以便开发者能够更好地区分哪些 EIP 更有可能被纳入硬分叉，而哪些不会。

以太坊基金会研究员 Ansgar Dietrichs 在 Zoom 聊天中写道，为 EIP 创建新标签是「错误的方向」，只会导致 CFI 标签变得「完全无用」。Beiko 表示，开发者可以继续在 GitHub 和 EthMagicians 上讨论改进网络升级流程的问题。

此外，以太坊基金会的 DevOps 工程师 Mario Vega 表示，他希望为与测试相关的更新创建一个新的 Discord 子频道。维加表示，目前在以太坊研发 Discord 中，测试发布信息分散在多个频道中。然而，他希望这个新的论坛能够成为客户团队从以太坊基金会 DevOps 团队获取测试更新的「一站式」参考。他要求客户团队就此提出反馈意见。

最后，Beiko 提醒开发者，接下来几天安排了两次小组会议，一次是关于 ePBS 的，将于 6 月 7 日举行，另一次是关于 PeerDAS 的，将于 6 月 11 日举行。