Fix spelling mistakes across the whole repository (#3808)

**Update:** Pushed additional changes based on the review comments. **This pull request fixes various spelling mistakes in this repository.** Most of the changes are contained in the first **3** commits: - `Fix spelling mistakes in comments and docs` - `Fix spelling mistakes in test names` - `Fix spelling mistakes in error messages, panic messages, logs and tracing` Other source code spelling mistakes are separated into individual commits for easier reviewing: - `Fix the spelling of 'authority'` - `Fix the spelling of 'REASONABLE_HEADERS_IN_JUSTIFICATION_ANCESTRY'` - `Fix the spelling of 'prev_enqueud_messages'` - `Fix the spelling of 'endpoint'` - `Fix the spelling of 'children'` - `Fix the spelling of 'PenpalSiblingSovereignAccount'` - `Fix the spelling of 'PenpalSudoAccount'` - `Fix the spelling of 'insufficient'` - `Fix the spelling of 'PalletXcmExtrinsicsBenchmark'` - `Fix the spelling of 'subtracted'` - `Fix the spelling of 'CandidatePendingAvailability'` - `Fix the spelling of 'exclusive'` - `Fix the spelling of 'until'` - `Fix the spelling of 'discriminator'` - `Fix the spelling of 'nonexistent'` - `Fix the spelling of 'subsystem'` - `Fix the spelling of 'indices'` - `Fix the spelling of 'committed'` - `Fix the spelling of 'topology'` - `Fix the spelling of 'response'` - `Fix the spelling of 'beneficiary'` - `Fix the spelling of 'formatted'` - `Fix the spelling of 'UNKNOWN_PROOF_REQUEST'` - `Fix the spelling of 'succeeded'` - `Fix the spelling of 'reopened'` - `Fix the spelling of 'proposer'` - `Fix the spelling of 'InstantiationNonce'` - `Fix the spelling of 'depositor'` - `Fix the spelling of 'expiration'` - `Fix the spelling of 'phantom'` - `Fix the spelling of 'AggregatedKeyValue'` - `Fix the spelling of 'randomness'` - `Fix the spelling of 'defendant'` - `Fix the spelling of 'AquaticMammal'` - `Fix the spelling of 'transactions'` - `Fix the spelling of 'PassingTracingSubscriber'` - `Fix the spelling of 'TxSignaturePayload'` - `Fix the spelling of 'versioning'` - `Fix the spelling of 'descendant'` - `Fix the spelling of 'overridden'` - `Fix the spelling of 'network'` Let me know if this structure is adequate. **Note:** The usage of the words `Merkle`, `Merkelize`, `Merklization`, `Merkelization`, `Merkleization`, is somewhat inconsistent but I left it as it is. ~~**Note:** In some places the term `Receival` is used to refer to message reception, IMO `Reception` is the correct word here, but I left it as it is.~~ ~~**Note:** In some places the term `Overlayed` is used instead of the more acceptable version `Overlaid` but I also left it as it is.~~ ~~**Note:** In some places the term `Applyable` is used instead of the correct version `Applicable` but I also left it as it is.~~ **Note:** Some usage of British vs American english e.g. `judgement` vs `judgment`, `initialise` vs `initialize`, `optimise` vs `optimize` etc. are both present in different places, but I suppose that's understandable given the number of contributors. ~~**Note:** There is a spelling mistake in `.github/CODEOWNERS` but it triggers errors in CI when I make changes to it, so I left it as it is.~~
2026-06-16 13:11:15 +00:00 · 2024-03-26 13:57:57 +00:00
parent b839c995c0
commit 002d9260f9
463 changed files with 1119 additions and 1017 deletions
@@ -74,7 +74,7 @@ The set of validators eligible to vote consists of the validators that had duty
 votes by the backing validators.

 If a validator receives an initial dispute message (a set of votes where there are at least two opposing votes
-contained), and the PoV or Code are hence not reconstructable from local storage, that validator must request the
+contained), and the PoV or Code are hence not reconstructible from local storage, that validator must request the
 required data from its peers.

 The dispute availability message must contain code, persisted validation data, and the proof of validity.
@@ -101,7 +101,7 @@ struct State {
 }

 enum MessageFingerprint {
-  Assigment(Hash, u32, ValidatorIndex),
+  Assignment(Hash, u32, ValidatorIndex),
  Approval(Hash, u32, ValidatorIndex),
 }

@@ -203,7 +203,7 @@ For all peers:
  * Compute `view_intersection` as the intersection of the peer's view blocks with the hashes of the new blocks.
  * Invoke `unify_with_peer(peer, view_intersection)`.

