Filecoin storage and retrieval logic
It is a decentralized exchange run by the network where all requirements and bids are stored in a blockchain for storing data on a Filecoin network.
The customer submits a bid order to the storage order book (using the PUT protocol, as explained in the next section). Customers must deposit the coins specified in the order and specify the number of copies they want to store. Customers can submit multiple orders or specify a replication factor in the order. Higher redundancy (higher replication factor) leads to higher tolerance for storage failures.
The storage miner stores the collateral through the pledge transaction in the blockchain through Manage.PledgeSector, and guarantees the storage to the network. The collateral (Filecoins) stores the time used to provide the service, and if the miner generates a proof of storage for the data submitted by them, the collateral is returned. If some storage proves to be unsuccessful, a certain percentage of collateral will be lost. Once the pledge transaction appears in the blockchain, the miners can provide storage in the storage market: they set the price and add an RFQ to the market order.
Once the pledge transaction appears in the blockchain (and therefore in the allocation table), the miners can provide their storage in the storage market: they set the price and add an RFQ to the market order via Put.AddOrders.
When a matching query & bid order is found (via Put.MatchOrders), the piece (data) sent by the client is sent to the miner.
When receiving this work, the miners run Put.ReceivePiece. Upon receipt of the data, both the miner and the customer sign the transaction order and submit it to the blockchain (in the storage market order book).
The storage miner's storage is divided into sectors, and each sector contains the portion assigned to the miner. The network tracks the sectors of each storage miner through an allocation table. At this point (when the transaction order is signed), the network assigns the data to the miner and records it in the allocation table.
When the storage miner sector is filled, the sector is sealed. A seal is a slow sequential operation that converts the data in a sector into a copy, which is the only physical copy of the data associated with the miner's public key. Sealing is necessary to copy the proof period (described in the Consensus section below).
When storage miners are assigned data, they must repeatedly generate proofs of replication to ensure they store the data (we will discuss them in detail below). The proof will be posted on the blockchain and the network will verify it.
All storage allocations are public to each participant in the network. In each block, the network checks to see if there is evidence for each assignment, checks if they are valid, and takes the appropriate action:
1. If any evidence is lost or invalid, the network will punish the storage miner by partial mortgage.
2. If a large amount of evidence is lost or invalid (defined by the system parameter Δfault), the network considers the storage miner to be faulty, settles the order as a failure, and re-introduces the same new order to the market.
3. If every storage miner storing this item fails, the piece will be lost and the customer will be refunded.
This is an off-chain exchange where customers and search miners discover each other in a peer-to-peer manner. Once the customer and the miner agree on the price, they will start using small payments to exchange data and coins one by one.
Retrieving miners announce their work by chatting on the web with their inquiries: they set prices and add inquiry orders to market orders.
The customer submits a bid order to the search market order. Retrieve miners to check if their order matches the corresponding bid order from the customer.
Once the order matches, Retrieval Miners will send the piece to the customer (the miner sends some data and sends a micropayment). Upon receipt of the goods, the miner and the customer sign the transaction order and submit it to the blockchain.