拒绝以 0xEF 字节开头的新合约代码

摘要

禁止部署以 0xEF 字节开头的新代码。账户 trie 中已存在的以 0xEF 字节开头的代码，其语义不受此更改影响。

动机

符合 EVM 对象格式 (EOF) 的合约将在部署时进行验证。为了确保状态中每个 EOF 格式的合约都是有效的，我们需要防止已部署（且未经验证）的合约被识别为此类格式。这将通过选择一个在任何已部署合约中都不存在的 magic 字节序列来实现。为防止搜索空间扩大并将分析限制在此分叉前已存在的合约，我们禁止使用该格式的起始字节（magic 的第一个字节）。

如果 EVM 对象格式提案未来未被部署，magic 可以被依赖版本控制的其他功能使用。如果版本控制变得过时，通过允许以 0xEF 字节开头的合约再次部署，可以很容易地回滚此更改。

规范

在 block.number == HF_BLOCK 之后，新的合约创建（通过创建交易、CREATE 或 CREATE2 指令）如果 代码 的第一个字节是 0xEF，将导致异常中止。

备注

initcode 是在创建交易、CREATE 或 CREATE2 指令的上下文中执行的代码。initcode 返回 代码（通过 RETURN 指令），该 代码 被插入到账户中。有关更多信息，请参阅黄皮书第 7 节（“合约创建”）。

操作码 0xEF 目前是一个未定义的指令，因此：它不弹出任何堆栈项，也不压入任何堆栈项，并且在执行时会导致异常中止。 这意味着以该指令开头的 initcode 或已部署的 代码 将继续中止执行。

由于以 0xEF 开头的 代码 导致的异常中止，其行为与 initcode 执行期间可能发生的任何其他异常中止完全相同，即在中止情况下，提供给 CREATE* 或创建交易的所有 gas 都将被消耗。

原理

选择 0xEF 字节是因为它类似于 Executable Format（可执行格式）。

使用未分配操作码的合约通常被认为存在语义改变的风险。因此，使用未分配的 0xEF 应该比选择已分配的操作码（例如 0xFD (REVERT)、0xFE (INVALID)或 0xFF (SELFDESTRUCT)）影响更小。诚然，虽然此类合约可能没有太大用处，但它们仍然在使用有效的操作码。

2021 年 5 月对状态中 18084433 个合约的分析显示，以 0xEF 字节开头的现有合约为 0 个，而以 0xFD、0xFE 和 0xFF 开头的合约分别为 1、4 和 12 个。

测试用例

以下每个测试用例都可以在 3 种不同的上下文中执行：

• 创建交易（无账户代码）
• CREATE，账户代码：0x6000356000523660006000f0151560165760006000fd5b (Yul 代码：

  mstore(0, calldataload(0)) if iszero(create(0, 0, calldatasize())) { revert(0, 0) }

  )，

• CREATE2，账户代码：0x60003560005260003660006000f5151560185760006000fd5b (Yul 代码：

  mstore(0, calldataload(0)) if iszero(create2(0, 0, calldatasize(), 0)) { revert(0, 0) }

  )

向后兼容性

这是一个突破性变更，因为以 0xEF 字节开头的新代码将无法部署，合约创建将导致失败。然而，鉴于字节码是从其第一个字节开始执行的，以 0xEF 作为第一个字节部署的代码无论如何都无法执行。

虽然这意味着当前没有可执行合约受到影响，但它确实拒绝部署以 0xEF 字节开头的新数据合约。

安全考虑

作者不知道此更改会带来任何安全或 DoS 风险。

版权

版权及相关权利通过 CC0 放弃。

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