Vitalik vs Top Developers: A <Virtual Roundtable> on the Web3 Virtual Machine Debate
TechFlow Selected TechFlow Selected
Vitalik vs Top Developers: A <Virtual Roundtable> on the Web3 Virtual Machine Debate
EVM pursues ecosystem compatibility, RISC-V focuses on hardware efficiency, WASM embraces multi-language development, MoveVM emphasizes asset security, while FuelVM pushes performance to the limit.
Navigating Web3 tides with focused insightsEach blockchain has its unique highlights and narratives. Technically, the code modules of blockchains are largely similar, all featuring node communication, consensus, and execution. Yet each selects the most suitable technologies and algorithms for itself—especially consensus algorithms and virtual machine technologies at the execution layer. Recently, Ethereum's attempt to switch from EVM bytecode to the RISC-V instruction set has brought this relatively obscure technical domain of virtual machines into public view.
A couple of days ago, I compiled an introductory article about RISC-V to help readers understand its past and future.
From EVM to RISC-V? Exploring the Origins and Applications of RISC-V in Web3
Today, I hope to share a more comprehensive and holistic perspective on virtual machines. I must admit my own research on virtual machines is limited, so I’ll take a shortcut: I’ve compiled and restructured design ideas and comments from leading figures across various projects online, allowing everyone to understand the differences and similarities among these virtual machines.
While organizing the material, I found these clashing viewpoints reminiscent of the “Hundred Schools of Thought” during China’s Spring and Autumn period. Inspired, I’ve integrated their expressions into a fictional roundtable discussion / Space format, presenting a “virtual roundtable” that emphasizes dynamic intellectual debate—after all, gentlemen seek harmony without uniformity.
To facilitate quick understanding of core arguments, here is a structured table comparing key characteristics of mainstream Web3 virtual machines, distilled from in-depth discussions by over 10 technical leaders throughout the text.
Covers architectural design, performance, and implementation challenges across nine types of solutions including RISC-V, WASM, EVM, etc.: (Swipe left/right to view full table)
In 2024, a proposal within the Ethereum community to replace EVM with RISC-V sparked heated debate. We virtually invite designers from various VM schools to engage in a technical clash across dimensions such as fundamental principles, ecosystem compatibility, and ZK-friendliness…
Host: First, welcome @VitalikButerin[1], co-founder of Ethereum. The EVM, as a pioneering virtual machine, is well known. As many know, you’re exploring further innovation—could you share your thoughts?
@VitalikButerin: Hello internet friends! I’m Vitalik; Chinese netizens like to call me "Little V" (smile~). Many are aware of my recent proposal suggesting EVM → RISC-V. You can read the original post[2] (Chinese version[3]) for details—I won’t repeat them here, just highlight key points:
• Replacing EVM with RISC-V as the virtual machine language for smart contracts may seem radical—but in fact, it might be the only viable path toward this goal.
• One of several limiting factors for Ethereum L1 scalability is execution efficiency, which remains a major bottleneck. We need higher efficiency and significantly simplified execution layers.
• Legacy EVM contracts will continue running, fully bidirectionally compatible with new RISC-V contracts. Multiple implementation approaches exist:
• The least disruptive option supports both virtual machines simultaneously.
• A more radical approach converts existing EVM contracts into calls to an EVM interpreter contract written in RISC-V, executing their current EVM code.
• Explicitly support the concept of a "virtual machine interpreter" in the protocol, requiring its logic to be implemented in RISC-V. EVM would be the first instance.
• Other languages could also be supported in the future (Move might be a candidate).
• Developer experience may remain almost unchanged—developers might not even notice the difference.
• Nervos CKB VM has already set a precedent, being essentially a RISC-V implementation[4].
Host: Thank you @VitalikButerin for sharing Ethereum’s latest plans. Your original post received strong support, though some commented that the proposal needs further study. Since today’s topic focuses on comparative advantages and disadvantages of VMs, we won’t delve into RISC-V feasibility details discussed there. However, we have invited other relevant guests aligned with our theme to join the conversation.
Host: Let’s welcome our second guest today: @IAmNickDodson[5], founder & CEO of Fuel Network[6], former ConsenSys member involved in Ethereum infrastructure and tool development, deeply engaged in optimizing Ethereum clients (like Geth or Parity)—a seasoned expert with authority on VM design and implementation.
@IAmNickDodson: First, Vitalik’s post is exciting. I’ve been working with EVM since before Ethereum mainnet launch, and I can say definitively—we knew back then it had flaws, and those issues persist today. Nevertheless, it has become the cornerstone for building truly decentralized applications, and we’re grateful for that. [src[7]]
Host: Why did you choose to develop FuelVM instead of adopting existing solutions?
@IAmNickDodson: When designing FuelVM, we studied various architectures: Instruction Set Architectures (ISA): MIPS, RISC-V, x86, ARM; virtual machine schemes: WASM; and blockchain-specific VMs: EVM, BitcoinScript, MoveVM, SVM, etc. Each has strengths, but none fully met our requirements. Later I’ll share my analysis and reflections on these options. Before that, I encourage viewers to consider three core questions: Is the architecture specifically designed for blockchain scenarios? Can it maintain performance under adversarial metering conditions? Does it genuinely improve upon EVM? [src[8]]
Host: Great, thank you for the introductions. Now, following @IAmNickDodson’s research order, let’s examine some representative VM projects/technologies. Please share your views and analyses, and feel free to jump in with differing opinions.
MIPS/RISC-V
@IAmNickDodson: These CPU ISAs were originally designed for early microchips and embedded devices.
Advantages: Simple architecture, well-documented, open-source ecosystem, compilable to native machine code (sometimes requiring additional processing), and multi-language support (Rust/Go, etc.).
Disadvantages: Fundamentally CPU ISAs (not virtual computing architectures); MIPS ISA is too basic, requiring more opcodes to achieve functions handled by single x86 or specialized VM instructions (see CISC section below), lacks adversarial gas metering considerations, not optimized for blockchain scenarios, lower zero-knowledge proof efficiency (referencing Starkware/Valida research).
Even if ZK reduces node metering needs, high-throughput scenarios still require pre-computation/shared proofs, necessitating anti-DoS mechanisms (making metering valuable). [src[9]]
Georgios Konstantopoulos[10] (Partner & CTO at Paradigm[11]): If you like @VitalikButerin’s proposal, you’ll love R55, which we’ve been quietly developing over the past few months... [src[13]]
0xpedro.eth/acc[14]: R55 allows writing smart contracts purely in Rust, executed via RISC-V in Ethereum clients. While Solidity compiles to EVM bytecode, R55 compiles Rust to RISC-V instructions—a framework unlocking hardware optimization potential. Using Rust on Ethereum? Interesting but tricky. RISC-V inherently knows nothing about Ethereum state (storage, calls, etc.), so R55 adds system calls. Via RISC-V’s ecall, Rust contracts can read storage (e.g., SLOAD), invoke contracts, or emit logs—seamlessly connecting Rust to Ethereum.
R55 is still under development, needing adjustments for gas and security, but the future is promising: rollups or app chains could run native Rust contracts, or zkEVMs could leverage RISC-V for cryptographic operations. To me, Rust’s safety and speed make it a powerful tool for Ethereum. Could R55 spark a wave of Rust developers on Ethereum? Maybe premature, but worth watching. [src[15]]
Dave Rauchwerk[16]: @VitalikButerin This is a great idea. A key advantage of RISC-V is its explicit extensibility. We should explore defining a custom set of RISC-V instructions dedicated to accelerating core, performance-critical EVM opcodes. RISC-V’s openness enables specialized hardware implementations (ASICs, FPGAs) beyond general-purpose CPUs. This opens a path to dramatically increase L1 TPS by accelerating core EVM logic directly in silicon—potentially orders of magnitude faster than current software interpretation or JIT methods.
Verifiability and Security: Compared to complex traditional ISAs, RISC-V’s modular and concise design makes formal verification easier. A formally verified RISC-V core executing EVM logic offers stronger runtime behavior guarantees—critical for securing high-value smart contracts. Enhanced with EVM-centric custom instructions, RISC-V presents a compelling route toward higher-performance, more secure, and scalable Layer 1 systems.
Additionally, benchmark existing EVM implementations against potential RISC-V software models. revive/PolkaVM looks excellent—it currently targets only RV32EM and deserves discussion. [src[17]]
Koute[18] (Head of PolkaVM at Parity Technologies[19]): Since PolkaVM was mentioned, let me explain what PolkaVM is and how it works.
PolkaVM currently supports riscv64emac with Zbb extension, but unlike most (all?) other RISC-V VMs, it cannot run standard RISC-V binaries as-is (it’s actually not a true RISC-V VM!). Offline, we take ordinary RISC-V ELF binaries built with standard compilers, then convert them into a more constrained, efficient custom bytecode specifically designed for VM use (not native hardware like RISC-V). Our goal is to minimize complexity in the VM itself (which runs on-chain), push complexity into offline tools (run off-chain), and enhance security by removing unnecessary features (e.g., raw RISC-V allows jumping to any address; PolkaVM bytecode fully virtualizes code addresses, preventing arbitrary jumps, and the bytecode isn’t even loaded into program-accessible memory).
Performance-wise, we approach bare-metal speeds[1]; we’re as fast as top-tier WASM VMs *wasmtime*, guarantee O(n) recompilation time, and accelerate program recompilation to native code by hundreds of times. Specifically, recompiling programs from raw PolkaVM bytecode to native code is much faster than caching recompiled artifacts and looking them up by hash—in fact, recompiling is faster than calculating the hash—and this doesn’t sacrifice runtime execution performance.
We primarily use RISC-V not because it’s an especially good bytecode for VMs (in fact, it’s not that great), but because it’s simple, well-supported, and relatively easy to transform into something else—giving us the best of both worlds: excellent software compatibility (you can use existing compilers and programming languages—I recently ported Quake to PolkaVM), while also gaining benefits of custom, optimized bytecode (extremely fast compilation, near-native performance, simplicity, and customizability). [src[20]]
dilrong[21]: @VitalikButerin claims replacing Ethereum Virtual Machine (EVM) with RISC-V could boost zero-knowledge (ZK) proof efficiency by 50–100x. But is RISC-V truly superior? EVM has run stably for about nine years, a proven platform, while RISC-V lacks rich practical experience in blockchain execution environments. Although PolkaVM adopted RISC-V, I believe it’s not yet sufficiently validated, having not undergone thorough mainnet testing.
EVM is specifically optimized for smart contract execution, whereas RISC-V is a general-purpose architecture likely lacking customization for blockchain use cases. While RISC-V’s versatility allows using programming languages from other blockchains, Vitalik himself noted improving existing Solidity is preferable. Transitioning the entire ecosystem to a new architecture is a daunting challenge.
Implementing RISC-V in software inevitably leads to performance degradation. Software-based execution via emulators raises doubts about task-handling efficiency. Conversely, adopting RISC-V hardware brings huge transition costs. I believe ZK-EVM already meets current needs. Considering development cost, transition workload, and risk of unforeseen bugs, replacing EVM with RISC-V seems unfeasible.
While transitioning to RISC-V may offer potential benefits, I believe improving ZK-EVM and optimizing existing EVM are more practical and stable alternatives. [src[22]]
Eduardo Bart[23] (Cartesi[24]’s VM Core Developer): As an active developer of Cartesi Machine[25], a RISC-V VM for blockchain applications, I’d like to share perspectives supporting RISC-V exploration for Ethereum’s execution layer.
I believe one major advantage of adopting RISC-V is immediate access to mature tools and ecosystems. Instead of building a fully custom environment, RISC-V allows developers (and core protocols) to leverage decades of accumulated expertise from compilers (GCC, LLVM), debuggers, libraries, and even full operating systems like Linux. Compared to newer, less battle-tested toolchains, this significantly lowers developer barriers and potentially reduces risks from compiler bugs. It aligns well with goals enabling contracts written in Rust or even C++ to compile through standard backends targeting Ethereum. For those concerned about bugs in LLVM or GCC, using formally verified compilers like CompCert[26], now capable of targeting RISC-V, enhances security. More broadly, it becomes possible to run applications atop formally verified RISC-V OS kernels (e.g., seL4[27]) within VMs covering RISC-V privileged ISA specifications—enabling complex apps requiring OS environments.
Performance concerns raised by some aren’t unfounded but are addressable. In my experience, properly implemented RISC-V does not sacrifice execution performance. While u256 operations naturally break down into multiple instructions, in practice, well-optimized RISC-V VMs should minimize this cost’s impact on overall performance. Moreover, VM-level optimizations can significantly reduce these costs, as RISC-V ISA’s extensibility allows adding blockchain-specific custom extensions to optimize common cryptographic operations (e.g., Keccak256).
I believe building future execution layers on a standardized, open, and well-supported ISA like RISC-V provides a solid foundation. It offers a path to leverage existing software ecosystems, potentially simplifying developer experiences and benefiting from future RISC-V hardware advancements.
Though the path is complex, I believe RISC-V’s potential advantages in scalability, tool maturity, and long-term maintainability make it a highly worthwhile direction for future blockchain execution environments. Currently, many robust, production-ready RISC-V VMs in the blockchain space prove such implementations are achievable. Specifically, I believe Cartesi Machine demonstrates the power of leveraging standard open ISAs. It’s a stable, high-performance RISC-V emulator implementing standard RV64GC ISA, capable of running entire Linux software stacks and unmodified RV64GC ELF binaries. Crucially, it’s fully deterministic—even floating-point operations. For those curious to experiment, I recommend trying my WebCM[28], a serverless terminal running virtual Linux directly in browsers via a Cartesi Machine simulator compiled to WebAssembly.
Currently, L1 proposals focus on zero-knowledge proofs, while Cartesi uses interactive fraud proofs, leveraging deterministic execution and state Merkle proofs for on-chain validation. Despite different verification mechanisms, Cartesi confirms building verifiable, deterministic execution environments atop RISC-V is feasible and worthwhile.
Of course, directly integrating RISC-V into L1 with zero-knowledge proofs poses unique and significant challenges—particularly around gas metering, precisely defining system calls for state interaction, and optimizing zero-knowledge circuits for RISC-V instructions. Performance within specific ZK contexts also requires deeper study. Fortunately, numerous RISC-V ZK VM projects are already researching and developing solutions in these areas.
Regarding implementation strategy, I believe serious consideration should be given to a “radical approach”—defining a protocol incorporating the concept of a virtual machine interpreter compiled to RISC-V. This approach could keep Ethereum’s core RISC-V VM minimal and simple, while remaining flexible enough to accommodate different VM interpreters beyond EVM, offering developers greater freedom in VM development.
In short, I believe leveraging standards like RISC-V offers tremendous advantages in tools, developer familiarity, flexibility, and even long-term hardware acceleration potential. My work with Cartesi Machine reinforces the view that RISC-V is a powerful and viable foundation for next-generation verifiable blockchain computing. I’m excited to see it seriously considered for Ethereum’s core execution layer. [src[29]]
Xuejie Xiao[30]: Hello everyone, I’m the original designer and current maintainer of Nervos CKB-VM. At Nervos, choosing CKB-VM stems entirely from first-principles thinking: we wanted a simple, secure, fast sandbox, lightweight enough to run efficiently on commercial CPUs. It turned out CPU instruction sets were optimal, and among them, RISC-V stood out. Of course, other open-source RISC CPU cores exist, but RISC-V attracts the most attention—meaning more contributors to toolchain development. That’s a huge advantage for us.
When discussing EVM vs RISC-V, I suggest going deeper—either compare both with precompiles, or both without. Comparing EVM-with-precompiles to RISC-V-without, or vice versa, seems inappropriate to me. Assuming JIT or AOT RISC-V implementation, or introducing AVX instructions, we might achieve performance comparable to EVM using a no-precompile RISC-V VM.
As far as we know, RISC-V was the best solution seven years ago, and remains so for the foreseeable future. If someone says RISC-V is a hardware solution, fine—we’ve implemented it purely in software, and it still perfectly meets our needs. In this sense, we’re satisfied with the current situation and will continue down this path. [src[31]]
Host: CKB-Virtual Machine (CKB-VM) is a RISC-V-based VM for executing smart contracts on Nervos CKB, written in Rust. Those interested can refer to @Xuejie Xiao’s 2018 article: An Introduction to Nervos CKB-VM[32], for insights into their original thinking—an excellent share!
ZKM[33]: @VitalikButerin’s RISC-V plan for Ethereum is very bold, but MIPS’ maturity and tradition make it a compelling dark horse—a fixed instruction set well-suited for low-latency ZK proofs. MIPS has powered critical systems for 40 years—Ethereum could leverage this stability to achieve similar (or better) efficiency gains, while reducing risks associated with adopting a hyped, still-maturing ISA like RISC-V. If MIPS is already proven, why bet on RISC-V’s growing pains? [src[34]]
WebAssembly (WASM)
@IAmNickDodson: Designed for browser/isolated environments to execute arbitrary code: Advantages: multi-language/environment support, compilable to native code, clear open specification, added metering later (though with overhead); Disadvantages: stack-based architecture (academic research suggests lower performance, though debatable), not blockchain-specific design, metering added as patch affecting performance, extremely poor debugging experience.
Theoretically WASM is a good choice, but debugging pain in actual development is extreme. Multiple teams fully committed to WASM told us they regretted it. By comparison, RISC-V/MIPS are easier to understand—perhaps why teams like Succinct/RISC0 chose them. [src[35]]
Peter Kieltyka[36] (Co-founder of Sequence[37]): @VitalikButerin I know this sounds stretched, but consider Offchain Labs’ EVM+/Stylus as a future L1 execution layer. It’s fully compatible with EVM bytecode, runs in a WASM VM, supports any WASM-compatible language (e.g., Rust), offers significant performance improvements, and maintains full interoperability at runtime with EVM bytecode contracts. This feels like the simplest upgrade path while preserving compatibility. [src[38]]
Xuejie Xiao[39]: Many view WASM as the ideal blockchain VM, mainly because WASM was designed for software implementation (if that makes sense—let’s ignore it for now). Did you know that before WASM, a subset of JavaScript called asm.js briefly gained popularity? asm.js later evolved into WASM, somehow becoming much larger than asm.js’s original vision (frankly, WASM now looks more like a clean, newly designed JVM than asm.js). But let’s not forget asm.js’s original goal: people wanted a software IR that deterministically maps to native CPU instructions—not JIT which achieves this only ~90% of the time. If RISC-V can achieve this goal, I think it’s well-suited as a software VM. [src[40]]
Hazel Hu[41] (Delphinus Lab[42]): While @VitalikButerin champions RISC-V, ZK VMs aren’t limited to this single technical path. ZK VMs aren’t exclusive to ETH—they’re independent, possibly larger than the ETH ecosystem. ETH needs ZKVMs, but ZKVMs aren’t confined to Ethereum. [src[43]]
ZK systems use RISC (Reduced Instruction Set Computing), with two choices: first, Cairo-like ZK-specific languages creating custom instruction sets (steep learning curve); second, using existing ISAs. RISC-V is one such option. Projects like @RiscZero[44], @SuccinctLabs[45], @NexusLabs[46], and Jolt supported by @a16z[47] are all RISC-V-based ZK VM initiatives.
As early as 2018, the Ethereum ecosystem launched eWASM. EVM inventor @gavofyork[48] expressed feasibility of WASM replacing EVM. Polygon co-founder @sandeepnailwal[49] has long been a staunch WASM supporter. However, eWASM wasn’t widely adopted due to engineering complexity, shifting priorities, and the rise of L2 solutions—subsequent roadmaps shelved eWASM.
After @VitalikButerin’s proposal, Zebra founder @shumochu[50], 1kx research partner @_weidai[51], and others pointed out WASM might be better suited for Ethereum’s execution layer, for these reasons:
Simpler workflow: RISC-V was designed for hardware implementation, not as an intermediate representation. If used as Ethereum’s contract execution layer, a VM layer must still be built to handle gas consumption and control execution flow—adding complexity.
Static analysis friendly: WASM lacks jump instructions, has simple code structure, making contract property verification easier.
Broad language support: Developers can write programs in nearly all mainstream programming languages and compile to WASM, greatly lowering learning costs. Miden founder @bobbinth[52] further suggested that for better ZK-friendliness, one could design instruction sets superior to RISC-V, or use WASM component model. [src[53]]
My team @Delphinuslab[54] open-sourced the industry’s first ZKWASM VM. Though currently only with a Solidity SDK, ZKVM contract settlement can occur on any chain—future expansion to non-EVM chains like Solana and Sui is entirely possible.
What can ZKWASM VM do?
1. Enable more developers to enter blockchain using their preferred programming languages, eliminating the need for everyone to learn Solidity (or more complex, niche blockchain languages) or Rust
2. Allow more Web2.5 web mini-programs to go on-chain with one click—if fully realized, thousands of browser apps could rapidly deploy to blockchain
3. Break the impossible trinity, achieving balance among decentralization, efficiency, and security. [src[55]]
x86/ARM
@IAmNickDodson: Both major CPU ISAs are non-open-source: ARM belongs to RISC (Reduced Instruction Set Computing), x86 to CISC (Complex Instruction Set Computing). With CPU hardware evolution, both have become extremely complex. Notably, while CISC has gradually been replaced by RISC in CPU domains due to complexity, in blockchain scenarios CISC反而 holds an advantage. [src[56]]
Xuejie Xiao[57]: x64 is too heavyweight (when we first tried RISC-V, someone was actually building a blockchain VM using x64!), while Arm may have licensing issues—or may not. [src[58]]
Bitcoin Script
@IAmNickDodson: The first blockchain VM, designed specifically for Bitcoin programming:
Advantages: Built for blockchain and Bitcoin transaction models, adapts to adversarial environments, supports basic operations like multisig
Disadvantages: Extremely limited functionality, severely constrained by Bitcoin network processing capacity.
We inherited P2SH (Pay-to-Script-Hash) from Bitcoin Script—a powerful paradigm of conditional programming. This prunable program pattern (removable from full nodes after execution) supports diverse scenarios: off-chain trading, multisig wallets, auctions, etc. Bitcoin’s architecture teaches us: VM design must deeply synergize with transaction models. [src[59]]
MoveVM
@IAmNickDodson: Blockchain-specific VM developed by Meta team, emphasizing security:
Advantages: Native blockchain design, supports adversarial metering, paired with dedicated Move language
Disadvantages: Sacrifices significant state flexibility for security, overly RISC-like (see earlier analysis), ecosystem fragmentation (incompatible variants on SUI/Aptos).
Move ecosystem nearly stagnated in 2020–21. We abandoned adoption because we didn’t want to be constrained by others’ non-innovative architectures, and its “security” features are mostly packaging of RISC systems, unable to prevent bad coding practices. At the time, formal verification applied only to simple methods, not full applications—too low cost-effectiveness. [src[60]]
EVM
@IAmNickDodson: Comparable to PHP in the blockchain world, powering smart contracts worth hundreds of billions:
Advantages: Native blockchain design, robust metering mechanism, full ecosystem compatibility, battle-tested Solidity language
Disadvantages: 256-bit word size design, supports only calls/contracts without script functionality, lacks conditional programming (no P2SH equivalent), based on oversimplified transaction model, inefficient (word size and opcode design cause massive computational waste), highly stateful design makes storage access a performance bottleneck.
While some teams claim novel databases or state access schemes solved these issues, fundamentally such computations could’ve been avoided. EVM suits rapid ecosystem building, but lacks innovation from transaction model and design space perspectives. Perhaps Vitalik’s announcement reflects this realization. [src[61]]
Alex Vlasov[62]: It’s unclear whether RISC-V is truly better than EVM. EVM is stack-based, so its register file is small. EVM operates on 256-bit numbers, which could be problematic if smaller values dominate. However, provers can access actual execution traces, allowing lighter implementations for smaller values (e.g., byte decomposition of 32-bit values occupies fewer rows than 256-bit values). [src[63]]
Another aspect is the cost of formal verification for smart contracts. EVM’s instruction set (ISA) is more limited than RISC-V’s, so F/V is generally simpler. RISC-V smart contracts typically contain more loops and memory operations, both problematic for F/V.
For example, a study (/www.cs.utexas.edu/~isil/solis.pdf[64]) shows about one-fifth of EVM smart contracts contain one or more loops. Since EVM operates on 256-bit values, more loops are needed in RISC-V code. Even with loop unrolling, this leads to larger SMT queries.
RISC-V has a richer memory model, implying more memory operations (e.g., EVM has 1024 256-bit stack slots, while RISC-V has 16–32 32/64-bit registers). Thus, aliasing (two syntactically different expressions pointing to same memory location) becomes a more severe issue. This in turn affects static analysis, such as call graph reconstruction, pointer analysis, etc.
I expect formal reasoning about RISC-V smart contracts with loops/aliasing will be more challenging compared to EVM smart contracts. [src[65]]
SVM
@IAmNickDodson: Solana Virtual Machine’s recent rise:
Advantages: Native blockchain design, supports adversarial metering, compilable to native code, high-performance design
Disadvantages: Complex and hard-to-understand architecture, poor developer experience with Rust and similar languages, lacks mature dedicated language.
We didn’t choose SVM mainly due to its transaction model assumptions—similar to Ethereum’s simple design prioritizing speed over complex multi-party settlements, mismatching our planned transaction model. [src[66]]
CairoVM
Akash Balasubramani (StarkWare Ecosystem Manager): @IAmNickDodson Brilliant analysis! Would’ve been even better with CairoVM included. [src[67]]
@IAmNickDodson: Only omitted because it wasn’t on our radar during 2020/21 research. I’m a big fan of Cairo and STARK technology. [src[68]]
Eli Ben-Sasson (Co-founder of StarkWare): @IAmNickDodson Excellent discussion! Only suggestion is to include Cairo analysis. Let me try: Advantages: Designed specifically for blockchain + zkSTARK efficiency, linear type safety, efficient gas metering (Sierra); Disadvantages: Lower知名度 / toolchain maturity :) [src[69]]
Host: Thank you all for your insightful comments. Ultimately, what conclusions have you reached? Any insights to share with us?
@IAmNickDodson: After studying all VMs, we realized the VM itself is overrated. Theoretically, these VMs (except BitcoinScript) can perform required computations at varying efficiencies. What truly matters is co-design between VM and transaction model. Many chains overemphasize VM while neglecting transaction model—the real core of blockchain behavior. [src[70]]
FuelVM’s uniqueness lies precisely here—these are FuelVM’s composite optimizations [src[71]]:
• Memory efficiency (shared memory context reduces copying)
• Intelligent use of registers and memory (e.g., placing entire transactions in visible memory for runtime introspection)
• Minimizing IO access
• Strengthening transaction-layer capabilities (transactions do more, VM does less)
• Transaction model combines state access with multi-asset/multi-condition/multi-execution mode transfer capabilities
• Golden balance between CISC and RISC
• No global state tree (UTXO model naturally prevents double-spending via temporal rollback)
• All opcodes optimized for metering efficiency
• Supports diverse program types like predicate-based conditional programming
• Companion Sway language combines Rust performance with Solidity developer experience
Traditional wisdom holds blockchain VMs should pursue minimal instructions (for security and native code compilation). But here’s the problem: in optimistic validation scenarios, every operation requires metering. The simpler the VM, the more opcodes needed for same functionality, increasing on-chain metering computation. Hence FuelVM chooses to design more efficient opcodes—accomplishing more with fewer operations. You can think of FuelVM as a fusion of CISC and RISC. While more instructions usually mean larger bytecode (impacting bandwidth-limited scenarios, mitigated by compression), this significantly reduces metering overhead in optimistic validation, giving developers more powerful tools. Even in ZK scenarios, compound operations allow better optimization. Simple ≠ Better. [src[72]]
Host: Any message for engineers considering other VM architectures? Like for Ethereum :)
@IAmNickDodson: If Ethereum chooses the RISC path, it must simultaneously reconsider its transaction model. The VM is just one puzzle piece—RISC-V alone cannot solve token accounting, transcend the smart contract paradigm, or build high-performance blockchain applications for all humanity and robots. Fuel chooses correctness over popularity, meaning ongoing pain (just look at our token), but it offers the open-source blockchain ecosystem a new design paradigm.
If you’re building a blockchain and need an architecture deeply aligned with blockchain essence, consider FuelVM/Sway. Performance is insane: 150k TPS on M4 processor, 10ms soft confirmation, runs from toaster ovens to supercomputers. Learn more about FuelVM: Why the FuelVM is the EVM but greatly improved and what this means for the future of blockchain[73]
Xuejie Xiao[74]: Another point about ZK: first, this is just my personal view on zero-knowledge. RISC-V has two distinct ZK-related use cases: 1) VM/IR expressing programs to be ZK-proven, 2) underlying platform where ZK verifiers run. A simple but inaccurate analogy: there’s a VM above zero-knowledge proof algorithms (point 1), and another VM below them (point 2). They should be discussed separately.
Nervos CKB-VM adopts strict no-precompile design, perfectly fitting point 2: you can compile ZK verifier code into RISC-V code and run that ZK verifier on Nervos CKB-VM. In this sense, Nervos CKB can flexibly support any ZK solution. In other words, I believe Nervos CKB-VM is a good choice for a VM under ZK algorithms.
Point 1 stands as a separate use case. I’m not deeply familiar with internal ZK proof mechanics, so I can’t judge whether RISC-V is suitable. I suspect certain characteristics of ZK proof algorithms might influence VM design above them.
I might be wrong, but I feel @VitalikButerin might be talking about point 2—appropriate VMs under ZK algorithms—so perhaps we don’t need to debate whether RISC-V suits ZK proofs?
porter | ZKsync[75]: ZKsync is ready for the following changes: New proving system Boojum2 is already RISC-V. Some developments will benefit the entire Ethereum ecosystem (not just ZKsync): A brand-new Solidity → LLVM → RISC-V compiler is coming soon. [src[76]]
@alacheng[77]: For ZK directions (if L1 scaling avoids re-execution during node validation, these zkvm will replace zkevm), @SuccinctLabs[78] and @RiscZero[79] are both zk RISC-V VMs, @UntoLabs[80] is a chain built by a core developer from Solana ecosystem, with RISC-V VM at execution layer. [src[81]]
Host: Thank you all immensely for your brilliant insights. This “virtual roundtable” concludes here. Due to time and space constraints, we couldn’t cover every distinctive VM—perhaps I’ll update or host a second session later. For detailed information, please click the [src] link at the end of each viewpoint/comment.
Summary
In this “virtual roundtable,” we saw different blockchain projects choosing divergent technical paths—EVM pursuing ecosystem compatibility, RISC-V focusing on hardware efficiency, WASM embracing multi-language development, MoveVM emphasizing asset security, and FuelVM breaking performance limits. This precisely illustrates that in blockchain, there’s no universally optimal solution—only trade-offs best aligned with individual development goals.
Through this technical debate, we glimpse:
• Ethereum’s conservative upgrade prioritizes ecosystem value
• Nervos embraces RISC-V driven by pursuit of hardware friendliness
• Aptos/Sui bet on MoveVM reflecting obsession with security
• Fuel takes an alternative path, using hybrid architecture to overcome performance bottlenecks
Behind these choices lie different answers to “what blockchain should be.” Understanding the logic behind these technical decisions may be more valuable than debating superiority—it reveals the field’s true diversity, foreshadowing a vibrant, pluralistic future for Web3. Fascinating, isn’t it?
Disclaimer
This content compiles and reorganizes public technical discussions, aiming for objective comparison and analysis of current mainstream Web3 virtual machine technologies. All projects, technical schemes, and products mentioned (including but not limited to EVM, RISC-V, WASM, MoveVM, FuelVM, etc.) are based on public community discussions, representing only the views of respective speakers, not the stance of the author or publishing platform.
Reader Notice:
1. Technical Neutrality: Discussion of VMs is limited to technical aspects only, not constituting endorsement or recommendation of any project, token, or product;
2. Timeliness Note: Information is based on publicly available data from 2025; actual developments may have changed;
3. Risk Warning: Cryptocurrencies and blockchain projects involve market, technical, and regulatory uncertainties; readers must conduct independent research and exercise caution;
4. Not Investment Advice: Content in no way constitutes investment advice; all technical analysis should not serve as investment basis.
Blockchain technology remains in rapid development; any technical choice must be evaluated against specific application scenarios. We encourage readers to make independent judgments using official project documentation, audit reports, and other primary sources.
Copyright Notice
This content is collected, compiled, and restructured from publicly available internet sources (including but not limited to technical forums, social media, developer documentation, etc.). To ensure coherence and readability, editors have made the following modifications to original content:
1. Content Editing: Including but not limited to excerpting viewpoints, refining sentences, restructuring paragraphs, and necessary decontextualization; some parts may lack full context;
2. Language Conversion: Translations between Chinese and English may involve semantic deviations or expression differences, not literal translations;
3. Technical Simplification: Some technical terms or descriptions have been simplified for accessibility, possibly sacrificing original precision.
Important Note:
• Final interpretation of all viewpoints and technical statements belongs to their original authors; please refer to the [src] original links marked at the end of each viewpoint;
• This article did not obtain prior authorization from mentioned project teams, technical groups, or speakers, serving solely as a public-interest technical discussion compilation;
• If content contains misrepresentation, copyright disputes, or suspected infringement, please contact @OpenBuildxyz[82] promptly; we will verify and correct immediately.
This article follows fair use principles, aiming to promote knowledge dissemination and discussion in blockchain technology, not for commercial purposes. When quoting, please credit original sources and comply with relevant copyright regulations.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
