How to Enable Partial History Expiry (PHE) on Geth, Besu and Nethermind Clients

Learn how to enable Partial History Expiry (PHE) on Geth, Besu, and Nethermind, a major step toward lighter Ethereum nodes, reduced storage, and a stateless future.

How to Enable Partial History Expiry (PHE) on Geth, Besu and Nethermind Clients

Partial History Expiry (PHE) has quietly shipped across Ethereum’s major clients, Geth, Besu, Nethermind and it's a foundational shift for node operators.

This guide walks you through what PHE is, how to enable it and what you should know before turning it on.

What Is Partial History Expiry?

By default, Ethereum clients store the full history of the blockchain, every block, every state change, going back to Genesis. While that's powerful, it's also heavy: running a full node can require terabytes of space.

Partial History Expiry (PHE) allows clients to discard historical block data older than a specific age, like 365 days. This makes nodes lighter, faster to sync, and more sustainable.

read more here: Ethereum Clients Roll Out Partial History Expiry

PHE does not impact consensus. It’s purely a local client setting for managing storage.

BREAKING-NEWS-5

⚙️ Enabling PHE on Geth

Requirements:

  • Geth version v1.14.0 or later
  • Works with snap sync or full sync

Command to Enable:

geth --history.expiration 365

This retains the most recent 365 days of history and prunes older blocks.

To disable:

geth --history.expiration 0

Verify:

  • Monitor logs for history pruning activity
  • Check disk usage with du -sh on your data directory

⚙️ Enabling PHE on Besu

Requirements:

  • Besu version v25.7.0 or newer
  • PHE is enabled by default for new SNAP-sync nodes

To set manually:

--data-storage-archive-mode=prune
--Xhistory-expiration=365

You can configure this via CLI or in your config.toml.

Verify:

  • Check logs for expiration checkpoints
  • Observe data size changes after sync

Note: If your node was synced before this release, you may need to resync to benefit from PHE.

⚙️ Enabling PHE on Nethermind

Requirements:

  • Nethermind version from early 2024 onward (recent versions support this)

Configuration:

In config.cfg or passed via CLI:

HistoryRetentionLimit = 365

Adjust this number as needed (in days). Nethermind uses this to prune blocks older than the limit.

To Confirm:

  • Monitor logs for “history pruning”
  • Check database size over time

Screenshot-2025-07-10-142939

What Happens During PHE?

Once enabled:

  • The node continues syncing and validating the latest blocks
  • Older blocks are pruned from local storage
  • JSON-RPC calls to expired blocks will return errors like “block not found”

This does not impact chain validation or future syncs.

BREAKING-NEWS-6

When Not to Enable PHE

Avoid enabling PHE if:

  • You run archive nodes for tools like The Graph, Dune, etc.
  • You use trace APIs (e.g., debug_traceBlockByNumber)
  • You need full replay/debug access for forensic tools

In those cases, keep PHE off or run a separate archival node.

Where Does This Fit in Ethereum’s Roadmap?

Partial History Expiry is a major stepping stone toward stateless Ethereum.

  • It supports EIP-4444, which proposes clients stop serving blocks older than 1 year
  • It lays groundwork for Verkle Tries, where Ethereum becomes truly stateless

“Pruning is the protocol learning to forget, so it can scale lighter and faster”.

BREAKING-NEWS-3

How PHE Works Internally (Simplified)

When a new block is imported:

  1. The client checks how old it is
  2. If it’s older than your expiry window (e.g., 365 days)…
  3. It deletes the block’s stored data (not state)

This keeps the local DB lean, while consensus and state remain intact.

BREAKING-NEWS-2

Why only these three Clients?

  • These are the most widely used clients for mainnet nodes today:

    • Geth: Dominant in production use (~60% of EL nodes)
    • Besu: Popular in enterprise, infra providers (like ConsenSys)
    • Nethermind: Gaining traction with tooling/dev-focused communities
  • Other clients either:

    • Handle data differently (e.g., Erigon)
    • Haven’t prioritized it
    • Are experimental/new (e.g., Reth)

Recommended Reads


Disclaimer: The information contained in this website is for general informational purposes only. The content provided on this website, including articles, blog posts, opinions, and analysis related to blockchain technology and cryptocurrencies, is not intended as financial or investment advice. The website and its content should not be relied upon for making financial decisions. Read full disclaimer and privacy Policy.

For Press Releases, project updates and guest posts publishing with us, email to contact@etherworld.co.

Subscribe to EtherWorld YouTube channel for ELI5 content.

Share if you like the content. Donate at avarch.eth

You've something to share with the blockchain community, join us on Discord!

Follow us at Twitter, LinkedIn, and Instagram.


Share Tweet Send
0 Comments
Loading...
You've successfully subscribed to EtherWorld.co
Great! Next, complete checkout for full access to EtherWorld.co
Welcome back! You've successfully signed in
Success! Your account is fully activated, you now have access to all content.