codex-storage/codex-research
1
0
Fork 0
mirror of https://github.com/codex-storage/codex-research.git synced 2025-01-09 18:26:07 +00:00
Code Issues Packages Projects Releases Wiki Activity

Rename: dispersal -> spreading

Browse Source
This commit is contained in:
Mark Spanbroek 2023-06-06 12:00:27 +02:00
parent 467d968076
commit b60af5f3e6
1 changed files with 12 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

23
design/marketplace.md
View File

@ -62,7 +62,7 @@ including a small amount of host losses that can be tolerated.
proof probability # frequency at which storage proofs are required
proof parameters # storage proof parameters
erasure coding # erasure coding parameters
dispersal # dispersal parameter
spreading # spreading parameter
repair reward # amount of tokens paid for repairs
hosts # amount of storage hosts (including loss)
@ -202,7 +202,7 @@ proofs and accrue payments for the slot.
Slot reservations could however provide a relatively cheap way for malicious
hosts to sabotage storage requests, by reserving a slot and never filling it.
There are two mechanisms that make this a costly attack to pull off. First,
there are the gas fees for the call to reserve a slot. Secondly, the dispersal
there are the gas fees for the call to reserve a slot. Secondly, the spreading
mechanism described below makes it harder to censor particular storage requests,
because it is unlikely that a malicious host has a short kademlia distance to
these storage requests.
@ -237,7 +237,7 @@ has one big disadvantage: hosts no longer know for how long they'll be kept to
the request. When a request is continuously topped up, they cannot leave the
request without losing their collateral.
Dispersal
Spreading
---------
Here we propose an an alternative way to select hosts for slots that is a
@ -263,11 +263,12 @@ lead to a higher cost of storage. Slot reservations help to alleviate this, but
reserving a slot still requires paying for gas costs. The more hosts try to
reserve a slot, the more gas fees are wasted.
To alleviate these problems, we introduce a dispersal parameter in the request.
The dispersal parameter allows a client to choose the amount of spreading within
the network. When a slot becomes empty then only a small amount of hosts in the
network are allowed to fill the slot. Over time, more and more hosts will be
allowed to fill a slot. Each slot starts with a different set of allowed hosts.
To alleviate these problems, we introduce a spreading parameter in the request.
The spreading parameter allows a client to choose the amount of distribution
within the network. When a slot becomes empty then only a small amount of hosts
in the network are allowed to fill the slot. Over time, more and more hosts will
be allowed to fill a slot. Each slot starts with a different set of allowed
hosts.
The speed at which new hosts are included is chosen by the client. When the
client choses a high speed, then very quickly every host in the network will be
@ -280,7 +281,7 @@ fill a slot.
distance between a and b: xor(a, b)
slot start point: hash(nonce || slot number)
allowed distance: elapsed time * dispersal parameter
allowed distance: elapsed time * spreading parameter
Each slot has a different start point:
@ -305,8 +306,8 @@ point is less that the allowed distance.
Note that even though we use the Kademlia distance function, this bears no
relation to the DHT. We use the blockchain address of the host, not its peer id.
This dispersal mechanism still requires modeling to check that it meets its
goals, and to find the optimal value for the dispersal parameter, given certain
This spreading mechanism still requires modeling to check that it meets its
goals, and to find the optimal value for the spreading parameter, given certain
network conditions. It is also worth looking into simpler alternatives.
Conclusion