Protocol

FCR essentially has two components: CID network and payment network.

Protocol explanation video

A brief explanation and walkthrough video of the protocol is explained here.

CID Network

CID Network is very similar to IPFS:

1. Content routing is based on Kademlia DHT.
2. Provider record is used to indicate an interest of serving a content.
3. One difference between FCR and IPFS is that after a provider record is found, FCR will need to first query for a CID Offer.

A CID Offer essentially is an offer for others to retrieve a piece:

{
    // The root ID of the ipld graph of this piece.
    Piece ID

    // The size of this piece.
    Size     

    // Price per byte or PPB: the price of this offer.
    Price per byte.

    // The payment recipient address and also the party that creates this offer.
    Recipient address

    // The address of a linked miner, it is optional.
    Linked miner address

    // The address of a linked miner proof, it is also optional.
    Linked miner proof

    ...
}

The total price of this piece offer equals to size * price-per-byte. This offer has a signature so that it can be verified by both the offer sender and the offer recipient. The offer also contains a linked miner address. This can be combined with the proof of storage in Filecoin to increase the reliability of this offer. A user is more likely to retrieve from a retrieval provider that has a linked miner.

4. After a CID Offer is accepted. Retrieval will be performed via Graphsync. Payment is made every block, either there is a direct payment channel established with the recipient and payment will be made directly or FCR will attempt to pay via proxy payment.

Payment Network

The most important part and the main contribution of the system is the payment network.

Minimum settlement time

The payment network is based on the idea of a long-live payment channel: It costs gas and time to create, update, settle, collect a payment channel. From the retreival client point of view, if a payment channel can only be used once, each retrieval will at least cost:

Gas creating channel + actual retrieval cost

Each retrieval will also at least take:

Time creating channel + actual retrieval time

From a retreival client's point of view, you could imagine that under some circumstance, especially when retrieving small pieces, the actual retrieval cost will be much lower than the gas involved in creating channel and the actual retreival latency will be bounded by the time taken to create a payment channel.

Also, from a retrieval provider's point of view, it costs gas to update and collect the retrieval payment. Therefore, in order to be profitable, the channel balance will have to be at least greater than the gas involved in updating and collecting a payment channel (if the channel is settled by the client):

Retrieval payment stored in payment channel > Gas to update payment channel + Gas to collect payment channel.

Because of this, you could imagine that the retrieval provider will likely to configure every retrieval to have a minimum payment in order to profit, which does not help the retrieval of small pieces in the market.

An easy way to solve this is to enforce a minimum settlement time when creating a payment channel. FCR solves this by a protocol but this can be solved in on-chain contract level.

In FCR, before channel sender tries to establish a payment channel with a channel recipient, the channel sender first queries for a promised minimum settlement time from the channel recipient:

Once a promised minimum settlement time is received, the channel sender will then create a payment channel. This minimum settlement time is enforced in FCR but can be violated by the recipient as the recipient can override FCR and interact with Filecoin directly. However, if this happens, FCR of the channel sender will record this event and the sender will then be able to block this recipient in the future.

Payment channel state

Because of the minimum settlement time, each payment channel in FCR system has two states: active payment channel and inactive payment channel.

Channel becomes inactive when: 1, minimum settlement time has passed or 2, the other party has violated the agreement and settled the payment channel prior to minimum settlement time.

When a channel is active, FCR only allow users to topup the channel and only when the channel is inactive will the user be allowed to settle/collect the channel.

Payment route

The concept of the payment route is crucial in FCR's payment network. For example:

In above example, Node A has two outbound payment channels: one to Node B and the other to Node C. Node B has one outbound payment channel to Node D. Node C has one outbound payment channel to Node D. Finally, Node D has one payment channel to Node E. Let's also assume every payment channel is being served to the payment network.

There would be two potential payment routes from Node A to Node E: Node A -> B -> D -> E and Node A -> C -> D -> E. Similarly, there is only one payment route from Node B to Node E: B -> D -> E and only one payment route from Node C to Node E: C -> D -> E.

There are in total 6 possible payment routes from Node A, the rest are: A -> B, A -> B -> D, A -> C and A -> C -> D.

Payment network is built based on a custom P2P protocol: each FCR node has the ability to serve a payment channel for others to use at a given surcharge. Also, every FCR node will publish all known payment routes to subscribers periodically, so in the end, each FCR node in the network can build a payment route network around itself. In order to do a proxy payment, FCR first try to search a payment route locally and if a payment route is found, FCR will query for a payment offer.

A payment offer essentially is an offer for others to do proxy payment:

{
    // The source address of this proxy payment and also the party that creates this offer.
    Payment source address

    // The destination address of this proxy payment.
    Payment destination address

    // Price per period or PPP: the price of this offer.
    Price per period

    // Period: the price of this offer.
    Period

    // Amt is the maximum amount covered by this payment offer.
    Amount

    ...
}

The surcharge is calculated via price per period / period. If price per period=5 and period=100, the surcharge is 5%. Similar to piece offer, this payment offer has a signature so that it can be verified by both the offer sender and the offer recipient.

Payment offer query

The payment offer is queried in a recursive manner, take the same example and assume node A wish to pay to node E via payment route A -> B -> D -> E. Node A in this case will first query Node B for a payment offer:

Node B will then query the next node in the payment route for a payment offer, that is Node D:

Since Node D has a direct payment channel with Node E, Node D will return a payment offer - PayOffer(D) to Node B:

After getting an offer from Node D, Node B will create a payment offer - PayOffer(B) to Node A:

The difference is that PayOffer(B) actually has a dependent offer, that is PayOffer(D). The surcharge of PayOffer(B) in this case will contain both the surcharge set by Node B and the surcharge set by Node D. FCR uses the following formula to calculate the new payment per period and period:

PPP(new) = MAX(PPP(B), PPP(D))
Period(new) = MIN(Period(B), Period(D))

In this case, Node B will never lose any money during proxy payment.

Proxy payment

Each proxy payment is also performed in a recursive manner: Node A will pay Node B, who will take a small cut before paying to Node D. Finally Node D will take a small cut and paying to Node E specifying the proxy payment sender to be Node A. Node E will need to provide a receipt back to Node D, which will be propagated all the way to Node A.

Chain of Trust

In the example, you can tell that Node A will need to trust Node B for the proxy payment. The same works for Node B, it will need to trust Node D. Node D will need to trust Node E for the receipt. Ultimately, Node A will need to trust Node E to return the data when it receives a receipt from Node E.

The reponsiblity is very clear in FCR: For a proxy payment through a particular node in the payment route, if the next node is not working, a refund must be provided back to the previous node. Fail to provide a refund nor a correct receipt will result in being blocked by the previous node. The same works for CID network, for example, if Node E fails to provide the data to Node A after it signs a receipt, Node E will be blocked by Node A.

Considering the payment is performed incrementally as multiple micro payments, trust is established along the way.