status-im/dagger-contracts
2
0
Fork 0
mirror of https://github.com/status-im/dagger-contracts.git synced 2025-01-28 23:35:04 +00:00
Code Issues Projects Releases Wiki Activity

Update Readme now that storage requests and offers are on-chain

Browse Source
This commit is contained in:
Mark Spanbroek 2022-03-15 10:17:55 +01:00
parent 3fd7c756d9
commit 743d1cdb07
1 changed files with 23 additions and 22 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

41
Readme.md
View File

@ -1,7 +1,7 @@
Dagger Contracts Dagger Contracts
================ ================
An experimental implementation of the contracts that underly the Dagger storage An experimental implementation of the contracts that underlay the Dagger storage
network. Its goal is to experiment with the rules around the bidding process, network. Its goal is to experiment with the rules around the bidding process,
the storage contracts, the storage proofs and the host collateral. Neither the storage contracts, the storage proofs and the host collateral. Neither
completeness nor correctness are guaranteed at this moment in time. completeness nor correctness are guaranteed at this moment in time.
@ -32,12 +32,13 @@ certain amount of time.
When all goes well, the client and host perform the following steps: When all goes well, the client and host perform the following steps:
Client Host Storage Contract Client Host Storage Contract
| | |
| | | |
| --- request (1) --> | | --------------- request (1) -------------> |
| | | |
| <----- bid (2) ---- | | | ---- offer (2) ----> |
| | |
| ----------- create contract (3) ---------> | | ------------- select offer (3) ----------> |
| | | |
| ----- data (4) ---> | | | ----- data (4) ---> | |
| | | |
@ -51,26 +52,26 @@ When all goes well, the client and host perform the following steps:
| | | |
| <-- payment (7) ---- | | <-- payment (7) ---- |
1. Client broadcasts off-chain a request for storage, containing the size of 1. Client submits a request for storage, containing the size of the data that
the data that it wants to store and the length of time it wants to store it 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 2. Several hosts submit offers containing a price
3. The client selects a bid and uses it to create a new storage contract 3. The client selects an offer
on-chain
4. The client sends the data it wants to store to the host 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 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 6. While the storage contract is active, the host proves that it is still
storing the data by responding to frequent random challlenges storing the data by responding to frequent random challenges
7. At the end of the contract the host is paid 7. At the end of the contract the host is paid
Contracts Contracts
--------- ---------
A storage contract can be created on-chain from a signed request and bid. The A storage contract can be negotiated through requests and offers. A request
request contains the size of the data and the length of time during which it contains the size of the data and the length of time during which it needs to be
needs to be stored. It also contains proof requirements such as how often a stored. It also contains a maximum price that a client is willing to pay and
proof will need to be submitted by the host. A random nonce is included to proof requirements such as how often a proof will need to be submitted by the
ensure uniqueness among similar requests. A bid contains a reference to the host. A random nonce is included to ensure uniqueness among similar requests. An
request it pertains to, a price, and an expiry time. offer 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 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 price of the contract. The payment is only released to the host upon successful
@ -94,12 +95,12 @@ proofs ensure with a high probability that the host is still holding on to the
data that it was entrusted with. data that it was entrusted with.
To ensure that a host is not able to predict and precalculate proofs, these 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 proofs are based on a random challenge. Currently we use ethereum block hashes
to determine two things: 1) whether or not a proof is required at this point in 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 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 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 proofs averages out to a value that was agreed upon by the client and host
by the client and host during the request/bid exchange. during the request/offer exchange.
Hosts have a small period of time in which they are expected to submit a proof. 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 When that time has expired without seeing a proof, validators are able to point