Parallel EVM: The Heart Surgery of High-Performance Layer 1

Original Title: "Parallel EVM: The Heart Surgery of High-Performance Layer1"

Source: Xiaozhu Web3

EVM: The Core of Ethereum

The EVM (Ethereum Virtual Machine) is the core of Ethereum, responsible for running smart contracts and processing transactions.

Virtual machines are typically used for the virtualization of real computers, usually by a "hypervisor" (like VirtualBox) or an entire operating system instance (like Linux's KVM). They must provide software abstractions of actual hardware, system calls, and other kernel functions.

The EVM operates in a more limited domain: it is merely a computation engine, providing abstractions for computation and storage, similar to the Java Virtual Machine (JVM) specification. From a high-level perspective, the JVM aims to provide a runtime environment independent of the underlying host operating system or hardware, ensuring compatibility across various systems. Similarly, the EVM executes its own bytecode instruction set, typically compiled from Solidity.

The EVM is a quasi-Turing complete state machine, "quasi" because every execution step consumes a finite resource called Gas. Therefore, any given smart contract execution is limited to a finite number of computation steps, preventing potential infinite loops that could halt the entire Ethereum platform.

The EVM lacks scheduling capabilities; Ethereum's execution module extracts transactions from blocks, and the EVM is responsible for executing them sequentially. During execution, the latest world state is modified, and after a transaction is completed, the state is accumulated to the latest world state after the block is completed. The execution of the next block strictly depends on the world state after the previous block's execution, making it difficult to optimize Ethereum's linear transaction execution process for parallel execution.

In this sense, the Ethereum protocol stipulates that transactions are executed sequentially. While sequential execution ensures that transactions and smart contracts can be executed in a deterministic order, ensuring security, it can lead to network congestion and delays under high load, which is why Ethereum has significant performance bottlenecks and requires Layer2 Rollup scaling.

The Path to Parallelism in High-Performance Layer1

Most high-performance Layer1 solutions are designed to optimize the inability of Ethereum to process transactions in parallel. Here, we will only discuss optimizations at the execution layer, namely virtual machines and parallel execution.

Virtual Machines

The EVM is designed as a 256-bit virtual machine to facilitate Ethereum's hash algorithms, which explicitly produce 256-bit outputs. However, the actual computers running the EVM need to map these 256-bit bytes to the local architecture to execute smart contracts, making the entire system very inefficient and impractical. Therefore, high-performance Layer1 solutions often use virtual machines based on WASM, eBPF bytecode, or Move bytecode instead of the EVM.

WASM is a small, fast-loading, portable bytecode format based on sandbox security mechanisms. Developers can write smart contracts in various programming languages (C/C++, Rust, Go, AssemblyScript, JavaScript, etc.), compile them into WASM bytecode, and execute them. WASM has been adopted as a standard by many blockchain projects, including EOS, Dfinity, Polkadot (Gear), Cosmos (CosmWasm), Near, and Ethereum will also integrate WASM in the future to ensure a more efficient, simple execution layer suitable for a fully decentralized computing platform.

eBPF, originally BPF (Berkeley Packet Filter), was initially used for efficient filtering of network packets. It evolved into eBPF, providing a richer instruction set that allows dynamic intervention and modification of the operating system kernel's behavior without changing the source code. This technology later extended beyond the kernel, developing a user-space eBPF runtime with high performance, security, and portability. Smart contracts executed on Solana are compiled into SBF (based on eBPF) bytecode and run on its blockchain network.

Move is a new smart contract programming language designed by Diem, focusing on flexibility, security, and verifiability. The Move language aims to address security issues in assets and transactions, allowing assets and transactions to be strictly defined and controlled. The Move bytecode verifier is a static analysis tool that analyzes Move bytecode to determine whether it adheres to required type, memory, and resource safety rules, eliminating the need for runtime checks at the smart contract level. Aptos inherits Diem Move, while Sui uses a customized version of Sui Move to write its smart contracts.

Parallel Execution

Parallel execution in blockchain means processing unrelated transactions simultaneously. Unrelated transactions are considered independent events. For example, if two people trade tokens on different platforms, their transactions can be processed simultaneously. However, if they trade on the same platform, the transactions may need to be executed in a specific order.

The main challenge in achieving parallel execution is determining which transactions are unrelated and independent. Most high-performance Layer1 solutions rely on two methods: the state access method and the optimistic parallel model.

The state access method requires knowing in advance which part of the blockchain state each transaction can access, thereby analyzing which transactions are independent. Representative solutions include Solana and Sui.

In Solana, programs (smart contracts) are stateless because they cannot access (read or write) any state that persists throughout the transaction process. To access or maintain state, programs need to use accounts. Each transaction in Solana must specify which accounts will be accessed during transaction execution, allowing the transaction processing runtime to schedule non-overlapping transactions for parallel execution while ensuring data consistency.

In Sui Move, each smart contract is a module composed of functions and structures. Structures are instantiated within functions and can be passed to other modules through function calls. The runtime stores structure instances as objects, and there are three different types of objects in Sui: owner objects, shared objects, and immutable objects. Sui's parallelization strategy is similar to Solana's, with transactions also needing to specify which objects they operate on.

The optimistic parallel model operates under the assumption that all transactions are independent, only retrospectively verifying this assumption and making adjustments if necessary. A representative solution is Aptos.

Aptos uses the Block-STM (Block Software Transactional Memory) method to apply optimistic parallel execution. In Block-STM, transactions are first set up in a block in a certain order and then split among different processing threads for simultaneous execution. While processing these transactions, the system tracks the memory locations each transaction changes. After each round of processing, the system checks all transaction results. If it finds that a transaction touched a memory location changed by an earlier transaction, it erases its results and reruns it. This process continues until every transaction in the block is processed.

Parallel EVM

Parallel EVM (Parallel EVM) was proposed as early as 2021, referring to an EVM that supports processing multiple transactions simultaneously, aiming to improve the performance and efficiency of the existing EVM. Representative solutions include Polygon's parallel EVM based on Block-STM and the parallel EVM developed by BSC in collaboration with NodeReal.

However, by the end of 2023, Paradigm's CTO Georgios Konstantopoulos and Dragonfly's Haseeb Qureshi