EVM: The Core of Ethereum

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

A virtual machine is typically used to virtualize a real computer, typically by a “hypervisor” (such as VirtualBox) or an entire operating system instance (such as KVM for Linux). They must respectively provide software abstractions of the actual hardware, system calls, and other kernel functions.

The EVM operates in a more limited domain: it’s merely a computing engine, therefore it provides abstractions for computation and storage, similar to the Java Virtual Machine (JVM) specification. From a high-level perspective, the JVM is designed to provide a runtime environment that is independent of the underlying host operating system or hardware, thereby enabling compatibility across a variety of systems. Likewise, the EVM executes its own set of bytecode instructions, which are typically compiled by Solidity.

EVM is a quasi-Turing complete state machine. It is “quasi” because all execution steps consume a limited resource Gas, so any given smart contract execution will be limited to a limited number of calculation steps, avoiding possible errors in the execution process. An infinite loop, causing the entire Ethereum platform to stop.

EVM does not have a scheduling function. Ethereum’s execution module takes out transactions one by one from the block, and EVM is responsible for executing them in sequence. The latest world state will be modified during the execution process. After a transaction is executed, the state will be 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, so the linear execution process of Ethereum’s transactions cannot be well optimized for parallel execution.

In this sense, the Ethereum protocol stipulates that transactions be executed in sequence. While sequential execution ensures that transactions and smart contracts can be executed in a deterministic order, guaranteeing safety, it can lead to network congestion and latency when faced with high load. This is why Ethereum has significant performance bottlenecks and requires Layer2 Rollup for capacity expansion.

High-Performance Layer1 Parallelism

Most high-performance Layer 1 designs their own optimization solutions based on Ethereum’s inability to handle parallel processing. Here we only talk about the optimization of the execution layer, that is, virtual machines and parallel execution.

Virtual Machine

The EVM is designed as a 256-bit virtual machine in order to make it easier to process Ethereum’s hashing algorithm, and it will explicitly produce 256-bit output. However, the computer actually running the EVM needs to map 256-bit bytes to the local structure to execute the smart contract, making the entire system very inefficient and impractical. Therefore, in terms of virtual machine selection, high-performance Layer 1 uses virtual machines based on WASM, eBPF bytecode or Move bytecode rather than EVM.

WASM is a compact, fast-loading, portable byte code format based on a sandbox security mechanism. Developers can use multiple programming languages (C/C++, Rust, Go, AssemblyScript, JavaScript, etc.) to write smart contracts, then compile them into WASM byte code and execute. WASM has been accepted 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 that Ethereum’s execution layer is more efficient, simple, and suitable as a fully decentralized computing platform.

eBPF, formerly known as BPF (Berkeley Packet Filter), was initially used for efficient filtering of network data packets. After evolution, it formed eBPF, providing a richer instruction set, allowing dynamic intervention and modification of the operating system kernel without changing the source code. Later, this technology evolved from the kernel to develop a user-mode eBPF runtime, which is high-performance, secure, and portable. All 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 solve security issues in assets and transactions, making assets and transactions strictly defined and controlled. Move’s 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 implementing at the smart contract level and checking at runtime. Aptos inherited Diem Move, while Sui writes its smart contracts through its own customized version of Sui Move.

Parallel Execution

Parallel execution in blockchain means processing unrelated transactions at the same time. Treat unrelated transactions as events that do not affect each other. For example, if two people trade tokens on different exchanges, their transactions can be processed simultaneously. However, if they are traded 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 which are independent. Most high-performance Layer1 relies on two approaches: state access methods and optimistic parallel models.

State access methods need to know in advance which part of the blockchain state each transaction can access, so as to analyze which transactions are independent. Representative solutions are Solana and Sui.

In Solana, programs (smart contracts) are stateless as they cannot access (read or write) any persistent state 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 the transaction execution, so the transaction processing runtime can schedule non-overlapping transactions for parallel execution, ensuring data consistency at the same time.

In Sui Move, each smart contract is a module, composed of function and structure definitions. Structures are instantiated in functions and can be passed to other modules through function calls. Stored structure instances in runtime act as objects. Sui has three different types of objects: owner objects, shared objects, and immutable objects. Sui’s parallelization strategy is similar to Solana’s, as transactions also need to specify which objects to operate.

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 first set in a certain order within the block, then split among different processing threads for simultaneous execution. While processing 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 touched a memory location changed by an earlier transaction, it erases its result and runs it again. This process continues until every transaction in the block has been processed.

Parallel EVM

Parallel EVM was first brought up in 2021, at that time it referred 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 jointly developed by BSC and NodeReal.

However, at the end of 2023, Georgios Konstantopoulos, CTO of Paradigm, and Haseeb Qureshi of Dragonfly, coincidentally mentioned parallel EVM while looking at the trends for 2024, igniting a wave of EVM compatible Layer1s that adopted parallel execution technology, including Monand and Sei V2.

