From f0c0d5bb384866953a3be7a80812e9392c828115 Mon Sep 17 00:00:00 2001 From: xiaolou86 <20718693+xiaolou86@users.noreply.github.com> Date: Tue, 24 Oct 2023 10:26:29 +0800 Subject: [PATCH] docs: fix typos --- design/marketplace.md | 2 +- design/proof-erasure-coding.md | 4 ++-- design/sales.md | 4 ++-- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/design/marketplace.md b/design/marketplace.md index 4ca2345..1b64cc3 100644 --- a/design/marketplace.md +++ b/design/marketplace.md @@ -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 diff --git a/design/proof-erasure-coding.md b/design/proof-erasure-coding.md index 0032902..b7947eb 100644 --- a/design/proof-erasure-coding.md +++ b/design/proof-erasure-coding.md @@ -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 diff --git a/design/sales.md b/design/sales.md index b4891eb..3fe9d76 100644 --- a/design/sales.md +++ b/design/sales.md @@ -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