来源：Vitalik Buterin
编译：KarenZ，Foresight News
4 月 20 日，Vitalik Buterin 在 Ethereum Magicians 平台提出一项关于以太坊长期 L1 执行层的重要提案。他建议采用 RISC-V 架构取代现有的 EVM（以太坊虚拟机）作为编写智能合约的虚拟机语言，旨在从根本上提升以太坊执行层的运行效率，突破当前主要的扩展瓶颈之一，同时大幅简化执行层的简洁性。
Foresight News 对该提案进行了全文编译，旨在帮助读者了解这一技术设想。以下为提案原文的编译内容：
本文提出了一个关于以太坊执行层未来的激进想法，其雄心程度不亚于共识层的 Beam Chain 计划。该提案旨在大幅提高以太坊执行层的效率，解决主要的扩展瓶颈之一，并显著简化执行层——事实上，这可能是实现这一目标的唯一途径。
核心构想：用 RISC-V 取代 EVM，作为智能合约编写的虚拟机语言。
重要说明：
- 账户体系、跨合约调用、存储等概念将完全保留。这些抽象设计运作良好且开发者已习惯使用。SLOAD、SSTORE、BALANCE、CALL 等操作码将转变为 RISC-V 系统调用。
- 在此模式下，智能合约可用 Rust 编写，但我预计多数开发者仍会继续使用 Solidity（或 Vyper）编写合约，这些语言将适配 RISC-V 作为新后端。因为用 Rust 编写的智能合约实际上可读性较差，而 Solidity 和 Vyper 更清晰易读。开发体验可能几乎不受影响，开发者甚至可能察觉不到变化。
- 旧版 EVM 合约将继续运行，并与新版 RISC-V 合约完全双向兼容。实现方式有几种，本文后续将详细探讨。
Nervos CKB VM 已开创先例，其本质上就是RISC-V 实现。
为何这样做？
短期来看，即将实施的 EIP（如区块级访问列表、延迟执行、分布式历史存储及EIP-4444）能解决以太坊 L1 的主要扩展瓶颈。中期将通过无状态性和 ZK-EVM 解决更多问题。长期来看，以太坊 L1 扩展的主要限制因素将变为：
- 数据可用性采样和历史存储协议的稳定性
- 保持区块生产市场竞争性的需求
- ZK-EVM 的证明能力
我将论证，替换 ZK-EVM 为 RISC-V 可以解决（2）和（3）中的关键瓶颈。
下表展示了 Succinct ZK-EVM 证明 EVM 执行层各环节所需的周期数：
图表说明：四个主要耗时环节为 deserialize_inputs、initialize_witness_db、state_root_computation 和 block_execution
其中 initialize_witness_db 和 state_root_computation 与状态树相关，deserialize_inputs 涉及将区块和见证数据转换为内部表示的过程——实际上超过 50% 与见证数据大小成正比。
通过将当前的 keccak 16-ary Merkle patricia tree 替换为使用使用易于证明的哈希函数的 binary tree，这些部分可以得到大幅优化。如果使用 Poseidon，我们可以在笔记本电脑上每秒证明 200 万次哈希值（相比之下，keccak 约为 15,000 hash/sec）。除了 Poseidon，还有许多其他选择。总的来说，这些组件有很大优化的空间。此外，我们可以通过移除 bloom来消除 accrue_logs_bloom。
剩下的 block_execution 约占当前证明周期（prover cycles）的一半。若要实现 100 倍的整体证明效率提升，EVM 证明效率至少需要提升 50 倍。解决方案之一是为 EVM 创建更高效的证明实现，另一方案是注意到当前 ZK-EVM 证明器实际是通过将 EVM 编译为 RISC-V 进行证明，直接让智能合约开发者访问该 RISC-V 虚拟机。
部分数据显示在特定情况下效率提升可能超 100 倍：
实际应用中，剩余的 prover 时间可能主要由当前的预编译（precompiles）操作占据。若将 RISC-V 作为主虚拟机，Gas schedule 将反映实际证明时间，经济压力将促使开发者减少使用高成本预编译。即便如此，增益也不会如此显著，但我们有充分的理由相信，这些增益将非常可观。
（值得注意的是，常规 EVM 执行中 「EVM 操作」 与 「其他操作」 的耗时占比也接近 50/50，因此我们直观认为，移除 EVM 作为「中间层」将带来同等显著的增益）
实施细节
该提案有多种实现方式。破坏性最小的方案是同时支持两种虚拟机，允许合约任选其一编写。两类合约都能访问相同功能：持久化存储（SLOAD/SSTORE）、持有 ETH 余额的能力、发起 / 接收调用等。EVM 与 RISC-V 合约可互相调用——从 RISC-V 视角看，调用 EVM 合约相当于执行带特殊参数的系统调用；而接收消息的 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 计划有望大幅简化以太坊共识层，而执行层若想实现类似提升，这种激进变革可能是唯一可行之路。
