这篇文章批判了以太坊改进提案EOF(EIP-7692)的复杂性,认为其引入了新的合约创建方式、移除/增加多种操作码,且其宣称的优势可以用更简单的方式在现有EVM上实现。
EOF 非常复杂。它引入了两种新的合约创建语义(EOFCREATE
和 TXCREATE
),移除并添加了十几个操作码。此外,据称的好处并不需要 EOF,它们可以用侵入性小得多的方式在当前的 EVM 中实现。让我们来探讨一下这些:
由于 JUMPDEST
的移除,提高了字节码大小:
JUMPDEST
。fork_blocknum
之后部署的。CALL2
等) 操作码,这些操作码不会访问 gas。GAS
操作码。gasleft
(子调用可能会在外部合约没有 OOG 的情况下 OOG)。PUSH2
JUMP
( I
) 提供一个例外来解决。BALANCE
)的语义,使其不会将地址的顶部 12 个字节归零,同样通过合约版本控制。移除 codesize
限制:
换句话说,EOF 的所有好处都可以通过对 EVM 进行更零碎、侵入性更小的更新来引入。
与此同时,EOF 的复杂性也不容忽视:
需要维护旧版的 EVM,可能无限期地维护。
工具需要支持 EOF。这需要在许多不同的团队之间进行协调和努力。
由于复杂性带来的漏洞风险。例如,send()
和 transfer()
现在允许重入。直到大阪计划完成前一个月才注意到这一点,即使 EOF 已经开发了近 4 年。
与此相关的是,EOF 一直是一个不断变化的目标:即使规范的某些部分不断变化,EOF 也在寻求发布,这使得编译器和应用程序开发人员难以审查整个包。
为编译器和应用程序开发人员确定新格式的工作。
由于标头,EVM 合约变得更加复杂。一个空的合约现在至少有 15 个字节。
字节码大小的权衡。例如,子例程仅声明就需要几个字节,这会惩罚具有许多小型子例程的合约。
更新: 我与人合着了一篇新的、更长的 EOF 深入分析:EOF:当复杂性超过必要性时。我们分解了它所谓的优势,并认为它们更多的是“锦上添花”,而不是必要的升级。我们没有增加复杂性,而是强调了更简洁、更少破坏性的解决方案,这些解决方案可以实现相同的目标。EOF 的目标是可靠的 —— 但有更明智的方法可以实现。
请阅读它,并在本主题中告诉我们你的想法。
- 原文链接: ethereum-magicians.org/t...
- 登链社区 AI 助手,为大家转译优秀英文文章,如有翻译不通的地方,还请包涵~
如果觉得我的文章对您有用,请随意打赏。你的支持将鼓励我继续创作!