The parallel technology of blockchain is already a commonplace topic, and the narrative will come up every once in a while, but currently it is mainly the transformation and imitation of the optimistic execution model represented by Aptos' Block-STM mechanism, without any substantial breakthroughs, so the heat is difficult to sustain. Looking to the future, there will be more emerging Layer1 projects joining the competition for parallel EVM, and some old Layer1 will also implement EVM parallel upgrades or EVM compatibility solutions. The two directions have the same goal, and more new narratives related to performance improvement will be born.
Author: Xiaozhu Web3
Cover: Photo by Shubham Dhage on Unsplash
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 commonly used to virtualize real computers, usually virtualized by a "hypervisor" such as VirtualBox or an entire operating system instance such as KVM for Linux. They must provide software abstractions of the actual hardware, system calls and other kernel functionality, respectively.
The EVM operates in a more limited domain: it is just a computation engine, and therefore provides abstractions for computation and storage, similar to, for example, 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, enabling compatibility across a wide variety of systems. Likewise, the EVM executes its own bytecode instruction set, which is typically compiled from Solidity.
EVM is a quasi-Turing-complete state machine. It is "quasi" because all execution steps consume a limited resource, Gas. Therefore, the execution of any given smart contract is limited to a limited number of calculation steps, avoiding possible infinite loops in the execution process, which may cause the entire Ethereum platform to stop.
EVM has no scheduling function. Ethereum's execution module takes out transactions from the block one by one, 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 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 previous block is executed, 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 guarantees security, it may cause network congestion and delays when facing high loads. This is why Ethereum has a huge performance bottleneck and needs Layer2 Rollup expansion.
The parallel path of high performance Layer1
Most high-performance Layer 1 designs their 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, the virtual machine 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 explicitly produces 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 machine, high-performance Layer1 is more likely to use 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, suitable as a completely decentralized computing platform.
The predecessor of eBPF is BPF (Berkeley Packet Filter), which was originally used for efficient filtering of network data packets. It evolved into eBPF, which provides a richer instruction set and allows dynamic intervention and modification of the operating system kernel without changing the source code. Later, this technology came out of the kernel and developed the user-mode eBPF runtime, which has 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 that focuses on flexibility, security, and verifiability. The Move language aims to address security issues in assets and transactions, allowing assets and transactions to be strictly defined and controlled. Move's bytecode verifier is a static analysis tool that analyzes the Move bytecode and determines whether the required type, memory, and resource safety rules are followed. It does not need to be implemented at the smart contract level and checked at runtime. Aptos inherits Diem Move, and 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. 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 Layer 1s rely on two approaches: state access method and optimistic parallel model.
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 in that they cannot themselves access (read or write) any state that persists across transactions. To access or persist state, programs use accounts. 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 to execute in parallel while ensuring data consistency.
In Sui Move, each smart contract is a module consisting of functions 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. 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, and only retrospectively verifies this assumption and makes adjustments when necessary. The representative solution is Aptos.
Aptos uses the Block-STM (Block Software Transactional Memory) approach 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 to be executed simultaneously. While processing these transactions, the system keeps track of the memory locations that each transaction changes. After each round of processing, the system checks all transaction results. If it finds that a transaction touches 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 the EVM that supported processing multiple transactions at the same time. It aimed 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.
But at the end of 2023, Paradigm's CTO Georgios Konstantopoulos and Dragonfly's Haseeb Qureshi both mentioned parallel EVM when looking forward to the trends in 2024, which brought about a wave of EVM-compatible Layer1 that uses parallel execution technology, including Monand and Sei.
Nowadays, the EVM-compatible solution Neon on Solana, the Layer2 Rollup Eclipse of Ethereum SVM (Solana Virtual Machine), the Layer2 Rollup Lumio of Ethereum Move Virtual Machine, and the modular execution layer Layer1 Fuel have all been labeled as parallel EVM, which is dazzling.
I think there are only three reasonable definitions of parallel EVM:
- Parallel execution upgrades of EVM-compatible Layer 1 that do not use parallel execution technology, such as BSC and Polygon;
- EVM-compatible Layer1 using parallel execution technology, such as Monand, Sei V2 and Artela;
- EVM-compatible solutions for non-EVM-compatible Layer1 that use parallel execution technology, such as Solana Neon.
BSC and Polygon are the most mainstream EVM-compatible Layer1, 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 uses 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. 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 public chain designed specifically for DeFI and based on Layer1 developed by Cosmos SDK. 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, aiming to be the first fully parallel EVM. Like Monad, Sei V2 will use optimistic parallelization. This allows the blockchain to execute transactions simultaneously without the developer having to define any dependencies. When a conflict occurs, the blockchain will track the parts of the storage 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). Its core members come from Ant Chain. Artela's EVM++ represents high scalability + high performance parallel EVM, which is implemented in two phases. The first phase 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 obtaining Solana's parallel transaction execution capabilities.
I would like to add that similar to Solana Neon, Near Aurora and EOS EVM+ also use this solution to run EVM as a smart contract to achieve EVM compatibility. In theory, Aptos and Sui can also adopt this solution to achieve non-invasive EVM compatibility. Movement Labs is doing such work. Movement is a modular framework for building and deploying Move-based infrastructure, applications, and blockchains in any distributed environment. Movement's Fractal module can seamlessly convert EVM opcodes to Move opcodes, which means that Solidity projects can take advantage of Move's performance and security advantages without 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 good direction for building the Aptos and Sui ecosystem.
Summarize
The parallel technology of blockchain is already a commonplace topic, and the narrative will come up every once in a while, but currently it is mainly the transformation and imitation of the optimistic execution model represented by Aptos' Block-STM mechanism, without any substantial breakthroughs, so the enthusiasm is difficult to sustain.
Looking into the future, more emerging Layer1 projects will join the competition for parallel EVM, and some old Layer1s will also implement EVM parallel upgrades or EVM-compatible solutions. The two directions lead to the same goal, and more new narratives related to performance improvements will be born.
However, compared to the narrative of high-performance EVM, I still hope that blockchain can flourish and have narratives similar to WASM, SVM and Move VM.
Disclaimer: As a blockchain information platform, the articles published on this site only represent the personal opinions of the author and the guest, and have nothing to do with the position of Web3Caff. The information in the article is for reference only and does not constitute any investment advice or offer. Please comply with the relevant laws and regulations of your country or region.
