---
id: 16
title: EVM 兼容意味着什么：字节码、预编译与工具链
slug: evm-compatibility-explained
date: 2026/09/03
summary: "兼容 EVM"常被简化成一句营销话术，但字节码、预编译合约与工具链三个层面，任何一处缩水都可能让开发者付出意料之外的代价。本文拆解 EVM 兼容的真实含义，以及常见的"假兼容"陷阱。
keywords: EVM兼容,字节码,预编译合约,Solidity工具链,Foundry
heroImage: /images/community-bg.png
---

几乎每一条新公链的官网首页都会出现同一句话:完全兼容 EVM。这四个字听起来像一句技术承诺,实际上更像一句需要被追问的广告词。它到底承诺了什么,是合约代码可以原封不动地部署,还是钱包和浏览器不用改一行代码就能接入,又或者只是"用 Solidity 写"这么低的门槛。这三种情况在工程上相差极大,但对外传播时经常被压缩成同一句话。

对于一条选择保留 EVM 兼容、同时又要把执行模型改成并行化的链而言,这个问题不是修辞游戏,而是每天都要面对的工程约束:改了执行顺序、加了冲突检测和多引擎调度之后,怎么保证字节码层面的行为跟以太坊主网分毫不差。

## 兼容的最小单位是字节码,不是语法

EVM 兼容最严格的定义发生在字节码层面。以太坊虚拟机执行的从来不是 Solidity 源码,而是编译后的操作码序列,一套围绕栈、内存和存储设计的指令集,外加一套账户模型:每个地址有 nonce、余额、代码哈希和独立的存储树。只要操作码语义、每条指令的 Gas 计价、栈深度限制和账户状态的读写规则跟以太坊主网完全一致,一份没有重新编译过的字节码就应该能在另一条链上跑出相同结果。

这个标准之所以重要,是因为它决定了迁移成本的下限。真正的字节码级兼容意味着已经部署在以太坊上的合约理论上可以不经重新编译直接搬迁,审计过的代码不需要重新审计,依赖 CREATE2 地址计算、依赖特定操作码 Gas 成本做防重入设计的合约也不会因为底层计价规则变化而出现意料之外的行为。反过来,如果一条链只是"支持用 Solidity 写合约",那开发者拿到的只是语法层面的熟悉感,合约一旦涉及到具体的 Gas 计价假设或者某个不常用的操作码,行为随时可能跑偏。

以太坊生态里对这种分级讨论得最系统的,是 Vitalik Buterin 在 2022 年那篇关于 zkEVM 分类的文章。他把兼容程度从高到低分成 Type 1 到 Type 4:Type 1 完全不改动以太坊现有系统的任何一部分,因此可以直接复用现有的区块浏览器和执行客户端,代表项目是 Taiko;Type 2 保持高度的 EVM 等价性,只做很小的底层优化,Scroll 和 Linea 属于这一类;Type 2.5 会对 Gas 成本、预编译支持等细节做轻微修改;Type 3 只实现操作码的一个子集,部分操作码被合并或替换成对证明系统更友好的版本,这意味着未经修改的以太坊字节码不一定能直接跑通;到了 Type 4,则彻底放弃字节码层面的兼容,把 Solidity 或 Vyper 编译到一套专门为高效生成证明而设计的自定义虚拟机上,zkSync Era 和 StarkNet 是这条路线的代表。

这套分类原本是为 zkEVM Rollup 方案设计的,但它揭示的问题是通用的:兼容不是有和没有的二元判断,而是一条从字节码等价到仅源码相似的连续谱系,越往谱系右侧走,底层改动的自由度越大,但迁移进来的合约出现行为偏差的风险也越高。

## 预编译合约:兼容声明里最容易被忽略的一块

字节码之外,另一个决定"兼容"成色的地方是预编译合约。以太坊在 0x01 到 0x09 这几个固定地址上内置了一批用普通字节码实现起来极其昂贵的密码学运算:0x01 是 ecrecover,用于从签名中恢复地址;0x02 和 0x03 分别是 sha256 与 ripemd160 哈希;0x05 是大数模幂运算 bigModExp;0x06 到 0x08 是 alt_bn128 椭圆曲线上的加法、标量乘法和配对运算,服务于 zk-SNARK 验证;0x09 是 blake2F,在 EIP-152 中被加入用于验证某些跨链场景的交易声明。Cancun-Deneb 升级之后,0x0a 又新增了 KZG 承诺验证的预编译,服务于 blob 交易的数据可用性验证。

这些预编译之所以被单独拎出来,是因为它们直接决定了哪些应用能在一条链上以合理的 Gas 成本运行。缺少 alt_bn128 相关预编译,大部分 zk 应用的链上验证成本会高到不可用;bigModExp 的计价如果跟以太坊主网不一致,依赖 RSA 验证或者某些密码学协议的合约行为就会跟着变化。这不是假设性的担忧。TRON 生态里就出现过 ModExp 预编译定价偏低的问题,官方提案 TIP-7883 明确指出偏低的计价给了攻击者用低成本发起高计算量 MODEXP 调用的空间,构成潜在的拒绝服务向量。Filecoin 的 EVM 运行时也存在类似的细节偏差,其文档明确写明与以太坊不同,调用预编译时通常不强制执行 Gas 上限,这意味着理论上一次预编译调用可以耗尽调用者提供的全部剩余 Gas。这些都是"号称兼容,细节跑偏"的真实案例,而不是理论上的边角情况。

