The Filecoin network achieves economies of scale by allowing anyone to participate as a storage provider. Currently, the network is composed of hundreds of storage providers distributed around the world. The content addressing and encrypted storage proof verifies that the data is stored correctly and securely on the miner's hardware for a long time, thus creating a powerful and reliable service.

Filecoin data

In order to store files on Filecoin, users must first import the files in their local Filecoin node. This step will generate a data CID-content identifier, an ID that uniquely describes the content, and then the data will be transmitted to the miner. Another way to store files on Filecoin is through offline transactions, which is not covered in this article.

To import data into the local Filecoin node, you can use the lotus client import command. It is important to remember the generated data CID (it can also be used on the local node in the future), because it must be used when retrieving data from the miner in the future.

After importing the data to the local node, the user must initiate a transaction. This can be done through lotus client trading commands. This command takes the data CID as input, generates Filecoin Piece, and interactively guides the user to complete the storage transaction process, see below for details.

Filecoin Piece is the main negotiation unit for users' data stored on the Filecoin network. Filecoin Piece has no specific size, but it is restricted by network parameters and the upper limit of the sector size. If a Filecoin Piece is larger than the sector size supported by the miner, then it must be divided into more pieces so that each piece fits into a sector.

A Filecoin Piece is a CAR file containing an IPLD DAG, corresponding data and Piece CID.

CAR stands for Content Addressable aRchives-each CAR file is a serialized representation of an IPLD DAG, which is to string together its data blocks, plus the header information describing the DAG graph (and the root CID) .

When users want to store files in the Filecoin network, they must first use UnixFS to generate the IPLD DAG of the file (this is the function of the lotus client import command). The hash representing the root node of the DAG is an IPFS-style CID, called the data CID.

UnixFS is a protobuf-based format used to describe files, directories, and symbolic links in IPFS. In Filecoin, UnixFS is used as the file format submitted to the Filecoin network.

The generated CAR file is filled with extra zero bits to make the file a binary merkle tree.

Warehousing transaction process

Users can store data in the Filecoin network through transactions and retrieve data from the Filecoin network. Participants in the network, including miners (supply side) and users (demand side), interact by storing transactions and retrieving transactions.

The life cycle of a storage transaction is as follows:

1. Discover

The user identifies the miner and determines their current asking price, that is, the price per GiB per epoch (30 seconds) that the miner wants to receive in order to accept the transaction. The unit is attoFIL (1 attoFIL equals 10^-18 * FIL). Currently, the minimum period of a transaction in Filecoin is 180 days.

You can query the synchronized nodes through the JSON RPC API and list all currently active miners (for testing purposes, public terminal nodes are used, and the Filecoin.StateListMiners method is used.

You can choose based on the miner's reputation and ability in the network. The reputation indicators of miners have not yet entered the Filecoin protocol, and this article does not involve them.

Once you select a specific miner, you need to obtain its PeerID, for example, use the Filecoin.StateMinerInfo method to establish a secure connection with them through the libp2p protocol.

Then you can use the Filecoin.ClientQueryAsk method to query a signed StorageAsk. This will establish a direct libp2p connection with the selected miner and ask for storage quotes.

The result includes the details of the transaction that the miner is willing to accept, such as the size range of the accepted Filecoin Piece and the price per GiB per epoch. It should be noted that proposing storage transaction recommendations that match the storage requirements of the miners is a prerequisite, but not enough to ensure that the transaction is accepted-the storage provider may run its own decision logic later.

2. Negotiation and data transmission

At this stage, the two parties reach an agreement on the terms of the transaction, such as transaction costs, transaction period, and transaction start time. Then transfer the data from the client to the miner.

3. Release

Publish the transaction on the chain through the PublishStorageDeals message, making the storage provider responsible for the disclosure of the transaction.

4. Done

After the transaction is released on the chain, it will be handed over to the storage mining subsystem, packaged into a sector, then packaged, and then continuously proven to be available.