# A Hybrid Ethereum: Experimenting with a RISC-V Execution Engine

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 code
* `0x??...` -> **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:

1. The node identifies the bytecode as EVM-based (either legacy or EOF).
2. Instead of executing it directly, the node invokes the `mini-evm` system contract.
3. The EVM bytecode is passed to the `mini-evm` as context.
4. The `mini-evm` interprets 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 corresponding `syscall` to 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.