The Road to Parallel Optimization of EVM

As we all know, the EVM is one of the most important core components of Ethereum, serving a key role as the "execution engine" and "smart contract execution environment." In a public chain network composed of thousands of nodes, the existence of the virtual machine allows smart contracts to run in the same way on nodes with different hardware configurations, ensuring consistency of results. This cross-platform compatibility is quite similar to the Java Virtual Machine (JVM).

Smart contracts are compiled into EVM bytecode before being deployed on the blockchain. When the EVM executes the contract, it reads these bytecodes sequentially, with each instruction having a corresponding Gas cost. The EVM tracks the Gas consumption during the execution of instructions, and the amount consumed depends on the complexity of the operations.

As the core execution engine of Ethereum, the EVM processes transactions using a serial execution method. All transactions are queued in a single line and executed in a confirmed order. This design is simple and easy to maintain, but as the user base expands and technology iterates, its performance bottlenecks have become increasingly prominent, especially after the maturation of Rollup technology, which is particularly evident in Ethereum's Layer 2 networks.

Sequencer, as a key component of Layer 2, undertakes all computational tasks in the form of a single server. If the efficiency of the accompanying external modules is high enough, the final bottleneck will depend on the efficiency of the Sequencer itself, at which point serial execution will become a significant obstacle.

A certain team has optimized the DA layer and data read/write module to the extreme, allowing the Sequencer to execute over 2000 ERC-20 transfers per second at most. This number seems high, but for complex transactions, the TPS value will inevitably suffer. Therefore, the parallelization of transaction processing will be an inevitable trend in the future.

The Two Core Components of Ethereum Transaction Execution

Aside from EVM, another core component related to transaction execution in go-ethereum is stateDB, which is used to manage account states and data storage in Ethereum. Ethereum uses a Merkle Patricia Trie tree structure as a database index, and each transaction execution in EVM alters certain data in stateDB, with these changes ultimately reflecting in the global state tree.

stateDB is responsible for maintaining the state of all Ethereum accounts, including EOA accounts and contract accounts. The stored data includes account balances, smart contract code, etc. During the transaction execution process, stateDB will read and write the data of the corresponding accounts. After the transaction execution is completed, stateDB needs to submit the new state to the underlying database for persistence processing.

Overall, the EVM is responsible for interpreting and executing smart contract instructions, changing the state on the blockchain based on the computation results, while the stateDB acts as a global state storage, managing the state changes of all accounts and contracts. Together, they create the transaction execution environment of Ethereum.

Specific Process of Serial Execution

Ethereum transaction types are divided into EOA transfers and contract transactions. EOA transfers are the simplest type of transaction, which is the ETH transfer between ordinary accounts, without involving contract calls. They are processed quickly and have very low gas fees.

Contract trading involves the invocation and execution of smart contracts. The EVM, when processing contract transactions, needs to interpret and execute the bytecode instructions in the smart contracts one by one. The more complex the contract logic and the more instructions involved, the more resources are consumed.

For example, the processing time for ERC-20 transfers is about twice that of EOA transfers, while more complex smart contracts, such as trading operations on a certain DEX, may take more than ten times longer than EOA transfers. This is because DeFi protocols need to handle complex logic such as liquidity pools, price calculations, and token swaps during transactions, which require very complex computations.

In serial execution mode, the collaboration process between the EVM and stateDB is as follows:

1. Transactions within a block are processed sequentially, with each transaction having an independent instance executing specific operations.
2. Although each transaction uses a different EVM instance, all transactions share the same state database stateDB.
3. During the execution of the transaction, the EVM needs to continuously interact with the stateDB, reading relevant data and writing back the changed data to the stateDB.
4. After all transactions are processed, the data in stateDB will be committed to the global state tree, generating a new state root.

The bottleneck of the EVM's serial execution model is obvious: transactions must be executed in a sequential queue. If a smart contract transaction takes a long time, other transactions can only wait, which prevents full utilization of hardware resources and significantly limits efficiency.

Multi-threaded Parallel Optimization Scheme for EVM

Parallel EVM is akin to a bank with multiple counters, allowing multiple threads to handle several transactions simultaneously, which can significantly improve efficiency. However, the tricky part is the state conflict issue, which requires coordinated handling.

A certain ZKRollup project has the following parallel optimization ideas for EVM:

1. Multi-threaded parallel execution of transactions: Set up multiple threads to simultaneously process different transactions, with no interference between threads, which can increase transaction processing speed by several times.

2. Allocate a temporary state database for each thread: Each thread is assigned an independent temporary state database (pending-stateDB). When threads execute transactions, they do not directly modify the global stateDB, but temporarily record the state change results in the pending-stateDB.

3. Synchronization of State Changes: After all transactions in a block are executed, the EVM will sequentially synchronize the state change results recorded in each pending-stateDB to the global stateDB. If there are no state conflicts during the execution of different transactions, the records in the pending-stateDB can be smoothly merged into the global stateDB.

The project has optimized the handling of read and write operations to ensure that transactions can correctly access state data and avoid conflicts:

• Read operation: When a transaction needs to read the state, the EVM first checks the ReadSet of the Pending-state. If the required data exists, it is read directly from the pending-stateDB. If the corresponding key-value pair is not found in the ReadSet, historical state data is read from the global stateDB of the previous block.

• Write Operation: All write operations are not directly written into the global stateDB, but are first recorded in the Pending-state's WriteSet. After the transaction execution is completed, the state change results are attempted to be merged into the global stateDB through conflict detection.

To address the issue of state conflicts, a conflict detection mechanism has been introduced:

• Conflict Detection: EVM monitors the ReadSet and WriteSet of different transactions. If multiple transactions attempt to read and write the same state items, it is considered a conflict.
• Conflict handling: When a conflict is detected, the conflicting transaction will be marked for re-execution.

After all transactions are executed, the change records in multiple pending-stateDBs will be merged into the global stateDB. If the merge is successful, the EVM will submit the final state to the global state tree and generate a new state root.

Multithreading parallel optimization significantly improves performance, especially when handling complex smart contract transactions. Research shows that in low-conflict workloads, the benchmark TPS can improve by 3 to 5 times compared to traditional serial execution. In high-conflict workloads, theoretically, if all optimization methods are employed, an improvement of up to 60 times can be achieved.

Summary

The EVM multi-threaded parallel optimization scheme significantly improves the transaction processing capability of the EVM by allocating a temporary state library for each transaction and executing transactions in parallel across different threads. By optimizing read and write operations and introducing conflict detection mechanisms, EVM-based public chains can achieve large-scale parallelization of transactions while ensuring state consistency, addressing the performance bottleneck caused by traditional serial execution models. This lays an important foundation for the future development of Ethereum Rollup.