Fix typos (#2493)

fix typos

MBIPS/MBIP-2.md

@@ -87,7 +87,7 @@ interact with a smart contract that is increasing the state storage size.
 
 A possible attack from a bad actor could be done by tricking a user to send a transaction to a smart contract which would trigger many CREATE to drain the user account into the deposit that the user won't be able to retrieve. (see [Addition 3](#addition-1---deposit-from-the-value) for a possible solution)
 
-Additionally some people might gamble that the deposit storage ratio (GLMR/bytes) will increase in the future and start to store more data on-chain in the hope to "resell" that storage in the future. However it is very unlikely for the storage to increase as the cost of storage becomes cheaper overtime.
+Additionally some people might gamble that the deposit storage ratio (GLMR/bytes) will increase in the future and start to store more data on-chain in the hope to "resell" that storage in the future. However it is very unlikely for the storage to increase as the cost of storage becomes cheaper over time.
 
 ## Addition 1 - Deposit from the "Value"
 

MBIPS/MBIP-3.md

@@ -28,7 +28,7 @@ In order to avoid impacting the gas price, a distinct mechanism is proposed.
 Users **CAN** send tokens to any address "rent deposit".
 
 The destination address **MUST** have sufficient "rent deposit"
-for a Smart Contract to be deployed. The sufficient amount correspond to 1 year of rent
+for a Smart Contract to be deployed. The sufficient amount corresponds to 1 year of rent
 based on the size of the contract plus initial storage data.
 
 Executing a transaction **MUST** burn part of the "rent deposit"

MBIPS/MBIP-4.md

@@ -63,7 +63,7 @@ given:
 
 ### `gasBaseFee`
 
-The `gasBaseFee` is the same as the `baseFee` defined before this MBIP. It simply represent the cost
+The `gasBaseFee` is the same as the `baseFee` defined before this MBIP. It simply represents the cost
 of executing 1 gas.
 
 ### Transaction payment

MBIPS/MBIP-5.md

@@ -9,12 +9,12 @@ created: 2023-05-11
 
 ## Simple Summary
 
-Increases the used gas based on storage increase in transaction to deal wiuth storage congestion.
+Increases the used gas based on storage increase in transaction to deal with storage congestion.
 
 ## Abstract
 
 Introduce a new mechanism when executing a transaction that will increase the gas used when
-a transaction increases the storate stage.
+a transaction increases the storage stage.
 
 ## Motivation
 
@@ -38,7 +38,7 @@ possible to `25% * 40kB * 2628000 blocks => 26.2GB`
 Deploying a Smart Contract of 24kB using 3_300_000 gas would require:  
 `24_000 * 15_000_000 / 40_000 + 3_300_000 => 12_300_000 gas`
 
-Execution a transaction using 48_000 gas and adding 3 storage items (444 bytes) would require:  
+Execution of a transaction using 48_000 gas and adding 3 storage items (444 bytes) would require:  
 `444 * 15_000_000 / 40_000 + 48_000 => 214_500 gas`
 
 ## Impact

MBIPS/MBIP-6.md

@@ -13,12 +13,12 @@ gasometer and how parachains are required to provide state transition proofs.
 
 ## Motivation
 
-Proof-of-validity (POV) size is a concept native to Polkadot parachains. In order to proof that the
+Proof-of-validity (POV) size is a concept native to Polkadot parachains. In order to prove that the
 state transition of a parachain block is valid, the relay chain needs a merkle proof: a partial
-state containing only the required to data to execute all the extrinsics included in the parachain
+state containing only the required data to execute all the extrinsics included in the parachain
 block.
 
-Because there is a target relay block time and the POV has to be transfered between
+Because there is a target relay block time and the POV has to be transferred between
 collators and validators, the POV size must be restricted to a certain amount, currently measured
 to be 5MB. That's why Moonbeam is soon to introduce POV metering, so POV consumption can be measured
 within the EVM execution, correctly accounting for this block space metric and satisfy the relay
@@ -101,12 +101,12 @@ substantial difference on how refunds work in Moonbeam vs. Ethereum and, in some
 assumptions done purely on what the cost is supposed to be metered by the traditional gasometer when
 successfully exiting the EVM:
 
-- Prior to execution: the need of providing a `gas_limit` that is enough to pay for whaveter the most
+- Prior to execution: the need of providing a `gas_limit` that is enough to pay for whatever the most
   used metric will be during the EVM execution.
 - After the execution: the refund will be calculated over the most used metric on exiting the EVM.
 
 ## Security Considerations
 
 This is a necessary security-related change in any EVM-compatible parachain. If not
 introduced, it opens up for spam vectors like being able to abuse block space and even filling
-full blocks worth of POV for a fraction of a cost.
+full blocks worth of POV for a fraction of the cost.

PERF.md

@@ -11,8 +11,8 @@ In addition to `perf` itself, some tools like [speedscope](https://github.com/jl
 
 # Configuring moonbeam
 
-Moonbeam node built with `--release`, contains enough symbols to have meanigful report for perf.
-However it is suggest to also combine the build with additional frame pointers in order to capture the full stack:
+Moonbeam node built with `--release`, contains enough symbols to have meaningful report for perf.
+However it is suggested to also combine the build with additional frame pointers in order to capture the full stack:
 
 ```
 RUSTFLAGS="-C force-frame-pointers=yes" cargo build --release
@@ -114,7 +114,7 @@ You can also use the following command to retrieve all the threads of execute_in
 perf script --no-inline | awk -v RS='' '/execute_in_transaction/' | grep ' cycles:u:' | tr -s ' ' | sed 's/^[ \t]*//' | cut -d' ' -f2 | sort | uniq
 ```
 
-(Each thread is a different execution, except in dev mode. So if for exemple your node imported 3 blocks during the recording,
+(Each thread is a different execution, except in dev mode. So if for example your node imported 3 blocks during the recording,
 it will have 3 threads. You can select the one you want for a specific block based on the order)
 
 Finally, export the data (with my example):
@@ -166,7 +166,7 @@ You can generate the load in many different way, ex: sending a bunch of request
 
 At this point you should have a `perf.data` file (and a `jit-xxxx.dump` if you used jitdump), follow the `Generating script for speedscope` part.
 
-## Exemple of debugging a wasm block production of a typescript-test
+## Example of debugging a wasm block production of a typescript-test
 
 1. Compile the node
 

docs/git-branches-conventions.md

@@ -21,7 +21,7 @@ too many branches.
 
 ## Releases branches
 
-This kind of branch shoud be named `perm-TAG`, where `TAG` is the git tag of the corresponding
+This kind of branch should be named `perm-TAG`, where `TAG` is the git tag of the corresponding
 release.
 
 ## Hotfix workflow

docs/workspace-dependencies.md

@@ -5,7 +5,7 @@
 Features listed in the root-level `Cargo.toml` and in individual crates `Cargo.toml` are additive
 (union of all sets of features). Also note that features may be enabled by other crates built to the
 same target (wasm vs client have distinct feature sets however). Features listed in the root-level
-`Cargo.toml` are enabled for all targets (hense the need for `default-features = false` for crates
+`Cargo.toml` are enabled for all targets (hence the need for `default-features = false` for crates
 used in a runtime crate.
 
 Prefer adding features in individual crates, unless it is a security flag feature like
@@ -16,12 +16,12 @@ Note that `default-features = false` only have an effect inside the root-level C
 should be added to any dependency that defaults to std if it is used in at least one runtime/wasm
 crate.
 
-## How to add a dependency ?
+## How to add a dependency?
 1. Add `my-dependency = { workspace = true }` in your crate.
 2. Look at the root-level `Cargo.toml` to see if the dependency is listed in it :
   - If it is not, add it in the proper section (Substrate/Frontier/etc) and subsection
     (wasm/client). Don't forget to add `default-features = false` if in wasm if necessary.
   - If it is, make sure it respects the std rule. If your crate is a runtime crate and the
     dependency was previously only used outside of the runtime, move the dependency in the "wasm"
     section and add `default-features = false`. It may require adding `features = ["std"]` in
-    non-runtime crates `Cargo.toml`, however it is not necessary most of the time.
+    non-runtime crates `Cargo.toml`, however it is not necessary most of the time.

pallets/ethereum-xcm/Cargo.toml

@@ -1,7 +1,7 @@
 [package]
 name = "pallet-ethereum-xcm"
 authors = [ "Parity Technologies <admin@parity.io>" ]
-description = "Xcm Transact compatibility for pallet-etherum."
+description = "Xcm Transact compatibility for pallet-ethereum."
 edition = "2021"
 license = "Apache-2.0"
 repository = "https://github.com/moonbeam-foundation/moonbeam/"