docs: fix typos (#2193)

polkadot/roadmap/implementers-guide/src/disputes-flow.md

@@ -52,7 +52,7 @@ stateDiagram-v2
     IncomingRequestDisputeAvailabilityData --> RespondUnavailable
     IncomingRequestDisputeAvailabilityData --> DisputeDataAvail
     DisputeDataAvail --> RespondWithDisputeAvailabilityData: Send
-    VoteGossipReceived --> Track: implies source peer has<br />dispute availablity data
+    VoteGossipReceived --> Track: implies source peer has<br />dispute availability data
 ```
 
 ---

polkadot/roadmap/implementers-guide/src/node/backing/statement-distribution-legacy.md

@@ -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.
 

polkadot/roadmap/implementers-guide/src/node/backing/statement-distribution.md

@@ -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

polkadot/roadmap/implementers-guide/src/node/disputes/dispute-distribution.md

@@ -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

polkadot/roadmap/implementers-guide/src/node/utility/candidate-validation.md

@@ -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

polkadot/roadmap/implementers-guide/src/node/utility/pvf-host-and-workers.md

@@ -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

polkadot/roadmap/implementers-guide/src/node/utility/pvf-prechecker.md

@@ -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.

polkadot/roadmap/implementers-guide/src/protocol-approval.md

@@ -330,7 +330,7 @@ We prefer doing approval checkers assignments under `RelayVRFModulo` or `RelayVR
 assignments benefit security the most.  We suggest assigning at least 16 checkers under `RelayVRFModulo` or
 `RelayVRFModuloCompact` although assignment levels have never been properly analyzed.
 
-Our delay criteria `RelayVRFDelay` and `RelayEquivocation` both have two primary paramaters, expected checkers per
+Our delay criteria `RelayVRFDelay` and `RelayEquivocation` both have two primary parameters, expected checkers per
 tranche and the zeroth delay tranche width.
 
 We require expected checkers per tranche to be less than three because otherwise an adversary with 1/3 stake could force

polkadot/roadmap/implementers-guide/src/runtime/hrmp.md

@@ -108,7 +108,7 @@ HrmpEgressChannelsIndex: map ParaId => Vec<ParaId>;
 /// Invariant: cannot be non-empty if the corresponding channel in `HrmpChannels` is `None`.
 HrmpChannelContents: map HrmpChannelId => Vec<InboundHrmpMessage>;
 /// Maintains a mapping that can be used to answer the question:
-/// What paras sent a message at the given block number for a given reciever.
+/// What paras sent a message at the given block number for a given receiver.
 /// Invariants:
 /// - The inner `Vec<ParaId>` is never empty.
 /// - The inner `Vec<ParaId>` cannot store two same `ParaId`.

polkadot/roadmap/implementers-guide/src/runtime/inclusion.md

@@ -133,7 +133,7 @@ All failed checks should lead to an unrecoverable error making the block invalid
      [`UpwardMessage`s](../types/messages.md#upward-message) from the
      [`CandidateCommitments`](../types/candidate.md#candidate-commitments).
   1. call `Dmp::prune_dmq` with the para id of the candidate and the candidate's `processed_downward_messages`.
-  1. call `Hrmp::prune_hrmp` with the para id of the candiate and the candidate's `hrmp_watermark`.
+  1. call `Hrmp::prune_hrmp` with the para id of the candidate and the candidate's `hrmp_watermark`.
   1. call `Hrmp::queue_outbound_hrmp` with the para id of the candidate and the list of horizontal messages taken from
      the commitment,
   1. Call `Paras::note_new_head` using the `HeadData` from the receipt and `relay_parent_number`.

polkadot/roadmap/implementers-guide/src/runtime/paras.md

@@ -189,7 +189,7 @@ UpgradeGoAheadSignal: map hasher(twox_64_concat) ParaId => Option<UpgradeGoAhead
 /// an upgrade for this parachain.
 ///
 /// This may be a because the parachain waits for the upgrade cooldown to expire. Another
-/// potential use case is when we want to perform some maintanance (such as storage migration)
+/// potential use case is when we want to perform some maintenance (such as storage migration)
 /// we could restrict upgrades to make the process simpler.
 ///
 /// NOTE that this field is used by parachains via merkle storage proofs, therefore changing

polkadot/roadmap/implementers-guide/src/runtime/scheduler.md

@@ -263,7 +263,7 @@ No finalization routine runs for this module.
     `Paras::parachains().len()` to it.
   - `next_core` is then updated by adding 1 and taking it modulo `config.parathread_cores`.
   - The claim is then added to the claim index.
-- `free_cores(Vec<(CoreIndex, FreedReason)>)`: indicate previosuly-occupied cores which are to be considered returned
+- `free_cores(Vec<(CoreIndex, FreedReason)>)`: indicate previously-occupied cores which are to be considered returned
   and why they are being returned.
   - All freed lease holding parachain cores should be assigned to their respective parachain
   - All freed on-demand parachain cores whose reason for freeing was `FreedReason::Concluded` should have the claim

polkadot/roadmap/implementers-guide/src/types/backing.md

@@ -30,7 +30,7 @@ work, we extract a signed wrapper.
 ```rust,ignore
 /// A signed type which encapsulates the common desire to sign some data and validate a signature.
 ///
-/// Note that the internal fields are not public; they are all accessable by immutable getters.
+/// Note that the internal fields are not public; they are all accessible by immutable getters.
 /// This reduces the chance that they are accidentally mutated, invalidating the signature.
 struct Signed<Payload, RealPayload=Payload> {
     /// The payload is part of the signed data. The rest is the signing context,