Vitalik新提议：RISC-V作为EVM智能合约的虚拟机语言

来源：Vitalik Buterin，Ethereum Magicians；编译：陶朱，金色财经

这篇文章为以太坊执行层的未来提出了一个激进的想法，这个想法与 Beam 链对共识层的努力一样雄心勃勃。它旨在大幅提高以太坊执行层的效率，解决主要的扩展瓶颈之一，并且还可以大幅提高执行层的简单性——事实上，这也许是唯一的方法。

想法：用RISC-V作为编写EVM智能合约的虚拟机语言。

重要澄清：

• 账户、跨合约调用、存储等概念将保持完全相同。这些抽象工作得很好，开发人员也习惯了它们。 SLOAD、SSTORE、BALANCE、CALL 等操作码将成为 RISC-V 系统调用。

• 在这样的世界里，智能合约可以用 Rust 编写，但我预计大多数开发人员会继续用 Solidity（或 Vyper）编写智能合约，这将适应添加 RISC-V 作为后端。这是因为用 Rust 编写的智能合约实际上相当丑陋，而 Solidity 和 Vyper 的可读性要高得多。或许 devex 的变化很小，开发人员可能几乎不会注意到这种变化。

• 旧式 EVM 合约将继续有效，并将与新式 RISC-V 合约完全双向互操作。有几种方法可以做到这一点，我将在本文后面进行介绍。

一个先例是 Nervos CKB VM，它基本上是 RISC-V。

为什么这么做？

短期内，以太坊 L1 可扩展性的主要瓶颈将通过即将推出的 EIP 得到解决，例如块级访问列表、延迟执行和分布式历史存储以及 EIP-4444。从中期来看，我们将解决无状态和 ZK-EVM 的进一步问题。从长远来看，以太坊 Layer1 扩展的主要限制因素是：

• 数据可用性采样和历史存储协议的稳定性

• 希望保持区块生产市场的竞争性

• ZK-EVM 验证能力

我认为用 RISC-V 替换 ZK-EVM 可以解决 (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 元 Merkle patricia 树替换为使用证明者友好哈希函数的二叉树来对这些部分进行大量优化。如果我们使用 Poseidon，我们可以在笔记本电脑上证明每秒 200 万次哈希值（而 keccak 每秒约 15,000 次哈希值）。除了波塞冬之外还有很多其他选择。总而言之，我们有机会大幅减少这些组件。作为奖励，我们可以通过摆脱 bloom 来摆脱 accrue_logs_bloom。

剩下的就是 block_execution，它大约占了今天花费的证明周期的一半。如果我们想要将总体证明器效率提高 100 倍，那么我们就无法回避至少需要将 EVM 证明器效率提高 50 倍这一事实。我们可以做的一件事是尝试创建在证明周期方面更高效的 EVM 实现。我们可以做的另一件事是注意到 ZK-EVM 证明器今天已经通过证明编译为 RISC-V 的 EVM 实现来工作，并让智能合约开发人员直接访问该 RISC-V VM。

一些数据表明，在有限的情况下，这可以使效率提高 100 倍以上：

实际上，我预计剩余的证明时间将主要由今天的预编译所主导。如果我们将 RISC-V 作为主要虚拟机，那么 gas 计划将反映证明时间，因此将存在经济压力来停止使用更昂贵的预编译；但即便如此，收益也不会如此令人印象深刻，但我们有充分的理由相信，收益将非常显著。

（顺便说一句，“EVM”和“其他东西”之间大约 50/50 的分割也出现在常规 EVM 执行中，我们直观地预计，从 EVM 作为“中间人”中移除的收益应该同样大）

实现细节

有多种方法可以实现此类建议。破坏性最小的方法是支持两个虚拟机，并允许在任意一个虚拟机中编写合同。两种类型的合约都可以使用相同类型的设施：持久存储（SLOAD 和 SSTORE）、持有 ETH 余额的能力、拨打和接听电话的能力等。EVM 和 RISC-V 合约可以自由地相互调用；从 RISC-V 的角度来看，调用 EVM 合约似乎是在进行带有一些特殊参数的系统调用；接收该消息的 EVM 合约会将其解释为 CALL。

从协议角度来看，一种更激进的方法是将现有的 EVM 合约转换为调用用 RISC-V 编写的 EVM 解释器合约的合约，该合约运行其现有的 EVM 代码。也就是说，如果 EVM 合约具有代码 C，并且 EVM 解释器位于地址 X，则该合约将被替换为顶层逻辑，当从外部使用调用参数 D 调用时，使用 (C, D) 调用 X，然后等待返回值并转发它。如果 EVM 解释器本身调用合约，要求运行 CALL 或 SLOAD/SSTORE，那么合约就会这样做。

中间路线是采用第二种选择，但为其创建一个明确的协议功能 —— 基本上，将“虚拟机解释器”的概念奉为圭臬，并要求其逻辑用 RISC-V 编写。 EVM 将是第一个，但也可能还有其他（例如，Move 可能是一个候选者）。

第二和第三个提案的一个主要好处是它们极大地简化了执行层规范 —— 事实上，这种想法可能是唯一可行的方法，因为即使是像删除 SELFDESTRUCT 这样的渐进式简化也非常困难。 Tinygrad 有一条严格的规定，即代码量永远不超过 10,000 行；最佳的区块链基础层应该能够很好地适应这些边界，甚至更小。光束链的努力对于大大简化以太坊的共识层具有很大的希望。但对于执行层来说，要想获得类似的收益，这种彻底的改变可能是唯一可行的途径。