以太坊正因 EOF 变成不必要的复杂性迷宫 - 让我们重新考虑 EOF - EIP

EOF 非常复杂。它引入了两种新的合约创建语义（EOFCREATE 和 TXCREATE），移除并添加了十几个操作码。此外，据称的好处并不需要 EOF，它们可以用侵入性小得多的方式在当前的 EVM 中实现。让我们来探讨一下这些：

• 降低编译器复杂度：

  • EIP-663 操作码允许更深入地访问数据栈。这很有用，但对于现代编译器来说不是必需的 —— 所有现代编译器都知道如何实现栈/寄存器溢出。这是 solc 的一个缺点，而不是底层 VM 的缺点。（例如，由于编译器和语言设计，Vyper 没有 stack-too-deep 的问题。）

• 由于 JUMPDEST 的移除，提高了字节码大小：

  • 我们可以直接移除 JUMPDEST。

• 使 EVM 更容易升级，例如添加或删除操作码：

  • 我们可以向现有的 EVM 添加验证规则。可以在创建时分析合约的字节码，并且我们可以禁止部署具有特定操作码的合约 —— 或者更改它们的语义 —— 如果它们是在给定的 fork_blocknum 之后部署的。

• 允许使用带有立即数的操作码：

  • 同样，我们不需要更改现有合约的语义。而是验证更新的语义并将其应用于新创建的合约。

• 移除 gas 内省：

  • 你可以直接添加 EIP-7069 ( CALL2 等) 操作码，这些操作码不会访问 gas。
  • 验证代码是否不包含 GAS 操作码。
  • 由于 63/64 规则，合约行为无论如何都取决于 gasleft（子调用可能会在外部合约没有 OOG 的情况下 OOG）。

• 移除代码内省:

  • 你可以向传统的 EVM 添加验证规则，以移除相关的操作码。需要引入新的创建操作码，但不需要与所有这些其他更改同时发布。

• 移除动态跳转：

  • 这也可以通过简单地更新定价并在 gas 计划中为 PUSH2 JUMP( I) 提供一个例外来解决。

• 子程序：

  • 现有的、对 EVM 侵入性较小的提案包括了子程序，并优先考虑静态跳转。

• 地址空间扩展：

  • 可以更改现有操作码（如 BALANCE）的语义，使其不会将地址的顶部 12 个字节归零，同样通过合约版本控制。

• 移除 codesize 限制：

  • 我们可以直接这样做，因为 initcode 是通过 EIP-3860 来计量的。

• ZK 友好性

  • EOF 据称更 ZK 友好。但是，我们还没有看到为什么这是一个硬性要求的论据。

换句话说，EOF 的所有好处都可以通过对 EVM 进行更零碎、侵入性更小的更新来引入。

与此同时，EOF 的复杂性也不容忽视：

• 需要维护旧版的 EVM，可能无限期地维护。
• 工具需要支持 EOF。这需要在许多不同的团队之间进行协调和努力。
• 由于复杂性带来的漏洞风险。例如，send() 和 transfer() 现在允许重入。直到大阪计划完成前一个月才注意到这一点，即使 EOF 已经开发了近 4 年。
• 与此相关的是，EOF 一直是一个不断变化的目标：即使规范的某些部分不断变化，EOF 也在寻求发布，这使得编译器和应用程序开发人员难以审查整个包。
• 为编译器和应用程序开发人员确定新格式的工作。
• 由于标头，EVM 合约变得更加复杂。一个空的合约现在至少有 15 个字节。
• 字节码大小的权衡。例如，子例程仅声明就需要几个字节，这会惩罚具有许多小型子例程的合约。

更新： 我与人合着了一篇新的、更长的 EOF 深入分析：EOF：当复杂性超过必要性时。我们分解了它所谓的优势，并认为它们更多的是“锦上添花”，而不是必要的升级。我们没有增加复杂性，而是强调了更简洁、更少破坏性的解决方案，这些解决方案可以实现相同的目标。EOF 的目标是可靠的 —— 但有更明智的方法可以实现。

请阅读它，并在本主题中告诉我们你的想法。

• EIP-7607: Fusaka Meta EIP
• EVM 对象格式 (EOF)

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