status-im
/
dagger-research
mirror of https://github.com/status-im/dagger-research.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity

docs: fix typos

This commit is contained in:
xiaolou86 2023-10-24 10:26:29 +08:00 committed by markspanbroek
parent a880c0e753
commit f0c0d5bb38
3 changed files with 5 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
design/marketplace.md
View File

@ -56,7 +56,7 @@ including a small amount of host losses that can be tolerated.
cid # content identifier
reward # tokens payed per second per filled slot
reward # tokens paid per second per filled slot
collateral # amount of collateral required per host and slot
proof probability # frequency at which proofs are required

4
design/proof-erasure-coding.md
View File

@ -18,7 +18,7 @@ called a 'slot'][0], so we'll refer to the piece that a single hosts stores as
its 'slot data'.
In the rest of this document we will ignore these two first purposes and dive
deeper into the third purpose; increasing the probabily of finding missing slot
deeper into the third purpose; increasing the probability of finding missing slot
data on a host. For this reason we introduce a secondary erasure coding scheme
that makes it easier to detect missing or corrupted slot data on a host through
storage proofs.
@ -426,7 +426,7 @@ Two concrete options are:
per proof. For 1TB this leads to a shards of 256 bytes. This means that the
SNARK needs to hash 200KB (40KB of shards + 160KB for Merkle paths) for a
storage proof. We can use the leopard library for erasure coding and keep
memory requirements for erasure coding to a negligable level.
memory requirements for erasure coding to a negligible level.
[0]: ./marketplace.md
[1]: https://github.com/catid/leopard

4
design/sales.md
View File

@ -161,7 +161,7 @@ from entering the queue.
### Removing slots from the queue
Hosts will also recieve contract events for when any contract is started,
Hosts will also receive contract events for when any contract is started,
failed, or cancelled. In all of these cases, slots in the queue pertaining to
these requests should be removed as they are no longer fillable by the host.
Note: expired request slots will be checked when a request is processed and its
@ -197,7 +197,7 @@ As soon as items are available in the queue, and there are workers available for
processing, an item is popped from the queue and processed.
When a slot is processed, it is first checked to ensure there is a matching
availabilty, as these availabilities will have changed over time. Then, the
availability, as these availabilities will have changed over time. Then, the
sales process will begin. The start of the sales process should ensure that the
slot being processed is indeed available (slot state is "free") before
continuing. If it is not available, the sales process will exit and the host