本文来自 Coinbase，原文作者：Ethen Pociask Eric Meng Nadir Akhtar Gabriela Melendez Quan Tom Ryan，由 Odaily 星球日报译者 Katie 辜编译。
为了加强对交易 ERC-20 和其他基于智能合约的资产的客户的安全和托管保证，Coinbase 区块链安全团队调查了定义这些资产行为的程序层：以太坊虚拟机（EVM）。在评估修改自身网络的 EVM 的项目时，Coinbase 的区块链安全团队会审查关键的 EVM 更改，以确定修改后的 EVM 是否能够提供与原始 EVM 实施相同的安全和托管保证。
分叉 EVM 现状
截至 2023 年 5 月，以太坊虚拟机（EVM）夺得最热门智能合约执行平台“榜一大哥”头衔。根据 DefiLlama 的数据，总锁仓价值（TVL）排名前 10 位的链中有 9 个支持 EVM 智能合约。因此，深入了解 EVM 对于支持整个区块链生态系统中的智能合约至关重要。
EVM 是一种虚拟机，用于在以太坊网络上去中心化执行智能合约。许多兼容 EVM 的区块链在其协议软件中直接利用不同语言的热门 Ethereum 执行客户端的标准实施方案，如 go-ethereum（Golang）和 besu（Java）。
也就是说，分叉和修改 EVM 实际上在区块链生态系统中非常常见，甚至在主要协议中也是如此。例如，为 Coinbase 的 Base L2 区块链提供“动力”的 Optimism Bedrock Stack 使用了一个名为 op-geth 的 go-ethereum 执行客户端的分叉版本，该版本运行的 EVM 与热门的以太坊执行客户端兼容。然而，这并不意味着以太坊上的 EVM 与 Optimism 上的 EVM 行为完全相同：op-geth EVM 在某些情况下的行为略有不同（即 DIFFICULTY 返回随机值是由序列器确定的）。
虽然这听起来很可怕，但对于 EVM 的采用来说，一般情况下是有益的。虽然标准 EVM 实施方案针对以太坊基础协议进行了高度优化，但分叉的 EVM 通常会针对自己的新协议进行扩展。因此，合约在某些 EVM 兼容链上的执行方式可能与在以太坊上的执行方式不同，EVM 智能合约行为的安全假设在不同协议之间也可能存在很大差异。
分叉 EVM 安全框架
为此，Coinbase 开发了一个Web3安全框架，用于评估一些分叉 EVM 实施方案中的安全影响。我们称之为 Coinbase 的分叉 EVM 框架，下面将对其进行详细的解释。
有了这个分叉 EVM 安全框架，Coinbase 能够有效地：
了解我们的以太坊代币框架的安全假设的无效性，使我们能够安全地启用新的 EVM 兼容区块链，以便在我们的去中心化交易所支持 ERC-20/ERC-721 代币；
为智能合约审计师提供关于分叉 EVM 的智能合约漏洞情况的分析，特别是跨网络中的微小差异；
确保在 Coinbase 的 Base L2区块链上安全使用和执行 EVM 智能合约。
兼容 EVM 的区块链的安全标准
为了解以太坊虚拟机中的安全风险是如何存在的，首先要知道标准 EVM 实施方案为我们提供了哪些保障。我们将标准 EVM 定义为以太坊执行规范中描述的以太坊验证器执行客户端一致使用的 EVM。到目前为止，最常用的客户端是 go ethereum（即 geth）。
我们将安全性总结为两个安全标准，它们代表了任何分叉 EVM 实施方案有资格获得 Coinbase 支持的最低要求。
我们如何审计 EVM 实施方案的安全风险？
我们的分叉 EVM 框架在评估是否符合总体安全标准（即合约不变性和安全执行环境）时，主要关注以下审计要求。需要注意的是，以下风险成分并不是分叉 EVM 审计的全部范围。
修改 EVM 操作码的定义和编码会导致合约执行方式的重大差异。例如，假设一些分叉的 EVM 实施（EVM）将算术 ADD 操作码定义逻辑（x 1 + x 2 ）改为减去两个值（x 1 - x 2 ）。
结果，偏离的 EVM 在执行上与标准 EVM 不相等且不兼容。修改操作码的后果可能是有益的行为，比如防止算术操作码中的整数溢出和下溢，也可能是更危险的行为，比如导致本地资产无限铸造的自毁行为。
EVM 使用预编译合约来定义复杂的功能（如加密函数），使用更方便和性能更强的语言，如 Golang，而不是使用不太容易访问的 EVM 字节码。
从根本上说，这些是通过节点软件中表示的预定链地址来访问的编程功能。以太坊黄皮书（截至 2023 年 5 月）中定义了 9 个预编译器，对这 9 个预编译器所做的任何更改或引入新的预编译器都需要进行审计。
让我们再举一个具体的例子——BNB 智能链漏洞。BNB 智能链使用 go-ethereum 的一个偏离的实施方案来运行节点。为此，引入了两个新的预编译合约（tmHeaderValidate，iavlMerkleProofValidate），利用第三方软件（即 Cosmos SDK）来执行轻客户端区块验证和 Merkle 证明验证。问题是，Cosmos SDK 软件在其 IAWL 树表示法中有一个实施错误，允许加密无效的证明通过验证。换句话说，任何人都可以凭空产生资金。攻击者能够利用嵌套在 iavlMerkleProofValidate 预编译器中的这个实施漏洞，从币安跨链桥中抽走数亿美元。
这个利用漏洞的例子是为了展示预编译器安全性的必要性，以及为偏离的 EVM 实施引入新的预编译合约所带来的潜在风险。
引入额外的预编译器可能带来的致命风险包括：
允许一方单方面修改任何已部署合约的状态；
这包括所有存储修改（插入、更新、删除）；
使用不受信任、未经验证或未经审计的第三方依赖项；
提供对不确定节点内值的访问。
尽管将编译器和 EVM 视为完全独立的实体，但值得注意的是，Solidity 编译器确实对前三个预编译合约（ecrecover、sha 256 和ripemd）的行为做出了严格的假设，这些合约通过 Solidity 语言中的本机语言关键字函数表示。在后台，Solidity 编译器实际上将这些关键字处理成字节码，字节码执行合约间静态调用操作。下图进一步说明了这种合约间的沟通方式。
修改标准预编译器会带来的安全风险包括：
允许中心化的交易对手单方面修改任何已部署合约的状态；
这包括所有存储修改（插入、更新、删除）；
Solidity 编译器预编译位置假设不一致；
提供对不确定节点内值的访问；
使用不受信任、未经验证或未经审计的第三方依赖项。
修改 EVM 基本组成部分所带来的关键风险包括：
不约束解释器堆栈，使其无限大；
对内存模型进行大小修改或改变，可能导致非确定性的执行；
绕过访问控制，允许任意的对手方单方面访问所有链状态；
使用不受信任、未经验证或未经审计的第三方依赖关系。
为什么要重视 EVM 安全性？
我们的目标是建立一个基于区块链技术的开放金融系统，为此，我们鼓励开发各种 EVM 实施方案。然而，为了让兼容 EVM 的区块链得到 Coinbase 的全面支持，它必须满足标准 EVM 实施的基本要求。本文希望提高人们对偏离 EVM 相关风险的认识，并鼓励资产发行人在偏离 EVM 时优先开发安全组件，提高整个 Web3 生态系统的安全意识。
