EVM 对象格式- EOF 的好处

• 原文链接：https://hackmd.io/aZurva_kR2GQdOgJfS7B6A
• 译者：AI翻译官
• 本文永久链接：learnblockchain.cn/article…

EOF (EVM Object Format)

是一组改进 EVM 的小型 EIP。它引入了一种新的字节码格式，并为 EVM 的未来做准备。

EOF 的价值难以解释，因为它不是单一的东西，并且由于其在多个分叉上的延迟以及多年来的开发/研究历史和不同版本，增加了理解的难度。

本文的目的是总结其好处并用一句话解释它们：

好处：

• EOF 允许操作码 gas 定价的变化。
  • 如果 gas 定价变化，传统字节码可能会表现不同。
  • 移除 gas 可观察性，意味着移除 GAS 操作码和 CALL/DELEGATECALL/STATICCALL 中的 gas 限制。
  • 允许 l2 根据其用例更改 gas。例如在 zk l2 中哈希被高估。EIP-7667: 提高哈希函数的 gas 成本 https://eips.ethereum.org/EIPS/eip-7667
  • 如果在柏林之前启用了现有的 EOF，则不需要此 EIP，并且可以移除访问列表。 https://eips.ethereum.org/EIPS/eip-2930
• 字节码更小，减少了 gas 使用
  • 早期数据显示代码/初始化代码大小和 gas 使用量的减少: https://notes.ethereum.org/@ipsilon/solidity_eof_poc
  • Uniswap-v3 部署的初始化代码减少 6.5%，部署代码减少 6.5%
  • 部署 UniswapV3Factory 消耗: ~14%更少的 gas，调用 runTest: ~9%更少的 gas。
  • ENS DNSRegistrar 部署的初始化代码减少~6%，部署代码减少~1.5%
  • ENS 调用 proveAndClaim: 对 EOF 消耗~10%更少的 gas。
• EOF 允许字节码转换和可升级性。
  • 移除代码可观察性意味着移除 PC, CREATE/CREATE2, EXTCODEHASH, EXTCODESIZE, EXTCODECOPY, CODESIZE 和 CODECOPY 操作码。
  • 如果代码更改，传统合约将会中断。
  • 这将允许我们在 verkle 到来时以任何形式塑造 EOF 字节码。
• EOF 启用操作码立即数
  • 开启 SWAPN, DUPN 和 EXCHANGE 操作码的可能性
  • 这允许 solidity 在堆栈大小上有更多自由。它解决了 solidity 中的堆栈过深问题。
• EOF 移除昂贵的 jumpdest 分析
  • 虽然在 Reth 中，分析与字节码一起保存，但其他客户端并非如此。在合约执行前移除 jumpdest 分析可以提高速度。
  • 移除分析后，我们将来可以增加最大字节码大小。
• 静态分析变得更容易
  • 子程序强制更结构化的控制流。这使得模糊测试更有效，并且线性时间静态分析成为可能。
  • 数据和代码分离，更易于推理。
  • EOF 字节码可以编译为更快的字节码。
  • EOF 字节码可以编译为机器码。
• 为 EVM 未来做好准备
  • 字节码的版本和结构允许其可扩展性。这对 L2 和标准化特别有用。
  • 一个例子是EIP-7701: Native Account Abstraction with EOF，它添加了新的头部部分。
• 地址空间扩展。
  • 新的 EXT*CALL 操作码通过要求地址字段用零填充，为以太坊未来的地址扩展做准备。当以太坊决定扩展地址空间时，EOF 将已准备好这些更改。

与当前 EVM 的集成

对于开发者来说，一个重要的问题是实施更改所需的努力、测试成本和维护这些操作码的成本。

新操作码不会与传统操作码冲突，并且 EOF 的验证不会触及已弃用的操作码。

EOF 的编码和解码可以进行模糊测试。验证是新的，在 Revm 中大约有~500 行代码，但有很多需要覆盖的边缘情况，需要集中精力在各个实现中正确处理。

创建交易用作 EOF 字节码的载体，它类似于 EOFCREATE，但在执行前请求验证。

大多数操作码非常简单：

• EXTCALL (0xf8), EXTDELEGATECALL (0xf9), EXTSTATICCALL (0xfb)
  • 具有与已弃用 CALL 相同的蓝图，但移除了 gas_limit 和内存输出字段。
  • 在 RETURNDATALOAD（在非常早期的分叉中引入）之前，CALL 的内存输出必须在执行 CALL 操作码之前设置。这不允许动态输出。
• EOFCREATE 和 RETURNCONTRACT
  • 是 EOF 的新功能，需要特殊处理。
  • EOFCREATE 引入了新的创建调用。
• EXCHANGE (0xe8), SWAPN (0xe7), DUPN (0xe6), DATACOPY (0xd3), DATASIZE (0xd2), DATALOADN (0xd1), DATALOAD (0xd0), RJUMP (0xe0), RJUMPI (0xe1), RJUMPV (0xe2), RETURNDATALOAD
  • 逻辑简单，大多数每个操作码需要 10-20 行代码来实现。没有很多需要覆盖的边缘情况。
• CALLF (0xe3), RETF (0xe4), 和 JUMPF (0xe5)
  • 需要子程序堆栈和堆栈验证，这些需要 20-30 行代码来衡量复杂性。

它们需要一个开发人员大约 2/3 个月的时间。测试工作已经开始。目前大约有~2000 个手写的验证测试，并且正在进行状态测试的工作。

更改集中在 EVM 上，因此与客户端其余部分的集成取决于客户端架构以及保存字节码的位置。

EXTCODESIZE 和 EXTCODEHASH 需要知道账户是否为 EOF，并返回预定义值（大小和 0xEF00 的哈希），这可能会略微改变客户端集成的方式。一个想法是在普通账户表中保存 is_eof 标志，以在调用任何 EXTCODE 类型的操作码时跳过加载字节码。

对 L2 的影响

最大的问题是为什么 L2 不实施这一更改？我们是否应该在以太坊 L1 上关闭 EVM 改进？

现实是 L2 还没有准备好，不仅如此，它们也没有一个平台来帮助集成这些创新。字节码版本控制有助于构建 L2 可以使用的平台，移除代码可观察性有助于缓解可升级性问题，gas 变化有助于 ZK L2 移除 gas 炸弹的 ddos 向量（例如，在 zk 中哈希值更高）。

更重要的是，EOF 不仅仅是一种格式，它需要语言（solidity/vyper/huff）的支持，并且需要工具支持以便可用。它需要一个生态系统来使用它，这种格式为 L2 提供了更多的稳定性以在其上进行创新。

缺点，传统字节码仍然存在

这是一个经常被问到的问题。传统字节码将永远存在，如果我们不提供替代方案，我们将被困在其中。有了替代格式的字节码，当状态过期发生时，我们可以过渡并移除传统字节码。

最后

EOF 不是下一个闪亮的新事物，它是修复初始 EVM 版本遗留问题的维护 EIP，除了打破它没有其他方法可以解决这些问题。它对于 EVM 的进一步发展和未来的保障是必要的。

本文由 AI 翻译，欢迎小伙伴们来校对。