◽Transaction flow

Serhio wants to send some Ether to Paul. →

Serhio opens his Ethereum wallet and creates a transaction sending 1 ETH from his address to Paul's address.

→

That transaction is broadcast to the Ethereum network and starts propagating to all the Ethereum nodes.

→

As the Ethereum nodes receive Serhio's transaction, they add it to their mempool, which is a temporary holding place for unconfirmed transactions.

→

Validator Andrey is validating new Ethereum blocks. He checks the mempool of pending transactions on his node and selects several, including Serhio's transaction to Paul.

→

Validator Andrey includes those selected transactions in the new block he is validating. After solving the proof-of-stake puzzle, he successfully validates the new block and broadcasts it to the network.

All the Ethereum nodes see the new valid block mined by Andrey and add it to their copy of the blockchain. This confirms all the transactions in that block, including Serhio's transaction to Paul.

→

Serhio's transaction is now removed from the mempool of all nodes as it has been confirmed and included in the blockchain.

→

Paul has now received 1 ETH from Serhio.

The nature of the mempool

The mempool isn't a single pool

The statement "many such cases" is reliable dogma, even in the case of mempools, because there is no single universal mempool. Each node on the Ethereum network maintains its own independent mempool of pending transactions. Therefore, thousands of nodes contain thousands of mempools.

Some mempool are more equal than others

Since transaction changes don't propagate consistently or instantly across nodes, a single transaction can simultaneously exist in multiple states across different mempools. This leads to inconsistencies across mempools, due to their differences in nodes, clients, configurations, and network peering. At no time do they contain the same transactions exactly or reflect the same state.

Mempool sizes can vary

When we look at the size of a mempool, depending on the number of pending transactions at a given time, which varies based on network activity, the mempool can be larger or smaller. As a result, longer wait times are needed for transaction confirmations for a larger mempool.