Blockchain node DB designs: from Geth to Erigon
summary
Erigon abandons live Merkle trees in the hot path and stores accounts and storage as flat key-value storage, then computes roots in a separate merkleization stage so execution is faster and commitments can be re-generated or upgraded. Engineering choices include bitmaps and dupsort subtables for compact history, and an ETL external-merge-sort step to reduce write amplification, cutting archival full-sync from roughly seven days to about 30 hours. MDBX is chosen to hold multi-terabyte archives reliably with transactional safety.
AI-written summary · about
chapters (9)
- 0:00Introduction to node storage
- 2:38Ethereum node architecture
- 4:08State database fundamentals
- 6:42Optimizing storage at Aragon
- 11:28Advanced engineering hacks
- 12:19Choosing a database engine
- 15:49ETL frameworks and sort order
- 18:22Future roadmap and snapshots
- 20:08Q&A and performance metrics
related talks
37mDiabolic Database Design
29mThe Design and Evolution of Event-Driven Databases
31mReimagining the Future: Where the Market is Evolving
25mManaging changes to your data with dat
17mA New Radix-Tree Based Memory Storage Engine
20mSlimArchive: A Lightweight Architecture for Ethereum Archive Nodes
14mRETH & Ethereum Resilience
42mJepsen 9: A Fsyncing Feeling