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

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

这个想法是：用 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 解决进一步的问题。从长远来看，以太坊 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 努力有望极大地简化以太坊的共识层。但是，要使执行层看到类似的收益，这种激进的改变可能是唯一可行的途径。

• 所有核心开发者 - 执行 (ACDE) #210, 4 月 24 日

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