Vitalik: 长期提案 L1执行层 用 RISC-V 替代 EVM

这篇文章提出了一个关于以太坊执行层未来的激进想法，其雄心壮志与 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。

为什么要这样做？

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

1. 数据可用性抽样和历史存储协议的稳定性
2. 保持区块生产竞争市场的愿望
3. ZK-EVM 的证明能力

我将论证用 RISC-V 替换 ZK-EVM 解决了 (2) 和 (3) 中的一个关键瓶颈。

这是一个表格，显示了 Succinct ZK-EVM 用于证明 EVM 执行层不同部分的周期数：

\ download (6)800×359 154 KB

有四个部分占用了大量时间：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 个哈希/秒）。除了 Poseidon 之外，还有许多其他选择。总而言之，有很大的机会可以大幅减少这些组件。作为额外的奖励，我们可以通过去掉 bloom 来摆脱 accrue_logs_bloom。

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

一些数字表明，在有限的情况下，这可以带来超过 100 倍的效率提升：

\<br>download (7)800×476 154 KB	\<br>4a3981f5-7c49-4631-9c7c-3216b4c62466583×528 33.4 KB

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

（顺便说一句，“EVM”和“其他东西”之间大约 50/50 的比例也出现在常规 EVM 执行中，并且我们凭直觉期望消除 EVM 作为“中间人”的收益应该同样大）

实现细节

有很多方法可以实现此类提案。最具破坏性的方法是支持两个 VM，并允许合约用任何一个编写。两种类型的合约都可以访问相同类型的设施：持久存储（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 有一个硬性规定，即永远不要超过 10000 行代码；一个最佳的区块链底层应该能够很好地适应这些范围，甚至更小。beam chain 的努力为大大简化以太坊的共识层带来了巨大的希望。但是，为了使执行层看到类似的收益，这种激进的改变可能是唯一可行的途径。

• 原文链接： ethereum-magicians.org/t...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～