EVM Parallelization Optimization: A Key to Enhancing Blockchain Performance

As the core execution engine of Ethereum, EVM has always processed transactions in a serial manner. This approach, while simple and easy to maintain, has increasingly exposed its performance bottlenecks as the user base expands and technology advances. Especially today, with the widespread application of Rollup technology, the serial execution of EVM has become a significant factor restricting the development of layer two networks.

Sequencer, as a core component of Layer 2, undertakes all computational tasks in the form of a single server. When the efficiency of other modules is high enough, the processing capacity of the Sequencer itself becomes the ultimate bottleneck. Some teams have optimized the DA layer and data read/write modules, enabling the Sequencer to execute about 2000 ERC-20 transfers per second. This number seems considerable, but when faced with more complex transactions, the TPS will inevitably decline significantly. Therefore, the parallelization of transaction processing has become an inevitable trend for future development.

In the code structure of Ethereum, in addition to the EVM, the stateDB is also a core component closely related to transaction execution. It is responsible for managing the account states and data storage of Ethereum. Every time the EVM executes a transaction, it alters certain data in the stateDB, and these changes are eventually reflected in the global state tree.

stateDB mainly maintains the status of all Ethereum accounts, including ordinary accounts and contract accounts, storing information such as account balances, smart contract codes, etc. During the transaction execution process, stateDB reads and writes the corresponding account data, and after the execution is completed, the new status is submitted to the underlying database for permanent storage.

In the traditional serial execution model, transactions within a block are processed sequentially one by one. Each transaction has an independent EVM instance to execute specific operations, but all transactions share the same stateDB. The EVM needs to frequently interact with the stateDB during execution, reading and writing relevant data.

The shortcomings of this serial execution model are obvious: transactions must queue up for execution, and if a complex contract transaction takes a long time, subsequent transactions can only be forced to wait, unable to fully utilize hardware resources, which severely limits processing efficiency.

To break through this bottleneck, the industry has proposed a multi-threaded parallel optimization solution for EVM. The core idea is to open multiple threads to process multiple transactions simultaneously, greatly improving efficiency. However, the main challenge of parallel execution is how to handle state conflict issues.

The parallel optimization approach of a certain project for EVM is worth noting. They allocate a transaction and a temporary state database (pending-stateDB) for each thread. The specific steps are as follows:

1. Multi-threaded parallel execution of transactions, with each thread operating independently.

2. Each thread has an independent pending-stateDB, and when a transaction is executed, it does not directly modify the global stateDB but temporarily stores the state changes in the pending-stateDB.

3. After all transactions in the block are executed, the EVM will sequentially synchronize the state changes in each pending-stateDB to the global stateDB.

The project has also optimized read and write operations:

• During read operations, the EVM first checks the ReadSet of the Pending-state. If the required data is available, it is read directly from the pending-stateDB; otherwise, it reads the historical state from the global stateDB of the previous block.

• Write operations are not directly written to the global stateDB, but are first recorded in the WriteSet of the Pending-state. After the transaction execution is complete, it attempts to merge into the global stateDB through conflict detection.

To address the issue of state conflicts, the project introduces a conflict detection mechanism:

• Monitor the ReadSet and WriteSet of different transactions during execution, and consider it a conflict when multiple transactions read and write the same state item.

• Mark conflicting transactions as needing to be re-executed.

After all transactions are executed, multiple pending-stateDB change records are merged into the global stateDB. Upon successful merging, the final state is submitted to the global state tree, generating a new state root.

Multithreading parallel optimization significantly improves performance, especially when handling complex smart contract transactions. Research shows that under low-conflict workloads, the benchmark TPS is 3-5 times higher than traditional serial execution. In high-conflict workloads, theoretically, employing all optimization techniques could even achieve a 60-fold improvement.

This 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 them in parallel across different threads. By optimizing read and write operations and introducing a conflict detection mechanism, it achieves large-scale parallelization of transactions while ensuring state consistency, effectively addressing the performance bottlenecks of the traditional serial execution model. This lays an important foundation for the future expansion of the Ethereum ecosystem.

Future research directions may include further optimizing storage efficiency, improving handling solutions in high-conflict situations, and exploring optimization using GPUs. These advancements will provide new momentum for the ongoing development of Blockchain technology.