## Beyond RISC-V: A Different Path for Ethereum Execution


Recently, Vitalik published an article on [Ethereum Magicians](https://ethereum-magicians.org/t/long-term-l1-execution-layer-proposal-replace-the-evm-with-risc-v/23617) proposing the replacement of the EVM with RISC-V to improve ZK-friendliness and achieve better performance. In this article, I would like to share the story behind Fluent, where we are pursuing similar goals, the challenges we encountered, how we are overcoming them as well as why we have chosen Blended Execution and what it means.

Before we start, here is a tiny glossary:

- STF \- state transition function
- ISA \- instruction set architecture
- EVM \- ethereum virtual machine
- ZK \- zero knowledge
- SVM \- solana virtual machine

## Introduction

At the time of its launch, EVM was a great virtual machine for the use case that it was created for, serving as an evolution of execution environments in blockchains, by introducing a Turing-complete environment. It was optimized to be efficient for hashing and signature verification operations, which heavily rely on 256-bit arithmetic. Even today, EVM can outperform other virtual machines in certain scenarios—for example, ERC20 smart contracts, which are fully based on 256-bit operations, can execute more efficiently on the EVM. Native CPU optimizations for 256-bit operations often deliver significantly better performance compared to running the same code on RISC-V, Wasm, or other platforms that lack carry flags or SIMD instructions.

However, performance is still a problem for developers especially when compute-heavy applications or custom cryptography is involved. Originally, Ethereum tried to solve the problem with eWasm, but that approach wasn’t successful because of backward compatibility issues, integration complexity and lack of gas/stack management functionality.

During the development of Fluent, we extensively researched most of these issues and can share potential solutions, along with their pros and cons, as well as the insights into Ethereum’s biggest bottlenecks when striving to balance ZK-friendliness and performance.

The goal is to build a fully operational EVM-equivalent protocol with a different VM (e.g. RISC-V or Wasm) underneath. It must preserve backward compatibility with the original EVM gas metering and state access model, while leveraging advanced ZK proving techniques and high-performance execution architectures. The protocol must remain backwards compatible with legacy EVM contracts and be migratable to the new scheme without any loss of performance or compatibility.

EVM equivalence entails support for all EIPs, hard forks, gas metering rules, the complete EVM opcode set, and more. Additionally, the architecture must remain compatible with Ethereum’s existing transaction model, as it directly influences gas metering via access lists. The system should also achieve so-called ZK-friendliness, making smart contracts significantly easier and cheaper to prove using zero-knowledge proofs, with state transitions that are more efficient to verify than in the original EVM architecture.

## Potential Approaches

There are two ways a VM to add support for EVM:

1. Multi-VM approach — maintains backward compatibility with existing EVM smart contracts by supporting multiple bytecode formats (e.g., EVM and RISC-V or EVM and Wasm).
2. Single VM approach — uses a single ISA to represent all VMs, either through bytecode compilation or emulation.

The former approach offers better runtime performance by allowing multiple VMs to coexist and leverage native CPU optimizations for executing different ISAs. This enables peak performance for both the EVM and the other VM simultaneously. However, its proving performance is inadequate: constructing a STF requires support for multiple ISAs, which slows down zero-knowledge proving and reduces the flexibility of the blockchain architecture for future modifications. Emulation does not solve this problem, as it introduces significant execution overhead and still results in slow proving.

The latter approach represents all VMs using a single ISA, improving proving performance by simplifying the STF. However, it introduces execution overhead due to the lack of native CPU optimizations and SIMD support for non-native VMs. This limitation can be mitigated by compiling all VM bytecodes into a single ISA, but this introduces potential security risks and requires thorough auditing of the compiler.

*Conclusion: the single VM approach appears more practical for achieving our goals, as it aligns with both performance and ZK-friendliness requirements. In the following sections, we assume a single VM model is used exclusively).*

## Technical Challenges

## Shared Memory Access

One of the biggest challenges is the shared memory access problem. Due to the stateful nature of EVM applications, the execution environment cannot determine in advance which data needs to be provided as input. Additionally, some data, such as balances or contract storage, may be modified during the execution of nested calls. In contrast, SVM requires the full state to be known before execution, and its lack of re-entrant calls enables a more stateless execution model.

In the EVM, this cannot be achieved without enforcing mandatory access lists that include all dependent contracts to be interacted with. Even if we assume full knowledge of a contract’s ABI and storage layout, this only solves the problem for accounts inside the CALLDATA; it still does not allow us to fully predict which storage slots or addresses will be accessed.

We cannot allow any existing EVM contracts to break, as that would violate full backward compatibility. The only viable approach is to account for every possible EVM contract to ensure the transition is fully compatible. Given these constraints, we now examine several architectural strategies to address them.

