Field report · 23 days · mainnet
A head-to-head bake-off of seven execution clients and five consensus clients — the same mainnet sync, on the same host, one client at a time — run end-to-end by a fleet of AI agents.
eth2quickstart.com · 2026-06-22 → 2026-07-14
The rig
Every client got a fair shot: its most disk-efficient mode, a fixed consensus partner, and a hard 72-hour cap. We recorded the final synced disk footprint and the sync duration — then watched what happened on restart.
Result 01 · disk footprint
Nethermind wins among clients that finished a pruned, comparable sync — ~4.6× leaner than geth. The hatched bars never finished: Nimbus-eth1's ~40 GB is only ~21% of a sync, not a win.
Result 02 · cold-sync speed
Completed syncs only. ethrex finished nearly 4× faster than the next client. So why does almost nobody run it?
The paradox
Gaps through 23 minutes resumed; a 26-minute gap stalled. In measured 1.5–2-hour gaps, ethrex discarded its synced state and re-synced from scratch (~2h) — an operability tax that helps explain why the fastest-syncing client has close to zero real-world mainnet adoption.
Bisected with controlled stop → wait → start cycles: clean resume at 12 / 20 / 23 min gaps; stuck at 26 min.
The under-reported axis
Sync speed and disk footprint are easy to measure and easy to publish. How a client behaves after downtime is neither — and it's the axis that most cleanly explains which clients people actually keep running.
Pick up where they left off. Boring, in the best way.
Stops resuming beyond ~25 minutes; longer measured gaps triggered a full re-snap.
A prolonged stale-CL outage aged out the pivot; the downloader died while RPC stayed up.
Execution-client scorecard
| Client | Result | Sync | Footprint | Mainnet |
|---|---|---|---|---|
| Nethermind | synced | ~14.5h | ~251 GiB | 36.0% |
| Geth | synced | 8h28m | ~1.13 TiB | 44.9% |
| Ethrex | synced | 2h16m | ~467 GiB, growing | ~0% |
| Besu | un-pruned | 19h18m | ~1.08 TiB | 17.4% |
| Reth | 72h cap | — | ~0.98 TiB* | 1.5% |
| Nimbus-eth1 | 72h cap | — | ~40 GB* | ~0% |
| Erigon | no-sync | deadlock | — | ~0% |
Only nethermind & geth are pruned-comparable on disk. Besu (un-pruned) and ethrex (still growing) synced fine but their footprints aren't; reth & nimbus-eth1 are full-sync-only, capped here. * partial
Consensus layer
All five checkpoint-synced to a validating head in minutes — ~6–9 min on the geth anchor, ~22–23 min on ethrex — with zero client-fault failures. Sync time is a tie, so footprint is the differentiator.
The same heavyweight/lightweight tiers held across two EL anchors — EL/CL decoupling, supported empirically (lodestar and lighthouse swapped within the smallest tier).
Methodology
A three-tier hierarchy kept the token cost sane and the judgment where it belonged:
Governance, non-negotiable: one candidate at a time · destructive actions human-gated · conventional commits · an agent cannot merge its own PR.
The machine that kept us honest
Nodes sync for 72h in detached systemd; the agent sleeps and wakes on decision-worthy events, not polling logs.
Conclusions pushed down to markdown + CSV so a fresh session recovers the run — no context-window bottleneck.
Before a result counts, the harness verifies the client ran its most disk-efficient mode — else it rejects the run, not the client.
A real benchmark, not a lab result: shared semi-production host, footprint from the final near-cap sample — never a mid-sync peak.
Four incidents, all caught & documented
Head frozen at block 4,651, 0 peers — everything else looked healthy. Root cause: P2P pinned to loopback. Fixed by advertising a routable external IP.
Downloader thread died, process stayed alive and kept answering RPC. Stale pinned CL stalled the beacon past the servable window.
Stalled just beyond ~25 min; longer measured gaps discarded state and re-snapped. Inherent to the current design.
OtterSync + a checkpoint-synced CL never issue the forkchoice update that would close the gap. Raising CPU caps didn't help.
If you run one node for the long haul
The real lesson: operational risk in an Ethereum node lives in the execution layer, not the consensus layer.
Read the whole thing
eth2quickstart.com/blog
One-line install → hardened Ethereum node, 12 clients, MEV integration. github.com/chimera-defi/eth2-quickstart
Speaker notes