The VM Landscape: Comparing Architectures for Next-Generation Blockchains

Introduction

Since Vitalik’s post about RISC-V the different approaches to VMs have come back to the front of everyone’s mind. In this post we recap a handful of approaches, run over their technical underpinnings and highlight some pros and cons of the approaches. The approaches in this work shouldn’t be taken as a complete list of options as such a list would take far too long to compile, it represents a list of the most notable and interesting examples. Until recently the EVM was the main contender in this space but recently we’ve seen multiple other approaches being pursued for numerous reasons including performance, verification simplicity, and zk-friendliness.

The EVM Ecosystem

The EVM has established itself as the leader in blockchain development ecosystems. As shown in Electric Capital's developer report, the EVM has 8,925 monthly active developers, 3.6 times larger than its closest competitor. 

What makes this developer concentration so significant is the powerful network effects it creates. Each developer who builds on EVM strengthens the ecosystem, creating tools, libraries, and knowledge that attract even more developers. This self-reinforcing cycle has created an insurmountable moat around the EVM.

The EVM's success is powered by its comprehensive tooling: development frameworks (Hardhat, Foundry, Truffle), testing tools (Tenderly, Remix), multiple languages (Solidity, Vyper, Fe), debugging solutions (Etherscan's contract verifier, Tenderly Debugger), client implementations (Geth, Erigon, Reth, Nethermind), infrastructure providers (Alchemy, Infura, QuickNode), extensive documentation (Ethereum.org, Solidity docs), educational resources (CryptoZombies, Buildspace, Paradigm CTF), security tooling (Slither, MythX, Echidna), on-chain data analytics (Dune Analytics, Etherscan), development environments (Hardhat Network, Anvil), and wallet integrations (MetaMask, WalletConnect). This self-reinforcing cycle has created a very strong moat around the EVM.

A critical component of this moat is the Solidity programming language. Most blockchain developers have already invested significant time mastering Solidity, and introducing a new language would create substantial friction in the ecosystem. This learning curve represents a major barrier to adoption for alternative VMs. 

Any evolution of the EVM must preserve backward compatibility with existing Solidity code, allowing developers to leverage their existing knowledge and codebases. This constraint means that while we might be able to modify the EVM engine itself for better performance or ZK-friendliness, wholesale replacement with architectures requiring new programming paradigms faces steep adoption challenges.

The EVM: Architecture and Technical Details

Let’s start at the beginning. The EVM. The EVM is a stack-based EVM with 256 bit words, likely chosen due to the ubiquitousness of 32 byte crypto (256-bit values are common in cryptographic algorithms particularly for Keccak-256 hashes and ECDSA signatures). It is implemented as a 1024 element LIFO stack. It contains about 140 op codes including some blockchain specific calls such for storage and logging. The EVM has no general purpose registers and relies on a linear byte-array for memory. In native execution, EVM bytecode is typically interpreted, though some clients use AOT/JIT compilation. The stack architecture means many ops are 1-byte instructions with implicit operands, which keeps code compact and decoding simple. However, performance on CPU is lower than a register machine. The EVM is single-threaded with a global state by default though numerous projects including Sei have incorporated parallel EVM execution. The EVM is not particularly zk-friendly with the Keccak-256 MPT leading to expensive circuits, the wide word operations are frequently broken into smaller field operations for proving, and the stack machine’s proving has proven burdensome.

Modified EVM Architectures

Given the issues with the EVM when it comes to zk-proving some have proposed modified EVM architectures to address some of the aforementioned downsides while keeping the stack execution model, the majority of the EVM instruction set, and perhaps most importantly the tooling and ecosystem. These are frequently called type 2 (or 3) EVMs in the world of ZK L2s. One option would be to replace Keccak with a Poseidon variant, a hash algorithm designed to be efficient over prime fields which frequently leads to an order or two fewer constraints. Though allowing for more efficient proving the change would lead to backwards compatibility issues with some contracts. Another possible EVM modification to simplify the EVM for proving would be to replace the MPT with an SMT. SMTs are much simpler to implement in circuits and the account proof is a fixed-depth sequence of hashes unlike the variable path length in an MPT. 

