This document explores a technical experiment: transitioning Ethereum's execution sandbox from the EVM to the RISC-V Instruction Set Architecture (ISA). We'll cover the proposed design, the new components required, and the ideologies behind creating a more powerful, backward-compatible Ethereum node.
The Goal
The objective is to design an Ethereum node that uses a RISC-V VM as its native execution sandbox. Critically, this new node must remain fully backward-compatible, supporting EVM smart contracts deployed both before and after this architectural change. This means EVM and RISC-V contracts must be able to coexist and interact seamlessly.
Ethereum's Current Architecture: The EVM
Today, all smart contract logic on Ethereum runs within the Ethereum Virtual Machine (EVM). The lifecycle of a contract is split into two main phases.
Smart Contract Deployment (CREATE)
Deployment transforms source code (like Solidity) into a live contract on the blockchain. The process involves compiling the code into init bytecode (which runs once to set up the contract) and runtime bytecode (the final logic stored on-chain). An Externally Owned Account (EOA) or another contract sends a transaction containing this init code. The EVM executes it, and if successful, the runtime bytecode is stored at a newly computed address, making the contract active.
Smart Contract Interaction (CALL)
To interact with a deployed contract, a transaction is created with the target address and a data payload specifying the function and arguments. When a validator processes the transaction, the EVM loads the contract's runtime bytecode and executes the requested function. During execution, a contract can read/write to storage, transfer ETH, and even call other contracts. The outcome is either a successful state change or a revert, where all changes are undone but the sender still pays for the gas used.
The Proposed Hybrid Architecture
The core of this experiment is to replace the EVM with a constrained RISC-V VM. This isn't about running a full Linux distribution on-chain; it's about creating a purpose-built execution sandbox for smart contracts that leverages the power and flexibility of RISC-V. Communication with the blockchain state (storage, precompiles) would be handled via syscalls.
For native RISC-V contracts (e.g., written in Rust and compiled to RISC-V), the deployment and interaction flows would be analogous to the current EVM process but would execute directly on the new, more performant RISC-V VM.
The real challenge—and the most interesting part of this design—is achieving seamless backward compatibility. How can a RISC-V VM execute old EVM contracts?
Solving for Backward Compatibility
Two primary hurdles must be overcome: differentiating between bytecode types and executing legacy EVM code.
1. Differentiating EVM and RISC-V Bytecode
With both EVM and RISC-V contracts on the same chain, the node needs a way to know which execution environment to use for a given address. Modifying the account schema to add a flag would be a breaking change.
A more elegant solution is to leverage a magic number at the beginning of the bytecode. Similar to the Ethereum Object Format (EOF) EIP which uses 0xEF to identify EOF-formatted contracts, a new prefix could be introduced to flag bytecode as a RISC-V variant. When the node fetches contract code, it can instantly identify the target architecture based on this prefix.
0xEF...-> EOF-compliant EVM code0x??...-> RISC-V code (with a new designated magic number)- Anything else -> Legacy EVM code
This approach is simple, efficient, and avoids disruptive state changes.
2. Executing EVM Code with a mini-evm Emulator
To run legacy EVM contracts, we introduce a mini-evm emulator. This is not a full-fledged, separate virtual machine but rather a specialized system contract or precompile that lives within the RISC-V VM.
When a transaction targets an EVM contract, the process is as follows:
- The node identifies the bytecode as EVM-based (either legacy or EOF).
- Instead of executing it directly, the node invokes the
mini-evmsystem contract. - The EVM bytecode is passed to the
mini-evmas context. - The
mini-evminterprets the EVM bytecode instruction by instruction. When it encounters opcodes that interact with the blockchain state (e.g.,SSTORE,SLOAD,CALL,LOG), it makes the correspondingsyscallto the parent RISC-V VM to perform the action.
This design effectively translates EVM execution into the native language of the RISC-V environment. The mini-evm acts as an on-the-fly interpretation layer, ensuring that all state changes, whether initiated from a RISC-V or EVM contract, are handled consistently by the core RISC-V VM.
This hybrid model proposes a viable path for evolving Ethereum's execution engine to the more modern and flexible RISC-V ISA without sacrificing the existing ecosystem. By using a magic number for bytecode differentiation and a mini-evm emulator for backward compatibility, the chain can support both legacy and next-generation smart contracts within a single, unified architecture.
Potential benefits of such a switch are significant, including support for mature programming languages like Rust and C++, access to a robust toolchain, and potential performance improvements. However, this experiment also highlights key challenges that would need to be addressed, such as designing a fair and comprehensive gas metering model for the complex RISC-V instruction set and ensuring the mini-evm emulator is both highly performant and secure.
Ultimately, this experiment demonstrates that a fundamental architectural shift is possible, paving the way for a more powerful and developer-friendly Ethereum in the future.