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

这篇文章批判了以太坊改进提案EOF(EIP-7692)的复杂性,认为其引入了新的合约创建方式、移除/增加多种操作码,且其宣称的优势可以用更简单的方式在现有EVM上实现。

EOF 非常复杂。它引入了两种新的合约创建语义(EOFCREATETXCREATE),移除并添加了十几个操作码。此外,据称的好处并不需要 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 的目标是可靠的 —— 但有更明智的方法可以实现。

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

  • 原文链接: ethereum-magicians.org/t...
  • 登链社区 AI 助手,为大家转译优秀英文文章,如有翻译不通的地方,还请包涵~
点赞 0
收藏 0
分享
本文参与登链社区写作激励计划 ,好文好收益,欢迎正在阅读的你也加入。

0 条评论

请先 登录 后评论
以太坊中文
以太坊中文
以太坊中文, 用中文传播以太坊的最新进展