# Table of Contents - [Introduction | Old Faithful](#introduction-old-faithful) - [gRPC Methods | Old Faithful](#grpc-methods-old-faithful) - [Looking up CIDs | Old Faithful](#looking-up-cids-old-faithful) - [RPC Methods | Old Faithful](#rpc-methods-old-faithful) - [Indexes | Old Faithful](#indexes-old-faithful) - [Content Identifiers | Old Faithful](#content-identifiers-old-faithful) - [RPC server | Old Faithful](#rpc-server-old-faithful) - [Retrieving from Filecoin | Old Faithful](#retrieving-from-filecoin-old-faithful) - [Usage & Installation | Old Faithful](#usage-installation-old-faithful) - [Geyser | Old Faithful](#geyser-old-faithful) - [Filecoin v2 retrievals | Old Faithful](#filecoin-v2-retrievals-old-faithful) - [Filecoin v1 retrievals | Old Faithful](#filecoin-v1-retrievals-old-faithful) - [Accessing OF1 from old-faithful.net | Old Faithful](#accessing-of1-from-old-faithful-net-old-faithful) - [Local file system | Old Faithful](#local-file-system-old-faithful) - [Generating | Old Faithful](#generating-old-faithful) - [Creating indexes | Old Faithful](#creating-indexes-old-faithful) - [HTTP | Old Faithful](#http-old-faithful) - [Software integrations | Old Faithful](#software-integrations-old-faithful) - [Hosting | Old Faithful](#hosting-old-faithful) - [Warehouse nodes | Old Faithful](#warehouse-nodes-old-faithful) - [Filecoin | Old Faithful](#filecoin-old-faithful) - [Making a local copy | Old Faithful](#making-a-local-copy-old-faithful) - [Validation | Old Faithful](#validation-old-faithful) - [Historical blocks | Old Faithful](#historical-blocks-old-faithful) - [Epoch 208 | Old Faithful](#epoch-208-old-faithful) - [Reproducibility | Old Faithful](#reproducibility-old-faithful) --- # Introduction | Old Faithful [NextContent Identifiers](/introduction/content-identifiers) Last updated 4 days ago The Old Faithful project has several parts: [](#tooling-to-produce-car-files-from-solana-snapshots) Tooling to produce CAR files from Solana snapshots --------------------------------------------------------------------------------------------------------------- The core of the Old Faithful is history archives in Content Addressable aRchives (CAR) format (, ). These represent a verifiable, immutable view of Solana's history. The CAR files that this project generates follow a specifically developed for Solana’s historical archives. The content's addressable nature means that each epoch, block, transaction, and shredding is uniquely identified by a content hash. By knowing this content hash, a user can retrieve a specific object of interest in a trustless manner, i.e., retrieve an object verifiably from a non-trusted source. The tooling operates on (end of epoch) snapshots generated using the default solana-ledger-tool that's used by Solana warehouse nodes to record the full epoch into a single archive. No changes to the default Solana tools are required to produce such archives for Old Faithful. [](#a-full-verified-genesis-archive-of1) A full, verified genesis archive: OF1 ----------------------------------------------------------------------------------- The second component of the Old Faithful project is **OF1**, a full genesis archive that contains every block from the genesis until the current epoch. There's a hot copy of the archive hosted by Triton , and the cold copy is published to various Filecoin Storage Providers (SPs). You can clone and run your own copy of this archive. We strongly recommend doing this if you are an infrastructure provider, indexer, or heavy user. [](#an-rpc-server-supporting-multiple-sources-of-retrievals) An RPC server supporting multiple sources of retrievals ------------------------------------------------------------------------------------------------------------------------- Old Faithful has an RPC server that you can run that supports retrievals from an Old Faithful archive (like OF1) via gRPC and the standard Solana JSON-RPC methods for fetching block and transaction data. Retrievals can be made via IPFS, the Filecoin network, or even by hosting the CAR files yourself on disk, a CEPH cluster, S3 or alternative compatible object storage services, HTTP (CDN), etc. The only real requirement is that the retrieval source you provide either publishes a standard Unix filesystem API or supports an HTTP API with range requests support. [](#geyser-integration-and-rust-library) Geyser integration & Rust library ------------------------------------------------------------------------------- There is a Geyser integration that provides an easy way to perform ETL with already existing Solana Geyser plugins. You can run this on an epoch CAR file and receive Geyser notifications with blocks and transactions. [overview](https://web3.storage/docs/concepts/car/) [specs](https://ipld.io/specs/transport/car/carv1/) [schema](https://github.com/rpcpool/yellowstone-faithful/blob/main/ledger.ipldsch) [Read more about Generating Old Faithful archives.](/generating) [https://files.old-faithful.net](https://files.old-faithful.net) [Read more about hosting your own copy of Old Faithful archives.](/hosting) [Read more about running the RPC server.](/usage-and-installation/rpc-server) [Read more about using the Geyser integration.](/#geyser-integration-and-rust-library) --- # gRPC Methods | Old Faithful gRPC supports all the methods as the JSON-RPC endpoint plus two new streaming methods for txs and blocks, full list below: * getBlock * getTransaction * getSignaturesForAddress * getBlockTime * getGenesisHash (for epoch 0) * getFirstAvailableBlock * getSlot * getVersion * StreamTransactions * StreamBlocks grpcurl examples: Copy ```shellscript # download proto file wget -O old-faithful.proto https://raw.githubusercontent.com/rpcpool/yellowstone-faithful/refs/heads/main/old-faithful-proto/proto/old-faithful.proto # GetVersiono grpcurl \ -proto old-faithful.proto \ -H 'x-token: ' \ -d '' \ customer-endpoint-2608.mainnet.rpcpool.com:443 \ OldFaithful.OldFaithful/GetVersion # GetBlockTime grpcurl \ -proto old-faithful.proto \ -H 'x-token: ' \ -d '{"slot": 307152000}' \ customer-endpoint-2608.mainnet.rpcpool.com:443 \ OldFaithful.OldFaithful/GetBlockTime # Get Block grpcurl \ -proto old-faithful.proto \ -H 'x-token: ' \ -d '{"slot": 307152000}' \ customer-endpoint-2608.mainnet.rpcpool.com:443 \ OldFaithful.OldFaithful/GetBlock # GetTransaction grpcurl \ -proto old-faithful.proto \ -H 'x-token: ' \ -d '{"signature": "GbXoI+D7hhgeiUwovUhtaxog6zsxFcd5PKfhQM85GR6+NqmiFmQDf9cCCVj8BRj+DR1RvgR/E2E/ckbSGuQKCg=="}' \ customer-endpoint-2608.mainnet.rpcpool.com:443 \ OldFaithful.OldFaithful/GetTransaction # StreamBlocks grpcurl \ -proto old-faithful.proto \ -H 'x-token: ' \ -d '{"start_slot": 307152000, "end_slot": 307152010}' \ customer-endpoint-2608.mainnet.rpcpool.com:443 \ OldFaithful.OldFaithful/StreamBlocks # StreamBlocks with filters grpcurl \ -proto old-faithful.proto \ -H 'x-token: ' \ -d '{"start_slot": 307152000, "end_slot": 307152010, "filter": {"account_include": ["Vote111111111111111111111111111111111111111"]}}' \ customer-endpoint-2608.mainnet.rpcpool.com:443 \ OldFaithful.OldFaithful/StreamBlocks # StreamTransactions with filters grpcurl \ -proto old-faithful.proto \ -H 'x-token: ' \ -d '{"start_slot": 307152000, "end_slot": 307152010, "filter": {"vote": false, "failed": true}}' \ customer-endpoint-2608.mainnet.rpcpool.com:443 \ OldFaithful.OldFaithful/StreamTransactions ``` [PreviousRetrieving from Filecoin](/usage-and-installation/retrieving-from-filecoin) [NextRPC Methods](/usage-and-installation/rpc-methods) Last updated 4 days ago --- # Looking up CIDs | Old Faithful Support for these endpoints is currently in progress. You can look up CIDs for individual slots or transactions by using our hosted service: * Transaction signatures: **https://cid.old-faithful.net/api/v1/sig-to-cid/** * Blocks: **https://cid.old-faithful.net/api/v1/slot-to-cid/** Both will return the CID for the block or transaction if present or HTTP 404 if the TX or slot is unavailable. [PreviousUsage & Installation](/usage-and-installation) [NextRetrieving from Filecoin](/usage-and-installation/retrieving-from-filecoin) Last updated 1 month ago --- # RPC Methods | Old Faithful The JSON-RPC API follows the standard Solana RPC API and supports the following methods: * getBlock * getTransaction * getSignaturesForAddress * getBlockTime * getGenesisHash (for epoch 0) * getFirstAvailableBlock * getSlot * getVersion [PreviousgRPC Methods](/usage-and-installation/grpc-methods) [NextRPC server](/usage-and-installation/rpc-server) Last updated 5 days ago --- # Indexes | Old Faithful Indexes are needed to map Solana’s block numbers, transaction signatures, and addresses to their respective Content Identifiers. These indexes have been developed as part of this project. There are four content identifier indexes that the Old Faithful index generation can provide: * **slot-to-cid**: Lookup a CID based on a slot number * **tx-to-cid:** Lookup a CID based on a transaction signature * **cid-to-offset-and-size**: Index for a specific CAR file, used by the local RPC server (see above) to find CIDs in a car file * **sig-exists**: Index to check whether a specific signature exists in an epoch. In addition, Old Faithful supports an index `gsfa` that maps Solana addresses to a list of transaction signatures. This allows Old Faithful to support “Get Signatures For Address.” [PreviousContent Identifiers](/introduction/content-identifiers) [NextUsage & Installation](/usage-and-installation) Last updated 9 months ago --- # Content Identifiers | Old Faithful [PreviousIntroduction](/) [NextIndexes](/introduction/indexes) Last updated 9 months ago 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 . From : > 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. [here](https://docs.ipfs.tech/concepts/content-addressing/) [https://docs.ipfs.tech/concepts/content-addressing/#what-is-a-cid](https://docs.ipfs.tech/concepts/content-addressing/#what-is-a-cid) --- # RPC server | Old Faithful [PreviousRPC Methods](/usage-and-installation/rpc-methods) [NextLocal file system](/usage-and-installation/rpc-server/local-file-system) Last updated 5 days ago [](#overview) Overview --------------------------- Old Faithful ships with an RPC server that supports and . [](#command-line) Command line ----------------------------------- The RPC server is available via the `faithful-cli rpc` command. The command accepts a list of and dirs as arguments. Each config file is specific for an epoch and provides the location of the block/transaction data and the indexes for that epoch. The indexes are used to map Solana block numbers, transaction signatures, and addresses to their respective CIDs. The indexes are generated from the CAR file and can be generated via the `faithful-cli index` command (see ). It supports the following flags: * `--listen`: The address to listen on, e.g. `--listen=:8888` * `--include`: You can specify one or more (reuse the same flag multiple times) glob patterns to include files or dirs that match them, e.g. `--include=/path/epoch-*.yml`. * `--exclude`: You can specify one or more (reuse the same flag multiple times) glob patterns to exclude files or dirs that match them, e.g. `--exclude=/something-*/epoch-*.yml`. * `--debug`: Enable debug logging. * `--proxy`: Proxy requests to a downstream RPC server if the data can't be found in the archive, e.g. `--proxy=/path/to/my-rpc.json`. See for more details. * `--gsfa-only-signatures`: When enabled, the RPC server will only return signatures for getSignaturesForAddress requests instead of the full transaction data. * `--watch`: When specified, all the provided epoch files and dirs will be watched for changes, and the RPC server will automatically reload the data when changes are detected. Usage: `--watch` (boolean flag). This is useful when you want to provide just a folder and add new epochs to it without restarting the server. * `--epoch-load-concurrency=2`: Epochs to load in parallel when starting the RPC server. Defaults to the number of CPUs. This is useful when you have a lot of epochs and want to speed up the initial load time. * `--max-cache=`: Memory to use for caching. Defaults to 0 (no limit). This is useful when you want to limit the memory usage of the RPC server. NOTES: * By default, the RPC server doesn't support the `jsonParsed` format. You need to build the RPC server with the `make jsonParsed-linux` flag to enable this. [](#configuration-file-format) Configuration file format ------------------------------------------------------------- To configure the RPC server, you create a configuration file per Epoch of data you want the server to support. The RPC server allows you to specify a single file or a folder of config files if you want to support multiple. The RPC server can also be configured to watch this folder for newly added epochs, meaning you can put new ones online. The basics of the Epoch configuration file contains three fields: * `version`: current version is 1 * `epoch`: the epoch that this config file is for, an Old Faithful server can only host one config per epoch * `genesis`: (only used for epoch 0), provide a URI to a genesis file if you want to serve epoch 0. * `data`: retrieval configuration for the block/transaction data * `indexes`: retrieval configuration for the index data (each index header is a `uri` argument) * `slot_to_cid`: provide a local file system path or HTTP URI to the slot-to-cid index * `cid_to_offset_and_size`: provide a local file system path or HTTP URI to the cid-to-offset-and-size index * `sig_to_cid`: provide a local file system path or HTTP URI to the sig-to-cid index * `sig_exists`: provide a local file system path or HTTP URI to the sig exists index * `gsfa`: provide a local file system path to an unpacked gsfa index folder. If you want to use a remote URI, you need to start the faithful RPC with `--gsfa-only-signatures.` Sample config file[](#sample-config-file) Copy epoch: 0 # epoch number (required) version: 1 # version number (required) data: # data section (required) car: # Source the data from a CAR file (car-mode). # The URI can be a local filepath or an HTTP url. # This makes the indexes.cid_to_offset_and_size required. # If you are running in filecoin-mode, you can omit the car section entirely. uri: /media/runner/solana/cars/epoch-0.car filecoin: # filecoin-mode section: source the data directly from filecoin. # If you are running in car-mode, you can omit this section. # if enable=true, then the data will be sourced from filecoin. # if enable=false, then the data will be sourced from a CAR file (see 'car' section above). enable: false genesis: # genesis section (required for epoch 0 only) # Local filepath to the genesis tarball. # You can download the genesis tarball from # wget https://api.mainnet-beta.solana.com/genesis.tar.bz2 uri: /media/runner/solana/genesis.tar.bz2 indexes: # indexes section (required) cid_to_offset_and_size: # Required when using a CAR file; you can provide either a local filepath or a HTTP url. # Not used when running in filecoin-mode. uri: '/media/runner/solana/indexes/epoch-0/epoch-0-bafyreifljyxj55v6jycjf2y7tdibwwwqx75eqf5mn2thip2sswyc536zqq-mainnet-cid-to-offset-and-size.index' slot_to_cid: # required (always); you can provide either a local filepath or a HTTP url: uri: '/media/runner/solana/indexes/epoch-0/epoch-0-bafyreifljyxj55v6jycjf2y7tdibwwwqx75eqf5mn2thip2sswyc536zqq-mainnet-slot-to-cid.index' sig_to_cid: # required (always); you can provide either a local filepath or a HTTP url: uri: '/media/runner/solana/indexes/epoch-0/epoch-0-bafyreifljyxj55v6jycjf2y7tdibwwwqx75eqf5mn2thip2sswyc536zqq-mainnet-sig-to-cid.index' sig_exists: # required (always); you can provide either a local filepath or a HTTP url: uri: '/media/runner/solana/indexes/epoch-0/epoch-0-bafyreifljyxj55v6jycjf2y7tdibwwwqx75eqf5mn2thip2sswyc536zqq-mainnet-sig-exists.index' gsfa: # getSignaturesForAddress index # optional; must be a local directory path. uri: '/media/runner/solana/indexes/epoch-0/gsfa/epoch-0-bafyreifljyxj55v6jycjf2y7tdibwwwqx75eqf5mn2thip2sswyc536zqq-gsfa.indexdir' [](#data-retrieval-modes) Data retrieval modes --------------------------------------------------- The faithful RPC server supports four different data retrieval modes. You can opt for the one that fits your needs the best. [](#remote-vs.-local-indexes) Remote vs. local indexes ----------------------------------------------------------- Indexes can be utilized either over HTTP or via a local file system. Currently, we do not host the indexes on Filecoin, though this may change in the future. We highly recommend storing indexes locally on high-speed storage for the best performance. The GSFA index required to support getSignaturesForAddress can currently not be used remotely. If you want to rely on remote indexes, you can leave out the GSFA index or specify the GSFA index to return only the signatures and not the transaction body. In this mode, you can use a remote gSFA index. To enable this mode, run faithful-cli in the following way: Copy faithful-cli rpc -gsfa-only-signatures=true 455.yml [](#proxying) Proxying --------------------------- The RPC server provides a proxy mode that allows it to forward traffic it can't serve to a downstream RPC server. To configure this, provide the command line argument `--proxy=/path/to/faithful-proxy-config.json`pointing it to a config file. The config file should look like this: Copy { "target": "https://api.mainnet-beta.solana.com", "headers": { "My-Header": "My-Value" }, "proxyFailedRequests": true } The `proxyFailedRequests` flag will make the RPC server proxy not only RPC methods that it doesn't support but also retry requests that failed to be served from the archives (e.g. a `getBlock` request that failed to be served from the archives because that epoch is unavailable). [](#log-levels) Log Levels ------------------------------- You can set the desired log verbosity level by using the `-v` flag. The levels are from 0 to 5, where 0 is the least verbose and 5 is the most verbose. The default level is 2. Example: Copy faithful-cli -v=5 rpc 455.yml `car`: used for , and retrievals `filecoin`: used for retrievals [gRPC](/usage-and-installation/grpc-methods) [JSON-RPC](/usage-and-installation/rpc-methods) [epoch config files](https://github.com/rpcpool/yellowstone-faithful#epoch-configuration-files) [Index generation](https://github.com/rpcpool/yellowstone-faithful#index-generation) [RPC server proxying](https://github.com/rpcpool/yellowstone-faithful#rpc-server-proxying) [Filecoin v1,](/usage-and-installation/rpc-server/filecoin-v1-retrievals) [http](/usage-and-installation/rpc-server/http) [local file system](/usage-and-installation/rpc-server/local-file-system) [Filecoin v2](/usage-and-installation/rpc-server/filecoin-v2-retrievals) [Local file system](/usage-and-installation/rpc-server/local-file-system) [HTTP (useful for S3 and S3 likes)](/usage-and-installation/rpc-server/http) [Filecoin v1](/usage-and-installation/rpc-server/filecoin-v1-retrievals) [Filecoin v2 (in progress)](/usage-and-installation/rpc-server/filecoin-v2-retrievals) --- # Retrieving from Filecoin | Old Faithful [PreviousLooking up CIDs](/usage-and-installation/looking-up-cids) [NextgRPC Methods](/usage-and-installation/grpc-methods) Last updated 9 months ago Data can be fetched directly from Filecoin using CIDs and regular Filecoin tooling. To do so, you will need the CID of the Solana object to fetch—this may be found using the slot-to-cid or the tx-to-cid indexes; see . Once you have the CID, use to download the data. Lassie can be installed using the standard go toolchain: Copy $ go install github.com/filecoin-project/lassie/cmd/lassie@latest To fetch the data, simply Copy $ lassie fetch [-o ] [-t ] [/path/to/content] This will download the data as a CAR file. To extract the CAR file contents, use tool -- Copy $ go install github.com/ipld/go-car/cmd/car@latest $ car extract -f [Looking up CIDs](/usage-and-installation/looking-up-cids) [lassie](https://github.com/filecoin-project/lassie) [go-car](https://github.com/ipld/go-car) --- # Usage & Installation | Old Faithful [PreviousIndexes](/introduction/indexes) [NextLooking up CIDs](/usage-and-installation/looking-up-cids) Last updated 9 months ago Three software projects comprise Old Faithful: * , used for running the and for the RPC server * , used for processing * used for car files. You can also like . You only need the Faithful CLI if you are interested in working with the Faithful dataset and retrieving data. [](#building-and-installing-faithful) Building and installing Faithful --------------------------------------------------------------------------- Basic installation of faithful can be done by downloading the repository and building it (requires Golang >1.20): Copy $ git clone https://github.com/rpcpool/yellowstone-faithful.git $ make There are also binary builds for Linux available at . If you want jsonParsed support in the RPC server, you need to run: Copy $ make jsonParsed-linux [](#building-and-installing-radiance) Building and installing Radiance --------------------------------------------------------------------------- You will need to build Radiance with RocksDB support following the guide here: [Faithful](http://github.com/rpcpool/yellowstone-faithful) [RPC server](/usage-and-installation/rpc-server) [creating the necessary indexes](/generating/creating-indexes) [Radiance](http://github.com/rpcpool/radiance-triton-faithful/) [warehouse nodes’ ledger archives and producing CAR files](/generating) [PoH check car,](https://github.com/rpcpool/poh-check-car) [validating PoH of Old Faithful](/validation) [interact with Old Faithful through standard Filecoin tooling](/usage-and-installation/retrieving-from-filecoin) [Lassie](https://github.com/filecoin-project/lassie) [https://github.com/rpcpool/yellowstone-faithful/releases](https://github.com/rpcpool/yellowstone-faithful/releases) [https://github.com/rpcpool/radiance-triton-faithful/blob/main/INSTALL.md](https://github.com/rpcpool/radiance-triton-faithful/blob/main/INSTALL.md) --- # Geyser | Old Faithful [PreviousAccessing OF1 from old-faithful.net](/usage-and-installation/accessing-of1-from-old-faithful.net) [NextSoftware integrations](/usage-and-installation/software-integrations) Last updated 9 months ago The Old Faithful project provides a geyser runner to set up simple ETL pipelines using . This can help you integrate Solana history data into your existing data stores, backfill pipelines, and other tooling. The example code: [existing Geyser plugins](https://github.com/rpcpool/solana-geyser-park) [https://github.com/rpcpool/yellowstone-faithful/tree/main/geyser-plugin-runner](https://github.com/rpcpool/yellowstone-faithful/tree/main/geyser-plugin-runner) --- # Filecoin v2 retrievals | Old Faithful This form of retrieval is currently a work in progress. A new piece-based splitting format simplifies Filecoin retrievals. This allows for a much more convenient configuration of Filecoin retrievals and supports other Filecoin protocols like bit swap and graphsync. To configure Filecoin v2 retrievals, you specify a Subset CID (a Subset is a range of Slots in an Epoch). For the OF1 archive, we intend to publish Subset CIDs in an easy-to-retrieve place. You can also specify an optional list of storage\_providers from which you want to fetch the data. Copy version: 1 epoch: 100 data: filecoin: enable: true subset_cids: - bafyreibqt2nvroysxlxctgb52xxn27ectsllv2xyka4qar7ga6vupmbs3i - bafyreibqt212roysxlxctgb52xxn27ectsll2xsfk24qar7ga6vusdjn32 storage_providers: - f02366527 indexes: slot_to_cid: uri: /of1/100/epoch-100-bafyreibqt2nvroysxlxctgb52xxn27ectsllv2xyka4qar7ga6vupmbs3i-mainnet-slot-to-cid.index sig_to_cid: uri: /of1/100/epoch-100-bafyreibqt2nvroysxlxctgb52xxn27ectsllv2xyka4qar7ga6vupmbs3i-mainnet-sig-to-cid.index sig_exists: uri: /of1/100/epoch-100-bafyreibqt2nvroysxlxctgb52xxn27ectsllv2xyka4qar7ga6vupmbs3i-mainnet-sig-exists.index gsfa: uri: /of1/100/epoch-100-bafyreibqt2nvroysxlxctgb52xxn27ectsllv2xyka4qar7ga6vupmbs3i-mainnet-gsfa.indexdir [PreviousFilecoin v1 retrievals](/usage-and-installation/rpc-server/filecoin-v1-retrievals) [NextAccessing OF1 from old-faithful.net](/usage-and-installation/accessing-of1-from-old-faithful.net) Last updated 9 months ago --- # Filecoin v1 retrievals | Old Faithful V1 retrievals on Filecoin are done using HTTP range requests to Storage providers hosting the files. Currently, this requires that you provide multiple pieces of information: * A metadata.yml file that specifies the way that the full epoch car file was split into Filecoin pieces * A deals.csv file that maps the individual Filecoin pieces to storage providers A sample config file for an epoch using Filecoin v1 retrievals would look like this: Copy version: 1 epoch: 100 data: car: from_pieces: deals: uri: '/of1/100/deals.csv' metadata: uri: '/of1/100/metadata.yaml' indexes: cid_to_offset_and_size: uri: /of1/100/epoch-100-bafyreibqt2nvroysxlxctgb52xxn27ectsllv2xyka4qar7ga6vupmbs3i-mainnet-cid-to-offset-and-size.index slot_to_cid: uri: /of1/100/epoch-100-bafyreibqt2nvroysxlxctgb52xxn27ectsllv2xyka4qar7ga6vupmbs3i-mainnet-slot-to-cid.index sig_to_cid: uri: /of1/100/epoch-100-bafyreibqt2nvroysxlxctgb52xxn27ectsllv2xyka4qar7ga6vupmbs3i-mainnet-sig-to-cid.index sig_exists: uri: /of1/100/epoch-100-bafyreibqt2nvroysxlxctgb52xxn27ectsllv2xyka4qar7ga6vupmbs3i-mainnet-sig-exists.index gsfa: uri: /of1/100/epoch-100-bafyreibqt2nvroysxlxctgb52xxn27ectsllv2xyka4qar7ga6vupmbs3i-mainnet-gsfa.indexdir All indexes except gsfa can use either a local file system URL or an HTTP URL. [PreviousHTTP](/usage-and-installation/rpc-server/http) [NextFilecoin v2 retrievals](/usage-and-installation/rpc-server/filecoin-v2-retrievals) Last updated 9 months ago --- # Accessing OF1 from old-faithful.net | Old Faithful [PreviousFilecoin v2 retrievals](/usage-and-installation/rpc-server/filecoin-v2-retrievals) [NextGeyser](/usage-and-installation/geyser) Last updated 9 months ago hosts a copy of the OF1 genesis archive with HTTP endpoints. This allows you to test and develop against the OF1 archive quickly. For infrastructure providers and other heavy users, we recommend looking at the documentation's "Hosting" or "Generating" sections to understand how you can build your own archive or create a duplicate to host in your infra. [](#car-files) Car files ----------------------------- Car files are available under the URL: Copy https://files.old-faithful.net//epoch-.car [](#metadata-files) Metadata files --------------------------------------- From the same epoch directory URL (`https://files.old-faithful.net/`), you can retrieve: * `metadata.yml`: metadata files for the split car files * `epoch-.cid`: epoch root CID [](#indexes) Indexes ------------------------- [Triton One](https://triton.one) --- # Local file system | Old Faithful [PreviousRPC server](/usage-and-installation/rpc-server) [NextHTTP](/usage-and-installation/rpc-server/http) Last updated 9 months ago Local file system mode is the simplest mode of retrieval. This can also be the fastest. In this mode, you host the CAR files locally as files on a file system. You can also host the indexes locally for best performance or mix with some indexes locally and some remotely. Copy version: 1 epoch: 100 data: car: uri: /of1/100/epoch-100.car indexes: cid_to_offset_and_size: uri: /of1/100/epoch-100-bafyreibqt2nvroysxlxctgb52xxn27ectsllv2xyka4qar7ga6vupmbs3i-mainnet-cid-to-offset-and-size.index slot_to_cid: uri: /of1/100/epoch-100-bafyreibqt2nvroysxlxctgb52xxn27ectsllv2xyka4qar7ga6vupmbs3i-mainnet-slot-to-cid.index sig_to_cid: uri: /of1/100/epoch-100-bafyreibqt2nvroysxlxctgb52xxn27ectsllv2xyka4qar7ga6vupmbs3i-mainnet-sig-to-cid.index sig_exists: uri: /of1/100/epoch-100-bafyreibqt2nvroysxlxctgb52xxn27ectsllv2xyka4qar7ga6vupmbs3i-mainnet-sig-exists.index Be aware that a full local clone of the OF1 genesis archive runs in multiple 100s of TB. ### [](#split-retrievals) Split retrievals If your file system or network file system store does not like serving large files, you can configure split retrievals for the local file system in the same way they work for . [HTTP retrievals](/usage-and-installation/rpc-server/http#split-retrievals-advanced) --- # Generating | Old Faithful [PreviousSoftware integrations](/usage-and-installation/software-integrations) [NextHistorical blocks](/generating/historical-blocks) Last updated 9 months ago The primary data preparation tooling used in this project is based on the `radiance` tool developed by Jump's Firedancer team. Radiance provides the relevant code for working with the Solana ledger archives in Rocksdb format. For the Old Faithful project, Radiance was forked, and a full CAR generation command was introduced: The radiance tool utilizes the RocksDB snapshots generated by nodes. From these snapshots, a CAR file per epoch is generated. This CAR file then needs to be processed by Filecoin tools such as which generates the details needed for making a Filecoin deal. Currently, this tool is being tested from the following warehouse archives: * Solana Foundation (public) * Triton One (private) If you have warehouse nodes generating RocksDB archive snapshots, please get in touch with lk@triton.one (even if they can't be publicly available). We would like to have you generate CAR files for verification purposes. [Warehouse](https://github.com/solana-labs/solana-bigtable) [split-and-commp](https://github.com/rpcpool/go-fil-dataprep/) [![Logo](https://github.com/fluidicon.png)GitHub - rpcpool/radiance-triton-faithfulGitHub](https://github.com/rpcpool/radiance-triton-faithful/tree/main) --- # Creating indexes | Old Faithful Once the radiance tooling has been used to prepare a car file (or if you have downloaded a car file externally), you can generate indexes from this car file by using the `faithful-cli`: Copy NAME: faithful CLI index - Create various kinds of indexes for CAR files. USAGE: faithful CLI index command [command options] [arguments...] DESCRIPTION: Create various kinds of indexes for CAR files. COMMANDS: cid-to-offset slot-to-cid sig-to-cid all Create all the necessary indexes for a Solana epoch. gsfa sig-exists help, h Shows a list of commands or help for one command OPTIONS: --help, -h show help ### [](#examples) Examples * `faithful-cli index all `: Generate all **required** indexes for a CAR file. * `faithful-cli index gsfa `: Generate the gsfa index for a CAR file. NOTES: * You need to have the CAR file available locally. * The `cid_to_offset_and_size` index has an older version, which you can specify with `cid_to_offset`instead of `cid_to_offset_and_size`. ### [](#flags) Flags: * `--tmp-dir=/path/to/tmp/dir`: Where to store temporary files. Defaults to the system temp dir. (optional) * `--verify`: Verify the indexes after generation. (optional) * `--network=`: Network to use for the gsfa index. Defaults to `mainnet` (other options: `testnet`, `devnet`). (optional) [PreviousWarehouse nodes](/generating/warehouse-nodes) [NextHosting](/hosting) Last updated 9 months ago --- # HTTP | Old Faithful [PreviousLocal file system](/usage-and-installation/rpc-server/local-file-system) [NextFilecoin v1 retrievals](/usage-and-installation/rpc-server/filecoin-v1-retrievals) Last updated 9 months ago To use HTTP retrievals, you only need to point your config file to an HTTP endpoint that hosts the epoch-NNN.car file, which supports HTTP range requests. Copy version: 1 epoch: 100 data: car: uri: https://files.old-faithful.net/100/epoch-100.car indexes: cid_to_offset_and_size: uri: https://files.old-faithful.net/100/epoch-100-bafyreibqt2nvroysxlxctgb52xxn27ectsllv2xyka4qar7ga6vupmbs3i-mainnet-cid-to-offset-and-size.index slot_to_cid: uri: https://files.old-faithful.net/100/epoch-100-bafyreibqt2nvroysxlxctgb52xxn27ectsllv2xyka4qar7ga6vupmbs3i-mainnet-slot-to-cid.index sig_to_cid: uri: https://files.old-faithful.net/100/epoch-100-bafyreibqt2nvroysxlxctgb52xxn27ectsllv2xyka4qar7ga6vupmbs3i-mainnet-sig-to-cid.index sig_exists: uri: https://files.old-faithful.net/100/epoch-100-bafyreibqt2nvroysxlxctgb52xxn27ectsllv2xyka4qar7ga6vupmbs3i-mainnet-sig-exists.index ### [](#split-retrievals-advanced) Split retrievals (advanced) If your remote storage solution cannot handle large monolithic files like the 600 GiB files we produce, you can also use split retrievals in HTTP mode, similar to how they work in Filecoin v1 retrievals. You can use to split the files in any size you want. This tool will also generate metadata.yaml. After you have generated metadata.yaml and the split, you need to create a map from this tool's “piece CIDs” and the URI of the specific pieces. A sample config file for this use case would look like this (NOTE: this is just a sample; we currently do not host split retrievals on https://files.old-faithful.net): Copy version: 1 epoch: 100 data: car: from_pieces: metadata: uri: https://files.old-faithful.net/100/metadata.yaml piece_to_uri: baga6ea4seaqiogvxkc4cjgbimal52zgaqwo5ugcvy2bc72nrerro3wtzy47jepi: uri: https://files.old-faithful.net/100/baga6ea4seaqiogvxkc4cjgbimal52zgaqwo5ugcvy2bc72nrerro3wtzy47jepi.car baga6ea4seaqowdba7qkhqxw3umullabn7mx377we7vu3klguccuderfqclzpsiy: uri: https://files.old-faithful.net/100/baga6ea4seaqowdba7qkhqxw3umullabn7mx377we7vu3klguccuderfqclzpsiy.car baga6ea4seaqhky3ydiwp5toduhxpzt7oxm5cctuvrjbmkq5gzf3s6arayindoii: uri: https://files.old-faithful.net/100/baga6ea4seaqhky3ydiwp5toduhxpzt7oxm5cctuvrjbmkq5gzf3s6arayindoii.car indexes: cid_to_offset_and_size: uri: https://files.old-faithful.net/100/epoch-100-bafyreibqt2nvroysxlxctgb52xxn27ectsllv2xyka4qar7ga6vupmbs3i-mainnet-cid-to-offset-and-size.index slot_to_cid: uri: https://files.old-faithful.net/100/epoch-100-bafyreibqt2nvroysxlxctgb52xxn27ectsllv2xyka4qar7ga6vupmbs3i-mainnet-slot-to-cid.index sig_to_cid: uri: https://files.old-faithful.net/100/epoch-100-bafyreibqt2nvroysxlxctgb52xxn27ectsllv2xyka4qar7ga6vupmbs3i-mainnet-sig-to-cid.index sig_exists: uri: https://files.old-faithful.net/100/epoch-100-bafyreibqt2nvroysxlxctgb52xxn27ectsllv2xyka4qar7ga6vupmbs3i-mainnet-sig-exists.index [go-fil-dataprep](https://github.com/rpcpool/go-fil-dataprep) --- # Software integrations | Old Faithful [PreviousGeyser](/usage-and-installation/geyser) [NextGenerating](/generating) Last updated 9 months ago Integrating with the Old Faithful dataset should be relatively easy, considering that there are CAR file format readers in many languages: * JS: * Golang: * Rust: The schema for the CAR files is available here: [https://github.com/ipld/js-car](https://github.com/ipld/js-car) [https://github.com/ipld/go-car](https://github.com/ipld/go-car) [https://github.com/rpcpool/yellowstone-faithful/tree/main/geyser-plugin-runner](https://github.com/rpcpool/yellowstone-faithful/tree/main/geyser-plugin-runner) [https://github.com/rpcpool/yellowstone-faithful/blob/main/ledger.ipldsch](https://github.com/rpcpool/yellowstone-faithful/blob/main/ledger.ipldsch) --- # Hosting | Old Faithful [PreviousCreating indexes](/generating/creating-indexes) [NextMaking a local copy](/hosting/making-a-local-copy) Last updated 9 months ago Hosting your own local version of the archive is ideal for large-scale users such as infrastructure providers, explorers, or those wishing to access the archives with the highest possible throughput and lowest possible latency. There are two parts to hosting the data: * Hosting the indexes * Hosting the CAR files We recommend that you host the indexes on high-speed local or network storage. The critical element for high performance is that the indexes can be accessed with low latency. The CAR files themselves can be stored on somewhat higher-latency storage. To get started on hosting your own archive, you have a few different options: * Run warehouse nodes to * If you want a full or partial historical archive, you can: Indexes can more easily be generated locally but can also be cloned. [generate new car files continuously from Solana ledger copies](/generating/warehouse-nodes) [Generate your own archive from historical ledger copies](/generating/historical-blocks) [Clone OF1 from Triton One or Filecoin storage providers](/hosting/making-a-local-copy) --- # Warehouse nodes | Old Faithful [PreviousHistorical blocks](/generating/historical-blocks) [NextCreating indexes](/generating/creating-indexes) Last updated 9 months ago To generate the Old Faithful archives on an ongoing basis, we recommend that you run a Warehouse node. A warehouse node is just a Solana node set up with some start-up/stop scripts that generate archives per epoch. Warehouse nodes have been used to create the ledger copies that Old Faithful bases itself on. They have also been used to keep the older BigTable archives current. There are some examples and details about running a warehouse node here: With Old Faithful you use the rocksdb ledger copies generated by the warehouse nodes to generate the archives in content addressable format (CAR). [![Logo](https://github.com/fluidicon.png)GitHub - solana-labs/solana-bigtableGitHub](https://github.com/solana-labs/solana-bigtable) --- # Filecoin | Old Faithful [PreviousMaking a local copy](/hosting/making-a-local-copy) [NextValidation](/validation) Last updated 9 months ago You can publish Old Faithful-based archives with a Filecoin storage provider. This would allow you to use the Filecoin retrieval modes with your preferred provider. [](#for-warehouse-operators) For warehouse operators --------------------------------------------------------- ### [](#flow-v1) Flow v1 The basic flow of uploading Old Faithful data to Filecoin involves: 1. the CAR file for the epoch (or ) 2. Splitting the car file into suitable sized chunks for ingest into filecoin (32 GiB), saving the metadata.yaml produced as part of the process (will be needed for ). 3. Using boost to create deals for the split files, creating a deals.csv file in the process (see format below). 4. Once the deals are ingested, you can use the . #### [](#deals.csv-file-format) Deals.csv file format The deals.csv file format should contain the following headers as the first line (and then the corresponding values under each value): * provider * deal\_uuid * file\_name * URL * commp\_piece\_cid * file\_size * padded\_size * payload\_cid Sample deals.csv[](#sample-deals.csv) Copy provider,deal_uuid,file_name,url,commp_piece_cid,file_size,padded_size,payload_cid f02366527,db161970-b4ab-4a05-bae4-b0e559a48806,sp-epoch-100-baga6ea4seaqiogvxkc4cjgbimal52zgaqwo5ugcvy2bc72nrerro3wtzy47jepi.car,https://filecoin-car-storage-cdn.b-cdn.net/100/sp-epoch-100-baga6ea4seaqiogvxkc4cjgbimal52zgaqwo5ugcvy2bc72nrerro3wtzy47jepi.car,baga6ea4seaqiogvxkc4cjgbimal52zgaqwo5ugcvy2bc72nrerro3wtzy47jepi,30000000796,34359738368,bafyreibqt2nvroysxlxctgb52xxn27ectsllv2xyka4qar7ga6vupmbs3i f02366527,cd27c9bd-4d26-4deb-9579-6821e42bdbdd,sp-epoch-100-baga6ea4seaqowdba7qkhqxw3umullabn7mx377we7vu3klguccuderfqclzpsiy.car,https://filecoin-car-storage-cdn.b-cdn.net/100/sp-epoch-100-baga6ea4seaqowdba7qkhqxw3umullabn7mx377we7vu3klguccuderfqclzpsiy.car,baga6ea4seaqowdba7qkhqxw3umullabn7mx377we7vu3klguccuderfqclzpsiy,30000000081,34359738368,bafyreibqt2nvroysxlxctgb52xxn27ectsllv2xyka4qar7ga6vupmbs3i f02366527,c9237f39-0cfc-48ba-a4b8-7163f4543305,sp-epoch-100-baga6ea4seaqhky3ydiwp5toduhxpzt7oxm5cctuvrjbmkq5gzf3s6arayindoii.car,https://filecoin-car-storage-cdn.b-cdn.net/100/sp-epoch-100-baga6ea4seaqhky3ydiwp5toduhxpzt7oxm5cctuvrjbmkq5gzf3s6arayindoii.car,baga6ea4seaqhky3ydiwp5toduhxpzt7oxm5cctuvrjbmkq5gzf3s6arayindoii,2937660613,4294967296,bafyreibqt2nvroysxlxctgb52xxn27ectsllv2xyka4qar7ga6vupmbs3i f02366527,473a2c70-8f0f-498b-b539-d3f0e50a4579,sp-epoch-100-baga6ea4seaqiogvxkc4cjgbimal52zgaqwo5ugcvy2bc72nrerro3wtzy47jepi.car,https://filecoin-car-storage-cdn.b-cdn.net/100/sp-epoch-100-baga6ea4seaqiogvxkc4cjgbimal52zgaqwo5ugcvy2bc72nrerro3wtzy47jepi.car,baga6ea4seaqiogvxkc4cjgbimal52zgaqwo5ugcvy2bc72nrerro3wtzy47jepi,30000000796,34359738368,bafyreibqt2nvroysxlxctgb52xxn27ectsllv2xyka4qar7ga6vupmbs3i f02366527,6b0a5754-371c-4cd9-8553-c26dc37a0763,sp-epoch-100-baga6ea4seaqowdba7qkhqxw3umullabn7mx377we7vu3klguccuderfqclzpsiy.car,https://filecoin-car-storage-cdn.b-cdn.net/100/sp-epoch-100-baga6ea4seaqowdba7qkhqxw3umullabn7mx377we7vu3klguccuderfqclzpsiy.car,baga6ea4seaqowdba7qkhqxw3umullabn7mx377we7vu3klguccuderfqclzpsiy,30000000081,34359738368,bafyreibqt2nvroysxlxctgb52xxn27ectsllv2xyka4qar7ga6vupmbs3i f02366527,63e14784-ac0b-44a9-8e3b-0395b654a519,sp-epoch-100-baga6ea4seaqhky3ydiwp5toduhxpzt7oxm5cctuvrjbmkq5gzf3s6arayindoii.car,https://filecoin-car-storage-cdn.b-cdn.net/100/sp-epoch-100-baga6ea4seaqhky3ydiwp5toduhxpzt7oxm5cctuvrjbmkq5gzf3s6arayindoii.car,baga6ea4seaqhky3ydiwp5toduhxpzt7oxm5cctuvrjbmkq5gzf3s6arayindoii,2937660613,4294967296,bafyreibqt2nvroysxlxctgb52xxn27ectsllv2xyka4qar7ga6vupmbs3i ### [](#flow-v2) Flow v2 [](#for-storage-providers) For storage providers ----------------------------------------------------- If you are a Filecoin storage provider, you can participate in the Old Faithful project by partnering with a Solana warehouse node operator that generates CAR file deals. Flow v2 for generating CAR files will be necessary to support . It is still in progress and involves the use of a new split tool. [Generating](/generating) [cloning it](/hosting/making-a-local-copy) [retrievals](/usage-and-installation/rpc-server/filecoin-v1-retrievals) [Filecoin v1 version of retrievals](/usage-and-installation/rpc-server/filecoin-v1-retrievals) [Filecoin v2 retrievals](/usage-and-installation/rpc-server/filecoin-v2-retrievals) --- # Making a local copy | Old Faithful [PreviousHosting](/hosting) [NextFilecoin](/hosting/filecoin) Last updated 9 months ago To host the archives locally, you need to arrange to pull a cold copy from one of the Filecoin providers or a special cold copy provided through old-faithful.net. The archives require about 250 TiB for the actual archive data and approximately 50 TiB for the indexes. We recommend storing the indexes in an NVME store. You can also . Generating the actual historical archives is quite an undertaking, however generating the indexes if you have a cloned local copy of the CAR files is fairly easy. See these . [generate the archives and indexes yourself](/generating) [docs about how to generate the indexes](/generating/creating-indexes) --- # Validation | Old Faithful [PreviousFilecoin](/hosting/filecoin) [NextReproducibility](/validation/reproducibility) Last updated 9 months ago [](#blockhashes-and-parent-child-relationships) Blockhashes and parent/child relationships ----------------------------------------------------------------------------------------------- During the generation of the CAR files, Old Faithful validates that each block generated has the correct links with the parent/child. This includes validating that each epoch's last block/first block links correctly with the slots in the following epochs. This ensures that there is a complete set of blocks from block 0 to the current block. [](#proof-of-history) Proof of History ------------------------------------------- Old Faithful supports full validation of Proof of History. In OF1, every epoch’s PoH has been validated with one exception (see ). Outputs from our validation of the history can be found at https://files.old-faithful.net//poh-check-.log. For example, : Copy I1109 13:00:28.125613 217304 main.go:130] Roots: 1 I1109 13:00:28.125641 217304 main.go:133] - bafyreibqt2nvroysxlxctgb52xxn27ectsllv2xyka4qar7ga6vupmbs3i (Epoch CID) PrevBlockHash: 47PrqQ4MJrT4G2GB7uHk5CdZadTKspB5HgDszzxHPJc2 EOF I1109 13:15:10.275042 217304 main.go:345] Waiting for all nodes to be parsed... I1109 13:15:10.275046 217304 main.go:347] All nodes parsed. I1109 13:15:10.275049 217304 main.go:349] Waiting to receive all results... I1109 13:15:10.292252 217304 main.go:352] All results received I1109 13:15:10.292261 217304 main.go:354] Waiting for all assertions to finish... I1109 13:15:10.292840 217304 main.go:356] All assertions finished I1109 13:15:10.292847 217304 main.go:359] Last block hash for slot 43631999: FUPcPKdnNUWRrwyDqpyAdMqX7XH6rvGM7eEHYYN2KX6M I1109 13:15:10.292855 217304 main.go:360] Number of checked entries: 110,592,602 I1109 13:15:10.292858 217304 main.go:361] Number of hashes: 345,600,000,000 I1109 13:15:10.292861 217304 main.go:363] Successfully checked PoH on CAR file I1109 13:15:10.292862 217304 main.go:143] Finished in 14m42.167217686s I1109 13:15:10.292864 217304 main.go:144] Read 196980689 nodes from CAR file I1109 13:15:10.292870 217304 main.go:59] CAR file checked successfully I1109 13:15:10.292872 217304 main.go:53] Took 14m42.170098595s Copy $ poh-check-car \ --workers=12 \ --auto \ --epoch=0 \ --car=/media/laptop/solana-history/cars/epoch-0.car To run this check yourself, you use the poh-check-car tool from . Sample usage of this tool: [Epoch 208](/validation/epoch-208) [https://files.old-faithful.net/100/poh-check-100.log](https://files.old-faithful.net/100/poh-check-100.log) [https://github.com/rpcpool/poh-check-car](https://github.com/rpcpool/poh-check-car) --- # Historical blocks | Old Faithful You need to source RocksDB ledger copies from those epochs to gather the raw data for historical blocks. These are available from the following sources: * Solana Foundation (public, Google Storage) * gs://mainnet-beta-ledger-us-ny5 * gs://mainnet-beta-ledger-europe-fr2 * gs://mainnet-beta-ledger-asia-sg1 * Triton One (private) * For access, contact Triton One. Once you have downloaded the RocksDB ledger archives, you can run the Radiance tool to generate a car file for an epoch. Ensure you have all the slots available in the RocksDB ledger archive for the epoch. You may need to download multiple ledger snapshots to have a full set of slots available. Once you know you have a RocksDB dataset that covers all the slots for the epoch, run the radiance tool like follows: Copy radiance car create2 107 --db=46223992/rocksdb --out=/storage/car/epoch-107.car This will produce a car file called epoch-107.car containing all the blocks and transactions for that epoch. To specify multiple ledger snapshots, you can provide the db command line parameter multiple times `--db=12312/rocksdb --db=52321/rocksdb`. The radiance tooling will automatically stitch the RocksDB ledger archives together to form a full epoch car file. [](#check-mode) Check mode ------------------------------- You can check if your current ledger has the slots you require to generate the epoch-107.car by adding the following flag: Copy --check This will ensure that the radiance car create2 command will walk through and check that it has all the slots. [](#shred-revisions-epoch-less-than-32) Shred revisions (epoch <= 32) -------------------------------------------------------------------------- The shred format changed around epoch 32. Add the following flag for epochs up to 32 Copy --shred-revision=1 When generating epoch 32 itself, you need to provide the following flags: Copy --shred-revision=1 --next-shred-revision-activation-slot=10367766 Note: Depending on what snapshots you use to generate this CAR file, this shred revision transition may occur on epoch 22. [](#epoch-208) Epoch 208 ----------------------------- While generating the OF1 archive, Triton One could not find a ledger file covering approximately 495 slots during Epoch 208. Since the ledger data was missing, Triton worked with Anza Labs to recreate a ledger for these 495 slots to build an Old Faithful CAR file for this epoch. The gap exists between slots 89856108 and 89856602 (inclusive). For generating Epoch 208, you should, therefore, add this ledger copy as a CLI argument to radiance: Copy --db epoch-208-rocksdb/ [PreviousGenerating](/generating) [NextWarehouse nodes](/generating/warehouse-nodes) Last updated 9 months ago For more information about generating your own version of this ledger and validating that it is correct, see the page under Validation. [Epoch 208](/generating/historical-blocks#epoch-208) --- # Epoch 208 | Old Faithful [PreviousReproducibility](/validation/reproducibility) Last updated 9 months ago Since the ledger data , we do not have PoH data for these slots. This means that the that was conducted on the other slots could not be completed. Triton One worked with engineers from Anza Labs to solve this issue, which involves sourcing transaction and block data from Google BigTable and validating it through replay. Replaying such old blocks is difficult, but Anza Labs has created a special version of `solana-ledger-tool` to support this replay. [](#basic-theory) Basic Theory ----------------------------------- The basic theory of this validation is: 1. We have an account state snapshot, including a slot immediately before the gap, and another account state snapshot, which includes a slot immediately after the gap. 2. These account snapshots are based on two slots for which we have valid PoH information. 3. We have validated the PoH hashes for the two slots (before and after the gap) on which the account state snapshots are based. 4. We then replay the transactions sourced from Bigtable and validate that the bank hashes produced at each slot are valid. 5. After replay, we can produce an account state snapshot. This snapshot must match the one available after the Epoch 208 ledger gap. Going through this process, we can produce a new valid ledger for these 495 slots to generate the bank hashes. [](#availability-of-bank-hashes) Availability of Bank Hashes ----------------------------------------------------------------- While the data to recompute POH is lost, we still have the bank hashes available, as these are included in the votes submitted by the validators. Bank hashes (see ) contain: * Previous block hash * A hash of the delta of all accounts during the slot * The number of signatures in the block * The last blockhash of the block (i.e., the one referred to as the block’s ”blockhash”). As part of the replay of epoch 208, the bank hashes are recomputed and can be compared with those inside the votes submitted by the validators. We can also compute the stake weight of the votes based on the data available in BigTable. Since votes are signed by the validators, they cannot be forged. This means that during replay, you can reproduce the bank hashes. [](#performing-your-own-validation-of-epoch-208) Performing your own validation of Epoch 208 ------------------------------------------------------------------------------------------------- Currently, Triton One and Anza Labs have validated Epoch 208. We encourage other parties to run their own validation. The tooling is basic but should enable you to re-run the validation completely. You will need access to the required slots of a Google Bigtable archive (or other archive). ### [](#pre-requisites) Pre-requisites #### [](#hardware-specs) Hardware specs To verify, you need at least the following hardware specs: * 40 GiB available RAM (total system memory recommended at least 64 GiB) * 2 TiB available disk space (ideally NVME) * OS: Ubuntu 22.04.2 LTS Copy # print used memory, should have at lest 40 GiB available free -h # print available disk space,m should have at least 2TiB available df -h # print ubuntu version; must be 22.04 LTS lsb_release -a # print current version; must be at least GLIBC_2.32; GLIBC 2.35 is good ldd --version #### [](#bigtable-access-or-other-ledger-store) Bigtable access (or other ledger store) You need read-only credentials for a Google Bigtable copy of the Solana history or an equivalent source. If you want to reproduce it but do not have access to your own Bigtable, you can contact Anza Labs or Triton One to request access. #### [](#ledger-and-account-snapshots) Ledger and account snapshots Copy Ledger has data for 424323 slots 89423444 to 89856107 Copy Ledger has data for 424529 slots 89856602 to 90288016 This means that if you want to use the existing snapshots for validation, you need to replay between at least slot 89855469 and 89865552 (10083 slots). ### [](#building-solana-ledger-tool) Building solana-ledger-tool A special version of the `solana-ledger-tool` has been prepared, which has a patch to allow running the verification and skipping PoH verification (since PoH data is missing). Copy git clone git@github.com:solana-labs/solana-ledger-gap.git cd solana-ledger-gap git checkout origin/steviez_v1.7.9 # install dependencies sudo apt-get install \ build-essential \ pkg-config \ libudev-dev llvm libclang-dev \ protobuf-compiler \ libssl-dev \ apt-file # install rust (if not already installed) curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh source $HOME/.cargo/env . "$HOME/.cargo/env" cd ledger-tool nano Cargo.toml # add the following lines to [dependencies] ``` openssl-sys = "0.9.58" openssl = "0.10.30" ``` # install rust nightly 1.57.0 rustup install nightly-2021-12-06 rustup toolchain install nightly-2021-12-06 # build solana-ledger-tool cargo +nightly-2021-12-06 build --release # the final binary is located at ./target/release/solana-ledger-tool ./solana-ledger-gap/target/release/solana-ledger-tool # copy the binary to a location that is in the PATH (e.g. /usr/local/bin) cp ./target/release/solana-ledger-tool /usr/local/bin/solana-ledger-tool ### [](#running-verification) Running verification Running the verification will take some time. We recommend using a `tmux` session with an unlimited scrollback buffer to run the verification. Copy # create a working directory export WORKING_DIR_E208=/solana/e208 mkdir $WORKING_DIR_E208 mkdir $WORKING_DIR_E208/ledger cd $WORKING_DIR_E208 # download the pre-gap snapshots apt install -y aria2 pv bzip2 lbzip2 zstd aria2c -x 16 -s 16 -d $WORKING_DIR_E208/ledger https://storage.googleapis.com/mainnet-beta-ledger-us-ny5/89423444/rocksdb.tar.bz2 aria2c -x 16 -s 16 -d $WORKING_DIR_E208/ledger https://storage.googleapis.com/mainnet-beta-ledger-us-ny5/89855469/snapshot-89855469-9i59TwLmzXvbomizFZNuXgPygtx8zJ3P4nWDQuNxrTxK.tar.zst # get genesis file cd $WORKING_DIR_E208/ledger wget https://api.mainnet-beta.solana.com/genesis.tar.bz2 tar -xvf genesis.tar.bz2 -C $WORKING_DIR_E208/ledger/ # extract rocksdb (will take ~10 minutes; 2 hours if using networked storage) cd $WORKING_DIR_E208/ledger pv rocksdb.tar.bz2 | tar -x -I lbzip2 -C ./ # Step 0: Create a snapshot immediately before the gap # This will take ~10 minutes alias solana-ledger-tool="$WORKING_DIR_E208/solana-ledger-tool" sudo sysctl -w vm.max_map_count=1400000 sudo sysctl --system cd $WORKING_DIR_E208/ledger solana-ledger-tool create-snapshot --ledger ./ 89856107 ./ # Step I: Recreate shreds for the missing blocks (you will need bigtable credentials) # You need a service account key for bigtable in JSON format (to the Solana Foundation's bigtable) # It will be used to fetch the missing blocks. export GOOGLE_APPLICATION_CREDENTIALS=/solana/e208/bigtable.json solana-ledger-tool bigtable reconstruct-replayable-blocks --ledger ./ --store-transaction-status --starting-slot 89856107 --ending-slot 89856602 --snapshot-archive-path=$WORKING_DIR_E208/ledger/snapshot-89856107-2Uvbz6becuTbDVLdoUXfYN81wcwR5AxVGLJFbkG5Vy2w.tar.zst # verify bounds # should be: slots 89423444 to 89856602 solana-ledger-tool bounds --ledger $WORKING_DIR_E208/ledger # create a snapshot after the gap RUST_LOG=solana=info,solana_ledger::blockstore_processor=trace solana-ledger-tool create-snapshot --skip-poh-verify --ledger $WORKING_DIR_E208/ledger 89856602 $WORKING_DIR_E208/ledger/89856602/ # this will generate /solana/e208/ledger/89856602/snapshot-89856602-HZTS2FDwEFJFq3XiX6wHrS2297nsfbfRU69bqFkJDXZk.tar.zst # Now, we need to take that and use it --- # get Full State After the Gap mkdir $WORKING_DIR_E208/ledger-after-gap cd $WORKING_DIR_E208/ledger-after-gap aria2c -x 16 -s 16 -d $WORKING_DIR_E208/ledger-after-gap https://storage.googleapis.com/mainnet-beta-ledger-us-ny5/89855469/rocksdb.tar.bz2 aria2c -x 16 -s 16 -d $WORKING_DIR_E208/ledger-after-gap https://storage.googleapis.com/mainnet-beta-ledger-us-ny5/89855469/hourly/snapshot-89865552-CWFaiDterTZ1EFQrJkFghnnzERFJNNFT2USBnYTssxsF.tar.zst pv rocksdb.tar.bz2 | tar -x -I lbzip2 -C ./ # copy genesis file cp $WORKING_DIR_E208/ledger/genesis.bin $WORKING_DIR_E208/ledger-after-gap/genesis.bin # verify bounds: should be `Ledger has data for 424529 slots 89856602 to 90288016` solana-ledger-tool bounds --ledger $WORKING_DIR_E208/ledger-after-gap # Now we can use the snapshot at 89856602 and the ledger-after-gap to create a new snapshot at 89865552, # which should have the same hash as the downloaded snapshot-89865552-CWFaiDterTZ1EFQrJkFghnnzERFJNNFT2USBnYTssxsF.tar.zst solana-ledger-tool create-snapshot \ --skip-poh-verify \ --ledger $WORKING_DIR_E208/ledger-after-gap \ --snapshot-archive-path $WORKING_DIR_E208/ledger/89856602/ \ 89865552 $WORKING_DIR_E208/ledger-after-gap/89865552/ After running this process, the `$WORKING_DIR_E208/ledger-after-gap/89865552/` should have a file with the same filename as `snapshot-89865552-CWFaiDterTZ1EFQrJkFghnnzERFJNNFT2USBnYTssxsF.tar.zst`We can verify the filename hash to confirm that the snapshots are identical. We can also extract and validate that the two account states match identically (i.e., have the exact same accounts and account data). The two archive files, however, are slightly different in size since the process isn’t precisely reproducible regarding the specific compressed file. If used on the two snapshot-\*.tar.zst files, SHA256SUM will return two different hashes. However, if compared, the contents (account states) are the same. You need to download the account snapshots that you can use to compare against. The pre-account snapshot is hosted by Anza and is available in a Google Cloud storage bucket called mainnet-beta-ledger-us-ny5. This was produced by warehouse nodes running at the time. This snapshot is from a ledger that has been . The RocksDB snapshot at runs up to slot 89856107. Ledger tool reports: The latest account state snapshot before the missing slots is at slot 8985546. ). After the gap, the ledger snapshot at starts at 89856602. Ledger tool reports: The account state snapshot after the gap that we have available is at 89865552 [validated in the normal Old Faithful process](/validation) [https://storage.googleapis.com/mainnet-beta-ledger-us-ny5/89423444/rocksdb.tar.bz2](https://storage.googleapis.com/mainnet-beta-ledger-us-ny5/89423444/rocksdb.tar.bz2) [https://storage.googleapis.com/mainnet-beta-ledger-us-ny5/89855469/snapshot-89855469-9i59TwLmzXvbomizFZNuXgPygtx8zJ3P4nWDQuNxrTxK.tar.zst](https://storage.googleapis.com/mainnet-beta-ledger-us-ny5/89855469/snapshot-89855469-9i59TwLmzXvbomizFZNuXgPygtx8zJ3P4nWDQuNxrTxK.tar.zst) [https://storage.googleapis.com/mainnet-beta-ledger-us-ny5/89855469/rocksdb.tar.bz2](https://storage.googleapis.com/mainnet-beta-ledger-us-ny5/89855469/rocksdb.tar.bz2) [https://storage.googleapis.com/mainnet-beta-ledger-us-ny5/89855469/hourly/snapshot-89865552-CWFaiDterTZ1EFQrJkFghnnzERFJNNFT2USBnYTssxsF.tar.zst](https://storage.googleapis.com/mainnet-beta-ledger-us-ny5/89855469/hourly/snapshot-89865552-CWFaiDterTZ1EFQrJkFghnnzERFJNNFT2USBnYTssxsF.tar.zst) [PoH validation](/validation) [https://github.com/solana-labs/solana/blob/005c825b5c27bd57df9b0aadf0edb2e02215add0/runtime/src/bank.rs#L7047-L7052](https://github.com/solana-labs/solana/blob/005c825b5c27bd57df9b0aadf0edb2e02215add0/runtime/src/bank.rs#L7047-L7052) [for about 495 slots (89856108 and 89856602) is missing](/generating/historical-blocks#epoch-208) --- # Reproducibility | Old Faithful You will have identical archives with identical CIDs if you generate archives from the same RocksDB ledger. However, because transaction logs are included in the Old Faithful output, we cannot guarantee reproducibility across two RocksDB ledgers. For example, if you have two warehouse nodes generating Old Faithful archives from their local snapshot state, these may produce different transaction execution logs. This could happen, for example, if the two nodes run different Solana versions. The execution logs from the transactions are not validated and are not part of the validated set of the blockchain. They are metadata produced during the transaction's execution by the node executing them. [PreviousValidation](/validation) [NextEpoch 208](/validation/epoch-208) Last updated 9 months ago ---