Nowadays, Neon, the EVM compatible solution on Solana, the Layer2 Rollup Eclipse of Ethereum’s SVM (Solana Virtual Machine), the Layer2 Rollup Lumio of Ethereum’s Move Virtual Machine, and the modular execution layer Layer1 Fuel have all been tagged with parallel EVM, making it quite confusing.

I think there are only the following three categories that can be reasonably defined as parallel EVM:

1. There is no parallel execution upgrade of EVM-compatible Layer1 using parallel execution technology, such as BSC, Polygon;
2. EVM-compatible Layer1 using parallel execution technology, such as Monand, Sei V2 and Artela;
3. EVM-compatible solutions for non-EVM-compatible Layer 1 that use parallel execution technology, such as Solana Neon.

Needless to say, BSC and Polygon are the most mainstream EVM-compatible Layer 1. Here is a brief introduction to Monand, Sei V2, Artela and Solana Neon.

Monad is a high-performance EVM-compatible Layer 1 using a PoS mechanism, designed to significantly enhance scalability and transaction speed through parallel execution. Monad Labs was founded by Keone Hon, former head of research at Jump Trading. Monads allow transactions to be executed in parallel within a block to increase efficiency. It uses an optimistic parallelism model and starts executing a new transaction before the execution of the previous step is completed. To cope with incorrect results, Monad tracks input/output and re-executes inconsistent transactions. Static code parsers can predict dependencies, avoid ineffective parallelism, and revert to simple mode in times of uncertainty. This parallel execution increases throughput while reducing the likelihood of transaction failure.

Sei is a Layer1 developed based on the Cosmos SDK, a public chain specially designed for DeFi. Members of the Sei team have both tech and traditional financial backgrounds, having 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. Like Monand, Sei V2 will use optimistic parallelization. This allows the blockchain to execute transactions simultaneously without developers defining any dependencies. When conflicts occur, the blockchain tracks each transaction’s touched storage parts and reruns these transactions in order. This process continues recursively until all unresolved conflicts are resolved.

Artela is a scalable blockchain network that allows developers to build feature-rich decentralized applications (dApps), with core members from AntChain. Artela’s EVM++ represents a high scalability + high-performance parallel EVM. It will be implemented in two stages, the first of which will focus on parallel execution. Based on parallel execution, through elastic computing, it ensures that the network node’s computing power is scalable, eventually achieving elastic block space. Its parallel execution will group transactions according to transaction dependency conflict analysis to support parallel execution.

Solana Neon is a solution developed by Neon Labs for executing EVM transactions on Solana. Neon EVM is actually a smart contract on Solana, which implements an EVM interpreter within the contract, compiled into SBF bytecode. Neon EVM 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 of the Solana network are paid by the Neon Proxy. Solana requires transactions to provide an account list mandatorily, including wrapped transactions, so the Neon Proxy’s responsibilities include generating this account list, and it also gains Solana’s transaction parallel execution capability.

In addition, similar to Solana Neon, other solutions that run EVM as a smart contract to achieve EVM compatibility include Near Aurora and EOS EVM+. Theoretically, Aptos and Sui could also use this solution to achieve non-intrusive EVM compatibility, but I haven’t found relevant information (maybe Pontem is doing this?). If there are ongoing projects, please contact me for supplementation. EVM compatibility allows developers to easily migrate their Ethereum applications to the chain without making significant modifications, which is a great direction for building the Aptos and Sui ecosystem.

Conclusion

The topic of parallel technology in blockchain is already a commonplace topic, with narratives resurfacing from time to time. However, at present, the main focus is on modifications and imitations of the optimistic execution model, represented by Aptos’s Block-STM mechanism. However, without substantial breakthroughs, the heat is hard to sustain.

Looking ahead, we may expect more emerging Layer1 projects to join the race for parallel EVMs. Additionally, some existing Layer1 projects may implement EVM parallel upgrades or EVM-compatible solutions. These two paths lead to a similar outcome, potentially spawning more performance-related narratives.

However, compared to the narrative of high-performance EVM, I’m more hopeful for a diverse blockchain landscape, where narratives similar to WASM, SVM, and Move VM emerge.

statement:

1. This article is reproduced from [小猪Web3], the copyright belongs to the original author [ web3朱大胆], if you have any objections to the reprint, please contact the Gate Learn team, and the team will handle it as soon as possible according to relevant procedures.

2. Disclaimer: The views and opinions expressed in this article represent only the author’s personal views and do not constitute any investment advice.

3. Other language versions of the article are translated by the Gate Learn team and are not mentioned in Gate.io, the translated article may not be reproduced, distributed or plagiarized.