some fixes to please cargo-spellcheck (#3550)

* some fixes to please cargo-spellcheck * some (not all) fixes for the impl guide * fix
2026-07-23 22:25:42 +00:00 · 2021-08-02 13:00:04 +02:00
parent 2cfda98aca
commit 33fe763188
24 changed files with 160 additions and 143 deletions
@@ -4,8 +4,8 @@ This section is for the node-side subsystems that lead to participation in dispu
    * Detection. Detect bad parablocks, either during candidate backing or approval checking, and initiate a dispute.
    * Participation. Participate in active disputes. When a node becomes aware of a dispute, it should recover the data for the disputed block, check the validity of the parablock, and issue a statement regarding the validity of the parablock.
    * Distribution. Validators should notify each other of active disputes and relevant statements over the network.
-    * Submission. When authoring a block, a validator should inspect the state of the parent block and provide any information about disputes that the chain needs as part of the ParaInherent. This should initialize new disputes on-chain as necessary.
-    * Fork-choice and Finality. When observing a block issuing a DisputeRollback digest in the header, that branch of the relay chain should be abandoned all the way back to the indicated block. When voting on chains in GRANDPA, no chains that contain blocks that are or have been disputed should be voted on.
+    * Submission. When authoring a block, a validator should inspect the state of the parent block and provide any information about disputes that the chain needs as part of the `ParaInherent`. This should initialize new disputes on-chain as necessary.
+    * Fork-choice and Finality. When observing a block issuing a `DisputeRollback` digest in the header, that branch of the relay chain should be abandoned all the way back to the indicated block. When voting on chains in GRANDPA, no chains that contain blocks that are or have been disputed should be voted on.

 ## Components

@@ -17,15 +17,15 @@ This component should track all statements received from all validators over som

 This is responsible for tracking and initiating disputes. Disputes will be initiated either externally by another subsystem which has identified an issue with a parablock or internally upon observing two statements which conflict with each other on the validity of a parablock.

-No more than one statement by each validator on each side of the dispute needs to be stored. That is, validators are allowed to participate on both sides of the dispute, although we won't write code to do so. Such behavior has negative EV in the runtime.
+No more than one statement by each validator on each side of the dispute needs to be stored. That is, validators are allowed to participate on both sides of the dispute, although we won't write code to do so. Such behavior has negative extractable value in the runtime.

 This will notify the dispute participation subsystem of a new dispute if the local validator has not issued any statements on the disputed candidate already.

 Locally authored statements related to disputes will be forwarded to the dispute distribution subsystem.

 This subsystem also provides two further behaviors for the interactions between disputes and fork-choice
-    - Enhancing the finality voting rule. Given description of a chain and candidates included at different heights in that chain, it returns the BlockHash corresponding to the highest BlockNumber that there are no disputes before. I expect that we will slightly change ApprovalVoting::ApprovedAncestor to return this set and then the target block to vote on will be further constrained by this function.
-    - Chain roll-backs. Whenever importing new blocks, the header should be scanned for a roll-back digest. If there is one, the chain should be rolled back according to the digest. I expect this would be implemented with a ChainApi function and possibly an ApprovalVoting function to clean up the approval voting DB.
+    - Enhancing the finality voting rule. Given description of a chain and candidates included at different heights in that chain, it returns the `BlockHash` corresponding to the highest `BlockNumber` that there are no disputes before. I expect that we will slightly change `ApprovalVoting::ApprovedAncestor` to return this set and then the target block to vote on will be further constrained by this function.
+    - Chain roll-backs. Whenever importing new blocks, the header should be scanned for a roll-back digest. If there is one, the chain should be rolled back according to the digest. I expect this would be implemented with a `ChainApi` function and possibly an `ApprovalVoting` function to clean up the approval voting DB.

 ### Dispute Participation

@@ -30,7 +30,7 @@ This design should result in a protocol that is:

 #### Disputes

-Protocol: "/polkadot/send\_dispute/1"
+Protocol: `"/polkadot/send_dispute/1"`

 Request:

@@ -86,7 +86,7 @@ enum DisputeResponse {

 #### Vote Recovery

-Protocol: "/polkadot/req\_votes/1"
+Protocol: `"/polkadot/req_votes/1"`

 ```rust
 struct IHaveVotesRequest {
@@ -246,7 +246,7 @@ even if they did:

 So this general rate limit, that we drop requests from same peers if they come
 faster than we can import the statements should not cause any problems for
-honest nodes and is in their favour.
+honest nodes and is in their favor.

 Size of `N`: The larger `N` the better we can handle distributed flood attacks
 (see previous paragraph), but we also get potentially more availability recovery
@@ -6,14 +6,14 @@ Fortunately, most of that work is handled by other subsystems; this subsystem is

 ## Protocol

-Input: [DisputeParticipationMessage][DisputeParticipationMessage]
+Input: [`DisputeParticipationMessage`][DisputeParticipationMessage]

 Output:
-  - [RuntimeApiMessage][RuntimeApiMessage]
-  - [CandidateValidationMessage][CandidateValidationMessage]
-  - [AvailabilityRecoveryMessage][AvailabilityRecoveryMessage]
-  - [AvailabilityStoreMessage][AvailabilityStoreMessage]
-  - [ChainApiMessage][ChainApiMessage]
+  - [`RuntimeApiMessage`][RuntimeApiMessage]
+  - [`CandidateValidationMessage`][CandidateValidationMessage]
+  - [`AvailabilityRecoveryMessage`][AvailabilityRecoveryMessage]
+  - [`AvailabilityStoreMessage`][AvailabilityStoreMessage]
+  - [`ChainApiMessage`][ChainApiMessage]

 ## Functionality

@@ -57,7 +57,7 @@ Conclude.

 This requires the parameters `{ candidate_receipt, candidate_hash, session, voted_indices }` as well as a choice of either `Valid` or `Invalid`.

-Invoke [`DisputeCoordinatorMessage::IssueLocalStatement`][DisputeCoordinatorMessage] with `is_valid` according to the parametrization.
+Invoke [`DisputeCoordinatorMessage::IssueLocalStatement`][DisputeCoordinatorMessage] with `is_valid` according to the parameterization,.

 [RuntimeApiMessage]: ../../types/overseer-protocol.md#runtime-api-message
 [DisputeParticipationMessage]: ../../types/overseer-protocol.md#dispute-participation-message