docs: fix typos (#2193)

2026-06-24 19:31:14 +00:00 · 2023-11-07 20:11:06 +08:00
parent 295a848301
commit 4caa3d8d8e
23 changed files with 25 additions and 25 deletions
@@ -149,7 +149,7 @@ The receiver of such a message needs to request the actual payload via request/r

 This is necessary as distribution of a large payload (mega bytes) via gossip would make the network collapse and timely
 distribution of statements would no longer be possible. By using request/response it is ensured that each peer only
-transferes large data once. We only take good care to detect an overloaded peer early and immediately move on to a
+transfers large data once. We only take good care to detect an overloaded peer early and immediately move on to a
 different peer for fetching the data. This mechanism should result in a good load distribution and therefore a rather
 optimal distribution path.

@@ -3,7 +3,7 @@
 This subsystem is responsible for distributing signed statements that we have generated and forwarding statements
 generated by our peers. Received candidate receipts and statements are passed to the [Candidate Backing
 subsystem](candidate-backing.md) to handle producing local statements. On receiving
-`StatementDistributionMessage::Share`, this subsystem distributes the message across the network with redundency to
+`StatementDistributionMessage::Share`, this subsystem distributes the message across the network with redundancy to
 ensure a fast backing process.

 ## Overview
@@ -297,7 +297,7 @@ is `500ms` and above `RATE_LIMIT` is `100ms`. 1/3 of validators are malicious,
 so for 1000 this means around 330 malicious actors worst case.

 All those actors can send a message every `100ms`, that is 10 per second. This
-means at the begining of an attack they can open up around 3300 batches. Each
+means at the beginning of an attack they can open up around 3300 batches. Each
 containing two votes. So memory usage is still negligible. In reality it is even
 less, as we also demand 10 new votes to trickle in per batch in order to keep it
 alive, every `500ms`. Hence for the first second, each batch requires 20 votes
@@ -31,7 +31,7 @@ all the necessary parameters to the validation function. These are:
  * The [`ValidationData`](../../types/candidate.md#validationdata).
  * The [`PoV`](../../types/availability.md#proofofvalidity).

-The second category is for PVF pre-checking. This is primarly used by the [PVF pre-checker](pvf-prechecker.md)
+The second category is for PVF pre-checking. This is primarily used by the [PVF pre-checker](pvf-prechecker.md)
 subsystem.

 ### Determining Parameters
@@ -44,7 +44,7 @@ execution request:
 We use timeouts for both preparation and execution jobs to limit the amount of
 time they can take. As the time for a job can vary depending on the machine and
 load on the machine, this can potentially lead to disputes where some validators
-successfuly execute a PVF and others don't.
+successfully execute a PVF and others don't.

 One dispute mitigation we have in place is a more lenient timeout for
 preparation during execution than during pre-checking. The rationale is that the
@@ -24,7 +24,7 @@ relevant.
 When a PVF just becomes relevant, the subsystem will send a message to the [Candidate Validation] subsystem asking for
 the pre-check.

-Upon receving a message from the candidate-validation subsystem, the pre-checker will note down that the PVF has its
+Upon receiving a message from the candidate-validation subsystem, the pre-checker will note down that the PVF has its
 judgement and will also sign and submit a [`PvfCheckStatement`][PvfCheckStatement] via the [`submit_pvf_check_statement`
 runtime API][PVF pre-checking runtime API]. In case, a judgement was received for a PVF that is no longer in view it is
 ignored.