Discussion on Parallel EVM Technology

EVM and Solidity

Smart contract development is a fundamental skill for blockchain engineers. Developers typically use high-level languages like Solidity to write business logic, but the EVM cannot directly interpret this code. It needs to be compiled into low-level opcodes or bytecode that can be executed by the virtual machine. While there are tools that can automate this conversion, engineers who understand the underlying principles can program directly in opcodes to achieve maximum efficiency and reduce gas costs.

EVM Standards and Implementation

EVM, as the "execution layer", is the final place where smart contract opcodes are executed. The bytecode defined by EVM has become the industry standard, enabling developers to deploy contracts on multiple compatible networks. Although they follow the same standard, different EVM implementations can vary significantly. For example, Ethereum's Geth client implements EVM in Go language, while the Ethereum Foundation's Ipsilon team maintains the C++ version. This diversity provides room for optimization and customization.

Demand for Parallel EVM

Traditional blockchain systems execute transactions sequentially, similar to a single-core CPU. While this approach is simple, it is difficult to scale to internet-level user volumes. The parallel EVM allows for the simultaneous processing of multiple transactions, significantly increasing throughput. However, this also brings engineering challenges, such as handling write conflicts for concurrent transactions on the same contract. Nevertheless, parallel processing of unrelated contracts can proportionally enhance performance based on the number of threads.

Innovation of Parallel EVM

Taking Monad as an example, its key innovations include:

• Optimistic concurrency control algorithm: allows multiple transactions to be processed simultaneously, detecting conflicts by tracking inputs and outputs.
• Deferred execution: Postpone the execution of transactions to independent channels to maximize the utilization of block time.
• Custom state database: Directly store the Merkle tree on SSD to optimize state access speed.
• High-performance consensus mechanism: Improved HotStuff consensus, supporting hundreds of global nodes to synchronize.

Technical Challenges

Parallel execution introduces potential state conflicts that require conflict detection either before or after execution. For example, conflicts may occur when multiple transactions interact with a Uniswap pool simultaneously. Additionally, teams often need to redesign the state database and develop compatible consensus algorithms.

Overview of Parallel EVM Projects

Current parallel EVM projects can be divided into three categories:

1. Support parallel execution of EVM-compatible Layer 1 networks through upgrades, such as Polygon and the upcoming Fantom Sonic.

2. Adopt EVM-compatible Layer 1 networks with parallel execution from the very beginning, such as Monad, Sei V2, and Artela.

3. Layer 2 networks using non-EVM parallel execution technology, such as Solana Neon, Eclipse, and Lumio.

Main Project Introduction

• Monad: Aiming for 10,000 TPS, completed $244 million in financing, with a valuation of $3 billion.

• Sei: Launched Sei V2, becoming the first high-performance parallel EVM, with a TPS of 12,500.

• Artela: Enhanced execution layer through EVM++(EVM + WASM) dual virtual machines.

• Canto: An EVM-compatible network built on the Cosmos SDK, planning to introduce parallel EVM technology.

• Neon: An EVM-compatible solution on Solana, with TPS exceeding 2,000.

• Eclipse: Bringing Solana's virtual machine to Ethereum's Layer 2 solutions.

• Lumio: A modular VM Layer 2 network that supports various high-performance virtual machines.

The development of parallel EVM technology will provide higher scalability and efficiency for blockchain, promoting further development and application in this field.