Bounty Contract

Short Intro

1. Besides host chain client, there is a set of storage dealers that are users of the host chain;
2. On the host chain there is a Bounty Contract that clients use to propose a "Bounty Deal" for requesting to store files on a DSN (specifying the "bounty" payment and the duration for storage and optionally other features);
3. [optional] Dealers accept the deal and commit to provide evidence that the file has been stored on the selected DSN according with the terms specified by the client;
4. There is a Storage Oracle which can provide a statement that given files are marked as stored on the DSN;
5. The bounty is released to the dealer as soon as it post on the host chain the oracle statement.

In the following section we expand on the high-level overview above, providing full details.

Protocol Description

Parties:

• Host Chain Clients: An Host Chain Client is the user of our protocol. He wants to store a file on a DSN without interacting with it, but having the same guarantees as a DSN user. To do so the client creates a Bounty Deal Proposal on the host chain specifying the file to be stored, the DSN to be used, the bounty that will be paid and other terms and conditions (see below for the full description of the proposal).

• Storage Dealers: In our protocol, a Storage Dealer is the party that can read the host chain (eg, it has an host chain node) and can store files in a DSN (eg, it has access to the DSN as user or it is one of the node forming the DSN). And, after posting and storage proof on the chain (see next bullet point) can claim the bounty (or part of it).

  [Optional] When accepting a deal proposal, a dealer can be asked to put down a collateral as a guarantee for the storage service. This means that this collateral will be taken if the terms specified in the accepted deal are not respected.

Note that the dealer needs to provide evidence in the host chain about its activity on the DSN. To take care of this, we introduce the following entity:

• Storage Oracle: The Storage Oracle takes care of providing the evidence that a file is stored on a specific DSN. And this evidence can be used by the dealer to claim the bounty. More precisely,

  • The oracle is invoked from the host chain specifying a file_id;
  • Once invoked, the oracle checks the DSN to see if there is the evidence of the file corresponding to file_id be stored on the DSN at time T (the exact functioning of this depends on the DSN);
  • If the evidence is found, the oracle sings and sends back on the host chain its signed statement;
  • CallOracle(file_id) --> sig(file_id, T)

• Smart Contract and Blockchain: the smart contract contains the logic to create and accept the bounty deal proposal, release bounties and eventually slash dealers.

Note, we assume that a filesharing tool that can make the file available from the client to the storage dealer is used (eg, this can be done via IPFS).

SLA:

The protocol aims to boost the use of decentralized storage networks for storage over time.
A client using our protocol to store a file on a DSN is guaranteed that it will pay for the storage service (to the dealer) if and only if there is the evidence of file be stored throughout the agreed period of time (according to an agreed check in schedule).

Bounty Contract:

Create Deal Proposal

createDealProposal(data_uri, duration, bounty) -> deal_id

The host chain client proposes a bounty deal with the following inputs and conditions:

• The identifier of the file (or folder of files), data_uri;
• The list of DSNs that he want to store the file(s) on; [edit: we will have one contract per network]
• The list of the dealers that can redeem the bounty (if no address is specified we consider this to be open, meaning that the bounty can be obtained by any dealer who has the required proofs); [edit: the list of dealers is specified in the smart contract];
• The oracle addresses: the list of addresses that can send the storage statement messages; [edit: the oracle addresses is specified in the smart contract];
• The duration: period of time for which the files has to be stored, from when storage begins (ie, the first oracle statement is posted). Note that there may be a maximum for this value specified by the smart contract;
• The proving schedule: it specifies which is the frequency at which the oracle statement has to be posted (eg, every day or only once at the end of duration). We refer to this events as storage check-in(s);
  • Note: to simplify we assume that there is global proving schedule for the smart contract and the client does not have to specify this.
• The payment: "bounty", total amount (in native tokens) paid by the client to the dealer (if the deal is not invalidated by lacking of an oracle statement); at the moment of the request creation, the payment is "locked down" (ie, taken from the client's account and deposited to the smart contract);
  • The bounty release function: it describes the dynamics of the bounty release. For example:
    • The bounty is released over time at each storage check-in;
    • Or the bounty is released at the end of the duration, if all the storage check-ins were successful.
• [optional] The collateral: amount (in native tokens) required to be locked down from the dealer.
  • As we noted for the proving schedule, we may assume that there is a global realease function used in the smart contract and clients do not have to care about specifying this.

Cancel Deal Proposal

A client can cancel a proposal (not accepted yet) at any time, and this action will release the payment.

Moreover, proposals have a timeout after which they are not valid anymore (ie, can not be accepted).

Accept Deal Proposal

acceptDealProposal(uint256 deal_id, string data_uri)

A dealer can accept the terms specified in a proposal if all the following is true:

• It is one of the dealers in the sc dealer list (or the proposal was open);
• The proposal is active (no timeout, no cancel message);
• [optional] It has enough balance in his account in order to cover for the collateral (if collateral is needed). In this case, the collateral is "locked down" (ie, from the Storage Dealer's account deposited to the smart contract).

After a dealer has accepted, we say there is an active Bounty Deal between the dealer who accepted and the client who crated the deal proposal.
Also, we timestamp this on-chain, and we consider the deal active from this moment onward (timestamp_start).

Claim Bounty

claimBounty(deal_id, data_uri, signature)

This function can be called by a dealer according to the bounty release schedule.
At each call, the function does the following

• Check the schedule to see it the call is expected;
• Check if the deal has been accepted by the caller (ie, check is there is an active deal);
• Check the Oracle's signature
  • If valid, the deal is maintained active and if there is any due payment (see release function), this is deposited to the dealer's account from the smart contract vault.
  • Otherwise, the deal is terminated (the remaining part of the bounty is release back to the client, eventually the dealer is slashed).

List of events in the smart contract:

1. DealProposalCreated(uint256 index, StorageNetworks[], DealersAddress[] OracleAddress[], Duration, BountyAmount, ProvingSchedule, ReleaseFunction, CollateralAddress): Event emitted when new deal proposal is created by the client;
2. DealAccepted(uint256 index): Event emitted when a bounty deal is created by a dealer accepting the terms of a proposal (defines timestamp_start);
3. DealProposalCanceled(uint256 index): Event emitted when a proposal is canceled by the client before being accepted;
4. DealInvalidated(uint256 index): Event emitted when a bounty deal is invalidated (ie no expected valid oracle proof, according to the proving frequency);
5. BountyRedeemed(uint256 index): Event emitted when a bounty (or part of it) is redeemed by the dealer.