Contexts: EVM
EVM vs. Solidity
Writing smart contracts is a fundamental skill for blockchain developers. Engineers can use Solidity or other high-level languages to implement business logic. However, EVM cannot directly interpret Solidity; it requires compilation into a low-level language (opcode/bytecode) that the virtual machine can execute. Tools exist to automate this translation, relieving developers of the need to understand the compilation process.
Translation introduces overhead, but engineers with low-level coding experience can write program logic directly in opcodes within Solidity, achieving maximum efficiency and reducing gas consumption. For example, OpenSea's Seaport protocol uses inline assembly extensively to minimize user gas expenses.
EVM Performance Variability: Standards vs. Implementation
The EVM, also referred to as the "execution layer," is where 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 independent blockchains, compatibility with the EVM standard allows developers to deploy smart contracts across multiple networks with high cost-efficiency.
Though compliance with the EVM bytecode standard qualifies a virtual machine as an EVM, implementation methods can vary widely. For example, 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 custom implementations.
The Technology of Parallel EVM
Historically, the blockchain community has focused primarily on consensus algorithm innovations, with projects like Solana, Avalanche, and EOS being remembered more for their consensus mechanisms than their execution layers. Despite their contributions to execution layer innovations, these projects are often mistakenly thought to derive their performance solely from consensus algorithms.
In reality, high-performance blockchains require both innovative consensus algorithms and optimized execution layers, akin to the weakest link principle. For EVM-based blockchains that only improve consensus algorithms, enhancing performance necessitates more powerful nodes. For instance, Binance Smart Chain (BSC) processes blocks at a 2000 TPS gas limit, requiring machines with configurations several times higher than Ethereum's full nodes. While Polygon theoretically supports up to 1000 TPS, its actual performance often falls short.
The Need for Parallel Processing
In most blockchain systems, transactions are executed sequentially, similar to a single-core CPU where the next computation only begins after the current one completes. While this method is simple and has low system complexity, it is inadequate for scaling to internet-level user bases. Transitioning to a multi-core CPU parallel virtual machine allows for simultaneous processing of multiple transactions, significantly increasing throughput.
Parallel execution presents engineering challenges, such as handling concurrent transactions writing to the same smart contract. New mechanisms must be designed to resolve these conflicts. Parallel execution of unrelated smart contracts can enhance throughput proportionally to the number of parallel processing threads.
Innovations in Parallel EVM
Parallel EVM represents a set of innovations aimed at optimizing the execution layer in blockchain systems. Use Monad as a example, the key innovations include:
-
Parallel Transaction Execution: Monad employs an optimistic parallel execution algorithm, allowing multiple transactions to be processed simultaneously. This method starts transactions from the same initial state and tracks their inputs and outputs, generating provisional results for each transaction. Monad determines whether to execute the next transaction by checking if its input is related to the output of the currently processing transaction. If there is a relationship, the next transaction waits until the current transaction finalizes. If no relationship is detected, the system processes the next transaction in the original order. This approach significantly enhances transaction processing performance and reduces system latency.
-
Deferred Execution: In Monad's consensus mechanism, nodes agree on the official ordering of transactions without requiring the leader or validating nodes to have executed those transactions yet. Initially, the leader node orders the transactions and achieves consensus on their sequence among the nodes. Rather than executing transactions immediately, Monad defers execution to a separate channel, maximizing block time utilization and enhancing overall execution efficiency.
-
Custom State Database (Monad DB): Monad DB optimizes state storage and access by storing Merkle trees directly on SSDs. This direct storage approach minimizes read amplification, enhancing state access speed and making the execution of smart contracts faster and more efficient. By reducing the inefficiencies associated with traditional databases, Monad DB ensures rapid retrieval of state variables during parallel transaction execution.
-
High-Performance Consensus Mechanism (Monad BFT): Monad BFT, an improved version of the HotStuff consensus mechanism, supports synchronization among hundreds of globally distributed nodes with linear communication complexity. It uses pipelined voting stages to allow different stages of the voting process to overlap, reducing delay and increasing consensus efficiency. This modification significantly boosts the network's capacity to handle large-scale distributed operations.
Challenges
Technical Challenges of Parallel EVM
Sequential transaction execution bottlenecks are tied to CPU and state read/write processes. While this method is simple and reliable, parallel execution introduces potential state conflicts, requiring pre- or post-execution conflict checks. For instance, if a virtual machine supports four parallel threads, each handling a transaction, conflicts arise if all transactions interact with the same Uniswap pool. Such scenarios require careful conflict detection and resolution mechanisms to ensure efficient parallel processing.
Beyond the technical differences in implementing Parallel EVM, teams generally redesign and enhance state database read/write performance and develop compatible consensus algorithms like Monad's MonadDb and MonadBFT.
Challenges and Considerations
Two primary challenges for Parallel EVM are long-term engineering value capture by Ethereum and node centralization. While current development stages are not fully open-source, protecting intellectual property, these details will eventually be disclosed upon testnet and mainnet launches, risking absorption by Ethereum or other blockchains. Rapid ecosystem development will be crucial to maintain competitive advantages.
Node centralization poses a challenge to all high-performance blockchains, necessitating a balance between “blockchain trilemma” - permissionless, trustless operations and high-performance demands. Metrics like "TPS per hardware requirement" could help compare blockchains' efficiency under specific hardware conditions, as lower hardware demands could enable more decentralized nodes.
Parallel EVM Landscape
Apart from Monad, the Parallel EVM landscape includes Sei, MegaETH, Polygon, Neon EVM, BSC, and Paradigm's Reth client. Monad, Sei, Polygon, and BSC are Layer 1 blockchains, while MegaETH is likely a Layer 2 solution. Neon EVM is based on the Solana network, and Reth is an open-source client, with MegaETH development partly 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 since they are non-EVM networks.
Currently, existing parallel EVM networks can be categorized into three types:
-
EVM-Compatible Layer 1 Networks Upgraded with Parallel Execution Technology: Initially not employing parallel execution, these networks have 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 Built with Parallel Execution Technology: Examples include Monad, Sei V2, and Artela.
-
Layer 2 Networks Employing Non-EVM Parallel Execution Technology: These include expansion-oriented Layer 2 EVM-compatible chains like Solana Neon, Eclipse, and Lumio. These networks abstract EVM into a pluggable execution module, allowing the selection of the best "VM execution layer" as needed, thereby achieving 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 traditional EVM scalability issues by optimizing EVM with parallel execution and pipelined architecture, targeting a TPS of 10,000. On April 9, Monad completed a $225 million funding round led by Paradigm, reaching a valuation of $3 billion. Previously, it raised $19 million in a seed round in February last year, bringing total funding to $244 million, making it the highest-funded and valued parallel EVM project to date. Monad's founding team includes members from market-making giant Jump Trading. Keone Hon, the founder, was a research head 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, initially a Layer 1 network focused on trading, provides advanced infrastructure for trading applications such as DeFi, DEX, and gaming. In November last year, Sei announced a comprehensive upgrade to Sei V2, becoming the first high-performance parallelized EVM, boosting its TPS to 12,500. The parallel EVM testnet launched in February this year, supporting one-click migration of EVM-based 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 in adopting parallel processing technology.
Artela: Enhancing Execution Layer with EVM++ Dual Virtual Machine
Artela aims to unlock Layer 1 network scalability by extending EVM to support parallel execution. By building EVM++ (EVM + WASM), Artela seeks to enhance EVM blockchain performance and network execution efficiency. The core team members come from AntChain. The public testnet is live, and the Artela ecosystem incentive plan, Renaissance Plan, was launched in April.
Canto: Introducing Parallel EVM Technology
Canto, an EVM-compatible Layer 1 network built on Cosmos SDK and designed for DeFi applications, announced the Cyclone Stack development plan in March. This plan aims to introduce parallel execution EVM technology to enhance network performance.
Neon: Solana EVM Compatibility Solution
Neon EVM is a parallelized EVM built on the Solana network and the first Solana EVM compatibility solution. It supports Solidity and Vyper EVM developers in deploying their DApps to Solana with one click, benefiting from Solana's high throughput and low gas fees. Neon EVM wraps transactions similar to EVM networks into Solana transactions for execution, increasing transaction speed with a TPS of over 2,000.
Eclipse: Introducing SVM to Ethereum
Eclipse is a Rollup Layer 2 modular general solution supported by Solana Virtual Machine (SVM). Eclipse settles transaction data on Ethereum, using ETH as gas, but runs its execution layer in the SVM environment. Unlike Neon, which brings EVM to Solana, Eclipse introduces SVM to Ethereum, executing transactions on Solana's SVM while settling on Ethereum. Eclipse recently raised $50 million in an A round led by Hack VC and others. The mainnet is expected to open to developers soon.
Lumio: Modular VM Layer 2
Lumio, built on the OP Stack, is a modular VM Layer 2 network and part of the Optimism Superchain, known as SuperLumio. It aims to bring high-performance VMs like 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 its settlement layer, with the execution layer capable of using VMs like Aptos VM and Solana VM for parallel execution.
Conclusion
As blockchain technology evolves, focusing on the execution layer alongside consensus algorithms is crucial for achieving high performance. Innovations like Parallel EVM offer promising solutions to enhance throughput and efficiency, making blockchains more scalable and capable of supporting extensive user bases. The development and implementation of such technologies will shape the future of blockchain ecosystems, driving further advancements and applications in the space.
Reference: