Ethereum Virtual Machine EVM
EVM vs. Solidity
Writing smart contracts is an essential skill for blockchain developers. Engineers can use Solidity or other high-level languages to implement business logic. However, the EVM cannot interpret Solidity directly; it needs to compile the code into a low-level language (opcode/bytecode) that the virtual machine can execute. Tools exist to automate this conversion, alleviating the need for developers to understand the compilation process.
Conversion introduces additional overhead, but engineers with low-level coding experience can write program logic directly in Solidity using opcodes to achieve maximum efficiency and reduce gas consumption. For example, OpenSea's Seaport protocol makes extensive use of inline assembly to minimize the user's gas overhead.
EVM Performance Differences: Standards and Implementations
The EVM, also known 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 used on the Ethereum Layer 2 network or other independent blockchains, compatibility with the EVM standard allows developers to efficiently deploy smart contracts on multiple networks.
Although compliance with the EVM bytecode standard makes a virtual machine called 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.
Parallel EVM technology
Historically, the blockchain community has mainly focused on the innovation of consensus algorithms, with projects like Solana, Avalanche, and EOS becoming more famous for their consensus mechanisms rather than their execution layers. Although these projects contribute to innovation at the execution layer, their performance is often mistakenly thought to stem solely from their consensus algorithms.
In fact, high-performance blockchains require innovative consensus algorithms and optimized execution layers, similar to the weakest link principle. For the EVM blockchain, which only improves the consensus algorithm, improving performance requires more powerful nodes. For example, Binance Smart Chain (BSC) processes blocks under the gas limit of 2000 TPS, which requires a machine that is several times larger than an Ethereum full node. Although Polygon theoretically supports up to 1000 TPS, its actual performance often falls short of expectations.
Parallel processing needs
In most blockchain systems, transactions are executed sequentially, similar to a single-core CPU, with the next calculation starting only after the current calculation is completed. While this approach is simple and has low system complexity, it is not sufficient to scale to an Internet-scale user base. Moving to multi-core CPU parallel virtual machines can allow multiple transactions to be processed simultaneously, greatly increasing throughput.
Parallel execution brings engineering challenges, such as handling concurrent transactions written to the same smart contract. New mechanisms need to be devised to resolve these conflicts. Executing unrelated smart contracts in parallel improves throughput in proportion to 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 uses an optimistic parallel execution algorithm, allowing multiple transactions to be processed simultaneously. This approach starts transactions from the same initial state, tracks their inputs and outputs, and generates temporary results for each transaction. Monads decide whether to execute the next transaction by checking whether its inputs are related to the outputs of the currently processing transaction. If there is a relationship, the next transaction waits for the current transaction to complete. If there is no relationship, the system processes the next transaction in the original order. This approach significantly improves transaction processing performance and reduces system latency.
Delayed Execution: In Monad’s consensus mechanism, nodes achieve a formal ordering of transactions without requiring master nodes or validator nodes to execute these transactions. Initially, masternodes order transactions and reach consensus among nodes on their order. Monad does not execute transactions immediately, but postpones execution to an independent channel to maximize the use of block time and improve overall execution efficiency.
Custom state database (Monad DB): Monad DB optimizes state storage and access by storing Merkle trees directly on SSD. This direct storage method minimizes the read amplification effect and increases the speed of state access, making smart contract execution faster and more efficient. By reducing the inefficiencies of traditional databases, Monad DB ensures fast 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 between hundreds of globally distributed nodes with linear communication complexity. It uses a pipeline voting stage so that different stages of the voting process can be overlapped, reducing delays and increasing consensus efficiency. This modification significantly improves the network's ability to handle large-scale distributed operations.
challenge
Technical challenges of parallel EVM
Bottlenecks in sequential transaction execution are related to the CPU and state read/write processes. While this approach is simple and reliable, parallel execution introduces potential state conflicts that require pre- or post-execution conflict checking. For example, if a virtual machine supports four parallel threads, each processing a transaction, conflicts will occur when all transactions interact with the same Uniswap pool. This situation requires careful conflict detection and resolution mechanisms to ensure efficient parallel processing.
In addition to the technical differences in implementing parallel EVM, teams often redesign and enhance the read/write performance of state databases and develop compatible consensus algorithms, such as Monad’s MonadDb and MonadBFT.
Challenges and considerations
The two main challenges of parallel EVM are Ethereum's long-term engineering value capture and node centralization. While the current development stage is not yet fully open source to protect intellectual property, these details will eventually be revealed when the testnet and mainnet are launched, risking being absorbed by Ethereum or other blockchains. Rapid ecosystem development will be key to maintaining competitive advantage.
Node centralization is a challenge for all high-performance blockchains, requiring a balance between the “blockchain trilemma” of permissionless, trustless operation and high-performance requirements. Metrics like “TPS per hardware requirement” can help compare the efficiency of blockchains under specific hardware conditions, since lower hardware requirements can enable more decentralized nodes.
The landscape of parallel EVM
In addition to Monad, the parallel EVM landscape also 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, Reth is an open source client, and the development of MegaETH is partly based on Reth.
The main condition for parallel EVM is an EVM-compatible network. Although networks like Solana, Aptos, Fuel, and Sui employ parallel execution, they are not considered parallel EVM projects because they are non-EVM networks.
Currently, existing parallel EVM networks can be divided into three types:
EVM upgraded through parallel execution technology is compatible with Layer 1 networks**: These networks did not initially adopt parallel execution and were iteratively upgraded through technology to support parallel EVM. For example, Polygon completed a parallel EVM upgrade in 2022, and Fantom's upcoming Fantom Sonic upgrade will also introduce parallel execution.
EVM is compatible with Layer 1 networks** using parallel execution technology from the beginning: such as Monad, Sei V2 and Artela.
Layer 2 networks with non-EVM parallel execution technologies**: These include extension-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 best "VM execution layer" to be selected as needed, thereby enabling parallel capabilities. For example, Lumio's settlement layer is on Ethereum, but its execution layer can use Solana VM, Move VM, EVM, etc.
project
Monad: The leading parallel EVM
Monad aims to solve the scalability issues of traditional EVM by optimizing EVM parallel execution and pipeline architecture, with the goal of reaching 10,000 TPS. On April 9, Monad completed US$225 million in financing led by Paradigm, with a valuation reaching US$3 billion. Previously, it raised US$19 million in a seed round of financing in February last year, bringing the total financing amount to US$244 million, becoming the most funded and highest valued parallel EVM project to date. Monad’s founding team includes members from market-making giant Jump Trading. Founder Keone Hon worked as a research director 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 was launched in March and is expected to be available to the public within a few months.
Sei: Launch of parallel EVM network Sei V2
Sei was originally a Layer 1 network focused on trading, providing advanced trading application infrastructure such as DeFi, DEX and games. In November last year, Sei announced a comprehensive upgrade to Sei V2, becoming the first high-performance parallel EVM, increasing its TPS to 12,500. The parallel EVM test network was launched in February this year, supporting one-click migration of EVM applications. The mainnet is expected to go online in the first half of this year. In March this year, Sei launched the Parallel Stack open source framework to support Layer 2 and Rollup networks using parallel processing technology.
Artela: Enhance the execution layer through EVM++ dual virtual machines
Artela aims to unlock the scalability of Layer 1 networks by extending the EVM to support parallel execution. By building EVM++ (EVM + WASM), Artela aims to improve EVM blockchain performance and network execution efficiency. The core team members are from Ant Chain. The public beta network is online, and the Artela ecosystem incentive plan "Renaissance Plan" was launched in April.
Canto: Introducing parallel EVM technology
Canto is an EVM-compatible Layer 1 network built on the Cosmos SDK, specifically designed for DeFi applications. Canto announced the Cyclone Stack development program in March, which aims to introduce parallel execution EVM technology to improve 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 and enjoy Solana's high throughput and low gas fees. Neon EVM encapsulates transactions similar to the EVM network into Solana transactions for execution, thereby increasing transaction speed, with TPS exceeding 2,000.
Eclipse: Bringing SVM to Ethereum
Eclipse is a Rollup Layer 2 modular universal solution powered by the Solana Virtual Machine (SVM). Eclipse settles transaction data on Ethereum, using ETH as gas, but its execution layer runs in an SVM environment. Unlike Neon, which brings EVM to Solana, Eclipse brings SVM to Ethereum, executing transactions on Solana's SVM and settling on Ethereum at the same time. Eclipse recently raised $50 million in Series A funding led by Hack VC and others. The mainnet is expected to be open to developers soon.
Lumio: Modular VM Layer 2
Lumio is built on OP Stack, a modular VM Layer 2 network and part of the Optimism hyperlink, called SuperLumio. It is designed to bring high-performance virtual machines such as Aptos VM, Move VM, and Solana VM to existing major Ethereum and Bitcoin Layer 2 networks. Similar to Eclipse, Lumio supports the use of Ethereum or Bitcoin as the settlement layer, and the execution layer can use virtual machines such as Aptos VM and Solana VM for parallel execution.
in conclusion
As blockchain technology develops, it is equally important to focus on the execution layer and the consensus algorithm to achieve high performance. Innovations such as parallel EVM offer promising solutions to increase throughput and efficiency, making blockchains more scalable and capable of supporting a broad user base. The development and implementation of these technologies will shape the future of the blockchain ecosystem, driving further progress and applications in the field.
References:
