2023 年首次以太坊核心开发者会议：延后 EOF，暂定于 3 月份进行上海升级

撰文：Christine Kim （galaxy）

编译：DeFi 之道

图片来源：由 Maze AI 生成

1 月 5 日，以太坊开发者们在休息两周后召开了 2023 年首次全核心开发者 (ACD) 电话会议。从 2023 年开始，ACD 电话会议将更名为 ACD 执行 (ACDE) 电话会议，以反映开发者们对以太坊执行层变化的关注。 他们还将在@EthereumProtocol YouTube 频道进行直播，而不是在@EthereumFoundation YouTube频道。 ACDE 电话会议由以太坊基金会的 Tim Beiko 主持，它是以太坊开发者讨论和协调以太坊协议变更的两个会议系列之一， 而另一个系列会议，开发人员已将其重命名为 ACD 共识(ACDC)电话会议，重点讨论与以太坊共识层开发相关的主题。

在第 152 次全核心开发者执行 (ACDE) 电话会议上，开发人员同意从上海升级中删除与 EOF 实施相关的代码更改。 有关 EOF 的更多信息，请在此处阅读之前的电话会议记录。 他们还同意拒绝将新 EIP 添加到上海升级，这主要是为了确保质押 ETH 提款的时间表不会延迟。 作为上海升级唯一的主要代码更改，质押 ETH 提款功能目前正在一个开发者测试网络上进行测试。据悉，开发者们的目标是在下个月推出上海/Capella 升级的公共测试网，并暂定于 2023 年 3 月的某个时间启动主网升级。随后，开发者们简要讨论了以太坊执行层和共识层之间不同序列化方法的问题，以及引入 Poseidon 哈希函数作为 EVM 的预编译的新 EIP 。

上海升级计划

以太坊基金会的 DevOps 工程师 Barnabus Busa 更新了质押 ETH 提款测试的状态。 他表示，在圣诞节前推出的上海开发者测试网络，当前已进展到 4,000 个区块。 目前，所有 EL 和 CL 客户端组合都在该测试网上运行，其中 Teku-Erigon 和 Lighthouse-Erigon 等一些客户端组合遇到了问题。 Busa 提到，开发者们正努力在客户端团队的帮助下尽快启动一个新的开发者测试网。

然后，以太坊基金会 Geth (EL) 客户端的软件开发者 Marius van der Wijden 向上海升级较小的 EIP之一（ EIP 3860 ‌）提交了一个小的设计更改。提议的更改纠正了该 EIP 中令人困惑的失败模式，其中违反 initcode 限制导致零地址错误而不是 OOG 错误。根据以太坊基金会 Ipsilon 团队开发者Pawel Bylica 的说法，这样做的最初动机是为了促进用户友好性。然而，开发者们一致认为，将失败模式更改为 OOG 错误，会减少客户端实现中的混乱与漏洞。

延后 EOF，将其排除在上海升级之外

接下来，一名以太坊基金会 Geth (EL)客户端软件开发者(化名为“lightclient”)介绍了 EOF 实现的最新进展。

作为背景，EOF 代表 EVM 对象格式，其对以太坊的代码执行环境进行了一些更改。在其他变化中，与 EOF 实现相关的 EIP 将改进以太坊的交易格式，以更明确地区分智能合约代码和数据，并帮助 EVM 在未来更容易升级。lightclient 表示，在假期期间，致力于 EOF 实现的开发者们举行了两次会议，并讨论了相关 EIP 规范。在这些会议期间，开发者们同意删除其中一个 EIP（EIP 6206‌，因为它的复杂性），并使这些 EIP 中的数据部分成为强制性的，而不是可选的，以略微提高数据解析的简单性。据 lightclient 表示，EOF EIP 的测试也在取得进展。EOF EIP 的参考测试尚未正式发布，但以太坊基金会的安全负责人 Martin Holst Swende 已经开始对 EOF 的不同客户端实现进行差异测试（也称为差分模糊测试）。

“为 EOF 创建一个效果最好的 [测试] 案例并不容易，问题是有很多陷阱。 例如，如果你希望某些东西以某种方式失败，在 EOF 中，你必须非常具体，并且必须确保在达到你真正想要测试的内容之前，测试不会在其他地方失败。 所以，我认为如果我们以某种方式集中错误，这将是非常有价值的，”以太坊基金会测试团队的 Mario Vega 表示。

基于 EOF 实现以及测试的现状，Tim Beiko 提出了一个问题，即开发者们在下一次（上海）以太坊升级中包含这些 EIP 是否仍然可行的问题。在这个话题上，以太坊联合创始人 Vitalik Buterin 表达了他对仓促实施 EOF 的担忧，因为目前没有明确的路线图来确保未来对 EVM 的升级不会更加繁琐，也不会增加以太坊的技术债。Vitalik 表示：

“在 EVM 中，删除一些东西比删除其他功能要困难得多，你有用 EVM 代码编写的应用程序，如果 EVM 发生了变化，那么这些应用就无法更改 …我最大的担忧之一是对 EVM 的改进，特别是因为它很难弃用和实际删除一些东西，EVM 开发的哲学允许基本上大量的持续改进，而不是很快地致力于真正接近于不会更改的东西，这会让我们冒着创建一个 [EVM] V2，然后创建一个 V3，然后创建一个 V4 的风险，但仍然需要 V1、V2 和 V3 作为共识代码的一部分，因为我们没有移除它们的好方法。”