以太坊的最佳指令集架构是什么？

特别感谢 Alex Beregszaszi、Christian Reitwiessner、Georg Wiese、Guillaume Ballet 和 Justin Drake 的审阅和反馈。

大约一个月前，Vitalik 关于在 Ethereum 中使用 RISC-V 的帖子 [1] 导致一大群人考虑了几种不同的路径，重新开启了一些关于执行环境的辩论。 预测在柏林区块链周期间会有大量的讨论、分组会议和小组讨论试图回答这个问题，我写了一些笔记，变成了这份文档。

这里的目的是对不同的 VM/ISA 在一些选定的目标方面进行高层次的优缺点分析，有时会注入我个人的观点，以及对一些仍在开发中的场景可能发生什么的推测。 我将使用一些对上述帖子的回复中的评论，但我不会总结整个讨论。 那里有很多很棒的评论，你应该自己阅读。 虽然这是一篇长文。

请注意，Polkadot 开发者已经经历过类似的练习 [2]，我们绝对应该从中学习。

在这里，我考虑的是已经存在或正在积极开发中的选项，而不是试图从头开始创建一些东西。 这些是：

• EVM
• RISC-V
• MIPS
• WASM
• eBPF
• CairoVM
• Valida
• PetraVM

我们试图衡量：

• 简洁性（设计和实现）
• 执行性能（CPU 和硬件）
• 生态系统
• 工具
• 智能合约 DX/UX
• ZK 友好性/性能

EVM

EVM 可以说是仅次于 RISCV 和 MIPS 的最简单的。 每个 ISA 都需要用 Ethereum 系统调用进行扩展。 如果我们考虑剩下的 EVM 操作码，EVM 是编写解释器最简单的（同样，仅次于 RISCV 和 MIPS）。 鉴于它是为 Ethereum 制作的，Solidity 和 Vyper 生成的字节码比 RISCV 小一个数量级，例如，正如我个人在 R55 中观察到的那样。 然而，EVM 的 256 位原生字大小和复杂的 gas 计量使得 JIT 和专用硬件支持仍然是一个尚未解决的问题。

它拥有一个庞大、强大且具有凝聚力的生态系统，从而产生广泛的网络效应。 EVM 开发者（如 Solidity 和 Vyper 开发者）平均而言非常注重安全性：许多（如果不是大多数）人都知道并能够使用模糊测试和形式化验证工具，这些工具是其他生态系统中的大多数开发者甚至从未听说过的话题。 工具在过去几年中已经成熟，开发者可以享受大量针对 Ethereum 开发的在线材料，安全研究人员正在培养敏锐的眼光。

EVM 对 ZK 不友好。 为 EVM 专门构建的第一代 zkEVM 已经被解释 EVM 字节码的通用 zkVM 所取代。 如果 zkVM 的 ISA 和正在证明的程序之间有更多的兼容性，这种开销可以减少。

坚持使用 EVM 意味着：

• Ethereum 对其开发者社区和工具感到满意。
• Ethereum 需要在某种程度上专注于执行。
• 通用 zkVM 仍然需要变得更快。

在最初的帖子中，Lev 实际上建议 [3] 最佳情况实际上可能是 EVM + 某种容器格式 + 用于 ZK 证明的自定义 ISA。

RISC-V

RISC-V 非常简单，非常模块化且可扩展。 它可以进行 JIT 编译并在专用硬件中运行。 根据 PolkaVM 实验 [4]，CPU 性能似乎不错，结果显示比 wasmtime 和 cranelift 慢 2 倍。 然而，请注意，PolkaVM 实际上在 LLVM 编译后使用自定义和 WASM 启发式的想法修改了程序 [5] [6]。

用 Ethereum 系统调用扩展 RISC-V 应该不是问题，但我不确定如何处理 gas 计量。 在最初的帖子中有一个关于此的很好的子讨论 [7]。 字节码比 EVM 的大得多。 对于大多数 LLVM 编译的程序来说，情况都是如此。

RISC-V 工具很棒，因为 LLVM RISC-V 后端维护良好，你可以毫不费力地将 Rust 代码编译为 RISC-V。 围绕 RISC-V 工具的开发者社区也非常强大。 智能合约开发者社区有限。

