以太坊对象格式（EOF）：新内容？

最近几天，Solidity 0.8.29 发布了，其中包含一些有趣的新特性，其中我们有对 EOF 的实验性支持，所以让我们来谈谈这个，因为它似乎可能会成为开发中的常见事物。

EOF，代表 Ethereum Object Format（以太坊对象格式），它可以被认为是以太坊中可能是最大的改变，即使我们经历了一些重大的改变，比如 The Merge，EVM 看起来还是一样的。EOF 由一系列 EIP 组成：

• EIP-3540: EOF — EVM Object Format v1（EOF — EVM 对象格式 v1）
• EIP-3670: EOF — Code Validation（EOF — 代码验证）
• EIP-4200: EOF — Static relative jumps（EOF — 静态相对跳转）
• EIP-4750: EOF — Functions（EOF — 函数）
• EIP-5450: EOF — Stack Validation（EOF — 堆栈验证）
• EIP-663: SWAPN, DUPN and EXCHANGE instructions（SWAPN、DUPN 和 EXCHANGE 指令）
• EIP-6206: EOF — JUMPF and non-returning functions（EOF — JUMPF 和非返回函数）
• EIP-7069: Revamped CALL instructions（改进的 CALL 指令）
• EIP-7480: EOF — Data section access instructions（EOF — 数据段访问指令）
• EIP-7620: EOF Contract Creation（EOF 合约创建）
• EIP-7698: EOF — Creation transaction（EOF — 创建交易）

这 11 个 EIP 背后的想法是构建一个对开发者更友好的 EVM，具有新的验证和操作码，所有这些 EIP 都计划包含在 Pectra 升级中，我们已经可以在 Ethereum Sepolia、Holesky 和最新的 Hoodi 测试网（3 月 19 日发布）中测试其中的一些功能。

Legacy EVM vs EOF EVM（传统 EVM 与 EOF EVM）

当前的 EVM 或 Legacy EVM 没有结构，部署在其中的智能合约只是一组按顺序运行的操作码。当前 EVM 字节码看起来类似于这样

600480600B6000396000F3600080FD

由于当前的 EVM 没有任何格式化此代码的方法，正如我们在下一张图片中看到的那样

EVM 将会花费很大的力气逐字节的检查它是指令还是数据。

为此，EOF EIP 3540: EOF — EVM Object Format v1，为 EVM 字节码引入了一种容器格式

现在我们的字节码看起来像这样

EF00 01 01 0004 02 0001 0004 04 0021 00 00 80 0001 D10000 00 454F462068617320736F6D65206772656174206578616D706C6573206865726521

此字节码的各个部分的分解可以在此图像中看到

这种将数据与字节码分离的做法可能使静态分析器能够以更有效的方式工作

Stack too deep（堆栈太深）

如果你一直在用 Solidity 编写代码，肯定会遇到这个问题，这是因为 EVM 不是寄存器机器，而是堆栈机器，所有的计算都在堆栈上执行。此堆栈具有有限的大小。此大小允许你在堆栈中只有 16 个元素，这就是为什么我们有像 DUP16 这样的操作码，但没有 DUP17。

但是现在有了 EIP-663: SWAPN, DUPN and EXCHANGE instructions，我们有一些新的操作码，允许我们拥有多达 256 个局部变量，而不是当前的 16 个变量，我们可以说这完全消除了堆栈太深的问题。在 evm.codes 你现在可以玩这个，只需选择 EOF 作为 EVM 版本并查看一下

Code validations（代码验证）

这包含在 EIP-3670: EOF — Code Validation 中，目前没有代码验证，但现在有了 EOF，代码将被验证，并在必要时被拒绝，只允许部署有效的合约，而不是部署后再在运行时检查。其中一些验证是：

• 已弃用的操作码，如 SELFDESTRUCT
• 未定义或不完整的指令

JUMPDEST analysis（JUMPDEST 分析）

从 Ethereum Yellow Paper 中我们有：

“Jump Destination Validity. We previously used D as the function to determine the set of valid jump destinations given the code that is being run. We define this as any position in the code occupied by a JUMPDEST instruction. All such positions must be on valid instruction boundaries, rather than sitting in the data portion of PUSH operations and must appear within the explicitly defined portion of the code (rather than in the implicitly defined STOP operations that trail it).”

（“跳转目标有效性。我们之前使用 D 作为函数来确定给定正在运行的代码的一组有效跳转目标。我们将其定义为代码中被 JUMPDEST 指令占据的任何位置。所有这些位置必须位于有效的指令边界上，而不是位于 PUSH 操作的数据部分中，并且必须出现在代码的显式定义部分中（而不是出现在尾随它的隐式定义的 STOP 操作中）。”）

正如我们从 “the code that is being run” （“正在运行的代码”）中看到的那样，这些验证是在运行时进行的，这意味着每次代码运行时，此验证都负责检查所有目标是否有效，这些验证现在将在合约部署时执行。

Contract creation（合约创建）

使用 EOF，我们不再有 CREATE 和 CREATE2 操作码，对于 EOF 部署，EIP-7620: EOF Contract Creation 引入了：

• EOFCREATE 使用容器索引启动创建上下文
• TXCREATE 使用交易数据中的初始化代码启动创建上下文
• RETURNCONTRACT 在容器索引处部署合约字节码

CALL instructions（CALL 指令）

EIP-7069: Revamped CALL instructions 为调用引入了新的操作码：

• EXTCALL 与 CALL 相同，但没有 gas 或返回的数据参数
• EXTSTATICCALL 与 STATICCALL 相同，但没有 gas 或返回的数据参数
• EXTDELEGATECALL 与 DELEGATECALL 相同，但没有 gas 或返回的数据参数
• RETURNDATALOAD 从返回的数据中读取 32 字节的字，这意味着我们不再需要复制到内存，然后再从内存加载

结论

EOF 的出现是为了改善开发者体验，这里讨论的所有功能都带来了优势，例如减少合约大小、最佳的静态分析性能。当然，协议需要一个充分的理由，并进行良好的研究，以决定是否有必要将当前合约迁移到 EOF 合约。

你需要做什么？如果你是用户，什么都不需要，如果你是 Solidity 开发者，继续学习！

• 原文链接： blog.blockmagnates.com/e...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～