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.
Enabling PHE on Geth
Requirements:
- Geth version
v1.14.0or later - Works with
snapsync 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 -shon your data directory
Enabling PHE on Besu
Requirements:
- Besu version
v25.7.0or 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
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.
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”.
How PHE Works Internally (Simplified)
When a new block is imported:
- The client checks how old it is
- If it’s older than your expiry window (e.g., 365 days)…
- It deletes the block’s stored data (not state)
This keeps the local DB lean, while consensus and state remain intact.
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)
can you make the factual fix and changes and give me the corrected article in same style
Here’s a corrected version in the same style and voice, with factual fixes aligned to the July 2025 PHE rollout and current client guidance.
Partial History Expiry (PHE) has shipped across Ethereum’s major execution clients, and it’s a foundational shift for node operators.
This guide walks you through what PHE is, how to enable it today on Geth, Besu, and Nethermind, and what to know before turning it on.
What Is Partial History Expiry?
By default, Ethereum clients historically stored all block data from Genesis, which is powerful but heavy for disk and sync. Partial History Expiry lets clients remove pre‑Merge historical block bodies and receipts, immediately reclaiming roughly hundreds of gigabytes, without impacting consensus or head validation. PHE today targets pre‑Merge history; fully rolling “keep last N months” expiry remains an active roadmap item.
PHE does not impact consensus. It is a local storage policy; headers remain available for verification while old block bodies/receipts are offloaded or retrieved out‑of‑protocol.
Enabling PHE on Geth
Requirements:
- Geth v1.16.0 or later recommended.
- Applies to pre‑Merge history pruning; not a rolling N‑day retention.
Options:
- New nodes: start with history expiry mode that skips pre‑Merge bodies/receipts during sync (history-expiry mode/options as per release notes).
- Existing nodes: run the provided prune history workflow to remove pre‑Merge block bodies/receipts from local storage, then restart normally.
Example flows (pick one per your release docs):
- Fresh sync with history expiry enabled at startup.
- Offline prune of pre‑Merge history via the maintained prune command, then resume normal operation.
To verify:
- Watch logs for history expiry/pruning completion.
- Check disk usage on the data directory after completion.
Notes:
- There is no supported day-based flag like --history.expiration=365 for rolling retention on mainnet today.
- A higher-level history mode toggle has been discussed in development but is separate from a “days” setting.
Enabling PHE on Besu
Requirements:
- Besu 25.7.0 or newer.
- Scope: pre‑Merge history expiry; rolling time‑based retention is future work.
Options:
- New nodes: start with history expiry enabled so pre‑Merge bodies/receipts are not stored during sync.
- Existing nodes: run the history expiry prune process (online or offline as supported by your version), then continue normal operation.
How to set:
- Use the documented history expiry flag to enable pruning of pre‑Merge history.
- Do not use an --Xhistory-expiration=365 flag; a day-based retention flag is not part of current PHE usage.
Verify:
- Observe logs for pre‑Merge pruning progress/checkpoints.
- Compare database size before/after.
Note:
- Nodes synced before the PHE-supported release may need to run the prune workflow to see space reclaimed; a full resync is optional depending on your environment and target.
Enabling PHE on Nethermind
Requirements:
- Recent Nethermind releases from 2024–2025 that include PHE support.
- Scope: pre‑Merge history expiry by default in recent versions.
Configuration:
- New/default: pre‑Merge history expiry is enabled; Nethermind prunes pre‑Merge bodies/receipts according to the shipped defaults.
- To opt out or tune: use the documented Ancient barriers or related sync/history expiry toggles as per Nethermind docs.
- There is no generally supported “HistoryRetentionLimit = 365 days” for rolling time‑based pruning on mainnet today.
To confirm:
- Monitor logs for history pruning activity.
- Track database size trends post‑prune.
What Happens During PHE?
- The node continues syncing and validating the latest blocks.
- Pre‑Merge block bodies/receipts are pruned from local storage.
- Queries for pruned bodies/receipts may not be served locally; use archive providers, torrents, mirrors, or the Portal Network as they mature.
- Headers remain available to verify chain continuity.
When Not to Enable PHE
Avoid enabling PHE (or run a separate archival setup) if:
- You run archive services (e.g., Graph indexers, full historical analytics).
- You depend on trace/debug APIs requiring historical bodies/receipts.
- You need full replay/debug access for forensics across pre‑Merge data.
Where This Fits in the Roadmap
PHE is a major step toward stateless Ethereum:
- Aligns with EIP‑4444 by reducing the obligation for nodes to serve older block data.
- Establishes the groundwork for broader history availability out‑of‑protocol and for future upgrades like Verkle Tries.
- Rolling, time‑based expiry (e.g., “keep last 12 months”) is planned but not universally shipped as a supported, stable mode yet.
How PHE Works Internally (Simplified)
On pruning or during eligible sync modes:
- The client identifies pre‑Merge range.
- It removes stored block bodies/receipts in that range from the local database.
- It preserves headers so the chain remains verifiable while reducing disk usage.
Consensus/state at the head remains intact; this is storage hygiene, not a consensus change.
Why focus on these clients?
- Geth, Besu, and Nethermind are the most widely used EL clients in production today.
- Other clients like Erigon and Reth also support compatible pre‑Merge history pruning paths but differ in design and configuration surfaces.
- Coverage here prioritizes the three most commonly deployed clients for clarity.
Quick Reference: Do/Don’t
- Do:
- Use the client’s documented history expiry/prune commands for pre‑Merge data.
- Verify disk gains after completion and plan backups before pruning.
- Keep an archive source if your workloads require full history.
- Don’t:
- Expect “--history.expiration=365” to work across clients today.
- Conflate PHE with state expiry; PHE is about old block bodies/receipts, not state.
- Assume RPC to old bodies/receipts will succeed locally after pruning.
If you need, this can be adapted into per‑client step‑by‑step commands from the latest release notes you’re targeting.
Useful Links
- Ethereum Blog: Partial History Expiry
- Geth v1.14.0 Release
- Besu 25.7.0
- Nethermind Releases
- EIP-4444 Spec
Recommended Reads
- Lessons Learned from Fusaka Devnet 2
- Will Fusaka Be Ready in Time? Vitalik's 2025 Vision
- Glamsterdam: The Next Upgrade After Fusaka
- Do We Really Need High Gas Fees? Vitalik Thinks L1 Gas Limits Should Increase
- Nethermind's Surge has Officially Launched its Stage 2 Testnet (Hoodi)
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!
