As we all know, EVM is positioned as Ethereum's "execution engine" and "smart contract execution environment", and can be said to be one of Ethereum's most important core components. The public chain is an open network with thousands of nodes. The hardware parameters of different nodes vary greatly. If you want smart contracts to run the same results on multiple nodes and meet "consistency", you must try to build the same environment on different devices, and virtual machines can achieve this effect.

Ethereum's virtual machine EVM can run smart contracts in the same way on different operating systems (such as Windows, Linux, macOS) and devices. This cross-platform compatibility ensures that each node can get consistent results after running the contract. The most typical example is the Java virtual machine JVM.

The smart contracts we usually see in the block browser are first compiled into EVM bytecode and then stored on the chain. When EVM executes the contract, it directly reads these bytecodes in sequence, and each instruction (opCode) corresponding to the bytecode has a corresponding Gas cost. EVM tracks the Gas consumption of each instruction during execution, and the consumption depends on the complexity of the operation.

In addition, as the core execution engine of Ethereum, EVM processes transactions in a serial execution mode. All transactions are queued in a single queue and executed in a certain order. The reason why parallelization is not used is that the blockchain must strictly meet consistency. A batch of transactions must be processed in the same order in all nodes. If the transaction processing is parallelized, it is difficult to accurately predict the transaction order, unless the corresponding scheduling algorithm is introduced, but this will be more complicated.

The Ethereum founding team in 2014-15 chose the serial execution mode due to time constraints. Because it is simple in design and easy to maintain. However, with the iteration of blockchain technology and the increasing number of user groups, the requirements of blockchain for TPS and throughput are getting higher and higher. After the emergence and mature implementation of Rollup technology, the performance bottleneck brought by EVM serial execution has been exposed on Ethereum Layer 2.

As a key component of Layer2, Sequencer undertakes all computing tasks in the form of a single server. If the efficiency of the external modules that cooperate with Sequencer is high enough, the final bottleneck will depend on the efficiency of Sequencer itself. At this time, serial execution will become a huge obstacle.

The opBNB team has optimized the DA layer and data read/write modules to the extreme, and the Sequencer can execute up to about 2,000 ERC-20 transfers per second. This number seems high, but if the transaction to be processed is much more complicated than the ERC-20 transfer, the TPS value will inevitably be greatly reduced. Therefore, parallelization of transaction processing will be an inevitable trend in the future.

If we use real-life examples to compare serial execution and parallel execution, the former is like a bank with only one counter, and the parallel EVM is like a bank with multiple counters. In parallel mode, multiple threads can be opened to process multiple transactions at the same time, and the efficiency can be improved several times, but the tricky part is the state conflict problem.

If multiple transactions all declare that they want to rewrite the data of a certain account, conflicts will arise when they are processed at the same time. For example, only 1 NFT can be minted, and both transaction 1 and transaction 2 declare that they want to mint the NFT. If their requests are met, there will obviously be errors. Coordination is required to deal with such situations. State conflicts in actual operations are often more frequent than we mentioned, so if transaction processing is to be parallelized, measures must be taken to deal with state conflicts.

Reddio's parallel optimization principle for EVM

Let's take a look at the parallel optimization ideas of the ZKRollup project Reddio for EVM. Reddio's idea is to assign a transaction to each thread and provide a temporary state database in each thread, called pending-stateDB.

1. Multithreaded parallel execution of transactions: Reddio sets up multiple threads to process different transactions at the same time, and the threads do not interfere with each other. This can increase the transaction processing speed several times.

2. Allocate a temporary state database for each thread: Reddio allocates an independent temporary state database (pending-stateDB) for each thread. When executing transactions, each thread will not directly modify the global stateDB, but temporarily record the state change results in pending-stateDB.

3. Synchronous state changes: After all transactions in a block are executed, EVM will synchronize the state change results recorded in each pending-stateDB to the global stateDB in turn. If there is no state conflict between different transactions during the execution process, the records in pending-stateDB can be smoothly merged into the global stateDB.

Reddio optimizes the processing of read and write operations to ensure that transactions can correctly access state data and avoid conflicts.

Reddio has optimized how it handles read and write operations to ensure transactions can correctly access state data and avoid conflicts.

Read operation: When a transaction needs to read the state, EVM will first check the ReadSet of Pending-state. If the ReadSet shows that the required data exists, the EVM reads the data directly from pending-stateDB. If the corresponding key-value (key-value pair) is not found in the ReadSet, the historical state data is read from the global stateDB corresponding to the previous block.

Write operations: All write operations (that is, modifications to the state) will not be written directly to the global stateDB, but will first be recorded in the WriteSet of Pending-state. After the transaction execution is completed, try to merge the state change results into the global stateDB through conflict detection.

The key problem with parallel execution is state conflict, which is particularly significant when multiple transactions try to read and write the state of the same account. For this reason, Reddio introduces a conflict detection mechanism:

Conflict detection: During transaction execution, EVM monitors the ReadSet and WriteSet of different transactions. If multiple transactions are found trying to read or write the same status item, it is considered a conflict.

Conflict handling: When a conflict is detected, the conflicting transaction will be marked as requiring re-execution.

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

The performance improvement of multi-threaded parallel optimization is obvious, especially when dealing with complex smart contract transactions.

According to research on parallel EVM, in low-conflict workloads (less conflicting transactions in the transaction pool or transactions occupying the same resources), the TPS of the benchmark test is improved by about 3 to 5 times compared with traditional serial execution. In high-conflict workloads, theoretically even 60x can be achieved if all optimizations are used

Reddio's EVM multi-thread parallel optimization solution significantly improves EVM's transaction processing capabilities by allocating a temporary state library for each transaction and executing transactions in parallel in different threads. By optimizing read and write operations and introducing a conflict detection mechanism, the EVM-based public chain can achieve large-scale parallelization of transactions while ensuring state consistency, and solves the performance bottleneck caused by the traditional serial execution mode. This lays an important foundation for the future development of Ethereum Rollup