Ethereum: How to analyze pending blocks

• What is a pending block? It’s the block a node (whether proposer or not) believes will be next in line for inclusion on the chain. A proposer’s pending block is built from their local mempool and is what they’ll broadcast. A non-proposer’s pending block, however, is only a “best guess” since the proposer might have a different mempool or prioritization strategy.
• How does Geth create it? Up to version 1.14.0, Geth continuously managed a pending block in the background, updating it as new transactions arrived. Now, Geth builds a pending block on demand, caches it briefly (2 seconds by default), then discards or updates it when a new block is published or if a reorg happens.
• Why do transaction sets differ? Nodes prioritize local transactions first (if they meet gas requirements) and then sort remote ones by their effective gas tip. The block proposer might see different transactions altogether and order them differently based on fees, local config, or simply having a newer view of the mempool.
• What does the code show? By comparing the “pending” block to the finalized block with the same block number, you can see which transactions made it and how their positions changed. In practice, you’ll often find:
  • Some transactions in the pending block don’t appear in the finalized block.
  • The finalized block may include additional transactions.
  • Transaction orders may differ because the proposer’s actual block can diverge from your local pending snapshot.

​

Main article

​

Introduction

1. Earliest. Refers to the lowest numbered block available to the client.
2. Pending. Refers to the next block anticipated by the client, built atop the latest and including transactions typically sourced from the local mempool.
3. Latest. Points to the most recent block in the client’s observed canonical chain, subject to potential reorganizations even under normal conditions.
4. Safe. Represents the latest block secure from reorganizations under assumptions of an honest majority and specific synchronicity conditions.
5. Finalized. Denotes the most recent crypto-economically secure block, immune to reorganizations except under manual intervention coordinated by the community.

​

Geth implementation

1. Update. When new transactions arrive in the mempool, they are validated, sorted, and included in the pending block.
2. Discarding. When a new block is built and added to the blockchain or a blockchain reorganization occurs, the current pending block may become invalid due to changes in the state. A new pending block is generated based on the new blockchain state.

​

Mempool

​

Pending block

​

Code walkthrough

1. Check the version of the node we are connected to.
2. Fetch a pending block and its number.
3. Fetch the latest block with the same number.
4. Compare transactions in the pending and latest blocks.

​

Prerequisites

1. Log in to your Chainstack account and get a reliable Ethereum RPC endpoint. You can get by with a full node for this exercise.
2. Open your terminal (Command Prompt for Windows or Terminal for macOS/Linux) and run the following command to clone the GitHub repository.
   Bash

   git clone https://github.com/smypmsa/geth-pending-latest-block.git
   cd your-repository
   
3. Set up your Python virtual environment.
   macOS/Linux

   Windows

   python3 -m venv venv
   source venv/bin/activate
   
4. With the virtual environment activated, run the following command to install the required dependencies.
   Bash

   pip install -r requirements.txt
   
5. Create the environment variable file (.env) and paste your Chainstack endpoint URL there.
   Python

   ETH_NODE_URL=<your_eth_node_url>
   

​

Connect to the node

import os
import time

from dotenv import load_dotenv
from web3 import Web3

# Load environment variables
load_dotenv()
ETH_NODE_URL = os.getenv("ETH_NODE_URL")

# Create connection to Ethereum node
web3 = Web3(Web3.HTTPProvider(ETH_NODE_URL))

​

Fetch a pending block

def main():
    if not web3.is_connected():
        print("\nFailed to connect to the Ethereum node.")
        return

    print("\nConnected to the Ethereum node.")
    print("Node version:", web3.client_version)

    # Fetch pending block
    pending_block = web3.eth.get_block('pending')
    pending_block_number = pending_block.number

​

Fetch a finalized block

    # Retry fetching the finalized block with the same block number as the pending block
    finalized_block = None
    start_time = time.time()
    while True:
        try:
            finalized_block = web3.eth.get_block(pending_block_number, full_transactions=True)
            break
        except Exception as e:
            if time.time() - start_time > 60:
                print(f"Failed to fetch the finalized block within 60 seconds: {e}")
                return
        time.sleep(2)

​

