What Exactly Is RISC-V? Why Does Vitalik Want to Replace the EVM with It? Why Has It Sparked Community Debate?
In recent days, one of the hottest topics in the crypto community has been RISC-V. The spark for the discussion came from Vitalik's idea of replacing the EVM with RISC-V, which has stirred considerable debate. So, what exactly is RISC-V? Why does Vitalik want to replace the EVM with it? And why has it caused such a stir in the community? This article will break it all down for you.
On April 20, Vitalik Buterin published a post titled “Long-term L1 execution layer proposal: replace the EVM with RISC-V,” in which he shared the idea of using RISC-V to replace the EVM as the virtual machine language for writing smart contracts. The goal is to significantly improve the efficiency of Ethereum's execution layer, address one of its major scaling bottlenecks, and greatly simplify the execution layer. He even noted that this might be the only way forward.
What Is RISC-V?
The core idea behind RISC is: each instruction performs a single function and has a fixed format, making it easier to execute instructions in a pipelined and parallelized way. In contrast, traditional CISC architectures (like x86 or ARM) contain a wide variety of complex instructions and require sophisticated decoders.
RISC-V was initiated in 2010 by a team at the University of California, Berkeley, and has since evolved to its fifth version, all while maintaining the open-source spirit of the BSD license. Any enterprise or academic institution can build its own custom instruction sets on top of it.
Put simply, RISC is a real-world computer language that engineers use to build chips and processors. It has now reached its fifth generation—RISC-V. Unlike the closed ecosystems of Intel or ARM, RISC-V is open-source—anyone can build on top of it. Think of it as the Linux of computer hardware. It's open, customizable, and rapidly growing.
Why Replace the EVM with RISC-V?
- Better Performance for Zero-Knowledge Proofs
The Ethereum ecosystem has a high demand for ZK-Rollups, ZK-SNARKs/PLONK, etc. But when generating zk circuits, converting EVM bytecode and memory access into constraint systems comes at a high cost.
RISC-V, being a widely used real-world Instruction Set Architecture (ISA), already has mature ZK compilers like ZKLLVM and Pepper, which can directly map RISC-V instructions to circuits—greatly improving performance and efficiency.
- Easier Long-Term Development and Maintenance
To maintain backward compatibility with old protocols, EIPs, and community needs, the EVM has been bloated with new instructions and features, resulting in a massive codebase that's hard to refactor.
RISC-V is built on modular standards: its base instruction set is minimal, with many optional extensions (atomic ops, floating point, vector instructions). It leaves complexity to the application layer, allowing the execution layer to be implemented in just a few thousand lines of C code.
- Compatibility with Mainstream Tools and Compilers
Most blockchain developers are already comfortable with C/C++, Rust, Go, and similar languages, which are all based on LLVM and GCC compilers under the hood.
With native support for RISC-V, the on-chain execution layer can directly output binaries from mainstream compilers. Developers only need to write in standard languages to compile, debug, and verify contracts with a single command—massively lowering the learning curve.
- A Simpler, More Efficient Blockchain Design Path
The current EVM + Solidity model involves two layers of abstraction: you write in a high-level language, compile it into EVM bytecode, then execute it via an interpreter.
With RISC-V, you can directly execute “native” contracts, skipping the intermediate layer, shortening the instruction path, and greatly improving throughput and execution determinism.
Conclusion
The proposal to replace the EVM with RISC-V paints a future that is more open-source, universal, and efficient. But to make this vision a reality, it will have to overcome major challenges like compatibility, governance, forks, and development costs.
