What is a Blockchain Mempool and How Does it Work?

When you send your transaction to the blockchain, where is it really going? Transactions, when they are “in-flight,” are often referred to as being “in the mempool,” and you’d see that all too familiar “Pending” text in your Metamask.

The mempool serves as the gateway for blockchain transactions. Before a transaction can be recorded on a block, it must first pass through the mempool.

In this guide, you will learn what a blockchain mempool is, how it works, and how they’re different in chains like Ethereum versus, for example, Bitcoin.

Let’s get started.

‍

What is the mempool?

The mempool is a shortened term for “Memory Pool,” referring to a transaction that is in the memory of a blockchain node but has not been committed to the blockchain in a block yet.

You can think of the mempool as a waiting place or queue of transactions before each is included in the blockchain. A transaction in the mempool is waiting for a node to grab the transaction and include it in a block.

The term originally came from the Bitcoin ecosystem, and different blockchain nodes have different names for it.

• Ethereum via OpenEthereum, calls it the transaction queue
• Ethereum, via Geth, calls it the txpool
• Bitcoin calls it the Mempool

In the world of Bitcoin, a transaction in the mempool waits for a node to mine a block with the transaction included. In Ethereum, a transaction in the mempool waits for a node to validate it and include it in a block.

How do transactions get into the Mempool?

Here's how transactions get into a blockchain mempool, are synched, verfied, validated and propagated across blockchain node:

• Initially, a user starts a transaction from a Dapp or Wallet. This could be sending funds to another account or contract.
• The user then signs the transaction using their Wallet.
• The Wallet forwards the signed transaction to a node or RPC Provider, like Alchemy or Pocket, for inclusion on the blockchain network.
• This node verifies the transaction's validity and adds it to its mempool.
• As the node is part of a peer group, it broadcasts the transaction to other nodes.
• These peer nodes receive, validate, and add the transaction to their mempool. They then broadcast it to more peers, spreading the transaction across the network.
• Miners or validators, a specific node type, also receive the transaction from peers. They validate it and try to add it to a block.
• Eventually, a successful miner or validator includes a block with the transaction on the chain.
• This new block is then broadcast across the network.
• As all nodes receive the new block from their peers, they see the included transaction and remove it from their mempool.

There are as many mempools as there are nodes

We call it a “Memory Pool” since the transaction exists in the node's memory. Technically, each node in a blockchain has its memory pool. The mempool of a single node is essentially just a list of pending transactions.

Often, when people refer to the mempool, they refer to all mempools across all nodes; we’ll explain why further down.

In practice, when referring to the blockchain mempool, we refer to all transactions pending in any node in the blockchain ecosystem. This is because, most of the time, nodes with transactions in their mempool send those queued transactions out to other nodes, hoping that one of those other nodes is selected to build a block and can include the transaction.

When you send a transaction to a node via Metamask, Trezor, or any wallet, you send that transaction to a single node. If you open your Metamask or browser wallet, you’ll see an API (URL) pointing to a single node. That node is the single node to which you send your transaction, which will have it in its mempool.

A node doesn’t have to fan out its list of pending transactions to other nodes, but often, they do to increase the likelihood of the transaction being included. Mining or validating blocks can be time-intensive, requiring computation power or a node to be selected as the block builder. So, if a node never sent its list of pending transactions out to other nodes, that transaction could take a long time to be included!

If ETH node A has Transaction T and they don’t send T to any other node, then ETH node A would have to wait until they were the block builder to include the transaction! If you look at any of the nodes on the beacon chain, you’ll notice it can be months before a node is selected to be the block builder! Imagine having to wait a few months for your transaction to process. This is why most nodes share their mempool (list of queued transactions) with other nodes → to increase the likelihood of the transactions getting placed into a block.

‍

MEV and Private Blockchain Mempools

Based on the statement above, you’d think most blockchain nodes should always share their list of transactions, and for the most part, you’d be right. However, if your transaction carries sensitive information, you might not want to!

If you share the data in your mempool, you’re giving other nodes a heads-up on what transaction you want to send! This can give other nodes or malicious users information they can use against you and steal funds, access, or other nasty things! A node that “builds” a block can look at the incoming transactions and use this information for its gain.

This process of using the information and ordering transactions for monetary benefit is known as MEV or “Maximal Extractable Value,” previously known as “Miner Extractable Value.” The good news is that there is a solution: users can send “secret” transactions to the blockchain using something called private blockchain mempools.

Before getting into private mempools and how they help us protect our assets, let’s quickly look at one popular method of MEV called “front running.”

Maximal extractable value: Front running

// SPDX-License-Identifier: MIT
pragma solidity 0.8.20;

contract FrontRan {
    error BadWithdraw();

    bytes32 public s_secretHash;

    event success();
    event fail();

    constructor(bytes32 secretHash) payable {
        s_secretHash = secretHash;
    }

    function withdraw(string memory password) external payable {
        if (keccak256(abi.encodePacked(password)) == s_secretHash) {
            (bool sent,) = msg.sender.call{value: address(this).balance}("");
            if (!sent) {
                revert BadWithdraw();
            }
            emit success();
        } else {
            emit fail();
        }
    }

    function balance() external view returns (uint256) {
        return address(this).balance;
    }
}

This smart contract has a function called withdraw, where if a user passes in the correct password, the smart contract will decode the password and send the contract balance to whoever entered the password. The password is stored in hash form on-chain via the s_secretHash storage variable and would be very difficult to crack if you didn’t have the password.

The idea behind this contract is that whoever is told the password will be given the funds. However, MEV makes it so that a malicious node or block builder can be the ones to take the funds instead!

A malicious node or “MEV Bot” could see someone calling withdraw with the correct password in the mempool, copy the exact transaction, and order their transaction to go through first! They use the information gained from reading from the mempool to steal the funds of the FrontRan contract.

Looking into Solodit for “MEV” or “Front Running,” we see this attack vector all the time, and it’s a consideration every protocol builder needs to keep in mind when building protocols.

You can view minimized examples of MEV in the sc-exploits-minimized repository from the Cyfrin Updraft security and auditing curriculum.

‍

What is a private blockchain mempool?

Private blockchain mempools send our transaction to a small group of nodes who promise not to look at the transaction's details and affect the transaction's ordering.

The upside of using a service like this is that you won’t have to deal with MEV. The downside is that you have to trust the nodes are not going to do MEV, and it might take longer for your transaction to be included because fewer nodes are attempting to include the transaction in a block.

There are a few ways to send a transaction without it hitting the mempool, using a service like:

• Flashbots Protect
• MEVBlocker
• Securerpc

‍

Pros and cons of using private mempools

Benefits of using a private blockchain mempool

• Increased Privacy: Private blockchain mempools do not broadly expose your transaction details, providing greater privacy for your transactions.
• Reduced Risk of MEV Attacks: By keeping your transaction details private, the risk of MEV (Maximal Extractable Value) attacks is significantly reduced.
• Improved Control over Transaction Ordering: Private mempools provide better control over the order in which transactions are processed.

Disadvantages of using private mempools

• Security Over Speed: Despite potential delays in transaction confirmation due to fewer nodes being involved in the process, the enhanced security and privacy provided by private mempools often outweigh this minor inconvenience.

‍

Summary: What is a blockchain mempool?

The mempool is a pending queue of transactions waiting to be included into a block in a blockchain. It’s important because each node will often share their list of pending transactions with other nodes, which can give rise to MEV (Maximal Extractable Value) attacks.

‍