然而，在使用 RISC-V 或 WASM 时，智能合约 DX/UX 具有巨大的潜力：Rust 智能合约。 目前已建立的 Rust 智能合约非常糟糕，但可以很容易地得到相当大的改进。 R55 合约 表明它们可以非常简洁且侵入性最小。 Rust 智能合约使庞大的现有社区能够以最小的努力加入 Ethereum。 它还允许将现有的安全工具直接用于智能合约。 再次注意，这也适用于 WASM！ 所以不要到处说只有 RISCV 才能实现这一点。 我也明白很多人不一定重视上面的论点，但它仍然是一个可能性。 很大一部分开发者仍然更喜欢 Solidity 或 Vyper 是完全有效的，这是一件好事！ 让人们使用他们想使用的任何东西。

RISC-V 不是为 ZK 友好而设计的，当然，许多团队已经表明可以通过 RISC-V 实现出色的 ZK 证明性能。 大多数通用 zkVM 使用 RISC-V 作为 Rust 程序的 IR，并借助良好的工具和 ISA 的简单性。 RISC-V 是使 Rust ZK 证明实用的最短路径。 但这是性能最高的吗？ 不太可能。 包括我在内的几个人已经给出了为什么其他 ISA 更适合该目的的论据，同时仍然支持高级 Rust 程序。 最明显的一个是调用约定以及 RISC-V 在周期数方面对于本地计算的浪费程度，Mamy 在最初的讨论中强调了这一点 [8]。

考虑到所有不同的目标和方向，RISC-V 可能感觉是一个很好的折衷方案，但这仍然取决于 Ethereum 真正想要优化什么。 在任何情况下，它都需要一些自定义，与 EVM 以外的其他选项相比，这将是最小的。 你仍然必须信任（或者，验证）某种程度的自定义编译/转换。 但如果是 RISC-V，那么我认为有一种更好的方法可以做到这一点，这在下面的结论中进行了解释。

MIPS

MIPS 与 RISC-V 非常相似。 好吧，或者反过来。 RISC-V 通常被认为是“现代 MIPS”。 对于此比较，主要区别在于：

• RISC-V 高级语言工具对于 Rust 来说更好，但一般来说并非如此。 MIPS 在 Go 中的支持非常成熟。 例如，Optimism 在生产中使用 Go+MIPS 进行欺诈证明。 MIPS 的使用时间更长，并且拥有比 RISC-V 更大的生产社区。
• 硬件上的 MIPS 比 RISC-V 更成熟，这可以帮助执行。
• MIPS 在执行程序时似乎需要更少的周期，这可以在 EthProofs 上看到 [9]。 这也可以提高 ZK 证明的效率。
• 可能用于定位 MIPS 的高级程序将是 Go。 有趣的是，Go 已被用于在 CosmWasm 中编写智能合约，其活跃社区的入门门槛可能更低。

WASM (WebAssembly)

首先要注意的重要一点是，WASM 本身不是 ISA，并且通常比 EVM 和 RISC-V 更高级。 我个人认为，这为比较设定了一个基线，即我们不会按原样使用 WASM，而是会将其进一步编译为更低级别的东西。

WASM 比 EVM/RISC-V 更复杂。 它具有高级控制流以及更基本的指令。 它的 JIT 性能通常被认为是好的，尽管这不足以让当时的 eWASM 优于 EVM。 WASM 的复杂性是有原因的：它具有严格的形式规范，这些规范提供了关于堆栈使用和验证的编译时保证，EVM/RISC-V 只能梦寐以求。

WASM 工具可以说是比 RISC-V 的更好。 它具有出色的 LLVM 支持和庞大的开发者社区。 智能合约开发者社区有限，但由于 Arbitrum Stylus，可能比 RISC-V 的更大。

如上面的 RISC-V 部分所述，Rust 智能合约的潜力也无缝地适用于 WASM。 事实上，Solidity 过去有一个直接编译到 eWASM 的管道。

