fix: multiple typos of different importance

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,6 +1,6 @@
 ### What does it do?
 
-### What important points reviewers should know?
+### What important points should reviewers know?
 
 ### Is there something left for follow-up PRs?
 

client/evm-tracing/src/listeners/raw.rs

@@ -196,7 +196,7 @@ impl Listener {
 				result,
 				return_value,
 			} => {
-				// StepResult is expected to be emited after a step (in a context).
+				// StepResult is expected to be emitted after a step (in a context).
 				// Only case StepResult will occur without a Step before is in a transfer
 				// transaction to a non-contract address. However it will not contain any
 				// steps and return an empty trace, so we can ignore this edge case.
@@ -310,7 +310,7 @@ impl Listener {
 					}
 				}
 			}
-			// We ignore other kinds of message if any (new ones may be added in the future).
+			// We ignore other kinds of messages if any (new ones may be added in the future).
 			#[allow(unreachable_patterns)]
 			_ => (),
 		}

client/rpc/debug/README.md

@@ -1,8 +1,8 @@
-A port crate of some of the tracing related rpc requests from the go-ethereum [debug namespace](https://geth.ethereum.org/docs/interacting-with-geth/rpc/ns-debug). Includes `debug_traceTransaction`, `debug_traceBlockByNumber` and `debug_traceBlockByHash`.
+A port crate of some of the tracing-related rpc requests from the go-ethereum [debug namespace](https://geth.ethereum.org/docs/interacting-with-geth/rpc/ns-debug). Includes `debug_traceTransaction`, `debug_traceBlockByNumber` and `debug_traceBlockByHash`.
 
 ## How tracing works in Moonbeam
 
-Runtime wasms compiled with the `tracing` evm feature will emit events related to entering/exiting substates or opcode execution. This events are used by developers or indexer services to get a granular view on an evm transaction.
+Runtime wasms compiled with the `tracing` evm feature will emit events related to entering/exiting substates or opcode execution. These events are used by developers or indexer services to get a granular view on an evm transaction.
 
 Tracing wasms for each moonbeam/river/base runtime versions live at `moonbeam-runtime-overrides` repository in github.
 
@@ -64,9 +64,9 @@ sp_api::decl_runtime_apis! {
 Substrate provides two macro attributes to do what we want: `api_version` and `changed_in`.
 
 - `api_version`: is the current version of the Api. In our case we updated it to `#[api_version(2)]`.
-- changed_in: is meant to describe for `decl_runtime_apis` macro past implementations of methods. In this case, we anotate our previous implementation with `#[changed_in(2)]`, telling the `decl_runtime_apis` macro that this is the implementation to use before version 2. In fact, this attribute will rename the method name for the trait in the client side to `METHOD_before_version_VERSION`, so `trace_transaction_before_version_2` in our example.
+- changed_in: is meant to describe for `decl_runtime_apis` macro past implementations of methods. In this case, we annotate our previous implementation with `#[changed_in(2)]`, telling the `decl_runtime_apis` macro that this is the implementation to use before version 2. In fact, this attribute will rename the method name for the trait in the client side to `METHOD_before_version_VERSION`, so `trace_transaction_before_version_2` in our example.
 
-The un-anotated method is considered the default implemetation, and holds the current `trace_transaction` signature, with the new header argument and the empty result.
+The un-annotated method is considered the default implementation, and holds the current `trace_transaction` signature, with the new header argument and the empty result.
 
 ### Using a versioned runtime api from the client
 

client/rpc/debug/src/lib.rs

@@ -394,7 +394,7 @@ where
 			}
 		}?;
 
-		// Get ApiRef. This handle allow to keep changes between txs in an internal buffer.
+		// Get ApiRef. This handle allows to keep changes between txs in an internal buffer.
 		let mut api = client.runtime_api();
 
 		// Enable proof recording
@@ -546,11 +546,11 @@ where
 
 	/// Replays a transaction in the Runtime at a given block height.
 	///
-	/// In order to succesfully reproduce the result of the original transaction we need a correct
+	/// In order to successfully reproduce the result of the original transaction we need a correct
 	/// state to replay over.
 	///
 	/// Substrate allows to apply extrinsics in the Runtime and thus creating an overlayed state.
-	/// This overlayed changes will live in-memory for the lifetime of the ApiRef.
+	/// These overlayed changes will live in-memory for the lifetime of the ApiRef.
 	fn handle_transaction_request(
 		client: Arc<C>,
 		backend: Arc<BE>,

client/rpc/dev/src/lib.rs

@@ -34,7 +34,7 @@ use xcm_primitives::DEFAULT_PROOF_SIZE;
 #[jsonrpsee::core::async_trait]
 pub trait DevApi {
 	/// Inject a downward xcm message - A message that comes from the relay chain.
-	/// You may provide an arbitrary message, or if you provide an emtpy byte array,
+	/// You may provide an arbitrary message, or if you provide an empty byte array,
 	/// Then a default message (DOT transfer down to ALITH) will be injected
 	#[method(name = "xcm_injectDownwardMessage")]
 	async fn inject_downward_message(&self, message: Vec<u8>) -> RpcResult<()>;
@@ -97,7 +97,7 @@ impl DevApiServer for DevRpc {
 		};
 
 		// Push the message to the shared channel where it will be queued up
-		// to be injected in to an upcoming block.
+		// to be injected into an upcoming block.
 		downward_message_channel
 			.send_async(msg)
 			.await
@@ -144,7 +144,7 @@ impl DevApiServer for DevRpc {
 		};
 
 		// Push the message to the shared channel where it will be queued up
-		// to be injected in to an upcoming block.
+		// to be injected into an upcoming block.
 		hrmp_message_channel
 			.send_async((sender, msg))
 			.await

client/rpc/trace/src/lib.rs

@@ -109,7 +109,7 @@ where
 		}
 	}
 
-	/// `trace_filter` endpoint (wrapped in the trait implementation with futures compatibilty)
+	/// `trace_filter` endpoint (wrapped in the trait implementation with futures compatibility)
 	async fn filter(self, req: FilterRequest) -> TxsTraceRes {
 		let from_block = self.block_id(req.from_block)?;
 		let to_block = self.block_id(req.to_block)?;
@@ -360,7 +360,7 @@ impl CacheRequester {
 
 /// Data stored for each block in the cache.
 /// `active_batch_count` represents the number of batches using this
-/// block. It will increase immediatly when a batch is created, but will be
+/// block. It will increase immediately when a batch is created, but will be
 /// decrease only after the batch ends and its expiration delay passes.
 /// It allows to keep the data in the cache for following requests that would use
 /// this block, which is important to handle pagination efficiently.
@@ -386,7 +386,7 @@ enum CacheBlockState {
 		#[allow(dead_code)]
 		unqueue_sender: oneshot::Sender<()>,
 	},
-	/// Tracing has completed and the result is available. No Runtime API call
+	/// Tracing has been completed and the result is available. No Runtime API call
 	/// will be needed until this block cache is removed.
 	Cached { traces: TxsTraceRes },
 }
@@ -399,7 +399,7 @@ enum BlockingTaskMessage {
 	/// the semaphore. This is used to prevent the deletion of a cache entry for a block that has
 	/// started being traced.
 	Started { block_hash: H256 },
-	/// The tracing is finished and the result is send to the main task.
+	/// The tracing is finished and the result is sent to the main task.
 	Finished {
 		block_hash: H256,
 		result: TxsTraceRes,
@@ -435,7 +435,7 @@ where
 {
 	/// Create a new cache task.
 	///
-	/// Returns a Future that needs to be added to a tokio executor, and an handle allowing to
+	/// Returns a Future that needs to be added to a tokio executor, and a handle allowing to
 	/// send requests to the task.
 	pub fn create(
 		client: Arc<C>,
@@ -468,7 +468,7 @@ where
 				None
 			};
 			// Contains the inner state of the cache task, excluding the pooled futures/channels.
-			// Having this object allow to refactor each event into its own function, simplifying
+			// Having this object allows to refactor each event into its own function, simplifying
 			// the main loop.
 			let mut inner = Self {
 				client,
@@ -541,7 +541,7 @@ where
 		self.batches.insert(self.next_batch_id, blocks.clone());
 
 		for block in blocks {
-			// The block is already in the cache, awesome !
+			// The block is already in the cache, awesome!
 			if let Some(block_cache) = self.cached_blocks.get_mut(&block) {
 				block_cache.active_batch_count += 1;
 				tracing::trace!(
@@ -563,7 +563,7 @@ where
 
 				// Spawn all block caching asynchronously.
 				// It will wait to obtain a permit, then spawn a blocking task.
-				// When the blocking task returns its result, it is send
+				// When the blocking task returns its result, it is sent
 				// thought a channel to the main task loop.
 				tokio::spawn(
 					async move {
@@ -599,7 +599,7 @@ where
 
 						tracing::trace!("Block tracing finished, sending result to main task.");
 
-						// Send response to main task.
+						// Send a response to the main task.
 						let _ = blocking_tx
 							.send(BlockingTaskMessage::Finished {
 								block_hash: block,
@@ -628,13 +628,13 @@ where
 		// Respond with the batch ID.
 		let _ = sender.send(CacheBatchId(self.next_batch_id));
 
-		// Increase batch ID for next request.
+		// Increase batch ID for the next request.
 		self.next_batch_id = self.next_batch_id.overflowing_add(1).0;
 	}
 
 	/// Handle a request to get the traces of the provided block.
-	/// - If the result is stored in the cache, it sends it immediatly.
-	/// - If the block is currently being pooled, it is added in this block cache waiting list,
+	/// - If the result is stored in the cache, it sends it immediately.
+	/// - If the block is currently being pooled, it is added to this block cache waiting list,
 	///   and all requests concerning this block will be satisfied when the tracing for this block
 	///   is finished.
 	/// - If this block is missing from the cache, it means no batch asked for it. All requested