长期L1执行层提案：用RISC-V取代EVM - Magicians / Primordial Soup

这篇文章提出了以太坊执行层未来的一个激进想法，其雄心壮志与 beam chain 在共识层面的努力不相上下。它的目标是极大地提高以太坊执行层的效率，解决主要的可扩展性瓶颈之一，并且还可以极大地提高执行层的简洁性 - 事实上，这也许是实现这一目标的唯一途径。

这个想法是：用 RISC-V 替换 EVM，作为智能合约编写的虚拟机语言。

重要的澄清：

• 账户、跨合约调用、存储等概念将完全保持不变。这些抽象概念运作良好，并且开发者已经习惯了它们。像 SLOAD、SSTORE、BALANCE、CALL 等操作码，将变成 RISC-V 的系统调用（syscalls）。
• 在这样的世界中，智能合约_可以_用 Rust 编写，但 我预计大多数开发者会继续用 Solidity (或 Vyper) 编写智能合约，它们会进行调整以添加 RISC-V 作为后端。这是因为用 Rust 编写的智能合约实际上非常丑陋，而 Solidity 和 Vyper 更加 易读。 潜在地，开发体验（devex）的变化会非常小，开发者甚至可能几乎不会注意到这种变化。
• 旧式 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

实际上，我预计剩余的证明时间将主要由今天的预编译（precompiles）所主导。 如果我们使 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 努力为大大简化以太坊的共识层带来了巨大的希望。 但是，对于执行层来说，要看到类似的收益，这种激进的改变可能是唯一可行的途径。

• 所有核心开发者 - 执行 (ACDE) #210, 4 月 24 日
• EVM 2.0：以证明为中心 vs. 以执行为中心的方法

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