WASM 可以 ZK 友好。 我们只需将 WASM 转换为 ZK 友好的 ISA 即可:) 我认为这具有巨大的潜力，并且可以使 ZK 优化的 zkVM 不仅支持 DSL，还支持高级 Rust 代码（至少，希望也支持其他语言）。 这样做的原因正是 WASM 的更高级代码。 我们需要的唯一原语是 Write Once Memory (WOM) 区域。 这一概念由 CairoVM 在 zkVM 上率先提出，并也被 PetraVM 使用，为 zkVM 中本地计算的实现提供了更廉价的方式。 然而，这不是编译器习惯的原生概念，因此我们必须构建一个编译器。 使用 WASM 代码，我们有足够的信息将本地变量和堆栈转换为无限寄存器，进而将其转换为 zkVM 中的 WOM 访问（免责声明：在 powdr，我们与 Irreducible 合作，正在为 PetraVM 构建它 - WOMIR）。

最终，通过构建一个针对特定 zkVM 的精简的后 WASM 编译层，与纯 RISC-V zkVM 相比，此路径可能会产生更好的性能。 代价是更多编译器工作。

WASM 以前曾被考虑用于 Ethereum，但仅作为独立 VM。 从编译器的角度来看，它可以与任何较低级别的 VM 组合，其中将其与正确的 VM 组合可能会带来巨大的性能提升。 这可能是 PetraVM，RISC-V + 扩展，或其他从头开始构建的东西。

eBPF

eBPF 旨在为访客代码提供原生执行性能。 在区块链环境中，它与 Solanas 的高性能智能合约执行相关联。 它非常简单，可能在此比较中在“执行性能”指标中得分最高。 我也不知道在这种情况下如何实现 gas。

工具似乎也可以通过 LLVM 获得，但 Polkadot 开发者指出它可能不够成熟 [10]。 如果这可行，则可以像 RISC-V 和 WASM 一样启用 Rust 智能合约。 智能合约生态系统可能仅次于 EVM，Solana 在今年和去年吸引了许多新开发者。 例如，通过使用 R55，DX 也可以得到改进。

eBPF 的 zkVM 友好性可能与 RISC-V 的相似。 它不是为 ZK 证明而设计的，并且会损失一些性能，但考虑到经验证的原生执行优势和现有的智能合约社区，这也是可以接受的。

eBPF 似乎具有与 RISC-V 相似的特性和缺点，但可能具有更好的执行性能和更差的工具兼容性。

CairoVM

CairoVM 是一种 ZK 优化的通用 zkVM，可在 Starknet 上启用智能合约。 它易于阅读和理解，并提供了对 zkVM 优化的深刻见解，例如上面提到的 Write Once Memory。 它的执行是解释性的，并且由于素数域算术，JIT 编译可能很困难。

工具特定于 CairoVM，其中 Cairo 语言 是编写以 CairoVM 为目标的程序的主要 DSL。 这是该方法在 Ethereum 中将具有的主要缺点。 需要编写新的编译器后端，并且增加了原生素数域原语而不是机器字的难度。 如果没有这些，用户将仅限于 Cairo，尽管在 Starknet 中拥有大型社区，但这将是 Ethereum 的一个限制。

Valida

Valida 是一种新的 ZK 友好的 ISA，旨在支持通过 LLVM 从高级程序进行编译。 Valida 编译器实现了一个新的 LLVM 后端，因此可以执行比 RISC-V 更多的更高级别的编译器优化。

优点和缺点与上面提到的 WASM 路径类似，但更极端。 我们可以将高级程序编译为 ZK 优化的 VM，并执行编译器优化（可能比 WASM 中更多，尽管不确定程度）。 然而，这需要相当多的额外工作，比编写 LLVM 后端的 WASM 方法要多得多。 由于 Valida 支持 Rust，因此它受益于与 Rust 智能合约和社区方面相关的 RISC-V 和 WASM 相同的论点。

执行是解释性的，并且预计在汇编级别上是高效的。 Valida 非常有前景，并显示了在 ZK 证明生成时间方面可以取得的潜在收益 [11]。

PetraVM

PetraVM 也是一种新的 ZK 优化的 VM，但有一个转折：它使用 Binius 证明系统，而不是大多数通用 zkVM 使用的 STARK。 这意味着素数域算术不是问题，因为 Binius 支持 2 的幂作为字大小。 这当然与高级语言和 LLVM 习惯使用的常用机器字大小兼容。 目前可以通过解释器完成执行，JIT 和专用硬件将在未来推出。 ZK 证明生成旨在在专用硬件上进行。