Compare transactions

    # Compare transactions in the pending block and finalized block
    print(f"\nComparing txs in pending block and finalized block (block number: {pending_block_number}):")
    pending_block_tx_hashes = {tx.hex() for tx in pending_block.transactions}
    finalized_block_tx_hashes = {tx['hash'].hex() for tx in finalized_block.transactions}

    common_txs = pending_block_tx_hashes.intersection(finalized_block_tx_hashes)
    pending_only_txs = pending_block_tx_hashes - finalized_block_tx_hashes
    finalized_only_txs = finalized_block_tx_hashes - pending_block_tx_hashes

    position_changes = {
        "same_position": 0,
        "higher_position": 0,
        "lower_position": 0
    }

    for tx_hash in common_txs:
        pending_index = [tx.hex() for tx in pending_block.transactions].index(tx_hash)
        finalized_index = [tx['hash'].hex() for tx in finalized_block.transactions].index(tx_hash)

        if pending_index == finalized_index:
            position_changes["same_position"] += 1
        elif pending_index > finalized_index:
            position_changes["higher_position"] += 1
        else:
            position_changes["lower_position"] += 1

​

Putting it all together

import os
import time

from dotenv import load_dotenv
from web3 import Web3

# Load environment variables
load_dotenv()
ETH_NODE_URL = os.getenv("ETH_NODE_URL")

# Create connection to Ethereum node
web3 = Web3(Web3.HTTPProvider(ETH_NODE_URL))

def main():
    if not web3.is_connected():
        print("\nFailed to connect to the Ethereum node.")
        return

    print("\nConnected to the Ethereum node.")
    print("Node version:", web3.client_version)

    # Fetch pending block
    pending_block = web3.eth.get_block('pending')
    pending_block_number = pending_block.number

    # Retry fetching the finalized block with the same block number as the pending block
    finalized_block = None
    start_time = time.time()
    while True:
        try:
            finalized_block = web3.eth.get_block(pending_block_number, full_transactions=True)
            break
        except Exception as e:
            if time.time() - start_time > 60:
                print(f"Failed to fetch the finalized block within 60 seconds: {e}")
                return
        time.sleep(2)

    # Compare transactions in the pending block and finalized block
    print(f"\nComparing txs in pending block and finalized block (block number: {pending_block_number}):")
    pending_block_tx_hashes = {tx.hex() for tx in pending_block.transactions}
    finalized_block_tx_hashes = {tx['hash'].hex() for tx in finalized_block.transactions}

    common_txs = pending_block_tx_hashes.intersection(finalized_block_tx_hashes)
    pending_only_txs = pending_block_tx_hashes - finalized_block_tx_hashes
    finalized_only_txs = finalized_block_tx_hashes - pending_block_tx_hashes

    print(f"\nTxs in pending block: {len(pending_block.transactions)}")
    print(f"Txs in latest block: {len(finalized_block.transactions)}")

    position_changes = {
        "same_position": 0,
        "higher_position": 0,
        "lower_position": 0
    }

    for tx_hash in common_txs:
        pending_index = [tx.hex() for tx in pending_block.transactions].index(tx_hash)
        finalized_index = [tx['hash'].hex() for tx in finalized_block.transactions].index(tx_hash)

        if pending_index == finalized_index:
            position_changes["same_position"] += 1
        elif pending_index > finalized_index:
            position_changes["higher_position"] += 1
        else:
            position_changes["lower_position"] += 1

    print(f"\nTxs with higher position in the latest: {position_changes['higher_position']}")
    print(f"Txs with the same position in the latest: {position_changes['same_position']}")
    print(f"Txs with lower position in the latest: {position_changes['lower_position']}")
    print(f"Txs not included in the latest: {len(pending_only_txs)}")

if __name__ == "__main__":
    main()

​

Pending and latest blocks analysis

​

Key observations

1. The finalized block contains significantly more transactions than the pending block. This means that additional transactions were included by the block proposer after the pending block snapshot was taken.
2. Almost all transactions (120 out of 122) from the pending block ended up in a lower position in the finalized block.
3. Two transactions from the pending block were not included in the finalized block at all. This could be due to various reasons such as insufficient fees, reorganization, or replacement by higher-priority transactions.

​

Conclusion

​

Key findings

• Block proposers construct the pending block using the latest transactions from the local mempool, ensuring they are prioritized and validated according to consensus rules. These blocks are proposed to the network for inclusion in the blockchain.
• Non-block proposers (which can include validators when they are not proposing a block) construct a pending block based on their expectations of the next block’s transactions but lack the guarantee of actual inclusion, as the final decision rests with the block proposer.

• Transactions in the pending block are sourced from the mempool and primarily sorted by their effective gas tip, calculated as the difference between the gas fee cap and the base fee or the gas tip cap.
• Local transactions are prioritized over remote transactions, regardless of their effective gas tip, as long as they meet the minimum gas tip requirement.

• Legacy transactions (Type-0) are sorted by gas price alone, without considering the effective gas tip. This ensures backward compatibility and straightforward inclusion based on gas price.

​

About author

Anton Sauchyk

Developer Advocate @ Chainstack
Multiple years of software development and Web3 expertise