Parallel EVM: A heart-changing technique for high-performance Layer 1

Original title: "Parallel EVM: High-performance Layer1's Heart-changing Technique"

Original source: Xiaozhu Web3

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 often used for virtualization of real computers, usually by "hypervisors" such as VirtualBox or entire operating system instances such as Linux's KVM. They must provide software abstractions of actual hardware, system calls, and other kernel functions, respectively.

EVM operates in a more limited field: it is just a computing engine, so it provides abstractions for computing and storage, such as 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 achieving compatibility across a variety of systems. Similarly, the EVM executes its own bytecode instruction set, which is usually compiled from Solidity.

The EVM is a quasi-Turing-complete state machine, "quasi" because all execution steps consume a limited resource Gas, so any given smart contract execution is limited to a limited number of calculation steps, avoiding the possible dead loop in the execution process, which would cause the entire Ethereum platform to stop.

The EVM has no scheduling function. The Ethereum execution module takes out transactions one by one from the block, and the EVM is responsible for executing them in sequence. During the execution process, the latest world state will be modified. After a transaction is executed, the state is accumulated to reach the latest world state after the block is completed. The execution of the next block is strictly dependent on the world state after the execution of the previous block, so the linear execution process of Ethereum transactions cannot be well optimized for parallel execution.

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 and ensure security, it may cause network congestion and delays under high load, which is why Ethereum has a huge performance bottleneck and needs Layer2 Rollup expansion.

The parallel path of high-performance Layer1

Most high-performance Layer1 designs its own optimization solutions based on the defect that Ethereum cannot process in parallel. Here we only talk about the optimization of the execution layer, that is, virtual machines and parallel execution.

Virtual Machine

EVM is designed as a 256-bit virtual machine to make it easier to process Ethereum's hash algorithm, which will explicitly produce 256-bit output. However, the computer that actually runs EVM needs to map 256-bit bytes to the local architecture to execute smart contracts, making the entire system very inefficient and impractical. Therefore, in terms of the choice of virtual machines, high-performance Layer1 uses more virtual machines based on WASM, eBPF bytecode or Move bytecode, rather than EVM.

WASM is a bytecode format that is small, fast to load, portable, and based on a sandbox security mechanism. Developers can use a variety of programming languages (C/C++, Rust, Go, AssemblyScript, JavaScript, etc.) to write smart contracts, and then compile them into WASM bytecode and execute them. 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, thereby ensuring that Ethereum's execution layer is more efficient and simple, and suitable as a completely decentralized computing platform.

eBPF's predecessor was BPF (Berkeley Packet Filter), which was originally 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's behavior without changing the source code. Later, this technology came out of the kernel and developed a user-mode 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 solve security issues in assets and transactions, so that assets and transactions can be strictly defined and controlled. Move's bytecode verifier is a static analysis tool that analyzes Move bytecode and determines whether the required type, memory and resource safety rules are complied with. It does not need to be implemented at the smart contract level and checked at runtime. Aptos inherited Diem Move, and Sui wrote 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. Think of 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 in achieving parallel execution is to determine which transactions are unrelated and which are independent. Most high-performance Layer1s rely on two methods: state access methods and optimistic parallel models.

The state access method requires knowing 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 because they cannot access (read or write) any state that persists throughout the transaction by themselves. To access or maintain the state, the program needs to use an account. Each transaction in Solana must specify which accounts will be accessed during the transaction execution, so that the transaction processing runtime can 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 structure instances stored at runtime are objects, and there are three different types of objects in Sui, namely owner objects, shared objects, and immutable objects. Sui's parallelization strategy is similar to Solana, and transactions also need to specify which objects to operate on.

The optimistic parallel model operates under the assumption that all transactions are independent, but only retrospectively verifies this assumption and adjusts it when necessary. The 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 certain order within a block, and then split between different processing threads for simultaneous execution. As it processes these transactions, the system keeps track of the memory locations that each transaction changes. After each round of processing, the system checks all the transaction results. If it finds that a transaction touched a memory location that was changed by an earlier transaction, it erases its results and runs 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, it referred to EVM that supported processing multiple transactions at the same time, aiming to improve the performance and efficiency of existing EVM. Representative solutions include Polygon's parallel EVM based on Block-STM, and the parallel EVM developed by BSC and NodeReal.

But at the end of 2023, Paradigm's CTO Georgios Konstantopoulos and Dragonfly's Haseeb Qureshi mentioned parallel EVM when looking forward to the trend in 2024, bringing a wave of EVM-compatible Layer1s that use parallel execution technology, including Monand and Sei V2.

