如何评估「分叉版 EVM」的安全风险？

TVL 前 10 的链中有 9 个支持 EVM 智能合约。

原文标题：《How to uate Forked EVMs for Security Risks》

撰文：Ethen Pociask、Eric Meng、Nadir Akhtar、Gabriela Melendez Quan、Tom Ryan

编译：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操作码定义逻辑（x1 + x2）改为减去两个值（x1 - x2）。

结果，偏离的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、sha256和&ripemd）的行为做出了严格的假设，这些合约通过Solidity语言中的本机语言关键字函数表示。在后台，Solidity编译器实际上将这些关键字处理成字节码，字节码执行合约间静态调用操作。下图进一步说明了这种合约间的沟通方式。

修改标准预编译器会带来的安全风险包括：

• 允许中心化的交易对手单方面修改任何已部署合约的状态；
• 这包括所有存储修改（插入、更新、删除）；
• Solidity编译器预编译位置假设不一致；
• 提供对不确定节点内值的访问；
• 使用不受信任、未经验证或未经审计的第三方依赖项。

修改EVM基本组成部分所带来的关键风险包括：

• 不约束解释器堆栈，使其无限大；
• 对内存模型进行大小修改或改变，可能导致非确定性的执行；
• 绕过访问控制，允许任意的对手方单方面访问所有链状态；
• 使用不受信任、未经验证或未经审计的第三方依赖关系。

为什么要重视EVM安全性？

我们的目标是建立一个基于区块链技术的开放金融系统，为此，我们鼓励开发各种EVM实施方案。然而，为了让兼容EVM的区块链得到Coinbase的全面支持，它必须满足标准EVM实施的基本要求。本文希望提高人们对偏离EVM相关风险的认识，并鼓励资产发行人在偏离EVM时优先开发安全组件，提高整个 Web3 生态系统的安全意识。