### Mandatory Access Lists

Smart contracts can be made stateless by enforcing mandatory access lists or by modifying the EVM transaction structure. However, this breaks backward compatibility with the original EVM execution model, as it alters gas calculations for cold and warm storage accesses.

Therefore, we cannot adopt this method, as it can only be applied to new transaction types. While this approach may be suitable for new chains with no legacy state, it still breaks compatibility with certain smart contracts—for example, those that compute storage slots based on the block number—which can lead to a high rate of failed executions.

Ideally, this method is the most efficient, as it enables deterministic, predictable scheduling with active parallelization and asynchronous transaction proving, where the final result can be aggregated into the STF. It also simplifies the optimistic ZK rollup model, since only failed transactions—or the STF without transactions—need to be verified, reducing challenge windows and accelerating L1/L2 interaction. But it’s not applicable to EVM.

// This contract won’t work with mandatory access lists most of the time
contract MandatoryAccessListsDoesNotWorkHere {
    address[] private addresses;
    function theFunctionWithRandomAccess() external { 
        payable(addresses[block.number % addresses.length]).transfer(1);
    } 
}

### Environment Emulation

One possible solution is to use environment emulation. Let’s assume that within EVM smart contracts we have instructions like BALANCE, SLOAD, SSTORE, etc. We can expose system built-ins via a C-API to access these state values. For example, instead of using the BALANCE opcode directly, we introduce a built-in function like “balance”.

This approach is only feasible if we emulate the environment or implement dedicated circuits for the state trie, allowing lookup of balances and other required parameters through a specialized state circuit. However, this significantly increases the complexity of the zkVM and makes proving much more expensive.

This method works partially but introduces significant performance overhead for proving, as it requires environment emulation to map system built-ins. The overall trace size can increase by 10–30x for computation-light applications and up to 1,000–10,000x for larger applications with small function sizes. While the cost of verifying “secp256k1” operations helps mitigate this overhead, it remains substantial—particularly when aiming for optimal performance in computation-intensive applications, especially if more efficient methods for signature verification are available.

### Execution Interruption

Let’s assume that all applications have zero resource access by default and start with empty access lists (the worst case scenario). In such cases, it’s unclear which resources need to be passed in advance. This reflects the current state of Ethereum, where only about 20% of transactions use access lists, and even then, misses cannot be fully avoided.

If a required resource is missing, it can be dynamically “requested” from an external source, such as another smart contract. To facilitate this, interruptions can be introduced, along with an interruption handling mechanism. In this approach, the STF acts as a system-level smart contract responsible for managing and providing access to shared resources.

This approach ensures EVM equivalence, even for transactions with completely missing access lists, since all necessary information can be fetched during execution. However, it introduces additional performance overhead due to the need to serialize messages between the smart contract and the STF, and the inability to fully manage raw pointers. These performance issues can be mitigated by implementing a stateless in-memory state cache. Still, consistency across contract calls and cache invalidation must be carefully managed, and the performance benefits must be benchmarked.

Alternatively, the cache can be stored in the STF memory context and accessed through special system built-ins, making it cheaper to prove. However, this requires an additional post-state modification check for each smart contract call, which may introduce critical vulnerabilities.

This concept enables contracts to operate in a semi-stateless manner, eliminating the need for additional circuits to manage shared state access. The cost of interruptions can be mitigated through state caching, but this is most effective when all contracts utilize access lists and avoid unnecessary re-entrant calls to avoid cache invalidation.

### Service Messaging

The idea behind contract messaging is similar to execution interruptions, with one key difference: instead of triggering an interruption, we send a “message” to the target smart contract, treating each contract as a background service. For example, consider two smart contracts, A and B. During execution, two VM instances are created—one for each contract. If contract A wants to call contract B, it sends a special “call” message along with input parameters. In this model, all contracts are kept in memory throughout the block’s execution and behave like background microservices. These services are only unloaded after the block is fully processed.

Although this approach may seem different from interruptions, it fundamentally relies on the same interruption concept—only the terminology changes from “interrupt” to “send”. The STF is still responsible for routing messages between contracts. However, this model eliminates the need for a state cache, as each smart contract’s memory persists throughout the lifetime of the block and is always up to date.

## Gas

The EVM has a complex gas calculation mechanism, with concepts that are not particularly friendly to other established VM constructions, such as gas refunds, account creation cost and cold/warm access costs. Any alternative VM, whether RISC-V or Wasm, has its own gas accounting model, which may not align with EVM’s. This mismatch can lead to incorrect gas calculations.

