codex-storage
/
codex-contracts-eth
mirror of https://github.com/codex-storage/codex-contracts-eth.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

[readme] update readme with slots, add references

This commit is contained in:
Mark Spanbroek 2023-01-31 15:14:45 +01:00 committed by markspanbroek
parent 7c9ebb3c31
commit fcc28b3931
1 changed files with 39 additions and 26 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

65
Readme.md
View File

@ -1,10 +1,10 @@
Codex Contracts Codex Contracts
================ ================
An experimental implementation of the contracts that underlay the Codex storage An experimental implementation of the smart contracts that underlay the Codex
network. Its goal is to experiment with the rules around the bidding process, storage network. Its goal is to experiment with the rules around the bidding
the storage contracts, the storage proofs and the host collateral. Neither process, the storage contracts, the storage proofs and the host collateral.
completeness nor correctness are guaranteed at this moment in time. Neither completeness nor correctness are guaranteed at this moment in time.
Running Running
------- -------
@ -26,10 +26,10 @@ Overview
The Codex storage network depends on hosts offering storage to clients of the The Codex storage network depends on hosts offering storage to clients of the
network. The smart contracts in this repository handle interactions between 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 client and hosts as they negotiate and fulfill a contract to store data for a
certain amount of time. certain amount of time.
When all goes well, the client and host perform the following steps: When all goes well, the client and hosts perform the following steps:
Client Host Marketplace Contract Client Host Marketplace Contract
| | | | | |
@ -38,7 +38,7 @@ When all goes well, the client and host perform the following steps:
| | | |
| ----- data (2) ---> | | | ----- data (2) ---> | |
| | | | | |
| --- fulfill (3) ---> | | ----- fill (3) ----> |
| | | |
| ---- proof (4) ----> | | ---- proof (4) ----> |
| | | |
@ -51,19 +51,23 @@ When all goes well, the client and host perform the following steps:
1. Client submits a request for storage, containing the size of the data that 1. Client submits 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 it wants to store and the length of time it wants to store it
2. Client makes the data available to hosts 2. Client makes the data available to hosts
3. The first host to submit a storage proof can fulfill the request 3. Hosts submit storage proofs to fill slots in the contract
4. While the storage contract is active, the host proves that it is still 4. While the storage contract is active, host prove that they are still
storing the data by responding to frequent random challenges storing the data by responding to frequent random challenges
5. At the end of the contract the host is paid 5. At the end of the contract the hosts are paid
Contracts Contracts
--------- ---------
A storage contract can be negotiated through requests. A request contains the A storage contract contains of a number of slots. Each of these slots represents
size of the data and the length of time during which it needs to be stored. It an agreement with a storage host to store a part of the data. Hosts that want to
also contains a reward that a client is willing to pay and proof requirements offer storage can fill a slot in the contract.
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 contract can be negotiated through requests. A request contains the size of
the data, the length of time during which it needs to be stored, and a number of
slots. It also contains the reward that a client is willing to pay and proof
requirements such as how often a proof will need to be submitted by hosts. A
random nonce is included to ensure uniqueness among similar requests.
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
@ -82,23 +86,32 @@ percentage (slashed).
Proofs Proofs
------ ------
A host is required to submit frequent proofs while a contract is active. These Hosts are 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 proofs ensure with a high probability that hosts are still holding on to the
data that it was entrusted with. data that they were entrusted with.
To ensure that a host is not able to predict and precalculate proofs, these To ensure that hosts are not able to predict and precalculate proofs, these
proofs are based on a random challenge. Currently we use ethereum block hashes 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 hosts will not be able
able to predict the exact times at which a proof is required, the frequency of to predict the exact times at which proofs are required, the frequency of proofs
proofs averages out to a value that was agreed upon by the client and host averages out to a value that was set by the client in the request for storage.
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
out the lack of proof. If a host misses too many proofs, it results into a out the lack of proof. If a host misses too many proofs, it results into a
slashing of its collateral. slashing of its collateral.
References
----------
* [A marketplace for storage
durability](https://github.com/status-im/codex-research/blob/main/design/marketplace.md)
(design document)
* [Timing of Storage
Proofs](https://github.com/status-im/codex-research/blob/main/design/storage-proof-timing.md)
(design document)
To Do To Do
----- -----
@ -107,10 +120,10 @@ To Do
Because the actual proof of retrievability algorithm hasn't been determined yet Because the actual proof of retrievability algorithm hasn't been determined yet
we're using a dummy algorithm for now. we're using a dummy algorithm for now.
* Contract take-over * Contract repair
Allow another host to take over a contract when the original host missed too Allow another host to take over a slot in the contract when the original
many proofs. host missed too many proofs.
* Reward validators * Reward validators