在 10 月 12 日，以太坊开发人员齐聚 Zoom 参加了 All Core Developers Execution (ACDE) Call #172 会议。ACDE 电话会议是一个每两周举行一次的系列会议，由以太坊基金会协议支持主管 Tim Beiko 主持，开发人员在会上讨论和协调对以太坊执行层（EL）的更改。本周，开发者们主要关注以下议题的进展：
Cancun/Deneb（Dencun）测试
以太坊虚拟机（EVM）对象格式开发。
Dencun 测试
以太坊基金会的 DevOps 工程师 Barnabas Busa 最近分享了关于 9 月 29 日发布的 Devnet #9 的一些更新。
Devnet #9 现在的参与率为 93%，这意味着 93% 的验证者正在积极参与网络共识。
7% 未运行的验证器主要由 Geth (EL)/Teku (CL) 验证器节点组成。
Erigon (EL)/Prysm (CL) 客户端组合以及 EthereumJS (EL) 客户端也存在问题。
Flashbots 团队正在 Devnet #9 上测试 MEV-Boost 中继和构建器。Busa 鼓励其他中继和建筑商运营商与他联系，以便可以在 Devnet #9 上测试更多 MEV 基础设施。
Blob 事务尚未通过 MEV-Boost 构建器进行测试。在这种情况下，Blob 被构建者丢弃，但开发人员尚不确定这是否是由于 Blob 实际上无效、不符合最低基本费用要求，或者因为其他原因而被丢弃。
Busa 和他在以太坊基金会的同事 Parithosh Jayanthi 分享了即将推出的 Devnet #10 的最新动态：
本周 Devnet #10 尚未准备就绪，但预计下周将完成准备。
对于 Devnet #10，开发人员计划测试 EIP 4844 KZG 仪式中的可信设置文件。
Devnet #10 将拥有庞大的验证器群，包含 33 万个活跃验证器。在开发网络刚刚启动时，验证者的存款和退出将大量涌入，预计在网络启动后的一两天内，验证者的进入流失限制将从 5 次降为 4 次。虽然主网上实际的最大进入流失限制为 8，但开发人员将采用 4 的限制，以便在 Devnet #10 上测试 EIP 7514。
Busa 强调，目前开发人员仍在解决 Dencun 测试过程中的一些关键问题。在这些问题得到妥善解决之前，开发团队不会启动 Devnet #10，这很可能是在 Goerli 等公共以太坊测试网上激活升级之前的 Dencun 最终开发网。Jayanthi 在 Zoom 聊天框中概述了开发人员在启动 Devnet #10 之前需要解决的关键问题：
更新 EIP 4844 KZG 仪式的可信设置文件
Blob 事务的更好可视化
MEV 管道的完善
网络稳定性的提升
在电话会议中，Jayanthi 鼓励客户团队增加对 Beacon API 的支持，以提高 Blob 事务的可见性。Beiko 询问在 Devnet #10 推出后，开发者是否愿意升级 Goerli 测试网络。Busa 建议先观察 Devnet #10 的表现，再决定后续升级测试的步骤。
另外，Jayanthi 确认在 Devnet #10 推出后的一段时间内，开发人员可能会在公共测试网络的测试工作同时进行以太坊主网的影子分叉，以进一步测试 Dencun 升级。然而，Jayanthi 指出，影子分叉的实用性可能受到限制，因为在 Dencun 测试期间发现的大多数错误都是在点对点网络层面上。
Geth (EL) 开发人员 Marius van der Wijden 表示，他的同事 Péter Szilágyi 成功地在 Devnet #9 上运行了自己的节点，并发现了一个与 blob 垃圾邮件相关的严重问题。
据悉，为了防止节点崩溃，Szilágyi 实现了一个事务处理程序来限制他在开发网络上看到的 blob 数量。Van der Wijden 建议 CL 团队重新审视 EIP 4844 中的 3/6 最大 blob 目标/限制，并让 EL 团队对节点带宽需求和解决 blob 垃圾邮件的方法进行深入考虑。
为了进一步讨论这些问题，Beiko 鼓励开发者参加 10 月 16 日举行的 Dencun 互操作性测试电话会议。
EVM 对象格式开发
随后，开发人员们讨论了 EVM 对象格式 (EOF) 的最新进展。EOF 是一组聚焦于 EVM 更改的 EIP，而 EVM 是基于以太坊的虚拟机，用于执行智能合约代码。EOF 的倡导者之一，Danno Ferrin，对过去几个月来的 EOF 工作进行了概括和总结。
在演讲伊始，Ferrin 强调，他希望 EOF 能成为继 Cancun/Deneb（称为 Prague/Electra）之后的升级中的主要代码更改。Ferrin 表示，目前有四个主要团队正在致力于 EOF：
Team Ipsilon：由以太坊基金会资助的开发团队，专注于 EVM 的改进
EL 客户端团队：例如 Geth、Besu 和 Nethermind
高级语言编译器团队：例如 Solidity 和 Vyper
智能合约开发者：例如 SSTORE2 操作码的倡导者。
总的来说，各个团队正为 EOF 的发展做出贡献，共同推进以太坊网络的技术进步。
EOF 的主要目标是为 EVM 代码创建新的容器格式。这种容器格式将清晰地区分代码和数据，这在当前的格式中是无法实现的。它还允许引入新的操作码，帮助智能合约开发者更有效地设计应用程序，并提供更高的代码安全保障。EOF 需要为 EVM 代码创建新的容器格式，同时保持现有格式。
为了方便围绕 EVM 进行这些更改的实施和测试，Ferrin 详细介绍了开发者可以减少使用新 EOF EVM 代码的智能合约与不使用新 EOF EVM 代码的旧智能合约之间依赖关系的方法。尽管客户端团队需要维护两个版本的 EVM，但 Ferrin 认为新版本比当前的 EVM 更容易更新。他还表示，随着时间的推移，随着越来越多的智能合约开发者采用 EOF，当前的 EVM 可能会逐渐被淘汰。
Ferrin 在演讲中提到的 EOF 相关 EIP 包括：
EIP 3540：EVM 代码的新容器格式。
EIP 4200：引入静态跳转的三个新 EVM 跳转指令。
EIP 4750：两个新操作码将消除对动态跳转的需求并将其禁止。
EIP 663：两条新指令允许访问 256（而非 16）的堆栈深度。
EIP 7480：四个新指令，用于启用 EOF 容器数据部分的读取功能。
EIP 7069：三个新的调用指令，用于简化 Gas 使用和费用相关的语义。
EIP 5450：在合约执行期间引入 EOF 格式智能合约的验证。
EIP 3670：在合同创建时引入 EOF 格式智能合约的验证。
要查看关于 EOF 操作码更改的完整列表，请参阅 Ferrin 演示文稿中的以下图表。
关于 EOF 的测试进展，Ferrin 解释说，由于 EOF 规范尚未最终敲定，这也是目前还没有客户端实施升级的原因。然而，他预计 EOF 的测试将非常"独立"且相对简单，因为 EOF 的关注点仅在于对 EVM 执行的更改。他表示：「我们不需要担心网络交互，也无需担心与不同 CL/EL 组合的配对。我认为我们不需要同等级别的开发网络和测试网络，因为我们将能够对其进行测试。」Ferrin 补充说：「我们将编写明确的参考测试……此外，我们拥有的一大优势是一直在进行的差分 EVM 测试。」
在演讲结束时，Ferrin 重申了他希望看到 EOF 作为 Prague/Electra 升级中的主要代码更改。他还表示，在 Dencun 升级完成后的三到六个月内，在主网上进行 EOF 一系列代码更改的测试和执行是可行的。EOF 的最新规范可以在此处。关于这些规范的未解决问题已由 Ipsilon 团队在此处整理。EOF 规范的某些部分尚待完善。我们鼓励参加电话会议的开发人员在以太坊研究与开发 Discord 的「#EVM」频道中分享他们对 EOF 最新发展和规范的看法。
EVM 对象格式争论
Ferrin 的演讲引起了开发人员的广泛讨论。在电话会议上，开发人员对 EOF 的主要担忧有以下几点：
时间安排：包括 Tim Beiko 在内的几位开发人员对 Dencun 升级后 EOF 实施的三至六个月的时间表感到犹豫不决。
紧迫性：开发人员正在考虑将 Verkle 纳入布拉格/伊莱克特拉的另一个主要代码更改。8 月初，以太坊基金会开发者 Guillaume Ballet 分享了 Verkle 的最新进展。在本周的电话会议上，Ballet 强调，相较于 EOF，Verkle 是以太坊更紧迫的升级，因此应该优先考虑。Ballet 还表示，如果能降低 EOF 的复杂性并减少代码更改的数量，使其实现不会影响 Verkle 的时间表，那么他将支持升级。
好处：Van der Wijden 和 Nethermind (EL) 开发人员 Lukasz Rozmej 等人质疑 EOF 的直接好处与升级复杂性之间的权衡。对于缺乏对 EVM 如此大的改变的强烈需求的担忧，Ferrin 表示 EVM 是由以太坊最初的开发团队「在周末」编写的，可以进行大量改进以确保 EVM 保持与竞争对手的竞争力，如新的替代 Layer-1 区块链 Sui。「这不是安全风险，」Ferrin 说。「这更像是一项存在主义的交易。」
增加复杂性和风险：Van der Wijden 强调了 EOF 会增加协议复杂性和风险的方式。客户团队的负担将会增加，他们必须维护 EVM 的两个版本，并确保在未来的硬分叉期间考虑到它们之间的相互依赖性。Wijden 认为，Layer-2 团队不应尝试将维护 EVM 和 EOF 的工作并行「推」给客户端团队，而应致力于在自己的协议上实施对 EVM 的改进。
向后兼容性：EOF 的另一个主要问题是，它可能会给遗留智能合约带来向后兼容性问题。EOF 的设计方式将确保继续支持不使用 EOF 容器的遗留智能合约。然而，Ferrin 和以太坊基金会研究员 Ansgar Dietrichs 等开发人员建议，随着时间的推移，可能会淘汰旧的智能合约功能，并专门针对 EOF 进行升级。
EVM 治理：Dietrichs 还对 EOF 对 EVM 治理的影响表示担忧。以太坊正在不断发展，以支持在称为 Layer-2 的替代网络上执行智能合约。假设未来大多数用户活动和智能合约执行都发生在链外，并且以太坊主要用作数据可用性层，那么 EVM 的更改应该对第 2 层协议最重要，而不是以太坊主网。Dietrichs 建议开发人员仔细考虑并讨论如何在不断扩大的第 2 层生态系统中决定对 EVM 进行更改。
Ferrin 等人早在 2021 年就开始致力于 EOF 的研究。今年早些时候，由于 EOF 的多阶段路线图，EOF 被上海硬分叉拒绝。为了解决这个问题，EOF 支持者通过为升级创建更新的设计，该设计将在一次大型升级中引入所有与 EOF 相关的更改。然而，此次升级的复杂性是本周电话会议上提出的对 EOF 的主要担忧之一。van der Wijden 强调，这次开发人员应该仔细考虑 EOF 是否应该在以太坊上实现，而不是继续推迟有关 EOF 的决定。
「我知道 Ipsilon 团队和 Danno 花了很多时间来解决这个问题，说这么久之后我们可能不会交付它是相当严厉的，但我认为更糟糕的是说，『让我们看看』，然后我们又推迟了两年，然后我们说，『哦，我们毕竟不会发货了。』因此，我认为我们应该在 Devconnect 上做出决定，」van der Wijden 说道，并补充道，「如果这是我们想要做的事情，那么我们就会这么做，除非遇到类似的技术挑战，如果我们说这是我们不做的事情，那么我们就会这样做。我认为这不会发生，对于一直以来努力工作的团队来说，每个人都做出明确的决定是公平的。」
Rozmej 补充说，除了 EOF 和 Verkle 之外，开发人员也许应该重新考虑 EIP 4444 等代码更改，以解决历史链数据增长日益严重的问题。据 Rozmej 称，历史链数据增长速度为每月 20GB。Beiko 同意开发人员应该在 Devconnect 上继续讨论 EOF、Verkle 和 Prague/Electra。Beiko 还强调，将于 10 月 18 日星期三专门召集类似 EVM 的第 2 层协议，以鼓励这些团队之间的协作。同一天还将召开 EOF 实施者电话会议。最后，Beiko 提到了由 L2Beat 在 Devconnect 组织的专门 Layer2 日活动。
原文链接
