Dagger Contracts

An experimental implementation of the contracts that underly the Dagger storage network. Its goal is to experiment with the rules around the bidding process, the storage contracts, the storage proofs and the host stakes. Neither completeness nor correctness are guaranteed at this moment in time.

Running

To run the tests, execute the following commands:

npm install
npm test

Overview

The Dagger storage network depends on hosts offering storage to clients of the network. The smart contracts in this repository handle interactions between client and host as they negotiate and fulfill a contract to store data for a certain amount of time.

When all goes well, the client and host perform the following steps:

Client                 Host            Storage Contract
  |                     |
  | --- request (1) --> |
  |                     |
  | <----- bid (2) ---- |
  |
  | ----------- create contract (3) ---------> |
  |                                            |
  | ----- data (4) ---> |                      |
                        |                      |
                        | ---- start (5) ----> |
                        |                      |
                        | ---- proof (6) ----> |
                        |                      |
                        | ---- proof (6) ----> |
                        |                      |
                        | ---- proof (6) ----> |
                        |                      |
                        | <-- payment (7) ---- |

1. Client broadcasts off-chain a request for storage, containing the size of the data that it wants to store and the length of time it wants to store it
2. Several hosts reply off-chain with a bid containing a price
3. The client selects a bid and uses it to create a new storage contract on-chain
4. The client sends the data it wants to store to the host
5. Once the host has received the data it starts the storage contract
6. While the storage contract is active, the host proves that it is still storing the data by responding to frequent random challlenges
7. At the end of the contract the host is paid

Contracts

A storage contract can be created on-chain from a signed request and bid. The request contains the size of the data and the length of time during which it needs to be stored. It also contains proof requirements such as how often a proof will need to be submitted by the host. A random nonce is included to ensure uniqueness among similar requests. A bid contains a reference to the request it pertains to, a price, and an expiry time.

When a new storage contract is created the client immediately pays the entire price of the contract. The payment is only released to the host upon successful completion of the contract.

Stakes

To motivate a host to remain honest, it must put up some collateral (stake) before it is allowed to participate in storage contracts. The stake may not be withdrawn as long as a host is participating in an active storage contract.

Should a host be misbehaving, then its stake may be reduced by a certain percentage (slashed).

Proofs

A host is required to submit frequent proofs while a contract is active. These proofs ensure with a high probability that the host is still holding on to the data that it was entrusted with.

To ensure that a host is not able to predict and precalculate proofs, these proofs are based on a random challenge. Currently we use the ethereum block hash to determine two things: 1) whether or not a proof is required at this point in time, and 2) the random challenge for the proof. Although a host will not be able to predict the exact times at which a proof is required, the frequency of proofs averages out to once per proof period. This proof period was agreed upon by the client and host during the request/bid exchange.

Hosts have a small period of time in which they are expected to submit a proof. When that time has expired without seeing a proof, validators are able to point out the lack of proof. If a host misses too many proofs, it results into a slashing of its stake.

To Do

• Actual proofs

  Because the actual proof of retrievability algorithm hasn't been determined yet we're using a dummy algorithm for now.

• Contract take-over

  Allow another host to take over a contract when the original host missed too many proofs.

• Start failures

  When a contract fails to start it should be aborted after a timeout. A contract may fail to start because the client failed to send the data, or because the host failed to start the contract. To discourage this, a small portion of both the client and host money can be burned if the contract doesn't start within a certain amount of time.

• Reward validators

  A validator that points out missed proofs should be compensated for its vigilance and for the gas costs of invoking the smart contract.

• Analysis and optimization of gas usage