Vitalik激进新文：执行层扩容“不破不立”，EVM未来必须被迭代

本文来自：以太坊联合创始人 Vitalik

编译｜Odaily星球日报（ @OdailyChina ）

译者｜Azuma（ @azuma_eth ）

在这篇文章中，我将提出一个关于以太坊执行层未来的激进想法，其宏大程度与共识层的 Beam Chain 计划不相上下。该计划的目标是大幅提升以太坊执行层的效率，解决主要的扩展瓶颈之一，同时也能极大简化执行层的复杂性 —— 事实上，这可能是实现简化的唯一途径。

本文的核心观点是，用 RISC-V 取代 EVM 作为智能合约的虚拟机语言。

重要说明：

• 账户、跨合约调用、存储等概念将完全保留。 这些抽象机制运作良好且开发者已习惯使用。类似 SLOAD、SSTORE、BALANCE、CALL 等操作码将成为 RISC-V 的系统调用。

• 开发者仍可选择 Solidity 或 Vyper。 虽然理论上可用 Rust 编写智能合约，但预计大部分开发者会继续使用 Solidity（或 Vyper） ，这些语言将通过适配 RISC-V 作为后端编译目标 —— 这是因为 Rust 编写的智能合约可读性较差，而 Solidity 和 Vyper 更易理解。开发体验几乎不会改变，开发者可能完全感受不到差异。

• 新旧合约将实现双向互操作。 传统 EVM 合约将继续运行，并能与新型 RISC-V 合约完全交互。具体实现方式后文将详述。

• 已有先例可循： Nervos CKB VM 本质上就是基于 RISC-V 的实现。

为何需要这种变革？

短期内，以太坊 Layer 1 扩容的主要瓶颈将通过即将推出的 EIP（如区块等级访问列表、延迟执行、分布式历史存储以及 EIP-4444）得到解决；中期内，我们将通过无状态性和 ZK-EVM 来解决更多问题；但长期来看，限制以太坊 Layer 1 扩容的主要因素将变为：

1. 数据可用性采样与历史存储协议的稳定性；

2. 维持区块生产市场竞争性的需求；

3. ZK-EVM 的证明能力。

本文将论证， 用 RISC-V 替代 ZK-EVM 能突破第 2 点及第 3 点中的关键瓶颈。

以下是 Succinct ZK-EVM 用于证明 EVM 执行层各环节所需的周期数统计表：

四个主要耗时环节为：“deserialize_inputs”（数据反序列化）、“initialize_witness_db”（见证数据库初始化）、“state_root_computation”（状态根计算）和“block_execution”（区块执行）。

“见证数据库初始化”和“状态根计算”都与状态树有关，而“数据反序列化”指的是将区块和见证数据转换为内部表示的过程。 因此，实际上超过 50% 的时间与见证数据的大小有关。

通过将当前的“keccak 16-ary Merkle patricia tree”（keccak 十六叉 Merkle Patricia 树）替换为使用证明友好型哈希函数的“binary tree”（二叉树），这些环节可以得到大幅优化。如果我们使用“Poseidon”，我们可以在笔记本电脑上每秒证明 200 万次哈希（相比之下，keccak 为每秒约 15000 次哈希）。除了“Poseidon”之外还有许多其他选择。总的来说，有机会大幅削减这些环节的耗时。此外，我们还可以通过去除“accrue_logs_bloom”来进一步简化流程。

现在只剩下了“区块执行”，它大约占用了目前证明周期的一半。如果我们想将总体证明效率提高 100 倍，就必须至少将 EVM 证明效率提高 50 倍。 现有两种路径： 一是 尝试创建更高效的 EVM 实现，以减少证明周期； 二是直接让开发者使用 ZK-EVM 底层已采用的 RISC-V 虚拟机。

部分数据显示，特定场景下效率提升可超 100 倍：

实践中， 剩余证明时间将主要消耗于预编译合约（precompiles）。若将 RISC-V 设为主虚拟机，gas 费用机制将反映实际的证明耗时，经济压力将促使开发者减少使用高成本的预编译 。尽管实际收益可能不及理论值，但预期仍将非常显著。

值得注意的是，常规 EVM 执行中也存在类似的“EVM”与“其他环节” 50/50 的耗时分配，我们直观地认为，移除 EVM 作为“中间层”应能获得相近幅度的效率提升。

实现方法

有多种方法可以实现上述提案。

破坏性最低的方法是支持两种虚拟机，允许合约选用任一种虚拟机编写。 两种类型的合约都可以访问相同的功能：持久存储（SLOAD/SSTORE）、ETH 余额管理、发起和接收调用等。 EVM 与 RISC-V 合约可自由互调：从 RISC-V 视角调用 EVM 合约将被视为携带特殊参数的系统调用（syscall），而接收调用的 EVM 合约则将其解析为普通 CALL 指令。

更激进的方案会将现有 EVM 合约转换为调用 RISC-V 编写的 EVM 解释器合约来执行其原有的 EVM 代码。 具体而言，假设某 EVM 合约包含代码 C，且 EVM 解释器位于地址 X，则该合约将被替换为顶层逻辑：当外部以调用参数 D 发起调用时，该逻辑会向 X 发送（C, D）请求，等待返回值并转发。若 EVM 解释器自身需要调用合约以执行 CALL、SLOAD 或 SSTORE 等操作，合约将直接响应。

折中方案则是在第二种方案基础上，通过协议层明确支持"虚拟机解释器"概念 —— 即要求解释器逻辑必须用 RISC-V 编写。 EVM 将作为首个官方解释器，未来可能引入其他类型（例如 Move 语言解释器）。

第二和第三种方案的核心优势在于大幅简化执行层规范。考虑到即使像移除 SELFDESTRUCT 这类渐进式简化都困难重重，此类变革可能是实现简化的唯一现实途径。Tinygrad 项目严格规定代码量永不超 1 万行， 理想的区块链基础层应追求更极致的精简。Beam Chain 计划为以太坊共识层的简化指明方向，而执行层要实现类似突破，或许唯有通过此类根本性变革。