Another option would be to reduce the instruction set and remove infrequently used but expensive to prove OPs. The EVM could also be modified to facilitate parallel execution as opposed to proving which would entail a different set of potential modifications. The OP code set could be extended to allow contracts to declare at call entry which slots they will touch allowing for a scheduler to detect non-overlapping transactions immediately simplifying parallel execution. A register based core could be implemented to replace the stack machine allowing for the use of existing register allocation work for existing ISAs to be reused though this would come at the cost of larger transaction, more difficult JIT, and the need to port existing contracts. The addition of async and await OPs in the EVM would allow developers to parallelize subroutines in a single contract at the cost of complex gas accounting. CRDTs could allow for commutative writes without locking at the cost of massive complexity. Irrespective of the overall goal it is clear that an improved version of the EVM could be engineered to target that specific goal while ensuring decent backwards compatibility. 

RISC-V: A General-Purpose Alternative

Now the one everyone is talking about RISC-V. What is RISC-V even? RISC-V is an open instruction set designed for CPUs not blockchains but it has been considered for blockchains, and implemented by some like Nervos and Cartesi. The general argument seems to be that using a general-purpose ISA to avoid the EVM’s idiosyncrasies allow blockchains to take advantage of the active research in traditional computer architecture, and in the case of Ethereum allow for simpler zk-proving with some claims of an 800x improvement being thrown around. RISC-V is a traditional register-based ISA with 32 general-purpose registers, fixed-sized instructions, and a load/store memory model. The modular design of RISC-V allows for extensions including more complicated features like floating point maths or atomics. Though not entirely laid out yet it would probably be a minimal RISC-V version with few extensions that would be used by Ethereum if they go ahead with this change. The port to RISC-V would probably mean EVM OPs like SLOAD become syscalls. Though not designed for zk-friendliness, like the EVM, RISC-V is slightly friendlier. The simpler arithmetic on 64-bit ints can be natively represented in common ZK fields, though handling the ported 256-bit EVM maths in RISC-V may lead to slower execution. RISC-V has much simpler flow control compared to the EVM with standard pc and jump replacing the EVM’s jumpdest with its messy validation and jump logic. In short, RISC-V shifts the burden, instead of natively handling big hashes and big integers, it handles basic operations and leaves complex operations to software. On real hardware, RISC-V code would run orders of magnitude faster than EVM bytecode interpretation. Clients could compile RISC-V smart contracts to native code or eventually use actual RISC-V hardware to execute transactions. While RISC-V is simpler than the EVM in some ways it introduces its own complexity, the lack of built-in gas means that it would have to be simulated. RISC-V may also be beneficial in the world of parallelised VMs, RISC-V allows you to expose harts directly allowing a scheduler to assign transactions or parts of transactions to different harts, RVVs can be used for expensive blockchain operations such as curve pairings, contracts can explicitly call FENCE instructions to denote where strict ordering matters within them, and the use of LRSC can be used to implement lock-free parallel state reads.

WebAssembly (WASM)

Another common alternative that has been seen in projects such as Polkadot is WebAssembly. WASM is a stack-based virtual ISA originally designed to run browsers. WASM has registers and does not allow for arbitrary jumps to instruction addresses, and WASM is memory-safe. The structured nature of WASM means the bytecode is verifiable by default unlike most ISAs. Like the EVM memory is a linear byte array though WASM allows 64KB pages to exist which are shared by all functions in a module. Again WASM isn’t designed for zk-proving but has some friendly features including the structured flow control that we mentioned before and the smaller types. WASM execution is typically fast, approaching the speed of native execution with AOT/JIT and is much quicker than the EVM. WASM Threads bring shared buffers and atomic ops, letting contracts spawn parallel worker contexts that synchronize only on contested slots. SIMD v128 registers batch cryptographic loops and hashing into wide data lanes, delivering 4×–16× speedups. Isolated linear-memory arenas plus explicit memory fence calls let you shard state and aggressively reorder most memory ops while guaranteeing deterministic replay. Along with GC-backed actor isolation and preflight read/write scheduling, and WASM unlock multi-core and vector parallelism. RISC-V is a lower level approach to WASM allowing for more control and, probably, better performance at the cost of a more complicated security model. A significant amount of work is happening in the ZK space for RISC-V too which isn’t as true for WASM so with proving as the goal RISC-V feels a more natural choice.

