In-depth exploration of parallel EVM and its ecosystem
Ethereum Virtual Machine (EVM)
EVM vs. Solidity
Writing smart contracts is a fundamental skill for blockchain developers. Engineers can implement business logic using Solidity or other high-level languages. However, the EVM cannot directly interpret Solidity; it requires the code to be compiled into a low-level language (opcode/bytecode) that the virtual machine can execute. There are tools available to automate this conversion, alleviating the need for developers to understand the compilation process.
The conversion introduces additional overhead, but engineers with low-level coding experience can write program logic directly in Solidity using opcodes, achieving maximum efficiency and reducing gas consumption. For example, OpenSea's Seaport protocol extensively uses inline assembly to minimize users' gas costs.
Variability in EVM Performance: Standards vs. Implementation
The EVM, also known as the "execution layer," is where the compiled smart contract opcodes are ultimately computed and processed. The bytecode defined by the EVM is an industry standard. Whether for Ethereum Layer 2 networks or other standalone blockchains, compatibility with the EVM standard allows developers to efficiently deploy smart contracts across multiple networks.
Although compliance with the EVM bytecode standard makes a virtual machine an EVM, the implementation methods can vary significantly. For instance, Ethereum's Geth client implements the EVM standard in Go, while the Ethereum Foundation's Ipsilon team maintains a C++ implementation. This diversity allows for different engineering optimizations and customized implementations. >
Parallel EVM Technology
Historically, the blockchain community has primarily focused on innovations in consensus algorithms, with projects like Solana, Avalanche, and EOS being more known for their consensus mechanisms than their execution layers. Although these projects contribute to innovations in execution layers, their performance is often mistakenly attributed solely to their consensus algorithms.
In reality, high-performance blockchains require innovative consensus algorithms and optimized execution layers, similar to the principle of the weakest link. For EVM blockchains that only improve consensus algorithms, enhancing performance requires more powerful nodes. For example, Binance Smart Chain (BSC) processes blocks under a gas limit of 2000 TPS, requiring machines configured several times more powerful than Ethereum full nodes. While Polygon theoretically supports up to 1000 TPS, its actual performance often falls short of expectations.
The Need for Parallel Processing
In most blockchain systems, transactions are executed sequentially, similar to a single-core CPU, where the next computation begins only after the current computation is completed. While this approach is simple and has low system complexity, it is insufficient for scaling to an internet-level user base. Transitioning to a multi-core CPU parallel virtual machine can allow multiple transactions to be processed simultaneously, significantly increasing throughput.
Parallel execution brings engineering challenges, such as handling concurrent transactions writing to the same smart contract. New mechanisms need to be designed to resolve these conflicts. Parallel execution of unrelated smart contracts can proportionally increase throughput based on the number of parallel processing threads.
Innovations in Parallel EVM
Parallel EVM represents a series of innovations aimed at optimizing the execution layer of blockchain systems. Taking Monad as an example, its key innovations include:
Parallel Transaction Execution: Monad employs an optimistic parallel execution algorithm that allows multiple transactions to be processed simultaneously. This method starts transactions from the same initial state, tracks their inputs and outputs, and generates temporary results for each transaction. Monad decides whether to execute the next transaction by checking if its input is related to the output of the currently processed transaction. If there is a relation, the next transaction waits for the current transaction to complete. If there is no relation, the system processes the next transaction in the original order. This approach significantly enhances transaction processing performance and reduces system latency.
Delayed Execution: In Monad's consensus mechanism, nodes reach a formal ordering of transactions without requiring the main node or validating nodes to execute these transactions. Initially, the main node orders the transactions and reaches consensus on their order among the nodes. Monad does not execute transactions immediately but postpones execution to a separate channel, maximizing block time and improving overall execution efficiency.
Custom State Database (Monad DB): Monad DB optimizes state storage and access by directly storing Merkle trees on SSDs. This direct storage method minimizes read amplification effects, speeds up state access, and makes the execution of smart contracts faster and more efficient. By reducing the inefficiencies of traditional databases, Monad DB ensures quick retrieval of state variables during parallel transaction execution.
High-Performance Consensus Mechanism (Monad BFT): Monad BFT is an improved version of the HotStuff consensus mechanism, supporting synchronization among hundreds of globally distributed nodes with linear communication complexity. It uses a pipelined voting phase, allowing different stages of the voting process to overlap, reducing latency and increasing consensus efficiency. This modification significantly enhances the network's ability to handle large-scale distributed operations.
Challenges
Technical Challenges of Parallel EVM
The bottleneck of sequential transaction execution is related to the CPU and state read/write processes. While this method is simple and reliable, parallel execution introduces potential state conflicts that require conflict checks either before or after execution. For example, if a virtual machine supports four parallel threads, each handling a transaction, conflicts can occur when all transactions interact with the same Uniswap pool. This situation necessitates careful conflict detection and resolution mechanisms to ensure efficient parallel processing.
In addition to the technical differences in implementing parallel EVM, various teams often redesign and enhance the read/write performance of the state database and develop compatible consensus algorithms, such as Monad's MonadDb and MonadBFT.
Challenges and Considerations
The two main challenges of parallel EVM are the long-term engineering value capture of Ethereum and node centralization. Although the current development phase has not been fully open-sourced to protect intellectual property, these details will eventually be disclosed when the testnet and mainnet launch, facing the risk of being absorbed by Ethereum or other blockchains. Rapid ecosystem development will be key to maintaining a competitive edge.
Node centralization is a challenge for all high-performance blockchains, requiring a balance between the "blockchain trilemma"—permissionless, trustless operation, and high-performance demands. Metrics like "TPS per hardware requirement" can help compare the efficiency of blockchains under specific hardware conditions, as lower hardware requirements can enable more decentralized nodes. >
The Landscape of Parallel EVM
In addition to Monad, the landscape of parallel EVM includes Sei, MegaETH, Polygon, Neon EVM, BSC, and Paradigm's Reth client. Monad, Sei, Polygon, and BSC are Layer 1 blockchains, while MegaETH may be a Layer 2 solution. Neon EVM is based on the Solana network, and Reth is an open-source client, with part of MegaETH's development based on Reth.
The primary condition for parallel EVM is EVM-compatible networks. Although networks like Solana, Aptos, Fuel, and Sui adopt parallel execution, they are not considered parallel EVM projects because they are non-EVM networks.
Currently, existing parallel EVM networks can be categorized into three types:
EVM-compatible Layer 1 networks upgraded through parallel execution technology: These networks initially did not adopt parallel execution but upgraded through technological iterations to support parallel EVM. For example, Polygon completed its parallel EVM upgrade in 2022, and Fantom's upcoming Fantom Sonic upgrade will also introduce parallel execution.
EVM-compatible Layer 1 networks that adopted parallel execution technology from the start: For example, Monad, Sei V2, and Artela.
Layer 2 networks adopting non-EVM parallel execution technology: These include scalability-oriented Layer 2 EVM-compatible chains, such as Solana Neon, Eclipse, and Lumio. These networks abstract the EVM into a pluggable execution module, allowing the selection of the best "VM execution layer" as needed to achieve parallel capabilities. For instance, Lumio's settlement layer is on Ethereum, but its execution layer can use Solana VM, Move VM, EVM, etc.
Projects
Monad: Leading Parallel EVM
Monad aims to solve the scalability issues of traditional EVM by optimizing EVM parallel execution and pipelining architecture, targeting 10,000 TPS. On April 9, Monad completed a $225 million funding round led by Paradigm, achieving a valuation of $3 billion. Previously, it raised $19 million in a seed round last February, bringing its total funding to $244 million, making it the most funded and highest-valued parallel EVM project to date. The founding team members include individuals from market-making giant Jump Trading. Founder Keone Hon served as the head of research at Jump Trading for eight years, and co-founder James Hunsaker was a senior software engineer there and a core maintainer of Pyth Network. Monad's internal testnet launched in March and is expected to open to the public in a few months.
Sei: Launching Parallel EVM Network Sei V2
Sei was initially a Layer 1 network focused on trading, providing advanced trading application infrastructure such as DeFi, DEX, and gaming. Last November, Sei announced a comprehensive upgrade to Sei V2, becoming the first high-performance parallel EVM, increasing its TPS to 12,500. The parallel EVM testnet went live in February this year, supporting one-click migration of EVM applications. The mainnet is expected to launch in the first half of this year. In March, Sei introduced the Parallel Stack open-source framework, supporting Layer 2 and Rollup networks to adopt parallel processing technology.
Artela: Enhancing Execution Layer with EVM++ Dual Virtual Machine
Artela aims to unlock the scalability of Layer 1 networks by extending EVM to support parallel execution. By building EVM++ (EVM + WASM), Artela aims to enhance the performance of EVM blockchains and network execution efficiency. Core team members come from AntChain. The public testnet is live, and Artela's ecosystem incentive program, "Renaissance Plan," was launched in April.
Canto: Introducing Parallel EVM Technology
Canto is an EVM-compatible Layer 1 network built on the Cosmos SDK, designed specifically for DeFi applications. In March, Canto announced the Cyclone Stack development plan, which aims to introduce parallel execution EVM technology to enhance network performance.
Neon: Solana EVM Compatibility Solution
Neon EVM is a parallel EVM built on the Solana network and is the first Solana EVM compatibility solution. It allows Solidity and Vyper EVM developers to deploy their DApps to Solana with one click, enjoying Solana's high throughput and low gas fees. Neon EVM packages transactions similar to EVM networks into Solana transactions for execution, thereby increasing transaction speed, with TPS exceeding 2,000.
Eclipse: Bringing SVM to Ethereum
Eclipse is a modular Layer 2 solution supported by the Solana Virtual Machine (SVM). Eclipse settles transaction data on Ethereum, using ETH as gas, but its execution layer runs in the SVM environment. Unlike Neon, which brings EVM to Solana, Eclipse brings SVM to Ethereum, executing transactions on Solana's SVM while settling on Ethereum. Eclipse recently raised $50 million in a Series A funding round led by Hack VC. The mainnet is expected to open to developers soon.
Lumio: Modular VM Layer 2
Lumio is built on the OP Stack and is a modular VM Layer 2 network, part of the Optimism superchain, known as SuperLumio. It aims to introduce high-performance virtual machines (such as Aptos VM, Move VM, and Solana VM) into existing major Ethereum and Bitcoin Layer 2 networks. Similar to Eclipse, Lumio supports using Ethereum or Bitcoin as the settlement layer, with the execution layer capable of using virtual machines like Aptos VM and Solana VM for parallel execution.
>
Conclusion
As blockchain technology evolves, focusing on the execution layer is as important as on consensus algorithms to achieve high performance. Innovations like parallel EVM provide promising solutions to enhance throughput and efficiency, making blockchains more scalable and capable of supporting a wide user base. The development and implementation of these technologies will shape the future of the blockchain ecosystem, driving further advancements and applications in the field.
References:
