Getting started

Constructions

Useful resources

Distributed peer-to-peer storage

Filecoin is a data storage and retrieval marketplace that coordinates untrusted parties to buy and sell provable storage.

In Filecoin, users can pay to store their files on storage providers. Storage providers are computers responsible for storing files and proving they have stored the files correctly over time. Anyone who wants to store their files or get paid for storing other users’ files can join the Filecoin network.

Decentralised Network: In a centralized system, where the user trust the central service provider to keep the data safe and store it for a promised period. With the decentralized Filecoin network, on the other hand, we have access to a variety of storage providers who are competing. These providers are not trusted, but the design of Filecoin's protocol relies on a public bulletin board (a blockchain) that allows to verify that storage providers are honoring their agreements to store users data for an expected period of time. All participants in the network work together to verify each deal. This uses a consensus mechanisms that help users in a distributed network come to agreement without the need for a central authority.

Encode the storage and commit to it

First step to onboard storage consist in the Initialisation phase called also “Proof of Replication” in Filecoin jargon. In this step, a storage provider proves that they are storing a physically unique copy, or replica, of the data. Proof of Replication happens just once, at the time the data is first stored and uploaded in the system. As the storage miner receives each piece of the client data, they place it into a sector (usually 32GB). Sectors are the fundamental units of storage in Filecoin, and can contain pieces from multiple deals and clients.

Once a sector is full, a ComD (Commitment of Data) is produced and uploaded to the blockchain.

A Proof of Space Initialisation step asks the prover to generate some encoding of the data which is incompressible, called replica (or advice). The prover is supposed to store the replica persistently throughout the second stage. To make the storage verifiable, the prover commits to the replica (ComR) and to the data, proves the encoding transformation correct and posts the two commitments in the blockchain. The encoding process is designed to be slow and computationally heavy.

Prove later that you continuously store the Data

In the second stage, the verifier can repeatedly audit the prover and check if it is still storing the replica.

While the Initialisation is run once to prove that a storage provider stored a physically unique copy of the data at the time the sector was sealed, Execution is run repeatedly to prove that the storage provider are continuing to dedicate storage space to that same data over time.

During this audit phase, the prover has to open random positions from the replica and show they are consistent with the publicly-known commitment (ComR) stored in the blockchain.

Seal is an operation used on the data $D$ to create a replica. The following properties are requiered to hold for Seal:

Inputs: – prover key pair $(pk_P ,sk_P)$ – prover SEAL key $pk_{SEAL}$ – data $D$ Outputs: replica $R$, Merkle root commitment $C_R$ of $R,$ proof $π_{SEAL}$

Inputs:

– prover PoSt key $pk_{POS}$ – replica $R$ – random challenge $c$ – time parameter $t$ Outputs: a proof $π_{POS}$

Inputs:

– prover public key $pk_P$ – verifier SEAL and POS keys $vk_{SEAL}, vk_{POS}$ – hash of data $D, h_D$ – Merkle root of the replica, $C_R$ – random challenge,$c$ – tuple of proofs, $(π_{SEAL}, π_{POS})$ Outputs: bit $b$, equals 1 if proofs are valid

ON THIS PAGE