Custom ISAs for ZK-Proving

Now we’ll head into the land of custom ISAs designed for specific goals as opposed to the generic approaches we’ve already covered. We’ll start with those from the ZK world. Cairo is StarkWare’s virtual CPU designed for STARK proving. Cairo is neither a register machine nor a stack machine but a bit of a hybrid. Cairo does have several registers including a pc but all other data lives in a single array of memory. Cairo has a small instruction set focusing on memory ops, arithmetic, and flow control. By design valid Cairo execution traces can be defined by a single set of polynomials, essentially a specified arithmetization of an ISA as opposed to just an ISA. Not entirely surprisingly given Cairo was designed for zk-proving, Cairo has a number of features allowing for efficient STARK proving. All instructions in Cairo are designed to happen within the field used for proving meaning no need for decomposition, there is a fixed trace length per step, a lack of dynamic jumps, simple instructions encoded into a single field element, and chiplets which allow the ISA to be extended for specific tasks without the main trace being impacted, for example a dedicated table is used for Pedersen hashing where the Cairo CPU inputs to the table and then reads the output without doing the task itself. The raw execution speed of Cairo is slower than typical WASM or EVM but given its aim of cheap and quick proving that’s an acceptable tradeoff. Cairo isn’t alone in the ZK space here, Miden and Valida have both proposed their own approaches. Miden is similar in design to Cairo and can be considered a stack machine with chiplets. Miden stores programs as Merkelized Abstract Syntax Trees as opposed to linear bytecode allowing the program to be committed to in a single hash and the execution flow to be proven by opening the path as the program runs. This is an idea also seen in Simplicity.

Alternative non-ZK VM Approaches

MoveVM is a register-based stackless VM, it operates on a fixed number of local slots rather than a push/pop stack, and emphasizes safety and formal verification. While not designed for zk-proofs, its bytecode is verifiable. The approach lets the node precompute read/write sets and dispatch non-conflicting transactions in parallel. Sui enforces an object-oriented global state model, each piece of data is owned, and transactions declare exactly which objects they read and mutate. Because the global state is decomposed into independent objects and no implicit global storage exists, transactions that touch disjoint sets of objects are parallelizable by construction. The MoveVM itself is small and fast, with fewer than 50 core opcodes, no dynamic jumps, no re-entrancy, and a complete static type system with linear resource semantics. The SVM, or more correctly eBPF, is a VM originally designed for kernel-mode sandboxing. The eBPF VM is register-based with ten 64-bit general-purpose registers, a program counter, and two stack pointers. It uses a RISC-style instruction set with fixed-size 64-bit opcodes, JIT-compiled to native x86 at runtime for near-native performance. Contracts are deployed as ELF-compiled shared objects, written in Rust and compiled to eBPF via LLVM. Solana mandates that each transaction statically declare the full set of accounts it will access and whether each access is read or write. This enables the runtime to deterministically schedule transactions in parallel across cores, avoiding runtime data contention and eliminating the need for a global mutex. eBPF’s constrained memory model, no arbitrary memory access, enforced via bounds checking, lack of dynamic allocation, and structured control flow, verified via AOT analysis, make it a secure yet performant runtime.

Conclusion

While the EVM dominates today through its extensive tooling and developer network effects, alternative approaches offer compelling advantages for specific use cases. RISC-V provides potential ZK-proving efficiency and hardware acceleration, WASM brings speed and memory safety, while custom ISAs like Cairo optimize specifically for zero-knowledge proof generation.

However, the path forward must prioritize backwards compatibility above all. The EVM's greatest strength lies in its massive developer ecosystem and the shared knowledge around Solidity. Forcing developers to learn entirely new programming languages or paradigms would erode this critical moat and squander the accumulated value of thousands of tutorials, tools, libraries, and infrastructure components built around the current system.

Join the Sei Research Initiative

We invite developers, researchers, and community members to join us in this mission. This is an open invitation for open source collaboration to build a more scalable blockchain infrastructure. Check out Sei Protocol’s documentation, and explore Sei Foundation grant opportunities (Sei Creator Fund, Japan Ecosystem Fund). Get in touch - collaborate[at]seiresearch[dot]io