V神最新提案：以太坊长期L1执行层用RISC-V替换EVM

这篇文章提出了一个关于Ethereum执行层未来的激进想法，其雄心堪比共识层的beacon chain努力。它旨在大幅提高Ethereum执行层的效率，解决主要的scaling bottlenecks之一，同时还能显著简化执行层——事实上，这可能是实现简化的唯一途径。

核心想法：用RISC-V替换EVM，作为编写smart contracts的虚拟机语言。

重要澄清：

1. 账户、跨合约调用、存储等概念保持不变。这些抽象概念运行良好，开发者也已经习惯。像SLOAD、SSTORE、BALANCE、CALL等opcode将变成RISC-V的syscalls。
2. 在这种情况下，smart contracts可以用Rust编写，但我预计大多数开发者仍会继续使用Solidity（或Vyper），这些语言会适配RISC-V作为backend。这是因为用Rust编写的smart contracts代码往往不够美观，而Solidity和Vyper的可读性更强。潜在地，开发者体验（devex）变化可能很小，开发者甚至可能几乎察觉不到变化。
3. 旧式的EVM合约将继续运行，并与新式的RISC-V合约实现完全的双向互操作。有几种实现方式，我将在后文详述。
4. 一个先例是Nervos CKB VM，它基本上就是基于RISC-V。

为什么要这样做？

在短期内，Ethereum L1 scalability的主要瓶颈将通过即将推出的EIPs解决，例如block-level access lists、delayed execution、distributed history storage以及EIP-4444。在中期，我们通过statelessness和ZK-EVMs解决进一步的问题。在长期，Ethereum L1 scaling的主要限制因素将是：

1. 数据可用性采样（data availability sampling）和历史存储协议（history storage protocols）的稳定性。
2. 保持block production为竞争市场的愿望。
3. ZK-EVM的proving能力。

我将论证，替换ZK-EVM为RISC-V可以解决（2）和（3）中的关键瓶颈。

以下是Succinct ZK-EVM用于证明EVM执行层不同部分所需的cycles数量表：

在这四个部分中，耗时较多的有：deserialize_inputs、initialize_witness_db、state_root_computation和block_execution。

• initialize_witness_db和state_root_computation都与state tree相关。
• deserialize_inputs指的是将block和witness数据转换为内部表示的过程。因此，实际上超过50%的耗时与witness sizes成比例。

通过将当前的keccak 16-ary Merkle Patricia tree替换为使用prover-friendly hash function的binary tree，这些部分可以得到大幅优化。如果使用Poseidon，我们可以在笔记本电脑上每秒证明200万个hash（相比之下，keccak仅为约15,000 hash/sec）。除了Poseidon，还有许多其他选择。总的来说，这些组件有很大优化的空间。作为额外的好处，我们可以通过移除bloom来摆脱accrue_logs_bloom。

这就剩下block_execution，它目前占据了大约一半的prover cycles。如果我们想将总的prover效率提高100倍，就必须至少将EVM的prover效率提高50倍。我们可以尝试创建更高效的EVM实现，以减少prover cycles。另一种方法是注意到当前的ZK-EVM provers已经通过将EVM编译到RISC-V上进行证明，因此可以直接让smart contract开发者使用RISC-V VM。

一些数据表明，在特定情况下，这可能带来超过100倍的效率提升：

在实践中，我预计剩余的prover时间将主要由今天的precompiles主导。如果我们将RISC-V作为主要VM，那么gas schedule将反映proving时间，因此会有经济压力促使开发者停止使用更昂贵的precompiles。尽管如此，效率提升可能不会像数据所示那么惊人，但我们有充分理由相信它们将非常显著。

（顺便提一句，EVM与“其他部分”大约各占50%的比例也出现在常规EVM执行中，我们直觉上预期通过移除EVM作为“中间人”带来的提升同样会很大。）

实现细节

实现这种提案有多种方式。以下是几种可能的方法：

1. 最少破坏性的方式：支持两种VM，允许合约用任一种VM编写。两种合约都能访问相同的功能：持久化存储（SLOAD和SSTORE）、持有ETH余额、发起和接收调用等。EVM和RISC-V合约可以自由相互调用；从RISC-V的角度看，调用EVM合约就像是用特殊参数执行syscall；接收消息的EVM合约会将其解释为CALL。
2. 更激进的方式：将现有的EVM合约转换为调用RISC-V编写的EVM解释器合约（interpreter contract），以运行其现有EVM代码。也就是说，如果一个EVM合约有代码C，而EVM解释器位于地址X，那么该合约将被替换为顶层逻辑：当从外部以调用参数D调用时，它会以(C, D)调用X，然后等待返回值并转发。如果EVM解释器本身调用该合约，要求执行CALL或SLOAD/SSTORE，那么合约会执行相应操作。
3. 中间路线：采用第二种方式，但创建一个明确的协议特性——基本上是将“虚拟机解释器”的概念写入协议，并要求其逻辑用RISC-V编写。EVM将是第一个解释器，但可以有其他解释器（例如，Move可能是一个候选）。

第二种和第三种提案的一个关键好处是它们极大地简化了执行层规范——事实上，这种方法可能是实现简化的唯一实用途径，考虑到即使是像移除SELFDESTRUCT这样增量简化的难度都很大。Tinygrad有一个硬性规则：代码永远不超过10,000行；一个优化的区块链base layer应该能轻松适应这一限制，甚至更少。beacon chain的努力为大幅简化Ethereum的共识层带来了巨大希望。但要让执行层实现类似的简化，这种激进的变革可能是唯一可行的路径。