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

进阶4/23/2025, 6:00:34 AM
本文提出了一个关于以太坊执行层未来的激进想法,其雄心与共识层的 beam chain 努力不相上下。

本文提出了一个关于以太坊执行层未来的激进构想,其雄心堪比共识层中的 beam chain 项目。该想法旨在大幅提升以太坊执行层的效率,解决主要的扩展瓶颈之一,同时也可以显著简化执行层的设计 —— 实际上,这可能是唯一能实现简化的方法。

这个想法是:将EVM替换为RISC-V,作为智能合约所编写的虚拟机语言。

重要说明:

  • 账户、跨合约调用、存储等概念将完全保持不变。这些抽象机制本身运行良好,开发者也早已习惯。像 SLOAD、SSTORE、BALANCE、CALL 等操作码将变成 RISC-V 的系统调用。
  • 在这种新模式下,智能合约可以用 Rust 编写,但我预计大多数开发者仍会继续使用 Solidity(或 Vyper),只是这两种语言会适配 RISC-V 作为后端。因为用 Rust 写智能合约 实际上丑陋的,而 Solidity 和 Vyper 。也就是说,开发者的体验可能几乎不会改变,甚至几乎感觉不到差别。
  • 旧式的 EVM 合约将继续可用,并且可以与新式的 RISC-V 合约进行双向互操作。本文后面会详细讲解实现方式。

有一个先例是 Nervos 的 CKB 虚拟机,它本质上就是基于 RISC-V 的。

为什么要这样做?

在短期内,以太坊 L1 的主要扩展瓶颈将通过即将推出的 EIP(如区块级访问列表延迟执行、分布式历史存储及 EIP-4444)得到解决。中期内,我们会通过无状态性ZK-EVM 进一步优化。但从长期看,以太坊 L1 扩展性的主要限制因素将变为:

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

我将论证,用 RISC-V 替代 ZK-EVM 可以解决(2)和(3)中的关键瓶颈。

以下是 Succinct ZK-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 虚拟机。

一些数据表明,在某些有限场景下,这种方式可带来超过 100 倍的效率提升:

实际上,我预计剩余的证明时间将主要集中在当前的预编译合约上。如果我们将 RISC-V 设为主虚拟机,那么 gas 费用将反映证明时间,因此经济上会有压力促使人们停止使用更昂贵的预编译合约;即便如此,提升可能也没那么夸张,但我们有充分理由相信优化幅度仍然会非常可观。

(顺便说一句,在常规的 EVM 执行中,“EVM 执行”与“其他操作”的计算开销也是大约对半分的,因此我们直觉上也能预期,通过移除 EVM 作为“中间层”,带来的效率提升将同样巨大。)

实施细节

有多种方式可以实现这一提案。其中最不具破坏性的方式是同时支持两种虚拟机,允许合约可以用任意一种编写。两种类型的合约都可以访问相同类型的功能设施:持久化存储 (SLOAD 和 SSTORE)、持有 ETH 余额、进行调用或接收调用等。EVM 合约和 RISC-V 合约可以相互调用;从 RISC-V 的角度来看,调用 EVM 合约就像是使用某些特殊参数进行系统调用;而接收到该调用的 EVM 合约则将其解释为一次 CALL 操作。

从协议的角度看,更激进的方式是:将现有的 EVM 合约转化为调用一个用 RISC-V 编写的 EVM 解释器合约。也就是说,如果一个 EVM 合约包含代码 C,而 EVM 解释器的地址是 X,那么该合约就被替换为一个顶层逻辑:当从外部接收到调用参数 D 时,调用地址 X 并传入参数 (C, D),然后等待返回值并将其转发。如果解释器本身在执行过程中尝试进行 CALL 或 SLOAD/SSTORE 操作,那么合约就去执行它。

还有一种折中方案是执行上述第二种方案,但在协议层面上显式引入“虚拟机解释器”的概念,并要求其逻辑用 RISC-V 编写。EVM 将成为第一个被实现的解释器,但未来还可以支持其他虚拟机(例如 Move 就是一个可能的候选者)。

第二和第三种方案的一个关键优势在于:它们能大幅简化执行层的规范。实际上,这种激进的想法可能是实现简化的唯一可行路径,因为即使是像移除 SELFDESTRUCT 这样的渐进式简化也非常困难。

Tinygrad 项目有一个严格的规则,即代码不能超过 10000 行;而一个最优的区块链底层协议应当也能在这一范围内,甚至更小。Beam chain 项目在大幅简化以太坊共识层方面展现出了巨大潜力。但如果想在执行层获得类似的进展,也许只有像这样彻底性的变革才能实现。

声明:

  1. 本文转载自 [Ethereum Magicians]。所有版权归原作者所有 [Vitalik Buterin]。若对本次转载有异议,请联系 Gate Learn 团队,他们会及时处理。
  2. 免责声明:本文所表达的观点和意见仅代表作者个人观点,不构成任何投资建议。
  3. Gate Learn 团队将文章翻译成其他语言。除非另有说明,否则禁止复制、分发或抄袭翻译文章。

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

进阶4/23/2025, 6:00:34 AM
本文提出了一个关于以太坊执行层未来的激进想法,其雄心与共识层的 beam chain 努力不相上下。