One solution is to inject special gas-charging instructions or system built-ins into all migrated smart contracts, and to apply an alternative gas policy for newly written contracts. While this partially addresses the issue, it breaks compatibility with certain EVM contracts that rely strictly on the original gas semantics. For instance, the GAS opcode reveals the remaining gas, and contracts using it may behave unpredictably under a different VM.

The most straightforward way to preserve full backward compatibility with EVM gas policies is to use manual gas charging for trusted smart contracts. For example, an EVM runtime implemented on Wasm or RISC-V could manually deduct gas in accordance with EVM rules. This approach does not require ISA modification and can be implemented using system built-ins.

## Exploring Different ISAs

*In the following comparison, we focus only on RISC-V, Wasm, and EVM, as other VMs share similar architectural concepts. For example: LLVM IR features an ISA comparable to Wasm but includes more compilation-optimized instructions and extensions for native CPU targets; FuelVM is another context-dependent EE binary script language, similar to the EVM; MIPS is another reduced instruction set architecture similar to RISC-V; and Intel/AMD ISAs are not practical in this context.*

What is the best ISA for our goals? Before we begin, it's important to acknowledge that none of the existing VMs fully solve the problem. The primary reason is that they were designed for traditional CPU computation, not ZK proving. To achieve true ZK-friendliness, we would need a highly reduced ISA optimized for elliptic curve operations. That said, let’s start by comparing the available options.

#### RISC-V

RISC-V is an open-source hardware architecture with a wide range of extensions. It is widely used in many zkVMs today due to its 32-bit support, memory alignment, and simple ISA. However, RISC-V enforces strict execution rules in trusted environments, requiring additional bounds checks for memory and stack operations. Current implementations of RISC-V-based zkVMs—such as SP1, RiscZero, and others—operate within trusted environments to reduce proving overhead. However, smart contracts are untrusted by nature, and pre-verification is ineffective for certain instructions, such as memory loads/stores and jumps.

To achieve trustless execution of RISC-V, significant modifications to the executor are required, starting with verification of the binary structure (e.g., ELF segments, instruction encoding) and including bounds checks for memory and stack access. Adding these checks increases the complexity of the zkVM circuits, which can significantly reduce performance.

Such modifications may not be necessary for stateless VMs like SVM, where an invalidation proof is still required—but this approach does not work for the EVM account model.

*Conclusion: RISC-V offers ZK-friendly 32-bit extensions, and its memory alignment fits well within a 31-bit curve. However, it lacks built-in bound checks, was not originally designed for sandboxed computation, and has a complex binary structure that makes verification difficult.*

#### WebAssembly

WebAssembly (Wasm) is a sandboxed virtual machine primarily designed for in-browser computations. It has strong community support, having been under development for over eight years, and offers broad compatibility with multiple languages, compilers, and both AOT and JIT runtimes. Originally designed for trustless computation, WebAssembly enforces standardized constraints and strict, deterministic binary verification rules. It also supports a wide range of extensions, including SIMD, atomic operations, threading, and more.

However, binary verification is also one of Wasm's major pain points, along with its complex binary format, which includes LEB128-encoded values, optional segments, and a lack of memory alignment. Supporting these features introduces significant performance overhead for zero-knowledge proving.

*Conclusion: Wasm appears more promising than RISC-V due to its broader community support and the potential for higher performance through well-established AOT and JIT compilers. Its standardized binary verification and execution rules align well with the requirements of trustless computation in blockchain environments. However, its binary structure is not well-suited for ZK operations.*

Each of the technologies described above has its own strengths and weaknesses, but none offers a single, practical solution that fully addresses the problem. So instead, we propose combining them into a unified system that meets our goals.

## Blended Execution

We call this system Blended Execution because it literally “blends” different concepts, ideas, technologies, standards, VMs, and execution environments into a cohesive framework. It's not tied to a single product—it's a system designed to bridge efficient execution with zero-knowledge proving.

In this section, we will define Blended Execution more formally and bring together all our conclusions. Blended Execution is not a specific technology; rather, it's a conceptual approach that combines various technologies and ideas into a unified framework. It addresses the previously discussed challenges—including shared memory access, gas calculation, ZK proving efficiency, and high-performance execution—by integrating solutions in a cohesive model.

### rWasm

The core of Blended Execution is its virtual machine— in our case, rWasm (reduced WebAssembly). We found that it is impossible to solve both fast CPU execution and efficient ZK proving by using any existing VM, which led to the development of rWasm. rWasm is a specialized VM that combines the strengths of both RISC-V and Wasm. It follows strict Wasm-compatible deterministic verification rules while offering the ZK-friendliness of RISC-V. Since rWasm is derived from Wasm, it inherits all Wasm validation rules and maintains support for sandboxed execution. In essence, rWasm is an alternative binary representation of a Wasm binary.

