docs: fix typos (#2193)

2026-06-12 13:31:10 +00:00 · 2023-11-07 20:11:06 +08:00
parent 295a848301
commit 4caa3d8d8e
23 changed files with 25 additions and 25 deletions
@@ -2,7 +2,7 @@

 This folder contains [zombienet](https://github.com/paritytech/zombienet/) based integration tests for both
 onchain and offchain bridges code. Due to some
-[technical diffuculties](https://github.com/paritytech/parity-bridges-common/pull/2649#issue-1965339051), we
+[technical difficulties](https://github.com/paritytech/parity-bridges-common/pull/2649#issue-1965339051), we
 are using native zombienet provider, which means that you need to build some binaries locally.

 To start those tests, you need to:
@@ -8,7 +8,7 @@ Asset Hub allows users to:
 - Deploy promise-backed assets, both fungible and non-fungible, with a DOT/KSM deposit.
 - Set admin roles to manage assets and asset classes.
 - Register assets as "self-sufficient" if the Relay Chain agrees, i.e. gain the ability for an
-  asset to justify the existance of accounts sans DOT/KSM.
+  asset to justify the existence of accounts sans DOT/KSM.
 - Pay transaction fees using sufficient assets.
 - Transfer (and approve transfer) assets.
 - Interact with the chain via its transactional API or XCM.
@@ -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
 ```

 ---
@@ -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.
@@ -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
@@ -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`.
@@ -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`.
@@ -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
@@ -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
@@ -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,
@@ -74,7 +74,7 @@ The output above shows a **secret phrase** (also called **mnemonic phrase**) and
 **Private Key**). Those 2 secrets are the pieces of information you MUST keep safe and secret. All the other information
 below can be derived from those secrets.

-The output above also show the **public key** and the **Account ID**. Those are the independant from the network where
+The output above also show the **public key** and the **Account ID**. Those are the independent from the network where
 you will use the key.

 The **SS58 address** (or **Public Address**) of a new account is a reprensentation of the public keys of an account for
@@ -163,7 +163,7 @@ This time, we properly recovered `5He5pZpc7AJ8evPuab37vJF6KkFDqq9uDq2WXh877Qw6ia

 ### Inspecting a key

-If you have *some data* about a key, `subkey inpsect` will help you discover more information about it.
+If you have *some data* about a key, `subkey inspect` will help you discover more information about it.

 If you have **secrets** that you would like to verify for instance, you can use:

@@ -104,7 +104,7 @@ shortcuts:
 ## Mental Model

 BEEFY should be considered as an extra voting round done by GRANDPA validators for the current
-best finalized block. Similarily to how GRANDPA is lagging behind best produced (non-finalized)
+best finalized block. Similarly to how GRANDPA is lagging behind best produced (non-finalized)
 block, BEEFY is going to lag behind best GRANDPA (finalized) block.

 ```
@@ -302,7 +302,7 @@ periodically on the global topic. Let's now dive into description of the message

 ## Misbehavior

-Similarily to other PoS protocols, BEEFY considers casting two different votes in the same round a
+Similarly to other PoS protocols, BEEFY considers casting two different votes in the same round a
 misbehavior. I.e. for a particular `round_number`, the validator produces signatures for 2 different
 `Commitment`s and broadcasts them. This is called **equivocation**.

@@ -227,7 +227,7 @@ transactions that are prepared for block inclusion. Propagation is best
 effort, especially for block authors and is not directly incentivised.
 However the networking protocol might penalise peers that send invalid or
 useless transactions so we should be nice to others. Also see below a proposal
-to instead of gossiping everyting have other peers request transactions they
+to instead of gossiping everything have other peers request transactions they
 are interested in.

 Since the pool is expected to store more transactions than what can fit
@@ -45,7 +45,7 @@ board](https://github.com/paritytech/substrate/discussions).
 * Allow validators to block and kick their nominator set. (#7930)
 * Decouple Staking and Election - Part1: Support traits (#7908)
 * Introduces account existence providers reference counting (#7363)
-* contracts: Cap the surcharge reward by the amount of rent that way payed by a contract (#7870)
+* contracts: Cap the surcharge reward by the amount of rent that way paid by a contract (#7870)
 * Use checked math when calculating storage size (#7885)
 * Fix clear prefix check to avoid erasing child trie roots. (#7848)
 * contracts: Collect rent for the first block during deployment (#7847)
@@ -113,7 +113,7 @@ And update the overall definition for weights on frame and a few related types a
 ```diff=

 -const AVERAGE_ON_INITIALIZE_WEIGHT: Perbill = Perbill::from_percent(10);
-+/// We assume that ~10% of the block weight is consumed by `on_initalize` handlers.
+/// We assume that ~10% of the block weight is consumed by `on_initialize` handlers.
 +/// This is used to limit the maximal weight of a single extrinsic.
 +const AVERAGE_ON_INITIALIZE_RATIO: Perbill = Perbill::from_percent(10);
 +/// We allow `Normal` extrinsics to fill up the block up to 75%, the rest can be used
@@ -1,5 +1,5 @@
 # Root Testing Pallet

-Pallet that contains extrinsics that can be usefull in testing.
+Pallet that contains extrinsics that can be useful in testing.

 NOTE: This pallet should only be used for testing purposes and should not be used in production runtimes!
@@ -1,3 +1,3 @@
-Handling of blobs, typicaly validation code, which may be compressed.
+Handling of blobs, typically validation code, which may be compressed.

 License: Apache-2.0
@@ -20,5 +20,5 @@ comparing keys, not the values.
 `renamed_authorities`.


-`default_genesis_config_invalid.json` is just an imcomplete copy of
+`default_genesis_config_invalid.json` is just an incomplete copy of
 `default_genesis_config.json` with `babe::authorities` field removed.