Overview of EVM transaction processing

On Ethereum, engineers often write smart contracts in the Solidity language and compile them into binary code to be executed within the Ethereum Virtual Machine (EVM).

According to the Ethereum Yellow Paper's definition, both smart contracts and the execution of Ethereum itself are governed by a predefined protocol executed on all Ethereum client nodes. In the Ethereum network, all clients are peers and connected through a peer-to-peer (P2P) network. They maintain consistency of the Ethereum network's ledger, retrieve the latest blocks, and integrate the EVM to execute smart contracts.

With the upgrade to ETH2.0, the current Ethereum ecosystem consists of two types of clients: execution clients, also known as ETH1.0 clients, and consensus clients. Execution clients still employ Proof-of-Work (PoW) consensus, while consensus clients utilize Proof-of-Stake (PoS) consensus. As Ethereum evolves, the network will further converge, ultimately retaining only the PoS consensus.

The processing of Ethereum transactions occurs within execution clients. The most popular Ethereum execution clients currently include Geth and Erigon. Our main focus is also on execution clients. If not otherwise specified in the following text, when discussing clients, we are referring to Ethereum's execution clients.

Full-node clients in Ethereum store the complete set of network data and maintain the Ethereum world state. Each transaction and execution of a smart contract represents a modification to the world state. To ensure network consistency, the EVM was designed to operate in a serial execution mode. Consequently, when replaying a block on a client, only a single CPU core can be utilized, while the other cores are limited to auxiliary tasks, such as preloading account information involved in transactions into memory through parallel preprocessing.

Although Ethereum clients are technically peers, in practice, most clients perform block validation tasks, while only a small portion are involved in block sorting and packaging. Furthermore, there may be discrepancies in the timeliness of P2P network propagation.

We aim to leverage this asymmetrical relationship to provide a method for the majority of clients that primarily perform "verification" work to parallelize transaction processing and fully utilize the multi-core CPU performance of servers. We have designed a P-G mechanism that involves nodes with advantages in block production and network positions acting as Pioneer nodes. While sequentially executing transactions and EVM, the intermediate states are recorded and propagated to Guard Nodes that solely perform "verification" tasks. The Guard Nodes can utilize this intermediate state information to parallelize transaction processing and EVM execution, completing the task of validating blocks.