Investron

Vitalik proposes RISC-V instead of EVM as future $ETH L1 execution scaling and I will explain what's blockchain VMs and how they differ.
Virtual machines (VMs) are fundamental to many technologies, from routine software testing to powering entire data centers. However, the purpose of a VM varies greatly. Traditional VMs, exemplified by running Ubuntu on VirtualBox, primarily aim to simulate complete operating system environments, providing flexibility and isolation on a single physical machine. In contrast, blockchain VMs—such as the Ethereum Virtual Machine (EVM), WebAssembly (WASM), Solana’s Sealevel Virtual Machine (SVM), and Nervos CKB-VM (RISC-V)—are engineered for deterministic, secure, and decentralized execution of smart contracts. Although both types share the core concept of "a computer within a computer," their design priorities and technical demands diverge significantly. Recognizing these differences is crucial for developers, businesses, and enthusiasts to select the appropriate tool, whether for simple development and testing or for building complex decentralized applications.
Traditional Virtual Machines (Ubuntu, Linux, and More)
Traditional VMs offer a virtualized environment that emulates a full operating system, like Ubuntu, on top of a host OS such as Windows or macOS. A hypervisor manages this setup, allocating hardware resources—CPU time, RAM, and storage—between the host and the guest operating systems. The inherent isolation of each VM means that issues like crashes or malware within one VM typically do not affect the host OS or other VMs.
In enterprise and development settings, traditional VMs provide several key advantages. Firstly, they enable developers to test software across various operating systems without requiring separate physical hardware. Secondly, they enhance security by containing each environment, thereby limiting the impact of failures or attacks. Thirdly, traditional VMs improve hardware utilization, allowing organizations to consolidate servers and reduce costs by running multiple virtual machines on fewer physical devices. Despite these benefits, the resource overhead of running a complete operating system within each VM is substantial, consuming resources that could otherwise be used by the applications themselves.
The Need for Specialized VMs in Blockchain
While traditional VMs focus on replicating entire operating systems, blockchain VMs address a different critical requirement: ensuring that every node in a decentralized network executes the same code and arrives at identical results to maintain consensus. Practically, this necessitates blockchain VMs to enforce strict rules regarding arithmetic operations, memory allocation, and resource usage to guarantee determinism. If different nodes produced varying outcomes from the same transaction, the blockchain would fail to achieve consensus, potentially leading to network splits and a loss of trust in the ledger.
Furthermore, blockchains operate in potentially hostile environments, demanding robust security. Malicious actors might try to exploit vulnerabilities in smart contracts or the VM itself to steal funds or corrupt the network's state. Consequently, blockchain VMs sandbox the execution of contracts and meticulously track resource consumption—typically through mechanisms like "gas," "cycles," or similar fees—to prevent denial-of-service attacks or infinite loops. These considerations give blockchain VMs a unique character: they are more focused and specialized than general-purpose operating systems, yet they must be sufficiently robust to handle complex, Turing-complete logic in a deterministic manner.
Ethereum Virtual Machine (EVM)
Introduced by Ethereum in 2015, the EVM pioneered the concept of a widely adopted blockchain VM, establishing a model for how decentralized applications (dApps) could operate on a shared global computing platform. It employs a stack-based architecture and processes 256-bit words, a design choice partly intended to simplify cryptographic operations and ensure consistency across diverse hardware. However, this 256-bit model introduces overhead when running on typical 64-bit CPUs, as operations that are single steps in a 64-bit environment may require multiple operations on the EVM.
Developers write EVM smart contracts in high-level languages such as Solidity or Vyper, which are then compiled into EVM bytecode. The EVM interprets each opcode, charging users "gas" for every operation performed. While this mechanism effectively mitigates denial-of-service attacks, it also reveals certain inefficiencies. Interpretive execution can be slower than compiled approaches, and the pricing of gas can be challenging to optimize. Upgrading or extending the EVM often necessitates a hard fork of the Ethereum network, which can limit flexibility in implementing new cryptographic tools or performance optimizations. Nevertheless, the EVM's extensive ecosystem of developer tools, libraries, and community support makes it a prevalent choice for many dApps.
WebAssembly (WASM)
WebAssembly (WASM) originated in the web browser context, providing a platform-agnostic bytecode format that web browsers could execute at near-native speeds. Its success in web environments soon garnered attention within the blockchain space, where performance, modularity, and flexibility in programming languages are highly valued. Unlike the EVM, WASM uses standard 32-bit or 64-bit word sizes, aligning it more closely with modern CPU architectures. This alignment reduces some risks of integer overflow and lowers overhead compared to Ethereum’s 256-bit words.
Furthermore, WASM supports Just-In-Time (JIT) or Ahead-of-Time (AOT) compilation, enabling code to be translated into native instructions for the underlying hardware. This approach can significantly accelerate execution compared to interpretive models. Developers can also write smart contracts in various languages such as Rust, C, C++, AssemblyScript, or others that can be compiled to WASM, making it more accessible to developers not familiar with Solidity. While WASM’s evolving specifications—particularly features like threads and SIMD—are not always directly applicable to blockchains (which require deterministic execution), it remains a compelling option for platforms like Polkadot, $NEAR and Cosmos that aim for broader language support and higher transaction throughput.
Solana’s Sealevel Virtual Machine (SVM)
Solana’s Sealevel Virtual Machine (SVM) adopts a different strategy, prioritizing high throughput and parallelism. It compiles smart contracts into Berkeley Packet Filter (BPF) bytecode, initially designed for efficient filtering of network packets in operating systems. By leveraging multi-core hardware and segmenting the network’s state, Solana can process thousands of transactions concurrently, provided these transactions do not need to modify the same data. This approach contrasts sharply with many single-threaded or limited concurrency environments like the EVM, allowing $SOL to achieve transaction throughput levels that traditional blockchains struggle to match.
However, this speed comes with certain trade-offs. The hardware requirements for running a Solana validator are relatively high, which can potentially impact network decentralization. Managing state collisions—where multiple transactions attempt to modify the same on-chain data—also adds complexity to the design. Nevertheless, for high-velocity decentralized finance (DeFi) applications or NFT platforms, SVM’s parallelism offers the capacity to handle surges in traffic that would overwhelm less scalable systems.
CKB-VM (RISC-V)
Nervos Network’s CKB-VM utilizes the RISC-V instruction set, notable for its open-source nature, simplicity, and modularity. Unlike WASM, which was initially designed for browsers, RISC-V is an actual CPU architecture that can be implemented in hardware or emulated in software. By compiling smart contract code to RISC-V instructions, the CKB-VM gains several distinct advantages. Firstly, it avoids the overhead of interpretive execution if running on RISC-V hardware—potentially achieving near-native speeds. Secondly, it allows developers to introduce new cryptographic primitives or data structures directly as on-chain scripts without requiring a network-wide upgrade. This design fosters a high degree of flexibility and extensibility while still maintaining determinism.
Because RISC-V is less established in the blockchain space compared to EVM or WASM, the tooling around CKB-VM is not as extensive. However, languages like Rust, C, and Go already offer cross-compilation to RISC-V. This combination of flexibility, performance potential, and a future-proof design could become increasingly valuable as the industry seeks to integrate advanced cryptography (such as zero-knowledge proofs) without requiring disruptive protocol changes.
Comparisons: Resource Metering, Determinism, and Beyond
All blockchain VMs share fundamental characteristics to ensure the stability and security of decentralized consensus. Firstly, each VM implements resource metering—whether termed gas, cycles, or compute units—to discourage infinite loops and malicious code execution. Secondly, determinism is paramount: a contract that produces different outcomes on different machines would undermine the integrity of the ledger. By enforcing strict rules on how data is processed (e.g., integer arithmetic without floating-point operations), blockchain VMs guarantee consistent results across all nodes.
Despite these commonalities, each design involves unique trade-offs:
* EVM: Benefits from a rich ecosystem and extensive developer support but suffers from slower execution and a 256-bit architecture that can be inefficient on modern CPUs.
* WASM: Offers high performance, broad language support, and near-native compilation, but its specification and toolchain are still evolving.
* SVM: Provides extreme parallelism for high throughput, but comes with higher hardware demands and potential concerns regarding decentralization.
* CKB-VM (RISC-V): Features a minimalistic instruction set for speed and extensibility, although its adoption and tooling are less widespread than EVM or WASM.
Conclusion
While both traditional VMs and blockchain VMs are fundamentally "computers within computers," their objectives and constraints differ significantly. Traditional VMs aim to replicate entire operating environments—offering the convenience of running Ubuntu on a Windows host for testing or enhanced security through isolation. Blockchain VMs, in contrast, specialize in synchronizing computation across potentially thousands of nodes, each required to interpret and validate the same code identically. This results in a range of specialized execution environments—EVM, WASM, SVM, and RISC-V-based CKB-VM—that prioritize security, determinism, and performance in distinct ways. Understanding these nuances is essential for developers and enterprises to choose the appropriate VM for their specific use case, whether it involves building a DeFi protocol on Ethereum, experimenting with parallel execution on Solana, or leveraging the extensibility of a RISC-V-based blockchain. As decentralized technology continues to evolve, the ongoing development of these VMs will undoubtedly shape how we build and operate the next generation of blockchain applications.
#VitalikButerin #ScalingETH
#ETH #RISC_V #explain