logos-storage/logos-storage-docs
1
0
Fork 0
mirror of https://github.com/logos-storage/logos-storage-docs.git synced 2026-01-03 22:03:09 +00:00
Code Issues Packages Projects Releases Wiki Activity

Fix sales and purchasing roles (#27)

Browse Source 
Co-authored-by: Eric <5089238+emizzle@users.noreply.github.com>
This commit is contained in:
markspanbroek 2024-10-11 22:09:48 +02:00 committed by GitHub
parent a09c797804
commit 71db9795d0
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 25 additions and 21 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

46
learn/architecture.md
View File

@ -55,14 +55,18 @@ When the contract is reposted, some of the faulty node's collateral pays for the
### Marketplace architecture ### ### Marketplace architecture ###
The marketplace consists of a smart contract that is deployed on-chain, and the sales and purchasing modules that are part of the node software. The sales module is responsible for posting storage requests to the smart contract. The purchasing module is its counterpart that storage providers use to determine which storage requests they are interested in. The marketplace consists of a smart contract that is deployed on-chain, and the
purchasing and sales modules that are part of the node software. The purchasing
module is responsible for posting storage requests to the smart contract. The
sales module is its counterpart that storage providers use to determine which
storage requests they are interested in.
#### Smart contract #### #### Smart contract ####
The smart contract facilitates matching between storage providers and storage The smart contract facilitates matching between storage providers and storage
clients. A storage client can request a certain amount of storage for a certain clients. A storage client can request a certain amount of storage for a certain
duration. This request is then posted on-chain, so that storage providers can duration. This request is then posted on-chain, so that storage providers can
see it, and decide whether they want to fulfill a slot in the request. see it, and decide whether they want to fill a slot in the request.
The main parameters of a storage request are: The main parameters of a storage request are:
- the amount of bytes of storage that is requested - the amount of bytes of storage that is requested
@ -81,38 +85,38 @@ The smart contract also checks that storage providers keep their promises.
Storage providers post collateral when they promise to fill a slot of a storage Storage providers post collateral when they promise to fill a slot of a storage
request. They are expected to post periodic storage proofs to the contract, request. They are expected to post periodic storage proofs to the contract,
either directly or through an aggregator. If they fail to do so repeatedly, then either directly or through an aggregator. If they fail to do so repeatedly, then
their collateral can be forfeited. Their slot is then awarded to an other their collateral can be forfeited. Their slot is then awarded to another storage
storage provider. provider.
The smart contract indicates when a certain storage provider has to provide a The smart contract indicates when a certain storage provider has to provide a
storage proof. This is not done on a fixed time interval, but determined storage proof. This is not done on a fixed time interval, but determined
stochastically to ensure that it is not possible for a storage provider to stochastically to ensure that it is not possible for a storage provider to
predict when it should provide the next storage proof. predict when it should provide the next storage proof.
#### Sales #### #### Purchasing ####
The sales module in the node software interacts with the smart contract on The purchasing module in the node software interacts with the smart contract on
behalf of the node operator. It posts storage requests, and handles any other behalf of the node operator. It posts storage requests, and handles any other
interactions that are required during the lifetime of the request. For instance, interactions that are required during the lifetime of the request. For instance,
when a request is canceled because there are not enough interested storage when a request is canceled because there are not enough interested storage
providers, then the sales module can withdraw the tokens that were associated providers, then the purchasing module can withdraw the tokens that were
with the request. associated with the request.
#### Purchasing #### #### Sales ####
The purchasing module is the counterpart to the sales module. It monitors the The sales module is the counterpart to the sales module. It monitors the smart
smart contract to be notified of incoming storage requests. It keeps a list of contract to be notified of incoming storage requests. It keeps a list of the
the most promising requests that it can fulfill. It will favor those requests most promising requests that it can fulfill. It will favor those requests that
that have a high reward and low collateral. As soon as it finds a suitable have a high reward and low collateral. As soon as it finds a suitable request,
request, it will then try to first reserve and then fill a slot by downloading it will then try to first reserve and then fill a slot by downloading the
the associated data, creating a storage proof, and posting it to the smart associated data, creating a storage proof, and posting it to the smart contract.
contract. It will then continue to monitor the smart contract to provide it with It will then continue to monitor the smart contract to provide it with storage
storage proofs when they are required. proofs when they are required.
The purchasing module contains a best effort strategy for determining which The sales module contains a best effort strategy for determining which storage
storage requests it is interested in. Over time, we expect more specialized requests it is interested in. Over time, we expect more specialized strategies
strategies to emerge to cater to the needs of e.g. large providers versus to emerge to cater to the needs of e.g. large providers versus providers that
providers that run a node from their home. run a node from their home.
### Whitepaper ### ### Whitepaper ###