The Optimization Path of Parallel EVM: A Perspective from Reddio
TechFlow Selected TechFlow Selected
The Optimization Path of Parallel EVM: A Perspective from Reddio
An overview of the parallel EVM implementation approach for Reddio, an Ethereum Layer 2 solution.
Navigating Web3 tides with focused insightsAuthor: Wuyue, Geeker Web3
As is well known, the EVM serves as Ethereum's "execution engine" and "smart contract execution environment," making it one of Ethereum’s most critical core components. A public blockchain is an open network comprising thousands of nodes with vastly different hardware specifications. To ensure smart contracts produce identical results across all nodes—achieving "consistency"—it's essential to establish a uniform execution environment across diverse devices, which is precisely what virtual machines are designed to do.
Ethereum’s Virtual Machine (EVM) enables smart contracts to run in the same way across different operating systems (such as Windows, Linux, and macOS) and hardware setups. This cross-platform compatibility ensures that every node arrives at the same outcome after executing a contract. The most classic example of this concept is the Java Virtual Machine (JVM).
The smart contracts we view on block explorers have first been compiled into EVM bytecode before being stored on-chain. During execution, the EVM reads these bytecode instructions sequentially, with each opcode carrying a corresponding gas cost. The EVM tracks gas consumption for every instruction executed, where the amount consumed depends on the complexity of the operation.
In addition, as Ethereum’s core execution engine, the EVM processes transactions in a serial manner, queuing all transactions in a single sequence and executing them one by one in a deterministic order. Parallel execution is avoided because blockchains must strictly maintain consistency—every node must process a batch of transactions in exactly the same order. Introducing parallelism would make transaction ordering difficult to predict accurately unless complex scheduling algorithms were implemented, which adds significant complexity.
Due to time constraints during 2014–2015, Ethereum’s founding team opted for serial execution, as it was simple to design and easy to maintain. However, as blockchain technology has evolved and user bases have grown, demands for higher TPS and throughput have increased significantly. With the emergence and maturation of Rollup technology, the performance bottleneck caused by EVM’s serial execution has become glaringly apparent—especially on Ethereum Layer 2 networks.
The Sequencer, a key component of Layer 2, handles all computational tasks as a single server. If all external modules working alongside the Sequencer operate efficiently, the ultimate bottleneck will be determined solely by the Sequencer’s own performance—in which case, serial execution becomes a major impediment.
The opBNB team achieved a peak of over 2,000 ERC-20 transfers per second by heavily optimizing the DA layer and data read/write modules. While this number seems high, if transactions involve far greater complexity than simple ERC-20 transfers, the actual TPS drops significantly. Therefore, transaction processing parallelization is an inevitable future trend.
Below, we’ll dive into specific details to explain the limitations of traditional EVM and the advantages of parallel EVM.
Two Core Components of Ethereum Transaction Execution
At the code module level, besides the EVM, another core component in go-ethereum related to transaction execution is stateDB, responsible for managing account states and data storage on Ethereum. Ethereum uses a tree-like structure called Merkle Patricia Trie as the database index (directory). Every transaction executed by the EVM modifies certain data stored in stateDB, and these changes are ultimately reflected in the Merkle Patricia Trie (hereafter referred to as the global state tree).
Specifically, stateDB maintains the state of all Ethereum accounts, including both externally owned accounts (EOAs) and contract accounts. It stores data such as account balances and smart contract code. During transaction execution, stateDB performs read and write operations on relevant account data. After a transaction completes, stateDB commits the new state to the underlying database (e.g., LevelDB) for persistence.
In summary, the EVM interprets and executes smart contract instructions, changing the blockchain state based on computation results, while stateDB acts as the global state storage, managing state changes across all accounts and contracts. Together, they form Ethereum’s transaction execution environment.
Detailed Process of Serial Execution
Ethereum supports two types of transactions: EOA transfers and contract transactions. EOA transfers are the simplest type—essentially ETH transfers between regular accounts. These do not involve any contract calls and are processed very quickly. Due to their simplicity, EOA transfers incur minimal gas fees.
In contrast to simple EOA transfers, contract transactions involve calling and executing smart contracts. When processing such transactions, the EVM interprets and executes each bytecode instruction within the contract. The more complex the contract logic and the more instructions involved, the greater the resource consumption.
For example, an ERC-20 transfer takes about twice as long as an EOA transfer. More complex operations, such as trading on Uniswap, take even longer—sometimes up to ten times slower than EOA transfers. This is because DeFi protocols must handle complex logic like liquidity pool management, price calculations, and token swaps, requiring intensive computations.
So how do the EVM and stateDB collaborate under serial execution mode?
In Ethereum’s design, transactions within a block are processed sequentially—one after another. Each transaction (tx) has its own independent instance to carry out its specific operations. Although each transaction uses a separate EVM instance, they all share the same state database—stateDB.
During execution, the EVM continuously interacts with stateDB, reading required data from it and writing updated data back.
Let’s examine from a code perspective how EVM and stateDB work together:
1. The processBlock() function calls the Process() function to handle transactions contained in a block;
2. Inside the Process() function, a for-loop shows that transactions are executed one by one;
3. After all transactions are processed, processBlock() calls writeBlockWithState(), which then invokes statedb.Commit() to commit the state changes.
Once all transactions in a block are completed, the data in stateDB is committed to the global state tree (Merkle Patricia Trie), generating a new state root. The state root is a crucial parameter in each block, representing a “compressed” snapshot of the global state after the block’s execution.
It’s clear that the bottleneck of EVM’s serial execution model is obvious: transactions must line up and execute one after another. If a particularly time-consuming smart contract transaction appears, all others must wait until it finishes. This fails to fully utilize hardware resources like CPU, severely limiting efficiency.
Multi-threaded Parallel Optimization for EVM
Using a real-world analogy, serial execution is like a bank with only one counter, whereas parallel EVM is like a bank with multiple counters. In parallel mode, multiple threads can simultaneously process multiple transactions, potentially increasing efficiency several-fold. However, the tricky part lies in handling state conflicts.
If multiple transactions attempt to modify the same account data simultaneously, conflicts arise. For example, suppose only one NFT can be minted, but both Transaction 1 and Transaction 2 claim to mint it. If both requests succeed, a clear error occurs. Such scenarios require coordination. In practice, state conflicts occur frequently, so any parallelization scheme must include mechanisms to detect and resolve them.
Reddio’s Approach to EVM Parallel Optimization
Let’s look at ZKRollup project Reddio’s approach to EVM parallelization. Reddio assigns one transaction per thread and provides each thread with a temporary state database called pending-stateDB. Details are as follows:
1. Multi-threaded parallel transaction execution: Reddio uses multiple threads to process different transactions simultaneously, with no interference between threads—enabling multi-fold increases in processing speed.
2. Assigning temporary state databases to each thread: Each thread gets its own isolated temporary state database (pending-stateDB). Instead of directly modifying the global stateDB, each thread records state changes temporarily in its pending-stateDB.
3. Synchronizing state changes: After all transactions in a block are executed, the EVM synchronizes the state changes from each pending-stateDB into the global stateDB. If no state conflicts occurred during execution, the changes from each pending-stateDB can be merged smoothly into the global stateDB.
Reddio optimizes read and write operations to ensure correct state access and avoid conflicts.
-
Read operations: When a transaction needs to read state data, the EVM first checks the ReadSet in pending-stateDB. If the required data exists there, it reads directly from pending-stateDB. If the key-value pair isn’t found, it retrieves the historical state from the global stateDB of the previous block.
-
Write operations: All writes (i.e., state modifications) are not written directly to the global stateDB. Instead, they are first recorded in the WriteSet of pending-stateDB. Only after conflict detection passes are these changes attempted to be merged into the global stateDB.
The key challenge in parallel execution is state conflict, especially when multiple transactions attempt to read or write the same account state. To address this, Reddio introduces a conflict detection mechanism:
-
Conflict detection: During execution, the EVM monitors ReadSets and WriteSets across transactions. If multiple transactions attempt to read or write the same state item, a conflict is flagged.
-
Conflict resolution: When a conflict is detected, the conflicting transactions are marked for re-execution.
After all transactions complete, the change records from multiple pending-stateDBs are merged into the global stateDB. If the merge succeeds, the final state is committed to the global state tree, generating a new state root.
The performance gains from multi-threaded parallel optimization are evident, especially when handling complex smart contract transactions.
Research on parallel EVM shows that under low-conflict workloads (where few transactions in the mempool compete for the same resources), TPS benchmarks improve by approximately 3–5 times compared to traditional serial execution. Under high-conflict workloads, with all optimizations applied, theoretical improvements can reach up to 60 times.
Summary
Reddio’s multi-threaded parallel EVM optimization significantly enhances transaction processing capacity by assigning temporary state databases to individual transactions and enabling parallel execution across threads. By optimizing read/write operations and introducing conflict detection, EVM-based blockchains can achieve large-scale transaction parallelization while maintaining state consistency, effectively overcoming the performance bottlenecks of traditional serial execution. This lays a vital foundation for the future development of Ethereum Rollups.
We will continue to explore Reddio’s implementation in greater depth, covering topics such as further optimizations for storage efficiency, strategies for handling high-conflict scenarios, and leveraging GPU acceleration, among others.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@godrealmx
