Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs: fix typos #100

Merged
merged 1 commit into from
May 30, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion site/cid.markdown
Original file line number Diff line number Diff line change
Expand Up @@ -22,4 +22,4 @@ From [https://docs.ipfs.tech/concepts/content-addressing/#what-is-a-cid](https:/
> - The same content added to two different IPFS nodes using the same settings will produce the same CID.


The CAR files and CIDs that are generated by Old Faithful are reproducible and will be the same regardless from which Rocksdb ledger archive they are generated from. This means that entities that are running archive nodes and store Rocksdb ledger archives can easily generated their own CIDs for the same blocks and transactions and compare to the ones being generated by the Old Faithful project. In theory this means that 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 any time without trusting anyone but your own data generating nodes.
The CAR files and CIDs that are generated by Old Faithful are reproducible and will be the same regardless from 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 to the ones being generated by the Old Faithful project. In theory this means that 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 any time without trusting anyone but your own data generating nodes.
2 changes: 1 addition & 1 deletion site/data-preparation.markdown
Original file line number Diff line number Diff line change
Expand Up @@ -8,7 +8,7 @@ nav_order: 2

# Data preparation

The primary data preparation tooling used in this project is based in the `radiance` tool developed by Jump's Firedancer team. It is rapidely developing, and active development for this project is currently based out of this repository and branch: [Radiance Triton](https://github.com/gagliardetto/radiance-triton/).
The primary data preparation tooling used in this project is based in the `radiance` tool developed by Jump's Firedancer team. It is rapidly developing, and active development for this project is currently based out of this repository and branch: [Radiance Triton](https://github.com/gagliardetto/radiance-triton/).

The radiance tool utilises the rocksdb snapshots that have been generated by [Warehouse](https://github.com/solana-labs/solana-bigtable) nodes. From these snapshots a CAR file per epoch is generated. This CAR file then needs to be processed by Filecoin tools such as [split-and-commp](https://github.com/anjor/go-fil-dataprep/) which generates the details needed for making a Filecoin deal.

Expand Down
Loading