对于任何声称完整 EVM 兼容的新链,预编译清单是否齐全、计价是否与主网对齐,是比"能不能跑 Hello World 合约"更值得追问的问题。

## 工具链兼容:开发者真正每天打交道的那一层

再往上一层是工具链兼容。以太坊生态的开发效率建立在一整套围绕 Solidity 编译器、JSON-RPC 标准接口和本地开发环境搭建起来的工具生态上,eth_call、eth_sendRawTransaction、eth_getTransactionReceipt 这些标准 RPC 方法,是钱包、区块浏览器、索引服务和几乎所有中间件默认调用的接口。一条链只要在 RPC 层面精确复刻这套接口的行为,MetaMask、The Graph 这类基础设施就可以不做任何定制化开发直接接入。

开发框架层面,这两年发生了明显的格局变化。根据 2024 年的 Solidity 开发者调研,Foundry 的使用率已经从落后转为反超,达到 51.1%,而 Hardhat 的使用率为 32.9%,但这并不意味着 Hardhat 被淘汰,现有项目里仍有约六成在使用它,只是新项目和安全导向的开发几乎默认选择 Foundry 作为主力框架。Foundry 的核心组件 Forge 负责编译和测试,Cast 是命令行层面的链上交互工具,Anvil 则提供了一个本地模拟节点,用于快速分叉主网状态做集成测试。Hardhat 一侧也在追赶,2025 年底发布的 Hardhat 3 引入了 Rust 实现的执行层,把测试速度的差距大幅缩小,并且首次原生支持此前只有 Foundry 才有的 Solidity 测试写法。目前不少高可靠性要求的团队采取的是混合策略:用 Foundry 处理速度敏感的单元测试和不变量测试,用 Hardhat 处理需要 TypeScript 生态和插件系统支撑的部署脚本与合约验证流程。

这套工具链生态之所以重要,是因为它决定了开发者的实际生产力,而不只是决定了合约能不能编译通过。根据 Electric Capital 发布的开发者报告,2025 年前九个月以太坊生态新增了 16,181 名活跃开发者,总活跃开发者数量达到 31,869 人,是所有公链生态里增长最快、存量最大的阵营。这个规模效应意味着,任何一条新链只要能真正接入这套工具链而不是另起炉灶,就能直接借力一个数量级更大的开发者群体和已经跑通的审计、测试、监控体系,而不需要说服开发者重新学一套语言或者一整套新工具。

## 假兼容的代价,以及并行执行给这道题增加的难度

把字节码、预编译和工具链三层放在一起看,"假兼容"通常发生在某一层被悄悄简化的地方:字节码层面只实现了操作码子集,导致某些合约编译后无法直接运行;预编译清单不全或者计价偏离主网,导致依赖密码学运算的合约成本异常甚至存在安全隐患;工具链层面只兼容了最常用的几个 RPC 方法,一旦索引器或浏览器调用一个冷门接口就会报错。这些问题往往不会在部署第一个合约时暴露,而是在应用复杂度上升、开始调用密码学预编译或者依赖精确 Gas 语义做安全设计时才会显现,对开发者而言代价是审计过的假设在新链上悄悄失效。

对于把执行模型从单线程串行改成乐观并行的链而言,这道题会更难一层。多引擎并行执行意味着交易的执行顺序和调度方式跟原生以太坊客户端完全不同,冲突检测和重执行机制也是全新引入的组件,但字节码语义、Gas 计价规则和最终状态根的计算结果必须跟单线程执行完全一致,否则就无法称之为兼容,只能称之为一条"看起来像 EVM"的新链。这意味着并行化改造不能停留在调度层,预编译的计价和执行结果、账户模型的读写语义,都必须在改造之后逐条跟主网客户端对齐验证,这也是为什么真正做到完整 EVM 兼容同时保留并行执行能力的项目并不多,兼容声明背后是否经得起字节码级和预编译级的推敲,值得每一个评估新链的开发者认真核实一遍。

## 延伸阅读

- 前置阅读：[《Bitroot 定位：乐观并行 EVM 的高性能 Layer 1》](/zh/blog/bitroot-positioning)
- 下一篇：[《谁该读并行 EVM：合约开发、客户端工程、研究员三条路径》](/zh/blog/who-should-read-parallel-evm)

数据来源:Vitalik Buterin《The different types of ZK-EVMs》(vitalik.ca,2022);EVM 预编译合约清单(evm.codes、RareSkills);2024 Solidity 开发者调研(Foundry vs Hardhat 使用率数据);Hardhat 3 发布信息;TRON TIP-7883(ModExp 预编译计价问题);Filecoin EVM Runtime 官方文档(预编译 Gas 限制差异说明);Electric Capital 2025 开发者报告(以太坊活跃开发者数据)。