EVM: The Core of Ethereum

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, performed by a hypervisor or an entire instance of an operating system. They must provide a software abstraction of actual hardware, system calls, and other kernel functionalities.

The EVM operates in a more limited domain: it is merely a computing engine that provides abstractions for computation and storage, similar to the Java Virtual Machine (JVM) specification. At a high level, the JVM is designed to provide a runtime environment that is agnostic to the underlying host operating system or hardware, achieving cross-system compatibility. Similarly, the EVM executes its own bytecode instruction set, which is typically compiled from Solidity.

EVM is a quasi-Turing complete state machine, "quasi" because all execution steps consume a limited resource called Gas, so any given smart contract execution is limited to a finite number of computational steps, avoiding the possible infinite loops in the execution process that could cause the entire Ethereum platform to stop.

The EVM does not have scheduling capabilities; the execution module of Ethereum retrieves transactions from blocks, and the EVM is responsible for executing them sequentially. During the execution process, the latest world state is modified, and after the execution of a transaction is completed, the state is accumulated to reach the latest world state after the block is completed. The execution of the next block strictly relies on the world state after the execution of the previous block, so the linear execution process of Ethereum's transactions cannot be optimized for parallel execution very well.

In this sense, the Ethereum protocol stipulates that transactions are executed in sequence. Although sequential execution ensures that transactions and smart contracts can be executed in a deterministic order, ensuring security, it may lead to network congestion and delays when facing high loads. This is also why Ethereum has significant performance bottlenecks and requires Layer 2 Rollup scalability.

The Parallel Path of High-Performance Layer 1

Most high-performance Layer 1s design their optimization solutions based on the inability of Ethereum to process in parallel. Here, we only discuss optimizations at the execution layer, which refers to the virtual machine and parallel execution.

Virtual Machine

The EVM is designed as a 256-bit virtual machine, with the aim of making it easier to handle Ethereum's hashing algorithm, which will explicitly produce a 256-bit output. However, the computers that actually run the EVM need to map the 256-bit bytes to the local architecture to execute smart contracts, making the entire system very inefficient and impractical. Therefore, in terms of virtual machine selection, high-performance Layer 1s tend to adopt virtual machines based on WASM, eBPF bytecode, or Move bytecode, rather than EVM.

WASM is a small, fast-loading, portable bytecode format based on a sandbox security mechanism, allowing developers to write smart contracts using various programming languages, which are then compiled into WASM bytecode and executed. WASM has been adopted as the standard by many blockchain projects, including EOS, Dfinity, Polkadot, Cosmos, Near, and Ethereum will also integrate WASM in the future, ensuring that Ethereum's execution layer is more efficient and simple, making it suitable as a fully decentralized computing platform.

eBPF originated from BPF (Berkeley Packet Filter), originally designed for efficient filtering of network packets. It evolved into eBPF, which provides a richer instruction set, allowing for dynamic intervention and modification of the operating system kernel's behavior without altering the source code. Later, this technology emerged from the kernel and developed into user-space eBPF runtime, which features high performance, security, and portability. Smart contracts executed on a certain blockchain are compiled into SBF (based on eBPF) bytecode and run on its network.

Move is a new smart contract programming language that focuses on flexibility, security, and verifiability. The Move language is designed 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 and determines whether it complies with the required type, memory, and resource safety rules, without needing to be implemented at the smart contract level and checked at runtime. Some emerging public chains have inherited Move or written their smart contracts using their customized version of Move.

Parallel Execution

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

The main challenge of achieving parallel execution is determining which transactions are unrelated and which are independent. Most high-performance Layer 1s rely on two methods: state access methods and optimistic parallel models.

The state access method needs to know in advance which part of the blockchain state each transaction can access, in order to analyze which transactions are independent. Representative solutions are certain emerging public chains.

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

In certain implementations of Move, each smart contract is a module composed of function and structure definitions. Structures are instantiated within functions and can be passed to other modules via function calls. The structure instances stored at runtime act as objects, existing in three different types: owner objects, shared objects, and immutable objects. The parallelization strategy is similar to the aforementioned, and transactions also need to specify which objects to operate on.

