EVM: The Core Component of Ethereum

The EVM is a core part of Ethereum, responsible for running smart contracts and processing transactions. As a computational engine, the EVM provides an abstraction for computation and storage, similar to the Java Virtual Machine specification. The EVM executes its own bytecode instruction set, which is usually compiled from Solidity.

The EVM is a quasi-Turing complete state machine. "Quasi" refers to the fact that all execution steps consume a finite amount of resources, Gas, thereby avoiding the possibility of infinite loops that could halt the entire Ethereum platform.

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

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 can lead to network congestion and delays under high load conditions. This is also why Ethereum has significant performance bottlenecks and requires Layer 2 scaling.

The Path of Parallelism for High-Performance Layer 1

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

Virtual Machine

The EVM is designed as a 256-bit virtual machine, aimed at facilitating the processing of Ethereum's hash algorithms. However, computers running the EVM need to map the 256-bit bytes to local architecture to execute smart contracts, which makes the entire system very inefficient and impractical. Therefore, in terms of virtual machine selection, high-performance Layer 1 solutions more commonly adopt virtual machines based on WASM, eBPF bytecode, or Move bytecode, rather than the EVM.

WASM is a small, fast-loading, portable bytecode format based on sandbox security mechanisms. Developers can write smart contracts using various programming languages, then compile them into WASM bytecode for execution. WASM has been adopted as a standard by many blockchain projects, and Ethereum will also integrate WASM in the future, ensuring that Ethereum's execution layer is more efficient and simpler, making it suitable as a fully decentralized computing platform.

eBPF originated from BPF, which was originally used for efficient filtering of network data packets. After evolution, it formed eBPF, providing a richer instruction set that allows for dynamic intervention in the operating system kernel and modification of its behavior without changing the source code. Smart contracts executed on a certain blockchain are compiled into SBF (based on eBPF) bytecode and run on its blockchain 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 blockchain projects inherit Move or write their smart contracts using customized versions.

Parallel Execution

Parallel execution in blockchain means processing unrelated transactions simultaneously. Consider unrelated transactions as events that do not affect each other. For example, if two people trade tokens on different trading platforms, their transactions can be processed at the same time. However, if they trade 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 approaches: state access methods and optimistic parallel models.

The status access method requires prior knowledge of which part of the blockchain state each transaction can access, in order to analyze which transactions are independent.

In some 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 transaction execution, so that the transaction processing runtime can schedule non-overlapping transactions to execute in parallel while ensuring data consistency.

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

The optimistic parallel model operates under the assumption that all transactions are independent, only retrospectively verifying this assumption and making adjustments when necessary.

Some blockchains use Block-STM (Block Software Transactional Memory) to apply optimistic parallel execution. In Block-STM, transactions are first set up in a block in a certain order, and then split across different processing threads for simultaneous execution. While processing these transactions, the system tracks the memory locations modified by each transaction. After each round of processing, the system checks the results of all transactions. If it finds that a transaction has touched a memory location modified by an earlier transaction, it wipes 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, referring to an EVM that supports processing multiple transactions simultaneously, aimed at improving the performance and efficiency of the existing EVM. Representative solutions include a parallel EVM implemented based on Block-STM by a certain platform and a parallel EVM co-developed by another platform.

However, at the end of 2023, industry experts coincidentally mentioned the parallel EVM while looking ahead to the trends of 2024, sparking a wave of EVM-compatible Layer 1s that adopted parallel execution technology, including Monand and Sei.

Nowadays, certain Layer 1 and Layer 2 projects are all labeling themselves as parallel EVMs, dazzling people.

I believe that the only three categories that can be defined as parallel EVM are:

1. The parallel execution upgrade of the EVM-compatible Layer 1 that does not adopt parallel execution technology;

2. EVM-compatible Layer 1 that adopts parallel execution technology;

3. A non-EVM compatible Layer 1 EVM compatible solution that adopts parallel execution technology.

Here is a brief introduction to a few representative projects.

Monad is a high-performance Layer 1 compatible with EVM that adopts a PoS mechanism, aimed at significantly enhancing scalability and transaction speed through parallel execution. Monad allows for the parallel execution of transactions within a block to improve efficiency. It uses an optimistic parallel model that starts executing new transactions before the previous execution is completed. To address incorrect results, Monad tracks inputs/outputs and re-executes inconsistent transactions. The static code analyzer can predict dependencies, avoid invalid parallelism, and revert to a simple mode when uncertain. This parallel execution increases throughput while reducing the likelihood of transaction failures.

Sei is a Layer 1 blockchain developed based on the Cosmos SDK, specifically designed for DeFi. Sei V2 is a large-scale upgrade to the Sei network, aiming to be the first fully parallel EVM. Like Monad, Sei V2 will utilize optimistic parallelization. This allows the blockchain to execute transactions simultaneously without requiring developers to define any dependencies. When conflicts occur, the blockchain will track the storage parts touched by each transaction and rerun those transactions in order. This process will recursively continue until all unresolved conflicts are resolved.

Artela is a scalable blockchain network that enables developers to build feature-rich decentralized applications (dApps). The EVM++ launched by Artela represents a high scalability + high performance parallel EVM, implemented in two phases. The first phase will be designed around parallel execution, and based on parallel execution, it will ensure the scalability of network node computing power through elastic computing, ultimately achieving elastic block space. In parallel execution, transactions will be grouped based on transaction dependency conflict analysis to support parallel execution.

The EVM-compatible solution on a certain platform is a solution for executing EVM transactions on that platform. It is essentially a smart contract on that platform, which implements an EVM interpreter compiled into specific bytecode. It internally implements a set of Ethereum transaction models and account models, and users only need to pay EVM GAS fees to send transactions. The fees for the platform's network are paid by the agents. The platform mandates that transactions provide an account list, and wrapped transactions are no exception, so the agent's responsibilities include generating this account list while also gaining the platform's transaction parallel execution capability.

Similar to running EVM as smart contracts to achieve EVM-compatible solutions, there are several other projects. Theoretically, this approach can also be adopted on certain platforms to achieve non-intrusive EVM compatibility. Some projects are working on this, developing a modular framework for building and deploying Move-based infrastructure, applications, and blockchains in any distributed environment. One module of the project can seamlessly convert EVM opcodes to Move opcodes, which means 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 making large-scale modifications, which is a great direction for building the ecosystem.

Summary

The parallel technology of blockchain has become a well-trodden topic, with discussions resurfacing from time to time. However, so far, it mainly involves modifications and imitations of optimistic execution models represented by the Block-STM mechanism of a certain blockchain, without any substantial breakthroughs, making it difficult for the topic to maintain its heat.

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

However, compared to the narrative of high-performance EVMs, the blockchain's ability to flourish in various directions, with narratives like WASM, SVM, and Move VM, may be even more worth looking forward to.