每个区块链都有自己独特的亮点和叙事，从技术上讲，区块链的代码模块是差不多的，都具有节点通信、共识和执行，但又各自选取了最适合自己的技术和算法，特别是共识算法和执行层的虚拟机技术。这段时间因为以太坊想从 EVM 节点码切换成 RISC-V 指令集让虚拟机这个比较隐秘的技术领域暴露在大众面前。
前两天，我汇编了一篇关于 RISC-V 的科普文章，让大家了解它的过去和未来。
EVM 变 RISC-V？聊聊 RISC-V 的前世今生和 Web3 领域的应用
今天，我希望从更全面的、综合性地跟大家分享一些虚拟机的内容，本人不才，对虚拟机的研究学习不深，取个巧，我从网上将各项目的虚拟机大佬的设计构思或点评做一番混编，让大家可以了解各个虚拟机的异同。
在整理素材时，我感觉这些观点的碰撞特别像中国春秋战略时期的百家争鸣，所以灵机一动，我将他们的表达按现在流行的圆桌会议 / Space 形式整合在一起，呈现一场 “虚拟的圆桌会议” 给大家，突出 “争鸣” 这一动效性，君子和而不同嘛。
为便于快速掌握核心论点，这里通过结构化表格横向对比主流 Web3 虚拟机的关键特性，提炼自全文 10+ 技术领袖的深度讨论。
涵盖 RISC-V、WASM、EVM 等 9 类方案的架构设计、性能表现与落地挑战等：( 左右滑动查看完整表格 )
2024 年以太坊社区关于 RISC-V 替代 EVM 的提案引发激烈讨论，我们虚拟邀请各流派 VM 设计者，从技术本质、生态适配性、ZK 友好性等维度展开交锋……
主持人：首先欢迎 @VitalikButerin[1]，Ethereum 联合创始人，EVM 作为开创性的虚拟机，现在大家都知道了你想有更好的创新，可以和我们讲讲吗？
@VitalikButerin：网友朋友们，你们好！我是 Vitalik，中国网友喜欢叫我 “小 v”（笑～）。大家都知道了我近期发表的 EVM -> RISC-V 的建议提案，大家可以去论坛查看原文[2]（中文版[3]），这里我就不再赘述，只说一些关键的部分：
• 用 RISC-V 取代 EVM，作为智能合约编写的虚拟机语言这一想法虽然有些激进——事实上，这可能是实现这一目标的唯一途径。
• 以太坊 L1 扩展存在几个限制因素中，执行效率是主要的扩展瓶颈之一，我们需要提高效率并显著简化执行层。
• 旧版 EVM 合约将继续运行，并与新版 RISC-V 合约完全双向兼容。有多种实现方式：
• 破坏性最小的方案是同时支持两种虚拟机。
• 更激进的方法是将现有 EVM 合约转换为调用用 RISC-V 编写的 EVM 解释器合约，运行其现有 EVM 代码。
• 通过协议明确支持「虚拟机解释器」概念，要求其逻辑用 RISC-V 编写。EVM 将是首个实例。
• 未来还可支持其他语言（Move 可能是候选方案）。
• 开发体验可能几乎不受影响，开发者甚至可能察觉不到变化。
• Nervos CKB VM 已开创先例，其本质上就是 RISC-V 实现[4]。
主持人：谢谢 @VitalikButerin 向我们分享以太坊的最新计划，我有看到在原贴中有很多人表示支持，也有一部分表示方案有待进一步研究，鉴于本次主题为虚拟机的横向优劣势讨论，我们就不再细说原贴中的一些有关 RISC-V 可行性的细节。当然，我们也邀请了其中一些符合本主题的嘉宾参与下面的话题。
主持人：有请我们今天的第二位嘉宾：@IAmNickDodson[5]，Fuel Network[6] 创始人 & CEO，原 ConsenSys 成员，参与以太坊基础设施和工具的开发，深度参与了以太坊客户端（如 Geth 或 Parity）的优化工作，是一个对 VM 设计和实现很有经验和发言权的一个人。
@IAmNickDodson：首先，Vitalik 的帖子令人振奋。我从以太坊主网上线前就开始接触 EVM，可以明确地说——我们当时就知道它存在缺陷，如今这些问题依然存在。但不可否认，它已成为构建真正去中心化应用的基石，对此我们心怀感激。 [src[7]]
主持人：请问为什么你们选择开发 FuelVM 而不是采用其它已有方案呢？
@IAmNickDodson：在设计 FuelVM 时，我们研究了多种架构： 指令集架构 (ISA)：MIPS、RISC-V、x86、ARM，虚拟机方案：WASM ，以及区块链专用 VM：EVM、BitcoinScript、MoveVM、SVM 等等。它们各自都有亮点，但都无法完全满足我们的需求，等下我会谈谈我对这些选型的一些分析结论和思考。在那之前，我希望屏幕前的你也一并思考这三个核心问题： 该架构是否专为区块链场景设计？ 在对抗性计量环境下能否保持性能？ 相比 EVM 是否真正实现了改进？ [src[8]]
主持人：好的，感谢以上嘉宾的自我介绍，接下来我们依据 @IAmNickDodson 的研究顺序挑选出一些具有代表性的 VM 项目 / 技术，请各位说说你们的看法和分析，如果有不同观点也请随时参与进来。
MIPS/RISC-V
@IAmNickDodson：这些 CPU 指令集最初为早期微芯片和嵌入式设备设计
优势是：架构简单、文档完善、开源生态、可编译为原生机器码（有时需额外处理）和多语言支持（Rust/Go 等）。
劣势是：本质是 CPU 指令集（非虚拟计算架构），MIPS 指令集过于基础，完成 x86 或专用 VM 单条指令的功能需要更多操作码（见后文 CISC 部分） 、未考虑对抗性 Gas 计量、未针对区块链场景优化、零知识证明处理效率较低（参考 Starkware/Valida 的研究）。
即便 ZK 技术能降低节点计量需求，高吞吐场景下仍需预计算 / 共享证明，此时仍需抗 DoS 机制（计量仍有价值）。 [src[9]]
Georgios Konstantopoulos[10]（Paradigm[11] 合伙人兼 CTO）如果您喜欢 @VitalikButerin 的提案，那么您一定会喜欢我们在过去几个月里慢慢开发的这个 R55[12]… [src[13]]
0xpedro.eth/acc[14]：R55 允许您使用纯 Rust 编写智能合约，并通过 RISC-V 在以太坊客户端中执行。通常，Solidity 会编译为 EVM 字节码，但 R55 会将 Rust 编译为 RISC-V 指令，这是一个可以释放硬件优化潜力的开源框架。在以太坊上使用 Rust？有趣但棘手。RISC-V 本身并不了解以太坊的状态（存储、调用等），因此 R55 添加了系统调用。使用 RISC-V 的 ecall，Rust 合约可以读取存储（例如 SLOAD）、调用合约或发送日志——从而无缝地将 Rust 与以太坊连接起来。
R55 仍在开发中，需要对 gas 和安全性进行调整，但未来令人兴奋：rollup 或应用链可以运行原生 Rust 合约，或者 zkEVM 可以利用 RISC-V 进行加密操作。在我看来，Rust 的安全性和速度使其成为以太坊的利器。R55 能否为以太坊带来一波 Rust 开发者浪潮？或许现在还为时过早，但值得一看。[src[15]]
Dave Rauchwerk[16]：@VitalikButerin 这是一个很棒的想法。RISC-V 的一个关键优势是其明确的可扩展性。我们应该研究定义一组定制的 RISC-V 指令，专门用于加速核心的、性能至关重要的 EVM 操作码。RISC-V 的开放特性允许在通用 CPU 执行之外使用专用硬件实现（ASIC、FPGA）。这为通过直接在硅片中加速核心 EVM 逻辑，显著提升 L1 TPS 提供了途径，其速度可能比当前的软件解释或 JIT 方法快几个数量级。
可验证性和安全性：与复杂的传统 ISA 相比，RISC-V 的模块化和简洁设计使其更易于形式化验证。经过形式化验证的 RISC-V 核心执行 EVM 逻辑，可以提供更强大的运行时行为保障，这对于保障高价值智能合约的安全至关重要。RISC-V 可能通过以 EVM 为中心的自定义指令得到增强，为实现更高性能、更安全、更可扩展的 Layer 1 提供了一条引人注目的途径。
另外，将现有的 EVM 实现与潜在的 RISC-V 软件模型进行基准测试。revive/PolkaVM 看起来很棒 – 它目前仅针对 RV32EM，值得讨论。[src[17]]
Koute[18]（Parity Technologies[19] PolkaVM 的负责人）：正好提到了 PolkaVM，那我就详细解释一下 PolkaVM 是什么以及它的工作原理。
PolkaVM 目前支持带有 Zbb 扩展的 riscv64emac，但与大多数（所有？）其他 RISC-V VM 不同，它不能按原样运行 RISC-V 二进制文件（它实际上不是 RISC-V VM！）。离线时，我们会提取您使用普通编译器构建的普通 RISC-V ELF 二进制文件，然后将其转换为更受约束、更高效的自定义字节码，该字节码专为 VM（而不是像 RISC-V 那样的原生硬件）使用而设计。我们的想法是尽可能地消除 VM 本身的复杂性（需要在链上运行），将尽可能多的复杂性放入离线工具（可以在链下运行），并通过删除不必要的功能来提高安全性（例如，在原始 RISC-V 中，您可以跳转到任何地址；在 PolkaVM 字节码中，代码地址空间是完全虚拟化的，您无法跳转到任何地方，并且字节码甚至不会加载到程序可访问的内存中）。
性能方面，我们非常接近裸机性能[1]；它与最先进的 WASM VM 一样快 *，wasmtime 但保证了 O(n) 的重新编译时间，并将程序重新编译为本机代码的速度提高了数百倍。具体来说，从原始 PolkaVM 字节码开始将程序重新编译为本机代码，比缓存重新编译的工件并根据其哈希值查找要快得多（换句话说，重新编译程序比计算其哈希值更快），而且这还不会 * 牺牲运行时执行性能。
我们主要使用 RISC-V 并不是因为它对于 VM 来说是一种特别好的字节码（实际上它并不是那么好），而是因为它简单、支持良好并且相对容易转换为其他东西，所以我们可以兼得两全其美——出色的软件兼容性（您可以使用现有的编译器和编程语言，例如前几天我将 Quake 移植到 PolkaVM），但您也可以获得自定义、优化的字节码的好处（极快的编译速度、接近原生的性能、简单性和可定制性）。[src[20]]
dilrong[21]：@VitalikButerin 声称，用 RISC-V 替换以太坊虚拟机 (EVM) 可以将零知识 (ZK) 证明的效率提高 50 到 100 倍。然而，RISC-V 真的更胜一筹吗？EVM 已经稳定运行了大约九年，是一个久经考验的平台，而 RISC-V 在区块链执行环境中缺乏丰富的实际经验。虽然 PolkaVM 已经采用了 RISC-V，但我认为它尚未得到充分验证，因为它尚未在主网上得到彻底验证。
EVM 专门针对智能合约执行进行了优化，而 RISC-V 则设计为通用架构，可能缺乏针对区块链用例的定制优化。虽然 RISC-V 的多功能性允许使用其他区块链的编程语言，但 Vitalik 本人指出，利用现有 Solidity 进行改进更为可取。将整个生态系统过渡到新的架构是一项艰巨的挑战。
在软件中实现 RISC-V 不可避免地会导致性能下降。使用模拟器进行基于软件的执行会引发对其高效处理任务能力的质疑。另一方面，采用 RISC-V 硬件将带来巨大的过渡成本。我认为 ZK-EVM 已经能够满足当前需求。考虑到开发成本、过渡所需的工作量以及不可预见的错误的可能性，用 RISC-V 替换 EVM 似乎并非一个可行的方案。
虽然过渡到 RISC-V 可能会带来潜在的好处，但我认为改进 ZK-EVM 和优化现有的 EVM 是更实用、更稳定的替代方案。[src[22]]
Eduardo Bart[23]（Cartesi[24]’s VM Core Developer）：作为积极参与开发用于区块链应用的 RISC-V 虚拟机 Cartesi Machine[25] 的开发者，我想分享一些支持 RISC-V 在以太坊执行层探索方面的观点。
我认为采用 RISC-V 的最大优势之一是可以立即访问成熟的工具和生态系统。无需构建完全定制的环境，使用 RISC-V 可以让开发人员（以及核心协议）充分利用 GCC 和 LLVM 等编译器、调试器、库，甚至 Linux 等完整操作系统数十年来积累的经验。与较新、缺乏实践检验的工具链相比，这显著降低了开发人员的门槛，并可能降低编译器 bug 带来的风险。这与允许使用 Rust 甚至 C++ 等语言编写的合约通过标准后端编译，以以太坊为目标的目标非常契合。对于那些质疑 LLVM 或 GCC 中 bug 的人来说，使用 CompCert[26] 等经过形式化验证且目前能够以 RISC-V 为目标的编译器来增强安全保障是可行的。从更大角度考虑，甚至可以在涵盖 RISC-V 特权 ISA 规范的虚拟机（例如我正在开发的虚拟机）上，在经过正式验证的 RISC-V 操作系统内核（例如 seL4[27]）上运行应用程序，这对于要求在操作系统环境中运行的更复杂的应用程序来说是一种可能性。
一些人提出的性能担忧并非空穴来风，但可以解决。根据我的经验，RISC-V 在正确实施的情况下并不会牺牲执行性能。虽然 u256 操作自然会分解为多条指令，但在实践中，在经过良好优化的 RISC-V 虚拟机中，在大多数情况下，这样做的成本应该不会对性能造成太大影响。此外，虚拟机级别的优化技术可以显著降低这些成本，因为 RISC-V ISA 具有足够的可扩展性，可以添加针对区块链的自定义扩展，从而优化常见的加密操作（例如 Keccak256）。
我认为，将未来的执行层建立在像 RISC-V 这样标准化、开放且支持良好的 ISA 之上，将提供坚实的基础。它提供了一条利用现有软件生态系统的途径，有可能简化开发人员的体验，并受益于 RISC-V 领域未来硬件的进步。
虽然道路复杂，但我相信，RISC-V 在可扩展性、工具成熟度和长期可维护性方面的潜在优势，使其成为未来区块链执行环境非常值得追求的方向。目前，区块链领域中许多现有的 RISC-V 虚拟机证明了，稳健且可立即投入生产的 RISC-V 实现是可以实现的。具体来说，我认为 Cartesi Machine 展现了利用标准开放 ISA 的强大功能。它是一款稳定、高性能的 RISC-V 模拟器，实现了标准的 RV64GC ISA，能够运行整个 Linux 软件栈和未经修改的 RV64GC ELF 二进制文件。至关重要的是，它完全确定性，甚至包括浮点运算。对于那些好奇并想了解它运行能力的人，我推荐使用我的 WebCM[28] 实验进行实验，这是一个无服务器终端，通过模拟由编译为 WebAssembly 的 Cartesi Machine 模拟器驱动的 RISC-V 机器，直接在浏览器中运行虚拟 Linux。
目前，L1 提案专注于零知识证明，而 Cartesi 目前则通过交互式欺诈证明、利用确定性执行和状态 Merkle 证明来实现链上验证。尽管验证机制有所不同，但 Cartesi 确认，在 RISC-V 之上构建一个可验证且确定性的执行环境是可行且值得的。
当然，将 RISC-V 直接集成到 L1 并进行零知识证明会带来独特而重大的挑战，尤其是在 Gas 计量、定义状态交互的精确系统调用以及针对 RISC-V 指令优化零知识电路方面。在零知识证明的特定环境下的性能也需要深入研究。幸运的是，许多 RISC-V 零知识虚拟机项目已经在针对这些方面进行研究和开发。
关于实施策略，我认为应该认真考虑一种“激进的方法”，即定义一个协议，将编译为 RISC-V 的虚拟机解释器的概念融入其中。这种方法将开辟一条道路，使以太坊的核心 RISC-V 虚拟机能够保持最小化和简单化，同时仍然足够灵活，能够容纳 EVM 之外的不同虚拟机解释器，从而为开发人员在虚拟机开发中提供更多自由。
简而言之，我相信利用像 RISC-V 这样的标准在工具、开发人员熟悉度、灵活性，甚至长期硬件加速的潜力方面都具有巨大的优势。我使用 Cartesi Machine 的工作经验强化了这样一种观点：RISC-V 是下一代可验证区块链计算的强大且可行的基础。看到它被认真考虑用于以太坊的核心执行层，我感到十分兴奋。[src[29]]
Xuejie Xiao[30]：大家好，我是 Nervos CKB-VM 的原始设计者和现任维护者。在 Nervos 看来，选择 CKB-VM 完全出于第一性原理的思考：我们想要的是一个简单、安全、快速的沙盒，并且尽可能轻量地运行在商用 CPU 上。事实证明，CPU 指令集才是最佳选择，而 RISC-V 则在其他选择中脱颖而出，当然还有其他开源 RISC CPU 内核，但在我们看来，RISC-V 是最受关注的，这意味着会有更多人参与开发工具链。对我们来说，这将是一个巨大的优势。
当我们讨论 EVM 与 RISC-V 时，我建议我们更进一步，要么比较两者都包含预编译，要么比较两者都不包含预编译的优缺点。我们不要将包含预编译的 EVM 与不包含预编译的 RISC-V 进行比较，或者反过来，在我看来，这种比较并不恰当。假设使用 JIT 或 AOT RISC-V 实现，或者引入 AVX 指令，我们可能获得与使用无预编译 RISC-V 虚拟机的 EVM 相当的性能。
据我们所知，RISC-V 是 7 年前的最佳解决方案，在可预见的未来，它仍然是我们认为的最佳解决方案。如果有人说 RISC-V 是硬件解决方案，那就这样吧，我们已经通过纯软件实现了它，并且它仍然完美地满足了我们的需求。从这个意义上讲，我们对目前的情况感到满意，并将继续沿着这条道路前进。[src[31]]
主持人：CKB-Virtual Machine（CKB-VM）是一个基于 RISC-V 指令集的虚拟机，用于在 Nervos CKB 上执行智能合约，用 Rust 编写。大家有兴趣可以看 2018 年时 @Xuejie Xiao 发表的文章：An Introduction to Nervos CKB-VM[32]，看看他们那时候的思考，很棒的分享！
ZKM[33]: @VitalikButerin 为以太坊制定的 RISC-V 计划非常大胆，但 MIPS 的成熟度和传统使其成为一匹引人注目的黑马——一套非常适合低延迟 ZK 证明的固定指令集。 MIPS 已经运行了 40 年的关键系统—— Ethereum 可以利用这种稳定性，实现类似（甚至更优）的效率提升，同时降低采用像 RISC-V 这样被过度炒作且仍在成熟的 ISA 的风险。既然 MIPS 已经得到验证，为什么还要押注 RISC-V 的成长阵痛呢？[src[34]]
WebAssembly (WASM)
@IAmNickDodson：专为浏览器 / 隔离环境执行任意代码设计：优势：多语言 / 环境支持、可编译为原生代码、开源规范清晰、后期加入了计量功能（但带来额外开销），劣势：基于堆栈架构（学术研究认为性能较低，但需辩证看待）、非区块链专用设计、计量功能是后期补丁，影响性能、调试体验极差。
理论上 WASM 是不错的选择，但实际开发中调试极其痛苦。与我们交流的多个 All in WASM 的团队都表示后悔。相比之下 RISC-V/MIPS 更易理解，这或许正是 Succinct/RISC0 等团队选择它们的原因。 [src[35]]
Peter Kieltyka[36]（Sequence[37] 联合创始人）：@VitalikButerin 我知道这有点牵强，但不妨考虑一下 Offchain Labs 团队开发的 EVM+/Stylus 作为未来的 L1 执行层。它完全兼容 EVM 字节码，可在 WASM VM 中运行，并且支持任何支持 WASM 的语言（例如 Rust），性能显著提升，同时在运行时保持与 EVM 字节码合约的完全互操作性。感觉这是在保持兼容性的同时最简单的升级路径。[src[38]]
Xuejie Xiao[39]：许多人认为 WASM 是区块链虚拟机的理想选择，主要是因为 WASM 是为软件实现而设计的（如果这说得通，我们先忽略它）。您是否知道，在 WASM 诞生之前，JavaScript 的一个子集 asm.js 曾一度流行？asm.js 后来演变成了 WASM，并且不知何故变得比 asm.js 最初的愿景要庞大得多（恕我直言，现在 WASM 看起来更像是一个干净、全新设计的 JVM，而不是 asm.js）。但我们不要忘记 asm.js 最初的目标：人们渴望一个能够确定性地映射到原生 CPU 指令的软件 IR，而不是 90% 时间都能够做到的 JIT。如果 RISC-V 能够实现这样的目标，我认为它非常适合用作软件虚拟机。[src[40]]
Hazel Hu[41]（Delphinus Lab[42]）：虽然 @VitalikButerin 力挺 RISC-V，但 ZK 虚拟机不是只有这一条技术路线。ZK 虚拟机也不是 ETH 的专属，它是一个独立的可能比 ETH 生态更大的东西，ETH 需要 ZKVM，ZKVM 却并不局限于以太坊生态。[ src[43]]
ZK 系统使用 RISC 即精简指令集，这里又有两种选择，第一种是 Cairo 这样的 ZK 特定语言自建一个自定义的指令集（学习曲线过于陡峭），第二种是使用现有的指令集。RISC-V 就是其中之一。@RiscZero[44] , @SuccinctLabs[45], @NexusLabs[46] 和 @a16z[47] 支持的 Jolt 这几家都是基于 RISC-V 的 ZK 虚拟机项目。
早在 2018 年，以太坊生态就启动了 eWASM 项目，EVM 的发明者 @gavofyork[48] 曾表示过 WASM 取代 EVM 的可行性，Polygon 创始人 @sandeepnailwal[49] 也一直是 WASM 的坚定支持者。然而，eWASM 最终未被广泛采用，原因包括工程复杂性、优先级调整以及 L2 方案的兴起，在后续发布的路线图中，eWASM 被搁置。
@VitalikButerin 发布提案后，Zebra 创始人@shumochu[50]，1kx 研究合伙人 @_weidai[51] 等人都指出，WASM 也许比 RISC-V 更适合以太坊执行层，原因如下：
流程更简便：RISC-V 设计初衷是用于硬件实现，而不是作为中间表示。如果用作以太坊合约的执行层，仍需构建一个虚拟机层来处理 gas 消耗和控制执行流程，这增加了复杂性。
静态分析友好：WASM 没有跳转指令，代码结构简单，易于验证合约属性。
语言支持广：开发者可以用目前几乎所有主流编程语言编写程序编译为 WASM，学习成本大大降低。 Miden 创始人 @bobbinth[52] 进一步建议，如果追求 ZK 友好性，可以设计比 RISC-V 更优的指令集，或者用 WASM 组件模型。[src[53]]
我所在的 @Delphinuslab[54] 就开源了业界第一个 ZKWASM 虚拟机，虽然目前还只有 solidity 的 SDK，但实际上，ZKVM 的合约结算可以去任何链上，未来也完全可以拓展到 Solana, Sui 等等 EVM 异构链上。
ZKWASM 虚拟机到底可以有什么用？
1. 让更多的开发者使用自己最熟悉的编程语言进入区块链世界，不用强迫每个人学 Solidity（和更复杂更小众的区块链语言）或者 Rust
2. 让更多 Web2.5 网页小程序可以实现一键上链，如果完全跑通，数以千计的浏览器小程序都可以快速部署到区块链上
3. 打破不可能三角，实现去中心化、效率、安全的平衡。[src[55]]
x86/ARM
@IAmNickDodson：这两大 CPU 指令集均非开源： ARM 属于 RISC 精简指令集，x86 属于 CISC 复杂指令集。随着 CPU 硬件演进，二者都变得极其复杂。值得注意的是，虽然 CISC 因复杂性在 CPU 领域逐渐被 RISC 取代，但在区块链场景中 CISC 反而更具优势。 [src[56]]
Xuejie Xiao[57]：x64 太过重量级（当我们第一次尝试 RISC-V 时，居然有人正在使用 x64 构建区块链虚拟机！），而 Arm 可能存在许可问题，也可能不存在。[src[58]]
Bitcoin Script
@IAmNickDodson：首个区块链 VM，专为比特币编程设计：
优势：专为区块链和比特币交易模型打造、适应对抗性环境、支持多签等基础操作
劣势：功能极其有限、受比特币网络处理能力严重制约。
我们从 Bitcoin Script 继承了 P2SH（支付到脚本哈希）这一强大范式——条件编程。这种可修剪的程序范式（执行后可从全节点删除）能支持：场外交易 / 多签钱包 / 商品拍卖等丰富场景。比特币架构启示我们：VM 设计必须与交易模型深度协同。 [src[59]]
MoveVM
@IAmNickDodson：由 Meta 团队开发的区块链专用 VM，强调安全性：
优势：区块链原生设计、对抗性计量支持、配套专属语言 Move
劣势：为实现安全牺牲了大量状态灵活性、过度 RISC 化（见前文分析）、生态分裂（SUI/Aptos 存在不兼容变种）。
2020-21 年 Move 生态几乎停滞。我们放弃采用是因为不愿受制于无法创新的他人架构，且其 “安全” 特性更多是 RISC 系统的包装，并不能阻止糟糕的代码编写。当时的形式化验证仅适用于简单方法而非完整应用，性价比极低。 [src[60]]
EVM
@IAmNickDodson：堪称区块链界的 PHP，支撑着数千亿价值的智能合约：
优势：区块链原生设计、完善的计量机制、全生态兼容、Solidity 语言久经考验
劣势：256 位字长设计、仅支持调用 / 合约，缺乏脚本功能、缺少条件编程（无 P2SH 等价物）、基于过度简化的交易模型、效率低下（字长和操作码设计导致大量计算浪费）、高度状态化设计导致存储访问成为性能瓶颈。
虽然有些团队声称通过新型数据库或状态访问方案解决了问题，但本质上这些计算本可避免。EVM 适合快速建立生态，但从交易模型和设计空间角度看缺乏创新。Vitalik 的喊话或许正是意识到这一点。 [src[61]]
Alex Vlasov[62]：RISC-V 是否真的比 EVM 更好尚不清楚。EVM 基于堆栈，因此其寄存器文件很小。EVM 操作的是 256 位数字，如果小得多的值占主导地位，这可能会成为一个问题。然而，证明器可以访问实际的执行轨迹，因此它可以为较小的值选择更轻量的实现选项（例如，32 位值的字节分解占用的行数比 256 位值的字节分解占用的行数要少）。[src[63]]
另一个方面是智能合约形式化验证的成本。EVM 的指令集 (ISA) 比 RISC-V 更有限，因此 F/V 总体上会更复杂。RISC-V 智能合约通常会包含更多循环和更多内存操作，而这两者都会给 F/V 带来问题。
例如，一项研究 (/www.cs.utexas.edu/~isil/solis.pdf[64]) 表明，大约五分之一的 EVM 智能合约包含一个或多个循环。由于 EVM 操作的是 256 位值，因此在 RISC-V 代码中需要更多循环。即使循环展开，也会导致更大的 SMT 查询。
RISC-V 拥有更丰富的内存模型，应该会有更多的内存操作（例如，EVM 拥有 1024 个 256 位堆栈，而 EVM 则拥有 16-32 个 32/64 位寄存器）。因此，混叠（两个语法上不同的表达式指向同一内存位置）将是一个更严重的问题。这反过来会影响静态分析，例如调用图重构、指向分析等。
我预计，与 EVM 智能合约相比，对存在循环 / 混叠的 RISC-V 智能合约进行形式化推理将更具挑战性。[src[65]]
SVM
@IAmNickDodson：Solana 虚拟机近年崛起：
优势：区块链原生设计、对抗性计量支持、可编译为原生代码、高性能设计
劣势：架构复杂难懂、Rust 等语言开发体验差、缺乏成熟的专属语言。
我们未选择 SVM 主要因其交易模型假设——类似以太坊的简单设计更追求速度而非复杂多方结算，这与我们规划的交易模型不匹配。 [src[66]]
CarioVM
Akash Balasubramani（StarkWare 生态经理）：@IAmNickDodson 精彩分析！要是能包含 CarioVM 就更好了。[src[67]]
@IAmNickDodson：未包含只是因为 2020/21 年调研时它尚未进入我们视野。我是 Cairo 和 STARK 技术的忠实粉丝。 [src[68]]
Eli Ben-Sasson（StarkWare 联合创始人）： @IAmNickDodson 绝佳的讨论！唯一建议是加入 Cairo 分析。我来试补充： 优势：专为区块链 +zkSTARK 效率设计、线性类型安全、高效的 Gas 计量（Sierra），劣势：知名度 / 工具链完善度较低 🙂 [src[69]]
主持人：感谢大家的精彩点评，最终你们的结论是什么呢？有哪些洞见是可以分享给我们大家的呢？
@IAmNickDodson：研究所有 VM 后我们意识到：虚拟机本身的重要性被高估了。理论上这些 VM 都能（除 BitcoinScript 外）以不同效率完成所需计算。真正关键的是 VM 与交易模型的协同设计。许多链过度关注 VM 却忽视交易模型——这才是区块链行为的核心。 [src[70]]
FuelVM 的独特之处正在于此，这些是 FuelVM 的复合优化 [src[71]]：
• 内存效率（共享内存上下文减少拷贝）
• 寄存器与内存的智能利用（如将完整交易置于可视内存实现运行时自省）
• 极致减少 IO 访问
• 强化交易层能力（让交易承担更多，VM 承担更少）
• 交易模型兼具状态访问与多资产 / 多条件 / 多执行模式流转能力
• CISC 与 RISC 的黄金平衡
• 无全局状态树（UTXO 模型通过时间回溯天然防双花）
• 所有操作码为计量效率优化
• 支持谓词条件编程等多样化程序类型
• 配套 Sway 语言兼具 Rust 性能与 Solidity 开发体验
传统认知认为区块链 VM 应追求极简指令（出于安全和原生代码编译考虑）。但问题在于：乐观验证场景下每个操作都需计量。VM 越简单，实现相同功能所需操作码越多，链上计量计算量就越大。因此 FuelVM 选择设计更多高效操作码——用更少操作完成更多功能。你可以将 FuelVM 视为 CISC 与 RISC 的融合体。虽然更多指令通常意味着字节码体积增大（在带宽受限场景会有影响，但压缩可缓解），但这能显著降低乐观验证的计量开销，为开发者提供更强大的工具。即便在 ZK 场景，复合操作也能获得更好的优化效果。简单 ≠ 更好。[src[72]]
主持人：有想对其他 VM 技术选型的工程师说的吗？比如以太坊 🙂
@IAmNickDodson：如果以太坊选择 RISC 路线，必须同步考虑交易模型。VM 只是拼图的一部分——RISC-V 无法解决代币核算、突破智能合约范式、构建支撑全人类与机器人的高性能区块链应用等问题。Fuel 选择做正确而非流行的事，这意味着持续的痛苦（看看我们的代币就知道），但也为开源区块链生态提供了新的设计范式。
如果你正在考虑构建区块链，并需要深度契合区块链本质的架构，FuelVM/Sway 值得考虑。性能表现更是疯狂：M4 处理器上 15 万 TPS，10 毫秒软确认，从烤面包机到超算都能运行。你可以了解更多有关 FuelVM 的信息：Why the FuelVM is the EVM but greatly improved and what this means for the future of blockchain[73]
Xuejie Xiao[74]：关于 ZK 的另外一点，首先，这只是我个人对零知识的看法，RISC-V 有两种与零知识相关的不同用例：1）用于表达将被 ZK 证明的程序的虚拟机 /IR，2）ZK 验证器运行的底层平台。一个简单但不准确的类比是，在零知识证明算法之上有一个虚拟机（要点 1），在零知识证明算法之下也 有一个虚拟机（要点 2）。它们应该分开讨论。
Nervos CKB-VM 采用严格的无预编译设计，完美契合了第二点：你可以将 ZK 验证器代码编译为 RISC-V 代码，并在 Nervos CKB-VM 上运行该 ZK 验证器。从这个意义上讲，Nervos CKB 将能够灵活地支持任意的 ZK 解决方案。换句话说，我认为 Nervos CKB-VM 是 ZK 算法下的虚拟机 (VM) 的不错选择。
第一条将作为一个单独的用例，我对零知识证明的内部机制不太熟悉，因此无法判断 RISC-V 是否是一个合适的解决方案。我怀疑零知识证明算法的某些特性可能会影响在零知识证明算法之上构建虚拟机的选择。
我可能错了，但我感觉 @VitalikButerin 可能在这里谈论的是第 2 点，或者是 ZK 算法下的适当 VM ，所以也许我们不必讨论 RISC-V 是否适合 ZK 证明？
porter | ZKsync[75]：ZKsync 已准备好进行以下更改： 新的证明系统 Boojum2 已经是 RISC-V，有一些事情将使整个以太坊（不仅仅是 ZKsync）受益： 全新 Solidity – > LLVM – > RISC-V 编译器即将推出。[src[76]]
@alacheng[77]: ZK 方向的（如果扩展 L1 在节点验证时无需重新执行 那么这几个 zkvm 的将替代 zkevm），@SuccinctLabs[78] 和 @RiscZero[79] 都是 zk risc-v vm, @UntoLabs[80] sol 生态的一个核心开发者出来做的链 ，执行层 vm 是 risc-v vm。 [src[81]]
主持人：非常感谢各位大佬的精彩分享，本次 “虚拟圆桌会议” 就到此结束了。因时间和篇幅原因，还有很多特色的虚拟机我们不能一一引荐了，可能未来我会再继续更新或增加第二场。各位观众如需了解详情，可点击每个观点 / 发言结尾处的 [src]。
总结
在这场 “虚拟圆桌会议“ 中，我们看到不同区块链项目选择了截然不同的技术路线——EVM 追求生态兼容，RISC-V 专注硬件效率，WASM 拥抱多语言开发，MoveVM 强调资产安全，FuelVM 则突破性能极限。这恰恰说明，在区块链的世界里，没有放之四海而皆准的最优解，只有最适合自身发展目标的权衡取舍。
通过这场技术辩论，我们得以窥见：
• 以太坊选择保守升级，是因其生态价值优先
• Nervos 拥抱 RISC-V，源于对硬件友好的极致追求
• Aptos/Sui 押注 MoveVM，体现对安全性的偏执
• Fuel 另辟蹊径，用混合架构突破性能瓶颈
这些选择背后，是各团队对”区块链应该是什么”的不同答案。理解这些技术决策的逻辑，或许比争论孰优孰劣更有价值——它让我们看到这个领域真正的多样性，也预示着 Web3 未来可能呈现的百花齐放格局，很精彩，不是吗？
免责声明
本文内容为公开技术讨论的汇总与重组，旨在对当前主流 Web3 虚拟机技术进行客观对比与分析。文中提及的所有项目、技术方案及产品（包括但不限于 EVM、RISC-V、WASM、MoveVM、FuelVM 等）均基于开发者社区公开讨论内容整理，仅代表相关发言者的个人观点，不代表本文作者或发布平台的立场。
读者须知：
1. 技术中立性：本文对虚拟机的讨论仅限技术层面，不构成对任何项目、代币或产品的背书或推荐；
2. 时效性说明：区块链技术迭代迅速，文中信息基于 2025 年公开资料整理，实际发展可能已发生变化；
3. 风险提示：加密货币及区块链项目存在市场风险、技术风险与监管不确定性，请读者务必自行研究并谨慎决策；
4. 非投资建议：本文内容绝不构成任何形式的投资建议，所有技术分析不应作为投资依据。
区块链技术仍处于快速发展阶段，任何技术选型都需结合具体应用场景评估。我们鼓励读者通过项目官方文档、审计报告等一手信息进行独立判断。
版权声明
本文内容系根据互联网公开资料（包括但不限于技术论坛、社交媒体、开发者文档等）进行采集、汇总及重组而成。为保持行文连贯与可读性，编者对原始内容进行了以下处理：
1. 内容编辑：包括但不限于观点摘录、语句提炼、段落重组及必要的断章取义，部分内容可能存在上下文缺失；
2. 语言转换：涉及中英文互译的内容可能存在语义偏差或表达差异，非逐字直译；
3. 技术简化：部分专业术语或技术描述已作通俗化处理，可能损失原始精度。
重要说明：
• 所有观点及技术论述的最终解释权归原作者所有，请以每个观点结尾标注的[src]原始链接内容为准；
• 本文未经提及的项目方、技术团队或发言者事前授权，仅作为技术讨论的公益性整理；
• 若内容存在表述不当、版权争议或侵权嫌疑，请联系 @OpenBuildxyz[82] 及时告知，我们将第一时间核实并修正。
本文遵循合理使用（Fair Use）原则，旨在促进区块链技术知识的传播与讨论，不用于任何商业用途。引用时请注明原始来源并遵守相关版权法规。