Nowadays, Solana’s EVM-compatible solution Neon, Ethereum SVM (Solana Virtual Machine) Layer2 Rollup Eclipse, Ethereum Move Virtual Machine Layer2 Rollup Lumio, and modular execution layer Layer1 Fuel have all been labeled as parallel EVMs, which is dazzling.

I think there are only three reasonable categories that can be defined as parallel EVMs:

1. Parallel execution upgrades of EVM-compatible Layer1 that do not use parallel execution technology, such as BSC and Polygon;

2. EVM-compatible Layer1 that uses parallel execution technology, such as Monand, Sei V2, and Artela;

3. EVM-compatible solutions of non-EVM-compatible Layer1 that use parallel execution technology, such as Solana Neon.

BSC and Polygon are the most mainstream EVM-compatible Layer1s, so there is no need to say much. Here is a brief introduction to Monand, Sei V2, Artela and Solana Neon.

Monad is a high-performance EVM-compatible Layer1 that adopts the PoS mechanism, which aims to significantly enhance scalability and transaction speed through parallel execution. Monad Labs was founded by Keone Hon, the former head of research at Jump Trading. Monad allows transactions to be executed in parallel within a block to improve efficiency. It uses an optimistic parallel model to start executing new transactions before the execution of the previous step is completed. To cope with incorrect results, Monad tracks input/output and re-executes inconsistent transactions. The static code parser can predict dependencies, avoid invalid parallelism, and revert to a simple mode when uncertain. This parallel execution increases throughput while reducing the possibility of transaction failure.

Sei is a Layer1 developed based on the Cosmos SDK, a public chain designed specifically for DeFI. Sei team members have both technology and traditional financial backgrounds, and have worked for companies such as Robinhood, Databricks, Airbnb and Goldman Sachs. Sei V2 is a large-scale upgrade to the Sei network, designed to be the first fully parallel EVM. Like Monad, Sei V2 will use optimistic parallelization. This allows the blockchain to execute transactions simultaneously without requiring developers to define any dependencies. When a conflict occurs, the blockchain will track the storage parts touched by each transaction and rerun those transactions in sequence. This process will continue recursively until all unresolved conflicts are resolved.

Artela is a scalable blockchain network that enables developers to build feature-rich decentralized applications (dApps), and its core members come from Ant Chain. EVM++ launched by Artela represents high scalability + high performance parallel EVM, which is implemented in two stages. The first stage will be designed around parallel execution. On the basis of parallel execution, elastic computing will ensure that the computing power of network nodes can be expanded, and finally realize elastic block space. 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 and compiles to SBF bytecode. Neon EVM implements a set of Ethereum transaction models and account models internally, and users only need to pay EVM GAS fees to send transactions. The fees of the Solana network are paid by Neon Proxy. Solana requires transactions to provide an account list, and wrapped transactions are no exception, so the responsibilities of Neon Proxy include generating this account list, and also obtain Solana's transaction parallel execution capabilities.

One more thing to add here is that similar to Solana Neon, Near Aurora and EOS EVM+ also use EVM as a smart contract to achieve EVM compatibility. In theory, this solution can also be used on Aptos and Sui to achieve non-invasive EVM compatibility, but I haven’t found relevant information (maybe Pontem is doing this?). If there are ongoing projects, please contact me for additional information. EVM compatibility allows developers to easily migrate their Ethereum applications to the chain without large-scale modifications, which is a good direction for building the Aptos and Sui ecosystem.

Summary

Parallel technology of blockchain is already a commonplace topic, and the narrative will be raised every once in a while, but at present it is mainly the transformation and imitation of the optimistic execution model represented by Aptos' Block-STM mechanism, without any substantial breakthrough, so the heat is difficult to sustain.

Looking to the future, there will be more emerging Layer1 projects joining the competition of parallel EVM, and some old Layer1 will also implement EVM parallel upgrade or EVM compatible solutions. The two directions have different paths to the same destination, and more new narratives related to performance improvement will be born.

However, compared with the narrative of high-performance EVM, I still hope that blockchain can flourish, and there will be narratives similar to WASM, SVM and Move VM.

Original link

欢迎加入律动 BlockBeats 官方社群：

Telegram 订阅群： https://t.me/theblockbeats

Telegram 交流群： https://t.me/BlockBeats_App

Twitter 官方账号： https://twitter.com/BlockBeatsAsia