EVM 2.0 - Proving-Centric vs. Execution-Centric Approaches
This post is by StarkWare. We thank Vitalik Buterin, Tomasz Stańczak, Justin Drake, Ventali Tan, Federico Carrone (Fede), Bobbin Threadbare, Morgan Thomas, Guilamme Ballet, Mamy Ratsimbazafy (@mratsim), Alexander Hicks, Kevaundray Wedderburn and Jeremy Bruestle for careful review and comments.
Summary
We provide our outlook on the way to choose the next EVM. We see three potential routes, each presenting a different tradeoff:
- Prioritizing fast execution and a standard toolchain at the expense of fast ZK proving,
- Prioritizing fast proving at the expense of execution and standard toolchain, and
- A 2-step approach that passes through a blockchain-friendly VM followed by a ZK-VM, also at the expense of standard toolchain (though not necessarily fast execution).
A few years ago Starknet faced a similar question and chose the third option. We believe this is also the best path for the next EVM. At the very least, we suggest that this option be seriously explored alongside the other options.
Background: Rethinking the Ethereum Execution Layer
Ethereum – the “World Computer” – is the first and most successful blockchain that supports smart contracts and general computation. In a recent pair of influential posts [1, 2], Vitalik suggests “we replace the EVM with either RISC-V, or another VM that is the VM that Ethereum ZK-provers will be written in.”
The question of “which VM should we use?” is something StarkWare dealt with over the past 7 years, and as we brought more and more systems to production our insights shifted and matured. The following document, based on our collective experience, is StarkWare’s contribution to the important discussion surrounding the major architectural question that Ethereum is facing:
What should Ethereum’s next-generation execution layer look like?
This question spans multiple dimensions:
- Execution Efficiency: Can Ethereum design a VM that allows faster contract execution, lower latency for users, and better resource utilization for sequencers and full nodes?
- Provability: Should the VM be optimized for integration with zero-knowledge proofs, enabling verifiable execution and trustless scalability through zk-rollups or zk-proven Layer 1s?
- Developer Experience, Ergonomics and Safety: How can Ethereum improve language tooling, debugging, and formal verification, while ensuring the execution model is safe, deterministic, and easy to reason about?
- Open Source: As a decentralized and permissionless blockchain, it is important that whatever stack is chosen by Ethereum, it be sufficiently accessible and usable, which means open sourcing all relevant core components.
- Backwards compatibility: The current code base of Ethereum smart contracts and systems is the result of thousands of developer years, and its safety is backed by thousands of auditing years. Any VM that diverges significantly from the existing one will lead to (1) maintaining two VMs and code bases indefinitely and (2) increased costs and lower safety.
Below, we break down the main tradeoffs between execution-focused and proving-focused VM designs, evaluate the requirements for blockchain-safe execution, and explain our view for the best way to converge these different goals to form a unified architecture.
Key Concepts
Unlike traditional computing environments, blockchain execution must adhere to strict constraints around safety, determinism, and verifiability. These constraints inform how we reason about low-level code behavior (e.g., through sanitization), runtime isolation (sandboxing), and whether a VM is optimized for zero-knowledge proofs. This section introduces these core concepts and explains why they are essential in designing a secure and scalable blockchain execution environment. After presenting these concepts we’ll dive into concrete suggestions for the next generation EVM.
Blockchain Execution Safety
When executing blockchain transactions, the question of safety arises, as we wish to ensure smooth, safe and consistent execution across a diverse range of platforms. Safe execution requires, among other things:
- Restricting direct access to host resources (e.g., file system, system calls)
- Preventing side effects outside of state transitions
- Ensuring deterministic behavior across all nodes
- Restricting resource usage, either by gas metering (as on Ethereum) or by restricting the VM itself (as on Bitcoin)
ZK-friendliness
A ZK-friendly VM is one that is designed with efficient zero-knowledge proof generation in mind. Key attributes include:
- Minimal overhead when representing valid execution via arithmetic constraints
- Efficient memory models, avoiding dynamic access patterns or complex system-level features
- Traceability, enabling easy generation of proof witnesses
- Recursion-friendly execution, allowing proofs to be aggregated
zkVMs are virtual machines explicitly designed for efficient zero-knowledge proof generation. They prioritize structured computation, traceability, and memory determinism to enable succinct, verifiable proofs. These systems are ideal when real-time or low-latency proving is essential,
such as in ZK-rollups or on-chain verifiability.
Note: This short and quickly-written post omits many nuances that are crucial to the discussion, like:
- The execution environment and the metadata that needs to be proved (Patricia-Merkle trees vs. other commitment schemes) should play an important role in the choice of the next EVM.
- Each of the topics introduced here is worthy of far greater attention (which proving system are we assuming ZK friendliness over? Should multiple proving systems and multiple finite fields be supported? etc.)
We hope the Ethereum community undertakes this study at greater depth than what we cover here.
Design Options
Having explained the constraints arising from blockchain execution and from zk-friendliness, we move on to examining the architectural choices available. Broadly, these fall into three categories, each reflecting a different priority: optimizing for execution performance and developer experience; optimizing for provability; or combining the strengths of both through a layered approach. Each option introduces tradeoffs across performance, safety, tooling, backwards compatibility and future scalability. In the sections that follow, we outline what each path entails, highlight notable real-world examples, and explain how these designs respond to the challenges unique to blockchain environments.
Option 1: Execution-Focused Blockchain VM
If the primary goal is to create a new blockchain VM that delivers high performance and developer-friendly tooling, one should lean towards making the next EVM as close as possible to an established toolchain, one that is well maintained outside of the world of blockchain. This approach prioritizes:
- Fast Execution: Native-level performance for contract execution on commonly available hardware, to minimize block production and verification compute and latency. Notice that fast execution requires optimizing much more than the CPU because in modern computers CPUs are vastly faster than memory and I/O operations.
- Developer-Friendly Tooling: Compatibility with popular languages (blockchain and non-blockchain ones), IDE support, testing frameworks, and debugging tools.
However, the blockchain specific requirement above lead to either picking a blockchain stack, or modifying a popular standard stack, to ensure the unique blockchain requirements, including:
- Deterministic, Consensus-Safe Behavior: All contract execution must be sandboxed and produce deterministic results across all nodes in the network. Execution must be isolated from host machine internals. This prohibits system calls, file access, and unrestricted memory operations.
- Safe and Predictable Resource Usage: Includes built-in gas metering, bounded memory, and restricted instruction sets — ensuring contracts don’t overconsume resources or violate consensus rules.
- Upgradeable & Modular Design: Ideally, the VM allows for upgradable components (e.g., custom precompiles, cryptographic primitives) to be added in a backward compatible way.
Examples of existing blockchain-VMs that are optimized for execution include:
1. FuelVM (used by the Fuel network)
- Parallelizable execution (via UTXOs)
- Minimal and analyzable IR
- Custom language (Sway) with clear control over side effects
- Strong focus on modularity.
2. MoveVM (used by Aptos and Sui)
- Resource-oriented programming model enforces strict ownership and prevents data races or unauthorized state mutations.
- No unrestricted global state access, reducing runtime bugs and improving safety.
- Gas metering is integrated directly at the bytecode level.
- Extremely safe and deterministic, especially in DeFi contexts.
- Good language ergonomics and analyzability.
3. CosmWasm (WASM for Cosmos, used by Cosmos)
- Runs smart contracts compiled to WASM in Cosmos SDK chains.
- Uses Rust + no_std, C compiled to WASM, or similar compilation paths that ensure contracts cannot access unsafe system APIs.
- Supports multi-chain deployments due to Cosmos’s IBC (Inter-Blockchain Communication).
- Built-in gas accounting and memory limits.
- Leverages the WASM ecosystem safely, while sandboxing execution in a blockchain-native runtime.
- Ideal for developers already familiar with Rust or AssemblyScript.
Option 2: ZK-Proving Focused Language/VM
If Ethereum’s priority is to build a ZK-friendly system, then a VM explicitly designed for provability is called for. Such a VM would typically minimize circuit size, remove registers (or drastically minimize their number), enable recursion, and use a simple, well-constrained, instruction set.
Examples of existing VMs that are optimized for ZK-proving (Proper Disclosure: CairoVM is built by StarkWare, the co-authors of this writeup)
1. CairoVM (Used by Starknet)
- Designed from the ground up for STARK-based proof systems
- Uses a minimal, arithmetic-friendly instruction set
- Avoids problematic features like dynamic memory, indirect jumps, or system calls
- Stack-less, register-less architecture
- Paired with Sierra, a high-level, typed intermediate representation that provides safety and prevents undefined behavior.
- Compiles efficiently down to traceable, provable CASM code.
2. Valida VM (used by the Valida project)
- 31-bit field compatibility
- LLVM backend for compilation from high level languages, including Rust, C, WASM and more.
- Minimal instruction set, defined by degree-3 constraints
- Stack-less architecture, with direct memory manipulation
3. Miden VM (used by the Miden project)
- ISA with native instructions for both field and 32-bit arithmetic operations.
- Assembly language with structured control flow to simplify transpiration from WASM and enable use of WASM as an intermediate representation for higher-level languages.
- MAST (Merkelized Abstract Syntax tree)-based program representation to ensure deterministic linking and program commitments.
- Support for multiple isolated execution contexts enforced at the VM level, including separation between root and user contexts.
- Configurable kernels that enable extensibility without the need to modify the core arithmetic circuits of the VM.
- Focus on recursion-friendliness and client-side proving (i.e., relatively low memory requirements).
Option 3: Combine Both: Blockchain-Safe Language + ZK-Friendly VM
If Ethereum’s goal is to combine ZK efficiency, execution performance, and language safety then we should first acknowledge that there currently is no widely accepted framework, used outside of blockchain, which is a natural fit. Blockchain-related requirements of sanitization and sandboxing pull in one direction, whereas ZK-friendliness pulls in another direction. Going explicitly with one direction will mean that the other one is not well served.
This is the problem that StarkWare has faced in the past, and it is worth recounting our experience. After deploying our very first product – StarkEx – in the summer of 2020, we wanted to improve it and add new features. But the way we built that first system, writing polynomial constraints by hand, couldn’t be scaled safely. Our first Turing complete VM was the Cairo VM, which was a ZK-VM but one that wasn’t blockchain-safe. At inception we envisioned only StarkWare running this VM for its customers (Dexes and exchanges) and thus the blockchain attributes of sanitization and sandboxing were enforced internally when we wrote the code for those systems.
However, when we chose to develop Starknet as a general purpose L2, the issue of blockchain-safety raised its thorny head. To address this, we opted for a 2-step approach:
- HLL → Safe blockchain Intermediate Representation (Sierra): A high level language (like Cairo in the case of Starknet, or a Solidity-like language for Ethereum) is compiled to a blockchain-safe intermediate representation (Sierra). Sierra is a structured, typed intermediate representation designed for safety, determinism, and clear semantics.
- Sierra → zkVM: The Sierra code, already safe and gas-metered, is now compiled to a ZK-friendly VM for execution, supporting highly efficient proof generation. Starknet uses the Cairo VM but any of the aforementioned ZK-friendly VMs would be suitable for this purpose.
This approach also lends itself to fast native execution. To get this, one compiles the Sierra code for native execution (e.g., on x86 machines). Indeed, this approach is used by Starknet, via the Cairo-native compiler built by LambdaClass.
This two-step approach supports:
- Safe execution (and, with native compilation, also fast execution)
- Efficient proving using STARKs and recursive proof composition
- Flexible developer ergonomics, with growing support for high-level smart contract languages
The pros of this approach are execution safety and language structure, without compromising on proving performance. The cons of this approach are that it is a programming language and compilation stack that is non-standard (outside the context of the Starknet blockchain) which means that the developer experience, existing tooling, native execution performance and the ease of onboarding of new developers are worse than for standard non-blockchain toolchains. Additionally, the equivalence of the zkVM and native execution has to be established.
RISC-V as the next EVM - Challenges and Open Questions
Recall that what initiated this post is Vitalik’s suggestion to use RISC-V as the next EVM. To quote Vitalik, his suggestion
aims to greatly improve the efficiency of the Ethereum execution layer, resolving one of the primary scaling bottlenecks, and can also greatly improve the execution layer’s simplicity - in fact, it is perhaps the only way to do so.
The advantages of RISC-V are numerous - it is a general purpose ISA that is open source, and it has extensive tooling, good developer experience and support for numerous high level languages. Running in an emulated setting bypasses some of the main challenges having to do with gas metering, unsafe opcodes, etc. This might come at some loss of ecosystem benefits, as most RISC-V libraries assume unrestricted environments.
Which leads to the following open questions, which we suggest answering before deciding on it as the next EVM:
- How fast will a sandboxed, sanitized and gas-metered RISC-V VM be? .
- How efficient will zk-proofs be for the emerging code?
Conclusion
- Using existing architectures like RISC-V requires non-trivial modifications which may compromise the benefits of fast execution.
- ZK-proving general-purpose VMs will likely be less efficient than ZK-proving ZK-friendly VMs, and comparing the efficiency of the two approaches should be part of the research process of choosing the next EVM (assuming ZK-proving is one of the new EVM’s goals)
- A 2-step approach like Sierra + Cairo should be considered alongside the other two approaches – pure standard ISA (like RiscV/MIPS/x86) and pure ZK-VM (like Valida/Cairo/Miden).