chore: delete repeat words (#7034)

Co-authored-by: Dónal Murray <[email protected]>

Author: taozui472

polkadot/primitives/src/v8/mod.rs

@@ -1900,7 +1900,7 @@ pub struct SessionInfo {
 	/// participating in parachain consensus. See
 	/// [`max_validators`](https://github.com/paritytech/polkadot/blob/a52dca2be7840b23c19c153cf7e110b1e3e475f8/runtime/parachains/src/configuration.rs#L148).
 	///
-	/// `SessionInfo::validators` will be limited to to `max_validators` when set.
+	/// `SessionInfo::validators` will be limited to `max_validators` when set.
 	pub validators: IndexedVec<ValidatorIndex, ValidatorId>,
 	/// Validators' authority discovery keys for the session in canonical ordering.
 	///

polkadot/roadmap/implementers-guide/src/architecture.md

@@ -93,7 +93,7 @@ Runtime logic is divided up into Modules and APIs. Modules encapsulate particula
 consist of storage, routines, and entry-points. Routines are invoked by entry points, by other modules, upon block
 initialization or closing. Routines can read and alter the storage of the module. Entry-points are the means by which
 new information is introduced to a module and can limit the origins (user, root, parachain) that they accept being
-called by. Each block in the blockchain contains a set of Extrinsics. Each extrinsic targets a a specific entry point to
+called by. Each block in the blockchain contains a set of Extrinsics. Each extrinsic targets a specific entry point to
 trigger and which data should be passed to it. Runtime APIs provide a means for Node-side behavior to extract meaningful
 information from the state of a single fork.
 

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

@@ -84,7 +84,7 @@ slashing risk for validator operators.
 
 In future, we shall determine which among the several hardening techniques best benefits the network as a whole.  We
 could provide a multi-process multi-machine architecture for validators, perhaps even reminiscent of GNUNet, or perhaps
-more resembling smart HSM tooling.  We might instead design a system that more resembled full systems, like like Cosmos'
+more resembling smart HSM tooling.  We might instead design a system that more resembled full systems, like Cosmos'
 sentry nodes.  In either case, approval assignments might be handled by a slightly hardened machine, but not necessarily
 nearly as hardened as approval votes, but approval votes machines must similarly run foreign WASM code, which increases
 their risk, so assignments being separate sounds helpful.

polkadot/roadmap/implementers-guide/src/protocol-validator-disabling.md

@@ -111,7 +111,7 @@ checking (% for 30-ish malicious in a row).
 There are also censorship or liveness issues if backing is suddenly dominated by malicious nodes but in general even if
 some honest blocks get backed liveness should be preserved.
 
-> **Note:** It is worth noting that is is fundamentally a defense in depth strategy because if we assume disputes are
+> **Note:** It is worth noting that is fundamentally a defense in depth strategy because if we assume disputes are
 > perfect it should not be a real concern. In reality disputes and determinism are difficult to get right, and
 > non-determinism and happen so defense in depth is crucial when handling those subsystems.
 

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

@@ -16,7 +16,7 @@ struct SessionInfo {
     /// in parachain consensus. See
     /// [`max_validators`](https://github.com/paritytech/polkadot/blob/a52dca2be7840b23c19c153cf7e110b1e3e475f8/runtime/parachains/src/configuration.rs#L148).
     ///
-    /// `SessionInfo::validators` will be limited to to `max_validators` when set.
+    /// `SessionInfo::validators` will be limited to `max_validators` when set.
     validators: Vec<ValidatorId>,
     /// Validators' authority discovery keys for the session in canonical ordering.
     ///

substrate/client/network/README.md

@@ -261,7 +261,7 @@ data. I.e. it is unable to serve bock bodies and headers other than the most rec
 nodes have block history available, a background sync process is started that downloads all the missing blocks.
 It is run in parallel with the keep-up sync and does not interfere with downloading of the recent blocks.
 During this download we also import GRANDPA justifications for blocks with authority set changes, so that
-the warp-synced node has all the data to serve for other nodes nodes that might want to sync from it with
+the warp-synced node has all the data to serve for other nodes that might want to sync from it with
 any method.
 
 # Usage

substrate/frame/democracy/README.md

@@ -96,7 +96,7 @@ This call can only be made by the `CancellationOrigin`.
 
 This call can only be made by the `ExternalOrigin`.
 
-- `external_propose` - Schedules a proposal to become a referendum once it is is legal
+- `external_propose` - Schedules a proposal to become a referendum once it is legal
   for an externally proposed referendum.
 
 #### External Majority Origin

substrate/frame/democracy/src/lib.rs

@@ -113,7 +113,7 @@
 //!
 //! This call can only be made by the `ExternalOrigin`.
 //!
-//! - `external_propose` - Schedules a proposal to become a referendum once it is is legal for an
+//! - `external_propose` - Schedules a proposal to become a referendum once it is legal for an
 //!   externally proposed referendum.
 //!
 //! #### External Majority Origin

substrate/frame/recovery/README.md

@@ -67,7 +67,7 @@ permissionless. However, the recovery deposit is an economic deterrent that
 should disincentivize would-be attackers from trying to maliciously recover
 accounts.
 
-The recovery deposit can always be claimed by the account which is trying to
+The recovery deposit can always be claimed by the account which is trying
 to be recovered. In the case of a malicious recovery attempt, the account
 owner who still has access to their account can claim the deposit and
 essentially punish the malicious user.

substrate/frame/recovery/src/lib.rs

@@ -80,7 +80,7 @@
 //! should disincentivize would-be attackers from trying to maliciously recover
 //! accounts.
 //!
-//! The recovery deposit can always be claimed by the account which is trying to
+//! The recovery deposit can always be claimed by the account which is trying
 //! to be recovered. In the case of a malicious recovery attempt, the account
 //! owner who still has access to their account can claim the deposit and
 //! essentially punish the malicious user.