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
- 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
acceptDealProposalfrom 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;
createDealProposal(cid_list, size_list, SP_policy, duration, commP, verified, payment) -> proposal_id
cid_list: The identifiers of the files that is the subject of the deasl;
A client creates a deal proposal specifying:
- each cid is an IPFS address and it can be used to download the file;
size_list: the declared dimensions of the file in bytes;
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);
duration: requested duration for the storage deals;
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;
verified: boolean variable, set to 1 by the client if the deal proposal for a verified deal;
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
- We assume there is global “timeout”, ie a deal proposal can not be accepted by providers after the x epochs passed from creation.
acceptDealProposal(proposal_id) --> deal_id
- Check that the proposal is still open (not yet accepted, no timeout)
- [optional] check proposal parameters against a storage policy defined by the provider
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:
- for example, SP defines a max size and the function checks that
addBalancefrom 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;
publishStorageDealsfrom the storage market actor to publish the deal,
MarketNotifyDeal, get back the
- the check about datacap is made by the storage market
- (note: the commP passed to
publishStorageDealsis the one in the
proposal_id, the provider can not cheat here)
- If the proposal is open (ie, any SP can accept it), then see Research q: how do we deal with multiple SP accepting an “open proposal”?
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).