-#### `ApprovalDistributionMessage::DistributeAsignment`
+#### `ApprovalDistributionMessage::DistributeAssignment`

 Call `import_and_circulate_assignment` with `MessageSource::Local`.

@@ -115,7 +115,7 @@ On `Conclude`, shut down the subsystem.

 Launch the source as a background task running `run(recovery_task)`.

-#### `run(recovery_task) -> Result<AvailableData, RecoeryError>`
+#### `run(recovery_task) -> Result<AvailableData, RecoveryError>`

 ```rust
 // How many parallel requests to have going at once.
@@ -76,7 +76,7 @@ dispute is raised reconsider their vote and send an explicit invalid vote. If th
 recorded, then they could avoid a slash.

 This is not a problem for our basic security assumptions: The backers are the ones to be supposed to have skin in the
-game, so we are not too woried about colluding approval voters getting away slash free as the gambler's ruin property is
+game, so we are not too worried about colluding approval voters getting away slash free as the gambler's ruin property is
 maintained anyway. There is however a separate problem, from colluding approval-voters, that is "lazy" approval voters.
 If it were easy and reliable for approval-voters to reconsider their vote, in case of an actual dispute, then they don't
 have a direct incentive (apart from playing a part in securing the network) to properly run the validation function at
@@ -331,13 +331,13 @@ off-chain. The reason for this is a dispute can be raised for a candidate in a p
 validator that is going to be slashed for it might not even be in the current active set. That means it can't be
 disabled on-chain. We need a way to prevent someone from disputing all valid candidates in the previous era. We do this
 by keeping track of the validators who lost a dispute in the past few sessions and use that list in addition to the
-on-chain disabled validators state. In addition to past session misbehavior, this also heps in case a slash is delayed.
+on-chain disabled validators state. In addition to past session misbehavior, this also helps in case a slash is delayed.

 When we receive a dispute statements set, we do the following:
 1. Take the on-chain state of disabled validators at the relay parent block.
 1. Take a list of those who lost a dispute in that session in the order that prioritizes the biggest and newest offence.
 1. Combine the two lists and take the first byzantine threshold validators from it.
-1. If the dispute is unconfimed, check if all votes against the candidate are from disabled validators.
+1. If the dispute is unconfirmed, check if all votes against the candidate are from disabled validators.
 If so, we don't participate in the dispute, but record the votes.

 ### Backing Votes
@@ -591,7 +591,7 @@ Initiates processing via the `Participation` module and updates the internal sta

 ### On `MuxedMessage::Participation`

-This message is sent from `Participatuion` module and indicates a processed dispute participation. It's the result of
+This message is sent from `Participation` module and indicates a processed dispute participation. It's the result of
 the processing job initiated with `OverseerSignal::ActiveLeaves`. The subsystem issues a `DisputeMessage` with the
 result.

@@ -108,11 +108,11 @@ way that the receiving subsystem can further address the communication to one of
 This communication prevents a certain class of race conditions. When the Overseer determines that it is time for
 subsystems to begin working on top of a particular relay-parent, it will dispatch a `ActiveLeavesUpdate` message to all
 subsystems to do so, and those messages will be handled asynchronously by those subsystems. Some subsystems will receive
-those messsages before others, and it is important that a message sent by subsystem A after receiving
+those messages before others, and it is important that a message sent by subsystem A after receiving
 `ActiveLeavesUpdate` message will arrive at subsystem B after its `ActiveLeavesUpdate` message. If subsystem A
 maintained an independent channel with subsystem B to communicate, it would be possible for subsystem B to handle the
 side message before the `ActiveLeavesUpdate` message, but it wouldn't have any logical course of action to take with the
-side message - leading to it being discarded or improperly handled. Well-architectured state machines should have a
+side message - leading to it being discarded or improperly handled. Well-architected state machines should have a
 single source of inputs, so that is what we do here.

 One exception is reasonable to make for responses to requests. A request should be made via the overseer in order to
@@ -8,7 +8,7 @@ pre-checking. Head over to [overview] for the PVF pre-checking process overview.
 There is no dedicated input mechanism for PVF pre-checker. Instead, PVF pre-checker looks on the `ActiveLeavesUpdate`
 event stream for work.

-This subsytem does not produce any output messages either. The subsystem will, however, send messages to the
+This subsystem does not produce any output messages either. The subsystem will, however, send messages to the
 [Runtime API] subsystem to query for the pending PVFs and to submit votes. In addition to that, it will also
 communicate with [Candidate Validation] Subsystem to request PVF pre-check.

@@ -89,7 +89,7 @@ struct SessionChangeNotification {
 prev_config: HostConfiguration,
 // The configuration after handling the session change.
 new_config: HostConfiguration,
- // A secure randomn seed for the session, gathered from BABE.
+ // A secure random seed for the session, gathered from BABE.
 random_seed: [u8; 32],
 // The session index of the beginning session.
 session_index: SessionIndex,
@@ -62,7 +62,7 @@ HRMP related storage layout
 HrmpOpenChannelRequests: map HrmpChannelId => Option<HrmpOpenChannelRequest>;
 HrmpOpenChannelRequestsList: Vec<HrmpChannelId>;

-/// This mapping tracks how many open channel requests are inititated by a given sender para.
+/// This mapping tracks how many open channel requests are initiated by a given sender para.
 /// Invariant: `HrmpOpenChannelRequests` should contain the same number of items that has `(X, _)`
 /// as the number of `HrmpOpenChannelRequestCount` for `X`.
 HrmpOpenChannelRequestCount: map ParaId => u32;
@@ -233,7 +233,7 @@ executed the message.
    1. Send a downward message to the opposite party notifying about the channel closing.
        * The DM is sent using `queue_downward_message`.
        * The DM is represented by the `HrmpChannelClosing` XCM message with:
-            * `initator` is set to `origin`,
+            * `initiator` is set to `origin`,
            * `sender` is set to `ch.sender`,
            * `recipient` is set to `ch.recipient`.
        * The opposite party is `ch.sender` if `origin` is `ch.recipient` and `ch.recipient` if `origin` is `ch.sender`.
@@ -88,7 +88,7 @@ to `sanitize_bitfields` function for implementation details.
 Backed candidates sanitization removes malformed ones, candidates which have got concluded invalid disputes against them
 or candidates produced by unassigned cores. Furthermore any backing votes from disabled validators for a candidate are
 dropped. This is part of the validator disabling strategy. After filtering the statements from disabled validators a
-backed candidate may end up with votes count less than `minimum_backing_votes` (a parameter from `HostConfiguiration`).
+backed candidate may end up with votes count less than `minimum_backing_votes` (a parameter from `HostConfiguration`).
 In this case the whole candidate is dropped otherwise it will be rejected by `process_candidates` from pallet inclusion.
 All checks related to backed candidates are implemented in `sanitize_backed_candidates` and
 `filter_backed_statements_from_disabled_validators`.
@@ -39,7 +39,7 @@ enum AssignmentCertKindV2 {
        /// The core index chosen in this cert.
        core_index: CoreIndex,
    },
-    /// Deprectated assignment. Soon to be removed.
+    /// Deprecated assignment. Soon to be removed.
    ///  
    /// An assignment story based on the VRF that authorized the relay-chain block where the
    /// candidate was included combined with a sample number.
@@ -117,7 +117,7 @@ struct IndirectSignedApprovalVote {
 ## `CheckedAssignmentCert`

 An assignment cert which has checked both the VRF and the validity of the implied assignment according to the selection
-criteria rules of the protocol. This type should be declared in such a way as to be instantiatable only when the checks
+criteria rules of the protocol. This type should be declared in such a way as to be instantiable only when the checks
 have actually been done. Fields should be accessible via getters, not direct struct access.

 ```rust
@@ -82,7 +82,7 @@ struct DisputeState {
 struct ScrapedOnChainVotes {
    /// The session index at which the block was included.
    session: SessionIndex,
-    /// The backing and seconding validity attestations for all candidates, provigind the full candidate receipt.
+    /// The backing and seconding validity attestations for all candidates, providing the full candidate receipt.
    backing_validators_per_candidate: Vec<(CandidateReceipt<H>, Vec<(ValidatorIndex, ValidityAttestation)>)>
    /// Set of concluded disputes that were recorded
    /// on chain within the inherent.
@@ -22,7 +22,7 @@ All subsystems have their own message types; all of them need to be able to list
 are currently two proposals for how to handle that with unified communication channels:

 1. Retaining the `OverseerSignal` definition above, add `enum FromOrchestra<T> {Signal(OverseerSignal), Message(T)}`.
-1. Add a generic varint to `OverseerSignal`: `Message(T)`.
+1. Add a generic variant to `OverseerSignal`: `Message(T)`.

 Either way, there will be some top-level type encapsulating messages from the overseer to each subsystem.