logos-storage/logos-storage-research
1
0
Fork 0
mirror of https://github.com/logos-storage/logos-storage-research.git synced 2026-01-02 13:33:07 +00:00
Code Issues Packages Projects Releases Wiki Activity

fix: align terminology with code (#160)

Browse Source 
Co-authored-by: markspanbroek <mark@spanbroek.net>
This commit is contained in:
Adam Uhlíř 2023-03-09 11:55:52 +01:00 committed by GitHub
parent ad41558900
commit 7db5e654cb
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 47 additions and 47 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

94
design/marketplace.md
View File

@ -23,8 +23,8 @@ A new design
We propose to create new type of storage contract, containing a number of slots.
Each of these slots represents an agreement with a storage host to store a part
of the content. When a client wants store data on the network with durability
guarantees, it posts a storage contract on the blockchain. Hosts that want to
offer storage can fill a slot in the contract.
guarantees, it posts a storage Request on the blockchain. Hosts that want to
offer storage can fill a slot in the Request.
--------
@ -34,7 +34,7 @@ offer storage can fill a slot in the contract.
v
--------------
---------- | | --------
| Client | --- contract ---> | Blockchain | <--- fill slot --- | Host |
| Client | --- request ---> | Blockchain | <--- fill slot --- | Host |
---------- | | --------
--------------
^
@ -44,7 +44,7 @@ offer storage can fill a slot in the contract.
--------
The storage contract contains the content identifier, so that hosts can locate
The Request contains the content identifier, so that hosts can locate
and download the content. It also contains the reward that hosts receive for
storing the data and the collateral that hosts are expected to deposit. It
contains parameters pertaining to storage proofs and erasure coding. And
@ -52,12 +52,12 @@ finally, it contains the amount of hosts that are expected to store the content,
including a small amount of host losses that can be tolerated.
StorageContract
Request
cid # content identifier
reward # tokens payed per second per filled slot
collateral # amount of collateral required per host
collateral # amount of collateral required per host and slot
proof probability # frequency at which proofs are required
proof parameters # proof of retrievability parameters
@ -70,7 +70,7 @@ including a small amount of host losses that can be tolerated.
slots # assigned host slots
timeout # slots need to be filled before timeout
expire # slots need to be filled before timeout
Slots
-----
@ -107,37 +107,37 @@ reserved for repairs. An empty slot can be filled again once another host
submits a correct proof together with collateral. Payouts for the time interval
that a slot is empty are burned.
Payouts for all hosts are accumulated in the contract and payed out at contract
Payouts for all hosts are accumulated in the smart contract and paid out at Request
end. This is to ensure that the incentive posed by the collateral is not
diminished over time.
Contract lifecycle
------------------
A contract starts when all slots are filled. Regular storage proofs will be
A Request starts when all slots are filled. Regular storage proofs will be
required from the hosts that filled the slots.
Some contracts may not attract the required amount of hosts, for instance
Some Requests may not attract the required amount of hosts, for instance
because the payment is insufficient or the storage demands on the network are
too high. To ensure that such contracts end, we add a timeout to the contract.
If the contract failed to attract sufficient hosts before the timeout is
too high. To ensure that such Requests end, we add a timeout to the Request.
If the Request failed to attract sufficient hosts before the timeout is
reached, it is considered cancelled, and the hosts that filled any of the slots
are able to withdraw their collateral. They are also paid for the time interval
before the timeout. The client is able to withdraw the rest of the tokens in the
contract.
Request.
A contract ends when the money that was paid upfront runs out. The end time can
A Request ends when the money that was paid upfront runs out. The end time can
be calculated from the amount of tokens that are paid out per second. Note that
in our scheme this amount does not change during the lifetime of the contract,
in our scheme this amount does not change during the lifetime of the Request,
even when proofs are missed and repair happens. This is a desirable property
for hosts; they can be sure of a steady source of income, and a predetermined
contract length. When a contract ends, the hosts may withdraw their collateral.
Request length. When a Request ends, the hosts may withdraw their collateral.
When too many hosts fail to submit storage proofs, and no other hosts take over
the slots that they vacate, then the content can be considered lost. The
contract is considered failed. The collateral of every host in the contract is
Request is considered failed. The collateral of every host in the Request is
burned as an additional incentive for the network hosts to avoid this scenario.
The client is able to retrieve any funds that are left in the contract.
The client is able to retrieve any funds that are left in the Request.
|
| create
@ -165,13 +165,13 @@ The client is able to retrieve any funds that are left in the contract.
Repairs
-------
When a slot becomes empty, some of the remaining collateral associated with the
slot is used as an incentive to repair the lost content. Repair typically
involves downloading other parts of the content and using erasure coding to
restore the missing parts. This incurs costs for a host. To compensate the host
for these costs it receives not only its own collateral back at the end of the
contract, but also a reward. The size of the reward is a parameter of the
contract.
When a slot is freed because of missing too many storage proofs, some
collateral from the host that previously filled the slot is used as an incentive
to repair the lost content. Repair typically involves downloading other parts of
the content and using erasure coding to restore the missing parts. To incentive
other nodes to do this repair, there is repair fee. It is a partial amount of the original
host's collateral. The size of the reward is a fraction of slot's collateral
where the fraction is parameter of the smart contract.
The size of the reward should be chosen carefully. It should not be too low, to
incentivize hosts in the network to prioritize repairs over filling new slots in
@ -181,16 +181,16 @@ network to try to disable hosts in an attempt to collect the reward.
Renewal
-------
When a contract is about to end, and someone in the network wants the contract
to continue for longer, then they can post a new contract with the same content
When a Request is about to end, and someone in the network wants the Request
to continue for longer, then they can post a new Request with the same content
identifier.
We've chosen not to allow top-ups of existing contracts with new funds. Even
We've chosen not to allow top-ups of existing Requests with new funds. Even
though this has many advantages (it's a very simple way to extend the lifetime
of the contract, it allows people to easily chip in to host content, etc.) it
of the Request, it allows people to easily chip in to host content, etc.) it
has one big disadvantage: hosts no longer know for how long they'll be kept to
the contract. When a contract is continuously topped up, they cannot leave the
contract without losing their collateral.
the Request. When a Request is continuously topped up, they cannot leave the
Request without losing their collateral.
Dispersal
---------
@ -199,25 +199,25 @@ Here we propose an an alternative way to select hosts for slots that is a
variant of the "first come, first serve" approach that we described earlier. It
intends to alleviate these problems:
1. a single host can fill all slots in a contract
1. a single host can fill all slots in a Request
2. a small group of powerful hosts is able to fill most slots in the network
3. resources are wasted when many hosts try to fill the same slot
For a client it is beneficial when their content is stored on as many different
hosts as possible, to guard against host failures. Should a single host fill all
slots in the contract, then the failure of this single host could mean that the
slots in the Request, then the failure of this single host could mean that the
content is lost.
On a network level, we also want to avoid that a few large players are able to
fill most contract slots, which would mean that the network becomes fairly
fill most Request slots, which would mean that the network becomes fairly
centralized.
When too many nodes compete for a slot in a contract, and only one is selected,
When too many nodes compete for a slot in a Request, and only one is selected,
then this leads to wasted resources in the network. Wasted resources ultimately
lead to a higher cost of storage.
To alleviate these problems, we introduce a dispersal parameter in the storage
contract. The dispersal parameter allows a client to choose the amount of
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
@ -226,7 +226,7 @@ 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
able to fill slots. This increases the chances of a single host to fill all
slots in a contract. When the client choses a low speed, then it is more likely
slots in a Request. When the client choses a low speed, then it is more likely
that different hosts fill the slots.
We use the Kademlia distance function to indicate which hosts are allowed to
@ -269,31 +269,31 @@ Conclusion
The design that we presented here deviates significantly from the previous
marketplace design.
There is no explicit negotiation phase for storage contracts. Clients are no
There is no explicit negotiation phase for Requests. Clients are no
longer able to choose which hosts will be responsible for keeping the content on
the network. This removes the selection step that was required in the old
design. Instead a host presents the network with an opportunity to earn money by
storing content. Hosts can decide whether or not they want to take part in the
contract, and if they do they are expected to keep to their part of the deal
design. Instead, a host presents the network with an opportunity to earn money by
storing content. Hosts can decide whether they want to take part in the
Request, and if they do they are expected to keep to their part of the deal
lest they lose their collateral.
The first hosts that download the content and provide initial storage proofs are
awarded slots in the contract. This removes the explicit contract start (and its
awarded slots in the Request. This removes the explicit Request start (and its
associated timeout behavior) that was required in the old design. It also adds
an incentive to quickly start storing the content while slots are available in
the contract.
the Request.
While the old design required separate negotiations per host, this design
ensures that either the single contract starts with all hosts, or is cancelled.
ensures that either the single Request starts with all hosts, or is cancelled.
This is a significant reduction in the amount of interactions required.
The old design required new negotiations when a host is not able to fulfill its
obligations, and a separately designed repair protocol. In this design we
managed to include repair incentives and a repair protocol that is nearly
identical to contract start.
identical to Request start.
In the old design we had a single collateral per host that could be used to
cover many contracts. Here we decided to include collateral per contract. This
cover many Requests. Here we decided to include collateral per Request. This
is done to simplify collateral handling, but it is not a requirement of the new
design. The new design can also be made to work with a single collateral per
host.