PetraVM 是一种自定义的新 ISA 和 VM，需要编译器。 PetraML 语言正在构建为直接编译为 PetraVM 的 DSL，并且正在构建从 WASM 到 PetraVM 的编译器，以支持高级程序。 与 Valida 类似，PetraVM 通过 WASM 支持 Rust，因此它也受益于与 Rust 智能合约和社区方面相关的相同论点。

ISA 本地定义了 Write Once Memory，这可以在 WASM 侧启用强大的优化，如 WASM 部分中所述。 它还包含“常用”的 ALU/等指令集，基本上是具有 ZK 友好的原语的 RISC-V 的超集。

现在下结论还为时过早，但从纸面上看，PetraVM 对于 Ethereum 的目标听起来也很有希望。

个人结论

下表试图对上面给出的论点进行可视化近似。 请注意，这是基于观点的，并且细致入微，因为相同颜色的所有圆圈并不意味着完全相同的事情，并且我们需要更多的粒度才能完全准确。

RISC-V 仍然是以太坊执行环境未来的主要炒作。 然而，MIPS 似乎具有仅次于 RISC-V 的最佳平均水平，并且可能具有一些优势。 两者都受到现有工具、易用性和简单性的强烈支持。 zkVM 社区中对 RISC-V 的偏好似乎与使用 Rust 而不是 Go 密切相关，因为大量新的加密代码是用 Rust 编写的。 它们不是最 ZK 优化的选项。 但它们必须如此吗？

一种选择是使用一些原语制作一个自定义的 RISC-V 扩展，这将有助于它在 ZK 性能方面与其他 zkVM 匹配。 例如，上面在 WASM 和 PetraVM 部分中提到的原生 Write Once Memory (WOM)。 它提供了一种更便宜的方式来实现 zkVM 中的本地计算，并且可以解决 RISC-V 调用约定问题，以及启用其他优化。

权衡是它需要一个自定义编译器才能利用它。 权衡的权衡是 WASM 非常适合这一点，因为它的编译时堆栈形式分析（RISC-V 没有）可以导致将堆栈和本地变量最佳地分配到这样的 WOM 中。 很有可能最佳的通用 zkVM 路径是通过 WASM 进入自定义 RISC-V 扩展，其中后者也可以实现为 PetraVM 或对现有 RISC-V zkVM 进行相当小的修改。

没有什么是一成不变的，我当然期待看到各个团队在不久的将来所做的所有开发，并为这项工作做出贡献。

待办事项

本文档试图从 Ethereum L1 的角度提供不同 ISA 的主要优缺点的总体概述。 它没有做的是权衡每个指标。 如果需要进行任何更改，选择哪种 ISA 将在很大程度上取决于对 Ethereum 而言重要的是什么。 一旦可用，就可以针对每个项目和 ISA 进行更深入的技术讨论，并牢记特定目标。

我在此明确避免深入讨论的另一个技术讨论是存储在链上的智能合约编码的选择。 此处的不同选择导致在可重现构建和可验证转换方面有不同的要求。 下周三的主题:)

[1] https://ethereum-magicians.org/t/long-term-l1-execution-layer-proposal-replace-the-evm-with-risc-v/23617

[2] https://forum.polkadot.network/t/exploring-alternatives-to-wasm-for-smart-contracts/2434

[3] https://learnblockchain.cn/article/14437

[4] https://forum.polkadot.network/t/announcing-polkavm-a-new-risc-v-based-vm-for-smart-contracts-and-possibly-more/

[5] https://forum.polkadot.network/t/announcing-polkavm-a-new-risc-v-based-vm-for-smart-contracts-and-possibly-more/3811#the-compilation-pipeline-7

[6] https://learnblockchain.cn/article/17610

[7] https://ethereum-magicians.org/t/long-term-l1-execution-layer-proposal-replace-the-evm-with-risc-v/23617/72

[8] https://ethereum-magicians.org/t/long-term-l1-execution-layer-proposal-replace-the-evm-with-risc-v/23617/75

[9] https://ethproofs.org/blocks/22643600

[10] https://forum.polkadot.network/t/exploring-alternatives-to-wasm-for-smart-contracts/2434#ebpf-4

[11] https://www.lita.foundation/blog/keccak-acceleration-chip-and-benchmarks

• 原文链接： hackmd.io/@leoalt/best-i...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～