Fix typos (#1878)

2026-04-26 05:17:58 +00:00 · 2023-10-16 16:01:01 +08:00
parent 91c4360c3c
commit 19f38ca3aa
4 changed files with 9 additions and 9 deletions
@@ -579,7 +579,7 @@ fn follow_new_best_sets_best_after_it_is_imported() {
 		block_import_params.fork_choice = Some(ForkChoiceStrategy::Custom(false));
 		block_import_params.body = Some(body);

-		// Now import the unkown block to make it "known"
+		// Now import the unknown block to make it "known"
 		client.import_block(block_import_params).await.unwrap();

 		loop {
@@ -41,7 +41,7 @@ pub type RelayChainResult<T> = Result<T, RelayChainError>;

 #[derive(thiserror::Error, Debug)]
 pub enum RelayChainError {
-	#[error("Error occured while calling relay chain runtime: {0}")]
+	#[error("Error occurred while calling relay chain runtime: {0}")]
 	ApiError(#[from] ApiError),
 	#[error("Timeout while waiting for relay-chain block `{0}` to be imported.")]
 	WaitTimeout(PHash),
@@ -53,7 +53,7 @@ pub enum RelayChainError {
 	WaitBlockchainError(PHash, sp_blockchain::Error),
 	#[error("Blockchain returned an error: {0}")]
 	BlockchainError(#[from] sp_blockchain::Error),
-	#[error("State machine error occured: {0}")]
+	#[error("State machine error occurred: {0}")]
 	StateMachineError(Box<dyn sp_state_machine::Error>),
 	#[error("Unable to call RPC method '{0}'")]
 	RpcCallError(String),
@@ -67,7 +67,7 @@ pub enum RelayChainError {
 	Application(#[from] Box<dyn std::error::Error + Send + Sync + 'static>),
 	#[error("Prometheus error: {0}")]
 	PrometheusError(#[from] PrometheusError),
-	#[error("Unspecified error occured: {0}")]
+	#[error("Unspecified error occurred: {0}")]
 	GenericError(String),
 }

@@ -48,7 +48,7 @@ const MAX_SUBSCRIPTIONS: u32 = 64;

 #[derive(thiserror::Error, Debug)]
 enum LightClientError {
-	#[error("Error occured while executing smoldot request: {0}")]
+	#[error("Error occurred while executing smoldot request: {0}")]
 	SmoldotError(String),
 	#[error("Nothing returned from json_rpc_responses")]
 	EmptyResult,
@@ -79,7 +79,7 @@ game, so we are not too woried about colluding approval voters getting away slas
 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
-all - they could just always vote "valid" totally risk free. (While they would alwasy risk a slash by voting invalid.)
+all - they could just always vote "valid" totally risk free. (While they would always risk a slash by voting invalid.)


 So we do want to fetch approval votes from approval-voting. Importing votes is most efficient when batched. At the same
@@ -125,7 +125,7 @@ moment the dispute concludes! Two concerns that come to mind, are easily address
   enough: We are worried about lazy approval checkers, the system does not need to be perfect. It should be enough if
   there is some risk of getting caught.
 2. We are not worried about the dispute not concluding, as nodes will always send their own vote, regardless of it being
-   an explict or an already existing approval-vote.
+   an explicit or an already existing approval-vote.

 Conclusion: As long as we make sure, if our own approval vote gets imported (which would prevent dispute participation)
 to also distribute it via dispute-distribution, disputes can conclude. To mitigate raciness with approval-voting
@@ -307,7 +307,7 @@ spam, then spam slots for the disputed candidate hash are cleared. This decremen
 which had voted invalid.

 To keep spam slots from filling up unnecessarily we want to clear spam slots whenever a candidate is seen to be backed
-or included. Fortunately this behavior is acheived by clearing slots on vote import as described above. Because on chain
+or included. Fortunately this behavior is achieved by clearing slots on vote import as described above. Because on chain
 backing votes are processed when a block backing the disputed candidate is discovered, spam slots are cleared for every
 backed candidate. Included candidates have also been seen as backed on the same fork, so decrementing spam slots is
 handled in that case as well.
@@ -422,7 +422,7 @@ from them, so they would be an easy DoS target.

 In summary: The availability system was designed for raising disputes in a meaningful and secure way after availability
 was reached. Trying to raise disputes before does not meaningfully contribute to the systems security/might even weaken
-it as attackers are warned before availability is reached, while at the same time adding signficant amount of
+it as attackers are warned before availability is reached, while at the same time adding significant amount of
 complexity. We therefore punt on such disputes and concentrate on disputes the system was designed to handle.

 ### No Disputes for Already Finalized Blocks