Vitalik Buterin Considers RISC-V a Crucial Part of the EVM

According to Ethereum co-founder Vitalik Buterin, the Reduced Instruction Set Computing V (RISC-V) is a significant element in the Ethereum virtual machine (EVM). Buterin noted that the open-source instruction set is crucial in the existing validity proof formal verification roadmap.

The Ethereum co-founder acknowledged this while responding to a blockchain developer who sought his permission to work on an aspect of the EVM. The dev proposed having Ethereum’s beacon chain run the RISC-V and running the EVM in it. According to the dev, that would “make a lot of sense.” Buterin referred the developer to Alexander Hicks, an Ethereum team member working on formal certification and AI.

Related: Ethereum Vitalik Buterin’s Vision for User-Friendly Crypto Transactions Gains Momentum

Meanwhile, the developer cited Buterin’s EVM as the most economical, with the highest execution risk. Hence, he proposed managing the project and introducing RISC-V on the beacon chain before running the EVM in the modified chain.

It is worth noting that RISC-V is an open-source instruction set architecture based on established reduced instruction set computer principles. The protocol allows for implementation by anyone, including those without a license. RISC-V’s fundamental role in computing is to dictate how a processor executes instructions, with an instruction set architecture defining the interface between software and hardware.

Notably, RISC-V emphasizes simplicity and efficiency in executing instructions. Therefore, it facilitates simplified chip design, reduces complexity, and allows for a more straightforward optimization of hardware and software interactions.

Related: Vitalik Buterin Calls for Standardized Protocol to Bridge Ethereum’s Layer-2 Gap

After receiving Buterin’s go-ahead and noting his openness to improving the Ethereum network, the developer added to his initial proposal. He suggested re-evaluating the Ethereum’s execution layer (EL) and switching how it would work. According to the dev, that could involve a simplified process of wrapping QEMU in the engine API.