PR comments

- hosts => SPs
- describe F(t_i), and h better
- add additional description of why fill reward no longer needed
This commit is contained in:
Eric 2024-05-22 16:39:18 +10:00
parent 1bfd89bf95
commit 6507191318
No known key found for this signature in database

View File

@ -1,15 +1,15 @@
# Slot reservations # Slot reservations
Competition between hosts to fill slots has some advantages, such as providing Competition between storage providers (SPs) to fill slots has some advantages,
an incentive for hosts to become proficient in downloading content and such as providing an incentive for SPs to become proficient in downloading
generating proofs. It also has some drawbacks, for instance it can lead to content and generating proofs. It also has some drawbacks, for instance it can
network inefficiencies because multiple hosts do the work of downloading and lead to network inefficiencies because multiple SPs do the work of downloading
proving, while only one host is rewarded for it. These inefficiencies lead to and proving, while only one SP is rewarded for it. These inefficiencies lead to
higher costs for hosts, which leads to an overall increase in the price of higher costs for SPs, which leads to an overall increase in the price of storage
storage on the network. It can also lead to clients inadvertently inviting too on the network. It can also lead to clients inadvertently inviting too much
much network traffic to themselves. Should they for instance post a very network traffic to themselves. Should they for instance post a very lucrative
lucrative storage request, then this invites a lot of hosts to start downloading storage request, then this invites a lot of SPs to start downloading the content
the content from the client simultaneously, not unlike a DDOS attack. from the client simultaneously, not unlike a DDOS attack.
Slot reservations are a means to avoid these inefficiencies by only allowing SPs Slot reservations are a means to avoid these inefficiencies by only allowing SPs
who have secured a slot reservation to fill the slot. Furthermore, slots can who have secured a slot reservation to fill the slot. Furthermore, slots can
@ -19,12 +19,12 @@ address space on the network.
## Proposed solution: slot reservations ## Proposed solution: slot reservations
Before downloading the content associated with a slot, a limited number of hosts Before downloading the content associated with a slot, a limited number of SPs
can reserve the slot. Only hosts that have reserved the slot can fill the slot. can reserve the slot. Only SPs that have reserved the slot can fill the slot.
After the host downloads the content and calculates a proof, it can move the After the SP downloads the content and calculates a proof, it can move the slot
slot from its reserved state into the filled state by providing collateral and from its reserved state into the filled state by providing collateral and the
the storage proof. Then it begins to periodically provide storage proofs and storage proof. Then it begins to periodically provide storage proofs and accrue
accrue payments for the slot. payments for the slot.
``` ```
reserve proof & collateral reserve proof & collateral
@ -42,10 +42,10 @@ accrue payments for the slot.
---------------- time ----------------> ---------------- time ---------------->
``` ```
There is an initial race for eligible SPs who are first to secure a reservation, then a There is an initial race for eligible SPs who are first to secure a reservation,
second race amongst the SPs with a reservation to fill the slot (with collateral then a second race amongst the SPs with a reservation to fill the slot (with
and the generated proof). However, not all SPs in the network can reserve a slot collateral and the generated proof). However, not all SPs in the network can
initially: the [expanding window reserve a slot initially: the [expanding window
mechanism](https://github.com/status-im/codex-research/blob/ad41558900ff8be91811aa5de355148d8d78404f/design/marketplace.md#dispersal) mechanism](https://github.com/status-im/codex-research/blob/ad41558900ff8be91811aa5de355148d8d78404f/design/marketplace.md#dispersal)
dictates which SPs are eligible to reserve the slot. dictates which SPs are eligible to reserve the slot.
@ -57,25 +57,31 @@ number of SP addresses to fill/repair the slot at the start. Over time, the
number of eligible SP addresses increases, until eventually all SP addresses in number of eligible SP addresses increases, until eventually all SP addresses in
the network are eligible. the network are eligible.
The expanding window mechanismstarts off with a random source address, defined The expanding window mechanism starts off with a random source address, defined
as $hash(block hash, request id, slot index, reservationindex)$. The distance as $hash(block hash, request id, slot index, reservationindex)$, with a unique
between each SP address and the source address can be defined as $XOR(A, A_0)$ source address for each reservation of each slot. The distance between each SP
(kademlia distance). Once the allowed distance is greater than SP's distance, address and the source address can be defined as $XOR(A, A_0)$ (kademlia
the SP is considered eligible to reserve a slot. The allowed distance for distance). Once the allowed distance is greater than SP's distance, the SP is
eligible addresses over time $t_i$ can be [defined as $2^{256} * considered eligible to reserve a slot. The allowed distance for eligible
F(t_i)$](https://hackmd.io/@bkomuves/BkDXRJ-fC). As this allowed distance value addresses over time $t_i$ can be [defined
increases along a curve, more and more addresses will be eligible to participate as](https://hackmd.io/@bkomuves/BkDXRJ-fC) $2^{256} * F(t_i)$, where $2^{256}$
in reserving that slot. In total, eligible addresses are those that satisfy: represents the total number of 256-bit addresses in the address space, and
$F(t_i)$ represents the expansion function over time. As this allowed distance
value increases along a curve, more and more addresses will be eligible to
participate in reserving that slot. In total, eligible addresses are those that
satisfy:
$XOR(A, A_0) < 2^{256} * F(t_i)$ $XOR(A, A_0) < 2^{256} * F(t_i)$
Because the source address for the expanding window is generated using the slot Furthermore, the client can change the curve of the rate of expansion, by
index and the reservation index, that means the source address for each setting a [dispersal
reservation in each slot will be different. parameter](https://github.com/codex-storage/codex-research/blob/ad41558900ff8be91811aa5de355148d8d78404f/design/marketplace.md#dispersal)
of the storage request, $h$, which represents the percentage of the network
addresses that will be eligible halfway to the time of expiry. $h$ can be
defined as:
$h := F(0.5)$, where $0 \lt h \lt 1$ and $h \neq 0.5$
Furthermore, the client can set the rate of expansion by defining the [parameter
$h$](https://hackmd.io/@bkomuves/BkDXRJ-fC#Parametrizing-the-speed-of-expansion)
as the [dispersal parameter](https://github.com/codex-storage/codex-research/blob/ad41558900ff8be91811aa5de355148d8d78404f/design/marketplace.md#dispersal) of the request.
Changing the value of $h$ will [affect the curve of the rate of Changing the value of $h$ will [affect the curve of the rate of
expansion](https://www.desmos.com/calculator/pjas1m1472) (interactive graph). expansion](https://www.desmos.com/calculator/pjas1m1472) (interactive graph).
@ -91,7 +97,13 @@ transaction itself creates a signal of intent from an SP to fill the slot. If
the SP were to not fill the slot, then other SPs that have reserved the slot the SP were to not fill the slot, then other SPs that have reserved the slot
will fill it. will fill it.
#### No reservation reward #### No reservation/fill reward
Fill rewards were originally proposed to incentivize filling slots as fast as
possible. However, the SPs are already being paid out for the time that they
have filled the slot, thus negating the need for additional incentivization. If
additional incentivization is desired by the client, then an increase in the
value of the storage request is possible.
Adding a fill reward for SPs who ultimately fill the slot is not necessary Adding a fill reward for SPs who ultimately fill the slot is not necessary
because, like the SP rewards for providing proofs, fill rewards would be paid because, like the SP rewards for providing proofs, fill rewards would be paid
@ -101,14 +113,14 @@ payout. Therefore, if a client is so inclined to provide a fill reward, they
could instead increase the total reward of the storage request. could instead increase the total reward of the storage request.
In this simplified slot reservations proposal, there will not be reservation In this simplified slot reservations proposal, there will not be reservation
collateral and reward requirements until the behavior in a live environment can collateral nor reward requirements until the behavior in a live environment can
be observed and it is determined this are necessary mechanisms. be observed to determine these are necessary mechanisms.
### Slot reservation attacks ### Slot reservation attacks
Name | Attack description Name | Attack description
:------------|:-------------------------------------------------------------- :------------|:--------------------------------------------------------------
Clever SP | SP drops reservation when a better opportunity presents itself Clever SP | SP drops slot when a better opportunity presents itself
Lazy SP | SP reserves a slot, but doesn't fill it Lazy SP | SP reserves a slot, but doesn't fill it
Censoring SP | acts like a lazy SP for specific CIDs that it tries to censor Censoring SP | acts like a lazy SP for specific CIDs that it tries to censor
Greedy SP | SP tries to fill multiple slots in a request Greedy SP | SP tries to fill multiple slots in a request