Protocol research for a verified data bounty contract

• Data Bounty Contracts
• Functions:

Data Bounty Contracts

These are FVM contracts that automatise the storage of files (ie, deal making) on Filecoin.

In the following we assume the current Storage Market Actor, but the design of a bounty contract can be adapted to work with any future Market Actor that works as escrow and a ledger for all deals made.

High level description of deal making flow:

• The client calls the bounty contract to create an onchain deal proposal (see createDealProposal function);
• Dealers (ie, parties interested to accept deals, it can be providers or intermediaries in the future) keep scanning the Filecoin blockchain to look for deal proposal messages;
• When they found one that they want to accept, they call the acceptDealProposal from the bounty contract;
• The smart contract interacts with the Storage Market Actor to check the validity of the proposal and to lock down funds (ie, FIL tokens) to cover for payments and collaterals as needed;
• If no issue is found, the Storage Market Actor publish the accepted storage deal;

Functions:

• createDealProposal(cid_list, size_list, SP_policy, duration, commP, verified, payment) -> proposal_id

A client creates a deal proposal specifying:

1. cid_list: The identifiers of the files that is the subject of the deasl;
• each cid is an IPFS address and it can be used to download the file;
2. size_list: the declared dimensions of the file in bytes;
3. SP_policy: the policy that specifies the attributes that a provider must have in order to be able to accept the proposal
• For example: it can be a list of providers, “top ten” or the empty list (any provider can accept);
4. duration: requested duration for the storage deals;
5. commP_list: the Merkle Tree roots (computed using SHA256) of the files;
• For the MVP: commP is computed by the client and added as parameter to the deal proposal;
• Future: there is an oracle that provides this to the smart contract, and the commP can be added as output;
6. verified : boolean variable, set to 1 by the client if the deal proposal for a verified deal;
7. payment: the amount of FIL tokens paid to the provider for the service;
• Default to 0 in the prototype.

The function call addBalance from the Storage Market Actor to move from the client’s address to the client’s vault in the storage market account the tokens declared in payment.

Notes:

8. Proposal timeout:
• We assume there is global “timeout”, ie a deal proposal can not be accepted by providers after the x epochs passed from creation.
9. ToDo (@): check how signatures are handled by the market actor (FIP?)
• acceptDealProposal(proposal_id) --> deal_id

Provider locally downloads the file using cid and run the required local checks (eg, check that declared size matches with the one from the dowloaded file). If everything okay, the providers calls the accept deal function with input proposal_id. The function does the following:

1. Check that the proposal is still open (not yet accepted, no timeout)
2. [optional] check proposal parameters against a storage policy defined by the provider
• for example, SP defines a max size and the function checks that size ≤ max_size;
3. check if the client has enough balance to cover payment;
4. The function call addBalance from the Storage Market Actor to move from the provider’s address to the provider’s vault in the storage market account the tokens needed to cover for collateral;
5. Check caller address against the SP_policy;
6. Call the publishStorageDeals from the storage market actor to publish the deal,
• assuming MarketNotifyDeal , get back the deal_id
• the check about datacap is made by the storage market
• (note: the commP passed to publishStorageDeals is the one in the proposal_id, the provider can not cheat here)

• claimBounty(deal_id_list) This function can be called by a dealer to get payment according to the bounty proposal. The function does the following
• [??] Check the schedule to see it the call is expected;
• Call the storage market actor to check if deal is active;
• if yes, release payment
• otherwise, no payment and the deal is terminated (the remaining part of the bounty is release back to the client, eventually the dealer is slashed).