The optimistic parallel model operates under the assumption that all transactions are independent, simply retrospectively validating this assumption and making adjustments as necessary. Representative schemes are certain emerging public chains.

A certain public blockchain uses 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. During the processing of these transactions, the system tracks the memory locations changed by each transaction. After each round of processing, the system checks all transaction results. If it finds that a transaction has touched a memory location changed by an earlier transaction, it erases its results and runs it again. This process continues until every transaction in the block has been processed.

Parallel EVM

Parallel EVM was mentioned as early as 2021, at that time referring to an EVM that supports the simultaneous processing of multiple transactions, aimed at improving the performance and efficiency of the existing EVM. Representative solutions include certain public chains that implement Parallel EVM based on Block-STM.

However, at the end of 2023, some industry experts coincidentally mentioned parallel EVM while looking ahead to the trends of 2024, sparking a wave of adoption for EVM-compatible Layer 1s that utilize parallel execution technology, including some emerging projects.

Nowadays, certain EVM-compatible solutions, Ethereum SVM (Solana Virtual Machine) Layer 2 Rollups, Ethereum Move Virtual Machine Layer 2 Rollups, and modular execution Layer 1 are all rushing to label themselves as parallel EVMs, dazzling the eyes.

I think that only the following three categories can be defined as parallel EVMs.

1. The parallel execution upgrade of EVM-compatible Layer 1 without adopting parallel execution technology, such as certain mainstream public chains;

2. EVM-compatible Layer 1 that adopts parallel execution technology, such as some emerging projects;

3. EVM-compatible solutions of non-EVM compatible Layer 1 that adopt parallel execution technology, such as certain cross-chain projects.

Some mainstream public chains that are the most popular EVM-compatible Layer 1s go without saying, here is a brief introduction to some emerging projects and cross-chain solutions.

Some emerging public chains are high-performance Layer 1 that adopt PoS mechanisms and are EVM-compatible, aiming to significantly enhance scalability and transaction speed through parallel execution. They allow transactions to be executed in parallel within a block to improve efficiency. Typically, an optimistic parallel model is used, where new transactions begin execution before the previous execution is completed. To handle incorrect results, input/output is tracked and inconsistent transactions are re-executed. A static code analyzer can predict dependencies, avoid invalid parallelism, and revert to a simple mode in case of uncertainty. This parallel execution increases throughput while reducing the likelihood of transaction failures.

Some cross-chain solutions are developed to execute EVM transactions on top of other public chains. It is essentially a smart contract that implements an EVM interpreter, compiled into specific bytecode. It internally realizes a set of Ethereum transaction models and account models, allowing users to send transactions by only paying EVM GAS fees. The fees of the native network are paid by the proxy. Some public chains require transactions to provide an account list, and wrapped transactions are no exception, so the responsibilities of the proxy include generating this account list while also gaining the ability to execute native transactions in parallel.

Here is an additional point: similar to using EVM to run smart contracts to achieve EVM-compatible solutions, there are other cross-chain projects. Theoretically, certain emerging public chains could also adopt this solution to achieve non-intrusive EVM compatibility, and some projects are working on this. Some projects are a modular framework designed to build and deploy Move-based infrastructures, applications, and blockchains in any distributed environment. Some of these modules can seamlessly convert EVM opcodes into Move opcodes, which means that Solidity projects can leverage the performance and security advantages of Move without writing a single line of Move code.

EVM compatibility allows developers to easily migrate their Ethereum applications to the chain without large-scale modifications, which is a great direction for building a new emerging public chain ecosystem.

Summary

The parallel technology of blockchain has become a common topic that is often discussed. The narrative resurfaces periodically, but currently, it mainly involves the transformation and imitation of optimistic execution models represented by the Block-STM mechanism of certain public chains, without any substantial breakthroughs. Therefore, the enthusiasm is difficult to sustain.

Looking to the future, more emerging Layer 1 projects will join the competition of parallel EVM, and some older Layer 1s will also implement EVM parallel upgrades or EVM-compatible solutions. Both directions lead to the same goal, and new narratives related to performance improvements will also emerge.

However, compared to the narrative of high-performance EVMs, I still hope that the blockchain can flourish with various narratives like WASM, SVM, and Move VM.