logos-storage/logos-storage-docs
1
0
Fork 0
mirror of https://github.com/logos-storage/logos-storage-docs.git synced 2026-01-02 13:23:07 +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 ###
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 ####
The smart contract facilitates matching between storage providers and storage
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
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 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
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
their collateral can be forfeited. Their slot is then awarded to an other
storage provider.
their collateral can be forfeited. Their slot is then awarded to another storage
provider.
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
stochastically to ensure that it is not possible for a storage provider to
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
interactions that are required during the lifetime of the request. For instance,
when a request is canceled because there are not enough interested storage
providers, then the sales module can withdraw the tokens that were associated
with the request.
providers, then the purchasing module can withdraw the tokens that were
associated with the request.
#### Purchasing ####
#### Sales ####
The purchasing module is the counterpart to the sales module. It monitors the
smart contract to be notified of incoming storage requests. It keeps a list of
the most promising requests that it can fulfill. It will favor those requests
that have a high reward and low collateral. As soon as it finds a suitable
request, it will then try to first reserve and then fill a slot by downloading
the associated data, creating a storage proof, and posting it to the smart
contract. It will then continue to monitor the smart contract to provide it with
storage proofs when they are required.
The sales module is the counterpart to the sales module. It monitors the smart
contract to be notified of incoming storage requests. It keeps a list of the
most promising requests that it can fulfill. It will favor those requests that
have a high reward and low collateral. As soon as it finds a suitable request,
it will then try to first reserve and then fill a slot by downloading the
associated data, creating a storage proof, and posting it to the smart contract.
It will then continue to monitor the smart contract to provide it with storage
proofs when they are required.
The purchasing module contains a best effort strategy for determining which
storage requests it is interested in. Over time, we expect more specialized
strategies to emerge to cater to the needs of e.g. large providers versus
providers that run a node from their home.
The sales module contains a best effort strategy for determining which storage
requests it is interested in. Over time, we expect more specialized strategies
to emerge to cater to the needs of e.g. large providers versus providers that
run a node from their home.
### Whitepaper ###