本文提出了一个关于以太坊执行层未来的激进构想,其雄心堪比共识层中的 beam chain 项目。该想法旨在大幅提升以太坊执行层的效率,解决主要的扩展瓶颈之一,同时也可以显著简化执行层的设计 —— 实际上,这可能是唯一能实现简化的方法。

这个想法是:将EVM替换为RISC-V,作为智能合约所编写的虚拟机语言。

重要说明:

  • 账户、跨合约调用、存储等概念将完全保持不变。这些抽象机制本身运行良好,开发者也早已习惯。像 SLOAD、SSTORE、BALANCE、CALL 等操作码将变成 RISC-V 的系统调用。
  • 在这种新模式下,智能合约可以用 Rust 编写,但我预计大多数开发者仍会继续使用 Solidity(或 Vyper),只是这两种语言会适配 RISC-V 作为后端。因为用 Rust 写智能合约 实际上丑陋的,而 Solidity 和 Vyper 。也就是说,开发者的体验可能几乎不会改变,甚至几乎感觉不到差别。
  • 旧式的 EVM 合约将继续可用,并且可以与新式的 RISC-V 合约进行双向互操作。本文后面会详细讲解实现方式。

有一个先例是 Nervos 的 CKB 虚拟机,它本质上就是基于 RISC-V 的。

为什么要这样做?

在短期内,以太坊 L1 的主要扩展瓶颈将通过即将推出的 EIP(如区块级访问列表延迟执行、分布式历史存储及 EIP-4444)得到解决。中期内,我们会通过无状态性ZK-EVM 进一步优化。但从长期看,以太坊 L1 扩展性的主要限制因素将变为:

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

我将论证,用 RISC-V 替代 ZK-EVM 可以解决(2)和(3)中的关键瓶颈。

以下是 Succinct ZK-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 虚拟机。

一些数据表明,在某些有限场景下,这种方式可带来超过 100 倍的效率提升:

实际上,我预计剩余的证明时间将主要集中在当前的预编译合约上。如果我们将 RISC-V 设为主虚拟机,那么 gas 费用将反映证明时间,因此经济上会有压力促使人们停止使用更昂贵的预编译合约;即便如此,提升可能也没那么夸张,但我们有充分理由相信优化幅度仍然会非常可观。

(顺便说一句,在常规的 EVM 执行中,“EVM 执行”与“其他操作”的计算开销也是大约对半分的,因此我们直觉上也能预期,通过移除 EVM 作为“中间层”,带来的效率提升将同样巨大。)

实施细节

有多种方式可以实现这一提案。其中最不具破坏性的方式是同时支持两种虚拟机,允许合约可以用任意一种编写。两种类型的合约都可以访问相同类型的功能设施:持久化存储 (SLOAD 和 SSTORE)、持有 ETH 余额、进行调用或接收调用等。EVM 合约和 RISC-V 合约可以相互调用;从 RISC-V 的角度来看,调用 EVM 合约就像是使用某些特殊参数进行系统调用;而接收到该调用的 EVM 合约则将其解释为一次 CALL 操作。

从协议的角度看,更激进的方式是:将现有的 EVM 合约转化为调用一个用 RISC-V 编写的 EVM 解释器合约。也就是说,如果一个 EVM 合约包含代码 C,而 EVM 解释器的地址是 X,那么该合约就被替换为一个顶层逻辑:当从外部接收到调用参数 D 时,调用地址 X 并传入参数 (C, D),然后等待返回值并将其转发。如果解释器本身在执行过程中尝试进行 CALL 或 SLOAD/SSTORE 操作,那么合约就去执行它。

还有一种折中方案是执行上述第二种方案,但在协议层面上显式引入“虚拟机解释器”的概念,并要求其逻辑用 RISC-V 编写。EVM 将成为第一个被实现的解释器,但未来还可以支持其他虚拟机(例如 Move 就是一个可能的候选者)。

第二和第三种方案的一个关键优势在于:它们能大幅简化执行层的规范。实际上,这种激进的想法可能是实现简化的唯一可行路径,因为即使是像移除 SELFDESTRUCT 这样的渐进式简化也非常困难。

Tinygrad 项目有一个严格的规则,即代码不能超过 10000 行;而一个最优的区块链底层协议应当也能在这一范围内,甚至更小。Beam chain 项目在大幅简化以太坊共识层方面展现出了巨大潜力。但如果想在执行层获得类似的进展,也许只有像这样彻底性的变革才能实现。

声明:

  1. 本文转载自 [Ethereum Magicians]。所有版权归原作者所有 [Vitalik Buterin]。若对本次转载有异议,请联系 Gate Learn 团队,他们会及时处理。
  2. 免责声明:本文所表达的观点和意见仅代表作者个人观点,不构成任何投资建议。
  3. Gate Learn 团队将文章翻译成其他语言。除非另有说明,否则禁止复制、分发或抄袭翻译文章。
今すぐ始める
登録して、
$100
のボーナスを獲得しよう!
It seems that you are attempting to access our services from a Restricted Location where Gate.io is unable to provide services. We apologize for any inconvenience this may cause. Currently, the Restricted Locations include but not limited to: the United States of America, Canada, Cambodia, Thailand, Cuba, Iran, North Korea and so on. For more information regarding the Restricted Locations, please refer to the User Agreement. Should you have any other questions, please contact our Customer Support Team.