When a Wasm application is deployed, a compilation proof is generated—either on-chain or off-chain—and verified during deployment. This compilation proof ensures the integrity of the Wasm binary structure (including segments, function types, branches, and stack overflows/underflows). After validation, the Wasm code is translated into rWasm IR and stored in the account trie.

The key insight is that because rWasm is derived from Wasm, and the compilation proof guarantees structural correctness, rWasm ISA maintains full backward compatibility with Wasm. Therefore, the state transition for both is identical. This means Wasm and rWasm can be used interchangeably for execution. By leveraging this, we can use Wasm for faster execution and rWasm for efficient zero-knowledge proving.

In addition, rWasm supports a 32-bit execution trace extraction mode, where 64-bit stack operations are replaced with 32-bit equivalents to better align with 31-bit field elements, resulting in more efficient proving.


*Fig. 1\. Comparison of trace sizes for precompiled rWasm versus Wasmi running on RISC-V.*

However, rWasm requires a stateless model to function effectively without a stateless approach, which is incompatible with the EVM’s state transition model. To address this, we rely on the interruption mechanism introduced earlier. rWasm uses interruptions to send messages to the STF, requesting missing information from the state trie.


*Fig. 2\. Example of smart contract A calling smart contract B using interruptions.*

### EVM

To achieve full compatibility with the EVM, we implement system precompiled contracts (also known as the EVM loader or compatibility contracts). These special contracts are always gasless, preloaded, and executed using an AOT compiler. Their purpose is to replicate EVM smart contract deployment and execution rules. This contract exposes two entry points to enable deployment and execution compatibility. Most of the EVM's state transition and gas logic is moved into the Wasm contract, along with other precompiled contracts such as “blake2f”, “bls12381”, “ecrecover”, and others. This design simplifies the development and upgradeability of EVM standards and contributes to a more forkless system architecture.

Performance-wise, Blended Execution achieves nearly the same efficiency as a native, CPU-optimized EVM runtime. In fact, performance can be further improved—potentially exceeding that of traditional EVM implementations—by leveraging precompilation techniques.

To assign EVM contracts for execution via the EVM precompiled runtime, we use EIP-7702. During the deployment of an EVM application, an EIP-7702 account is created and delegated to the EVM runtime. Since smart contracts do not have private keys, authorization for this account cannot be revoked. This supports the concept of account ownership: because the account is delegated to a trusted contract, it can manage its own state without compromising the security of the chain or other execution environments.

### Extensibility

The Blended Execution system is designed to be fully extensible, meaning that other VMs—and even entire EEs—can be integrated into the runtime by adding new system precompiled runtimes. This is how compatibility with SVM is achieved. Moreover, modifications to the account structure or storage model do not affect compatibility with EVM contracts, as these contracts are delegated to a runtime that enforces specific constraints and execution rules. The same principle applies to the SVM runtime, which can only affect accounts it owns.

### ZK

The complexity of “blending” arises when ZK proving is introduced. Since rWasm is optimized for ZK-compatible state transitions, it eliminates certain instructions and introduces a dedicated entry point required to initialize all application resources. This design removes the need for additional circuits during program initialization, particularly when some resources remain unused. Thanks to its optimized and pre-verified binary representation, rWasm can begin execution almost immediately—without full decoding or additional pre-execution checks.

According to recent benchmarks, the rWasm ISA integrated into SP1 achieves the proving performance comparable to native SP1, while eliminating interpretation overhead. This optimization results in a reduction in trace size ranging from 10x to as much as 10,000x for smart contract calls.

## Conclusion

Both RISC-V and Wasm are strong candidates for replacing the EVM, but neither can achieve optimal execution performance and ZK efficiency in their original form. This is why a combined approach is necessary. Blended Execution offers a balanced trade-off between high execution performance and efficient proving.

Wasm appears to be a more desirable option compared to RISC-V, thanks to its robust AOT compilation support, extensibility, and built-in SIMD capabilities—which can accelerate 256-bit operations and matrix computations. Additionally, browser support enables off-chain computation directly in the browser, allowing for dedicated in-browser contracts with state management and proof aggregation. Edge computing, combined with Wasm and verifiable compute, helps bridge the gap between Web2 and Web3, enabling seamless integration.

Blended Execution is a conceptual framework that combines multiple ideas, including: a ZK-friendly rWasm VM fully compatible with Wasm transitions; an AOT-driven Wasm execution environment for near-native execution speed; a compilation proof for transitioning from Wasm to rWasm; EIP-7702 to enable account ownership for EVM and SVM runtimes; an interruption system for shared state access; and the stateless nature of applications to eliminate interpretation overhead.