EVM: The Core of Ethereum

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

A virtual machine is typically used for virtualization of real computers, usually virtualized by a "virtual machine manager" (such as VirtualBox) or an entire operating system instance (such as Linux's KVM). They must provide software abstractions for actual hardware, system calls, and other kernel functions.

The EVM operates in a more limited domain: it is just a computing 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 all execution steps consume finite resources called Gas, so any given smart contract execution is limited to a finite number of computational steps, preventing potential infinite loops during execution that could halt the entire Ethereum platform.

The EVM does not have scheduling capabilities; Ethereum's execution module extracts transactions from blocks, and the EVM is responsible for executing them sequentially. As the execution progresses, the latest world state is modified, with state accumulation occurring after each transaction execution, leading to the latest world state upon block completion. The execution of the next block strictly depends on the world state after the execution of the previous block, making Ethereum's transaction linear execution process challenging to optimize for parallel execution.

In this sense, the Ethereum protocol dictates that transactions be executed sequentially. While sequential execution ensures that transactions and smart contracts are deterministically executed, ensuring security, it may lead to network congestion and delays under high loads. This is why Ethereum faces significant performance bottlenecks, necessitating Layer2 Rollup scalability solutions.

The Path to Parallelism for High-Performance Layer1

Most high-performance Layer1 solutions are designed based on Ethereum's inability to process transactions in parallel, leading them to devise their optimization strategies, focusing on 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, explicitly producing 256-bit outputs. However, the actual computer running the EVM needs to map the 256-bit bytes to local architecture to execute smart contracts, making the entire system highly inefficient and impractical. Therefore, for virtual machine selection, high-performance Layer1 solutions often opt for virtual machines based on WASM, eBPF bytecode, or Move bytecode, rather than EVM.

WASM is a compact, fast-loading, portable, and sandbox-secure bytecode format that allows developers to 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, etc. 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 Berkeley Packet Filter (BPF), was initially used for efficient filtering of network packets. It evolved into eBPF, offering a richer instruction set, allowing dynamic intervention in the operating system kernel without modifying the source code, and altering its behavior. This technology later emerged from the kernel, developing into user-space eBPF runtimes 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, emphasizing flexibility, security, and verifiability. The Move language aims to address security issues in assets and transactions, enabling strict definition and control of assets and transactions. Move's bytecode verifier is a static analysis tool that analyzes Move bytecode and determines compliance with 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 its customized version of Sui Move to write its smart contracts.

Parallel Execution

Parallel execution in blockchain means processing unrelated transactions simultaneously, treating unrelated transactions as independent events. For example, if two individuals trade tokens on different platforms, their transactions can be processed concurrently. However, if they trade on the same platform, 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: state access method and optimistic parallel model.

The state access method requires prior knowledge of 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 as they cannot directly access (read or write) any state persisting throughout the entire transaction process; they need to use accounts to access or maintain state. Each transaction in Solana must specify which accounts it will access during transaction execution, enabling the runtime to schedule non-overlapping transactions for parallel execution while ensuring data consistency.

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

The optimistic parallel model operates under the assumption that all transactions are independent, retrospectively verifying this assumption and making adjustments when 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 initially ordered within a block and then split between different processing threads for simultaneous execution. While processing these transactions, the system tracks memory locations changed by each transaction. After each round of processing, the system checks all transaction results. If it detects a transaction touching a memory location altered by an earlier transaction, it erases its result and reruns it. This process continues until all transactions in the block are processed.

Parallel EVM

Parallel EVM (Parallel Ethereum Virtual Machine) was first proposed as early as 2021, referring to an EVM supporting the simultaneous processing of multiple transactions, aiming to improve the performance and efficiency of existing EVMs. Representative solutions include Polygon's Parallel EVM based on Block-STM, and BSC's collaboration with NodeReal to develop Parallel EVM.

However, by the end of 2023, Paradigm's CTO Georgios Konstantopoulos and Dragonfly's Haseeb Qureshi coincidentally mentioned Parallel EVM when looking ahead to 2024 trends, sparking a wave of EVM-compatible Layer1 solutions adopting parallel execution technology, including Monand and Sei.

Today, EVM-compatible solutions like Neon on Solana, Layer2 Rollup Eclipse for Ethereum SVM (Solana Virtual Machine), Layer2 Rollup Lumio for Ethereum Move Virtual Machine, and modular execution layer Layer1 Fuel have all embraced the label of Parallel EVM, creating a dazzling array of options.

I believe reasonable definitions of Parallel EVM fall into the following three categories:

  1. Parallel execution upgrades of EVM-compatible Layer1 solutions that have not adopted parallel execution technology, such as BSC, Polygon;

  • Layer1s that are EVM-compatible and utilize parallel execution technology include Monand, Sei V2, and Artela;

  • For Layer1s that are not EVM-compatible but utilize parallel execution technology, there are EVM-compatible solutions like Solana Neon.

    • It goes without saying that BSC and Polygon are the most mainstream EVM-compatible Layer1s. Here is a brief introduction to Monand, Sei V2, Artela, and Solana Neon.

    Monad is a high-performance EVM-compatible Layer1 utilizing a PoS mechanism, aiming to significantly enhance scalability and transaction speed through parallel execution. Monad Labs was founded by Keone Hon, former head of research at Jump Trading. Monad allows transactions to be executed in parallel within a block to improve efficiency. It employs an optimistic parallel model, starting the execution of new transactions before the completion of the previous ones. To address incorrect results, Monad tracks inputs/outputs and re-executes inconsistent transactions. A static code analyzer predicts dependencies to avoid invalid parallelism and reverts to a simple mode when uncertain. This parallel execution increases throughput while reducing the likelihood of transaction failures.

    Sei is a Layer1 developed based on Cosmos SDK, designed specifically for DeFi. The Sei team members have backgrounds in both technology and traditional finance, having previously worked at companies like Robinhood, Databricks, Airbnb, and Goldman Sachs. Sei V2 is a major upgrade to the Sei network, aiming to be the first fully parallel EVM. Similar to Monad, Sei V2 will utilize optimistic parallelization. This allows the blockchain to execute transactions simultaneously without developers defining any dependencies. In case of conflicts, the blockchain will track the storage parts touched by each transaction and rerun these transactions sequentially. This process continues recursively until all unresolved conflicts are resolved.

    Artela is a scalable blockchain network that enables developers to build feature-rich decentralized applications (dApps), with core members from AntChain. The EVM++ introduced by Artela represents a parallel EVM with high scalability and performance, implemented in two phases. The first phase will be designed around parallel execution, ensuring network node computing power scalability through elastic computing based on parallel execution, ultimately achieving elastic block space. Parallel execution will group transactions based on transaction dependency conflicts to support parallel execution.

    Solana Neon is a solution developed by Neon Labs for executing EVM transactions on Solana. Neon EVM is essentially a smart contract on Solana, implementing an EVM interpreter compiled into SBF bytecode. Neon EVM internally implements an Ethereum transaction model and account model, allowing users to send transactions by paying EVM gas fees. The fees on the Solana network are paid by the Neon Proxy. Solana mandates that transactions provide an account list, and wrapped transactions are no exception, so the responsibility of the Neon Proxy includes generating this account list, while also gaining Solana's transaction parallel execution capability.

    Additionally, solutions like Solana Neon, which run EVM as smart contracts to achieve EVM compatibility, also include Near Aurora and EOS EVM+. Theoretically, Aptos and Sui can adopt this approach to achieve non-intrusive EVM compatibility, and Movement Labs is working on such projects. Movement is a modular framework for building and deploying infrastructure, applications, and blockchains based on Move in any distributed environment. The Fractal module of Movement seamlessly converts EVM opcodes to Move opcodes, allowing Solidity projects to leverage the performance and security advantages of Move without writing any Move code.

    EVM compatibility enables developers to easily migrate their Ethereum applications to the chain without extensive modifications, providing a good direction for building the ecosystems of Aptos and Sui.

    Summary

    Parallel technology in blockchain has long been a topic of discussion, resurfacing periodically, mainly focusing on the optimistic execution model represented by Aptos' Block-STM mechanism, without substantial breakthroughs, making it difficult to sustain the hype.

    Looking ahead, more emerging Layer1 projects will join the competition for parallel EVM, and older Layer1s will also implement EVM parallel upgrades or EVM-compatible solutions. These two directions lead to the same goal, giving rise to more narratives related to performance improvements.

    However, compared to the narrative of high-performance EVM, I still hope to see a variety of narratives in blockchain, similar to WASM, SVM, and Move VM.