Content Identifiers

In the archives, each Epoch, Block, and Transaction gets a computed content identifier. These content identifiers can uniquely identify any of these elements when retrieving either from a locally stored CAR file or from IPFS or Filecoin.

indexes are used to map Solana's slot numbers, transaction signatures, or epoch numbers onto CIDs.

To learn more about CIDs, you can dive deep into the IPFS documentation here.

From https://docs.ipfs.tech/concepts/content-addressing/#what-is-a-cid:

A content identifier, or CID, is a label used to point to material in IPFS. It doesn’t indicate where the content is stored, but it forms a kind of address based on the content itself. CIDs are short, regardless of the size of their underlying content. CIDs are based on the content’s cryptographic hash. That means:

• Any difference in the content will produce a different CID

• The same content added to two different IPFS nodes using the same settings will produce the same CID.

The CAR files and CIDs generated by Old Faithful are reproducible and will be the same regardless of which Rocksdb ledger archive they are generated from. This means that entities that are running archive nodes and store Rocksdb ledger archives can easily generate their own CIDs for the same blocks and transactions and compare them to the ones being generated by the Old Faithful project theory. This means you can also choose to run a node that just generates and stores the CIDs but not the durable data and then compare those CIDs to the ones provided by Faithful. Using these CIDs, you can retrieve the actual data at any time without trusting anyone but your own data-generating nodes.