From f499b8453d3839b0557a0eef1c7f9be9615ece41 Mon Sep 17 00:00:00 2001 From: Mark Spanbroek Date: Mon, 8 Nov 2021 16:07:43 +0100 Subject: [PATCH] Add Readme --- Readme.md | 129 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 129 insertions(+) create mode 100644 Readme.md diff --git a/Readme.md b/Readme.md new file mode 100644 index 0000000..7f3c26d --- /dev/null +++ b/Readme.md @@ -0,0 +1,129 @@ +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 +