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