How Vitalik’s RISC-V Proposal Achieves Compatibility with Existing Smart Contracts

Vitalik Buterin’s proposal to replace the EVM with RISC-V aims to enhance execution efficiency and protocol simplicity while ensuring a smooth transition for the existing smart contract ecosystem. The compatibility implementation strategy combines architectural innovation with a gradual migration path, as detailed below:

______

⚙️ 1. Dual Virtual Machine Coexistence Architecture (Core Compatibility Solution)

1. Parallel Execution Mechanism

   • Coexistence of Old and New Virtual Machines: The protocol layer supports both EVM and RISC-V virtual machines simultaneously, allowing developers to freely choose the development architecture for new contracts. Existing EVM contracts can continue to run without modification, while new contracts can be directly written based on RISC-V.

   • Bidirectional Interoperability: Through the cross-virtual machine call interface defined at the protocol layer, when RISC-V contracts call EVM contracts, special system calls (such as simulating the CALL opcode) will be triggered; conversely, the call requests received by EVM contracts will be parsed into standard transaction formats, ensuring seamless interaction.

2. Transition Period Design

   • Developer-Invisible Upgrade: Languages like Solidity/Vyper will continue to serve as contract development tools, requiring only adjustments to the compiler backend (e.g., compiling Solidity code into RISC-V bytecode instead of EVM bytecode), so developers do not need to learn a new language or refactor logic.

   • Toolchain Compatibility: Development and debugging tools (such as Truffle, Hardhat) and security auditing frameworks will adapt to the RISC-V instruction set, avoiding ecosystem fragmentation.

______

🔄 2. On-Chain EVM Interpreter (Radical Compatibility Solution)

1. Interpreter Contract Mechanism

   • Protocol-Level Interpreter: The functionality of the EVM instruction set will be encapsulated into an on-chain interpreter contract written in RISC-V. All historical EVM contract code will be converted into call parameters for this interpreter (such as passing in the original EVM bytecode and input data), which will execute and return results.

   • Example Process:

   • Advantages and Risks

     • Protocol Simplification: The consensus layer only needs to support RISC-V native instructions, significantly reducing the complexity of specifications (e.g., removing redundant opcodes like SELFDESTRUCT).

     • Performance Trade-off: Initial interpreted execution may lead to lower efficiency than native EVM, relying on ZK proof optimization to improve proof speed.

______

🛠️ 3. Migration Path and Compatibility Layer Design

1. Phased Migration Strategy

   • Phase 1: Introduce RISC-V support, allowing new precompiled contracts (such as cryptographic functions) to directly use RISC-V implementations, gradually replacing EVM precompiled contracts.

   • Phase 2: Remove non-core precompiled contracts (such as elliptic curve operations) in a hard fork, replacing them with equivalent contracts implemented in RISC-V, maintaining call compatibility through address redirection.

   • Phase 3: After several years, migrate historical EVM contracts to the on-chain interpreter model, ultimately achieving a protocol layer that only natively supports RISC-V.

2. Security Sandbox and Gas Model Adaptation

   • Deterministic Execution Assurance: The RISC-V virtual machine must restrict non-deterministic operations (such as floating-point calculations) and isolate system calls through a sandbox mechanism, ensuring the same execution environment security as EVM.

   • Gas Model Reconstruction: Design a new gas pricing standard for RISC-V instructions, making it more aligned with ZK proof costs (e.g., charging based on actual computation cycles), while mapping the gas consumption of EVM opcodes through the compatibility layer.

______

💻 4. Developer Experience and Ecosystem Tools

1. Language and Tool Compatibility

   • Compiler Adaptation: The Solidity compiler (such as Solc) will add a RISC-V backend, allowing developers to continue using the original language to write contracts, with only the underlying bytecode format changing.

   • Multi-Language Support: Open the possibility of writing contracts in mainstream languages like Rust/C++, but migration is not mandatory to avoid ecosystem fragmentation.

2. Infrastructure Upgrades

   • Node Clients: Clients like Geth and Nethermind need to support dual virtual machine engines, with historical data storage compatible with the original format (such as Merkle Patricia trees).

   • Cross-Chain Compatibility: Sidechains and Layer 2 (such as Polygon, BSC) need to synchronize and adapt to the new bytecode, or convert transaction formats through middleware.

______

⚖️ 5. Community Practices and Technical References

1. Successful Case Studies

   • Nervos CKB: Has implemented RISC-V as the main chain virtual machine, allowing its contracts to directly call C language libraries, validating the feasibility of RISC-V in blockchain environments.

   • Arbitrum Stylus: Supports multi-language contracts through WASM, providing migration experience for RISC-V developer toolchains.

2. Risk Hedging Design

   • Interpreter Plugin Mechanism: The protocol reserves interfaces for future insertion of other virtual machines (such as Move, WASM), avoiding technological lock-in.

   • Formal Verification: Conduct formal proofs on the RISC-V interpreter and cross-layer calling logic to ensure compatibility logic is free of vulnerabilities.

______

💎 Conclusion: Core Logic of Compatibility Implementation

Vitalik’s proposal is based on the premise of minimizing ecosystem disruption, achieving a smooth transition from EVM to RISC-V through a three-stage path of dual virtual machine parallelism → interpreter encapsulation → final protocol unification, seamlessly adapting the toolchain. Essentially, it shifts the historical compatibility burden from the protocol layer to the application layer (such as the on-chain interpreter), ensuring the continued operation of existing contracts while bringing a qualitative change to execution layer efficiency and simplicity.

As Vitalik stated: “The protocol layer should be an underlying facility that does not need to be understood, and compatibility should be achieved by encapsulating complexity.” — This design philosophy runs through the entire migration architecture.