Ethereum EC pruning: disk size and the 4-second deadline
A Geth node and an Erigon node sit in the same rack, follow the same Ethereum mainnet, take the same engine-API traffic from their paired consensus clients. Today the Geth host's root filesystem reports ~1,688 GB used. The Erigon host reports ~509 GB. That is a 3.3× spread, on the same chain, with no archive mode involved. Both are full nodes, both synced to mainnet head.
Disk is only half of it. The same pruning that bounds those footprints also runs on the engine-API hot path, and on some consensus-client pairings it pushes engine_newPayload past the 4-second sync-committee deadline. This post covers both halves: how big each client gets and whether you can see it pruning, then what that pruning costs in latency once a node is at the tip.
- Absolute disk numbers are upper bounds, not steady state. Every EC host here was rebuilt in the last 7 to 16 days (we checked boot times and on-chain history). A fresh node has just finished an initial sync, whose on-disk layout is looser than a long-running, compacted one. The relative ordering (Erigon < Ethrex < Nethermind ≈ Besu < Reth < Geth) comes from architecture, not host age; read "Geth ~1.7 TB" as "heaviest by a wide margin," not a capacity-planning figure.
- We run no validators on this fleet. The latency half measures
engine_newPayload, the EC's slice of a validator's slot budget, not actual missed duties. Read those figures as a risk indicator, not a miss count. - newPayload P99 is observer-dependent. Each CC calls
notifyNewPayloadat a different point in the slot, so the same EC reads differently per CC. Nimbus is the headline; the full matrix is in the latency section. - Reth never finished syncing on this fleet, so it is excluded from the synced comparisons throughout (details in its section).
Key findings:
- 3.3× footprint spread on the same chain (root-FS used per host): Erigon ~509 GB, Ethrex ~598 GB, Nethermind ~1,225 GB, Besu ~1,261 GB, Reth ~1,352 GB (not synced), Geth ~1,688 GB.
- Five of six ECs grew 15 to 19 GB in the 7-day window (~2–3 GB/day, normal block ingestion). The cumulative spread comes from retention policy, not the past week's growth.
- Each EC exposes a different pruning surface, and Ethrex exposes none. Erigon's domain pruner fires ~501 k
blocksevents per host per week; Nethermind'sHybridpruner runs continuously at ~1,497 nodes/sec/host; Geth path-mode prunes implicitly; Ethrex has no pruning metric at all. - Reth is still in initial staged sync: its checkpoint sits ~70 to 130 k blocks behind the tip and is not advancing, so it is excluded from the synced comparisons.
- From Nimbus, three of five synced ECs cross the 4-second deadline on P99
engine_newPayload(Nethermind 4.44 s, Geth 4.67 s, Ethrex ≥5.00 s), but the ranking flips by consensus client. It is a pairing property, not a fixed EC property. - Nethermind's spikes trace to two deliberate v1.37.1 choices.
nethermind_pruning_timespikes past 5 s, over the deadline, entirely from the in-memory pruner. - Sync-committee duties get hit before attestations. A late sync-committee message misses the next block's
sync_aggregateoutright; a late attestation still has one slot of grace.
