Nodes act as a gateway to the Ethereum network. Before a miner can include your transaction in a block, a node must first accept it. And understanding how nodes accept transactions can unlock insights into how Ethereum works.
Our goal with this Mastering the Mempool series is to help you understand this crucial — but often under-explored — element of Web3. We suggest starting with our first post in the series, where we cover many of the core concepts of the mempool.
In this post, we explore how transactions enter the Ethereum mempool.
Nodes: The Gateways to the Mempool
Every Dapp needs a node to connect to the network. When you sign a transaction, that transaction is sent to the network via a node. In Ethereum, nodes can run different software — Geth and Parity are the two most common (see a full breakdown at ethernodes.org). While there are nuances in how Geth and Parity work, they are similar enough for our discussion today.
When a node receives your transaction, the node performs a series checks to see if the transaction can enter the mempool, including:
- Is the signature valid (i.e., the transaction has not been tampered with)?
- Are all required elements – such as the To: and From: addresses – present and valid?
- Is the From: address an external account (and not a contract account)?
- If the transaction transfers value, does the From: address balance cover the value?
- Does the transaction have a gas limit that’s below the block limit?
- Does the transaction fit into the local mempool? [Note 1: we plan explore mempool configuration options, which in turn control mempool capacity and minimum ETH gas requirements, in a future post in this series.]
If the transaction passes the node's checks, the transaction is added to the node's mempool. That node will also broadcast it to other nodes, called peers. Each of these peers will perform its own checks — adding valid transactions to its mempool and then broadcasting the transaction along to its peers. This process typically propagates the transaction across the entire network of the Ethereum network. [Note 2: In a future post, we plan to cover the networking aspect of nodes and their impact on the mempool. Spoiler alert: not all transactions reach every node!]
Valid transactions that enter the mempool then go into one of two pools — pending or queued. The pending pool is for transactions that are ready to be processed. These are eligible to be mined and may appear in the next block. The queued pool is for transactions that are not yet ready to be processed because they are 'out of order.'
Transaction Order
The transaction order of an address is a critical security feature for blockchains. Like traditional bank accounts – which typically use a centralized timestamp – the order ensures transactions happen in the intended sequence while preventing replay attacks and double-spending. Ethereum transactions use a nonce, a number that increases by one for each transaction.
The nonce guarantees proper transaction order. Any gaps in nonce order (for example: 31, 32, 33, 35) indicate that there may be transactions a node has not yet received. Any transactions with a gap in nonce order enter the queued portion of the mempool.
Confirmed, Pending, and Queued Transactions. The above image shows a snapshot of mempool data available from the Notify API.
Transactions in the queued pool are stuck as long as the gap in nonce order persist. These stuck transactions can lock up a web3 wallet, making it unable to send new transactions that will enter the pending pool and hence be eligible to be confirmed.
Reusing Nonces
Once the nonce of an address is confirmed in a block, it cannot be used again. This ensures a transaction is not replayed.
However, while a transaction is in the mempool, it can be replaced by a new transaction with the same nonce. This replacement feature is enables Speed Up and Cancel transactions, essentially overwriting the original transaction in the mempool with a new one.
There are some specific rules for this replacement feature, which we have discussed in detail in previous posts:
- Everything You Need to Know About Canceled Transactions – and How They Break Dapp UX
- Ethereum Speed Up Transactions: How They Work and What They Mean For Dapps
Not all Nodes are Alike
Since the mempool can use significant system resources – particularly memory – node operators have control over how their mempool is configured. This, in turn, impacts which transactions can be written into each mempool as well as their subsequent behavior. [Note 3: We plan to explore different Ethereum mempool setups in yet another future post.]
Additionally, there are different types of nodes in the Ethereum ecosystem. These nodes all play a different role:
- Full Nodes — Any computer that downloads the entire Ethereum blockchain and address states and validates new blocks. Miners use full nodes.
- Archival Nodes — A full node that also keeps all history for transactions and address state changes.
- Light Nodes — A computer that connects to full nodes as a gateway to the blockchain. Light nodes do not validate blocks and do not maintain the entire blockchain and address state. Light nodes (clients) do not have a mempool.
While you could run your own node to monitor the mempool, many traders and builders rely on The Blocknative Advantage to get real-time mempool data for Ethereum, xDai, and Polygon. Learn more and go-hands on with streaming mempool data in Mempool Explorer today. Combine it with our ETH gas API for a powerful pre-chain layer toolset.
TL;DR
Nodes are the gateway to the mempool. Understanding how they validate and share transactions with other nodes gives us insight into how transactions are confirmed and become part of the blockchain.
Want to dive deeper? Explore the next post in our Mastering the Mempool Series — Why the Mempool Matters: The Hidden Competition for Confirmation.
