// the find
erigontech/erigon
Ethereum implementation on the efficiency frontier
Erigon is a Go Ethereum execution client built around a staged sync pipeline and custom MDBX storage that keeps hot state on NVMe while shunting historical snapshots to cheap disk. It syncs mainnet archive in under 8 hours — geth does not. The target audience is node operators who need archive or validator setups and care about hardware costs and sync time over operational simplicity.
The snapshot-based sync genuinely works: downloading pre-built state segments instead of re-executing from genesis is why archive sync takes hours, not days. Per-transaction history granularity (Erigon3 improvement over per-block) means tracing tools can execute one historical transaction in isolation. Caplin, the embedded consensus layer, sidesteps the Engine API's one-block-at-a-time bottleneck — this is architecturally correct for how Erigon processes data in bulk. The rpcdaemon separation lets you point multiple read replicas at the same datadir without duplicating data, which is real horizontal scaling.
prune.mode=full now silently drops all pre-merge block data following partial history expiry — if you're not tracking the changelog you will lose blocks you expected to have. Erigon3 does not store Receipts or Logs; it re-executes transactions on every eth_getLogs call for historical data, which kills any workload doing heavy historical log indexing. MDBX pagesize is fixed at database creation and changing it requires copying the entire database through an integration tool — pick wrong and you own a multi-TB migration. The 3.0→3.1 upgrade path still requires a datadir backup and optional reset-and-resync, which makes validator maintenance windows mandatory rather than optional.