Typo fixes (#20)

* Update README.md

* Update README.md

I still get all of the unused warnings for both balances and system at this point when running cargo build

* Update README.md

* Update README.md

* Update README.md

* Update README.md

* Update README.md

* Update README.md

* Not sure if these are typos or not

* Update README.md

* Update proof_of_existence.rs

* Update README.md

* Update steps/33/README.md

* Update steps/29/README.md

* Update steps/17/README.md

---------

Co-authored-by: Shawn Tabrizi <[email protected]>

Author: Yung-Beef

steps/21/README.md

@@ -27,7 +27,7 @@ In our situation, you can simply call low level functions like `set_balance` bef
 Let's quickly break down the steps of executing a basic block:
 
 1. First we increment the blocknumber, since each new block will have a new blocknumber.
-2. Then we go through an execute each transaction in that block:
+2. Then we go through and execute each transaction in that block:
 	1. Each transaction for our blockchain will come from a user, thus we will increment the users nonce as we process their transaction.
 	2. Then we will attempt to execute the function they want to call, for example `transfer`.
 	3. Repeat this process for every transaction.

steps/33/README.md

@@ -16,12 +16,12 @@ pub trait Config {}
 
 Traits can contain within it two things:
 
-1. functions which must be implemented by the type
-2. associated types
+1. Functions which must be implemented by the type.
+2. Associated types.
 
 ### Custom Functions
 
-The more obvious use of traits is to define custom functions
+The more obvious use of traits is to define custom functions.
 
 Let's say we want to expose a function which returns the name of something.
 
@@ -143,7 +143,7 @@ Here we are basically saying that `Pallet` will use `Runtime` as its generic typ
 
 Phew. That was a lot.
 
-Let's practice all you have learned to create `Config` trait for your System Pallet, and then configure the pallet for the `Runtime` in `main.rs`.
+Let's practice all you have learned to create a `Config` trait for your System Pallet, and then configure the pallet for the `Runtime` in `main.rs`.
 
 1. Define the `Config` trait which will have your 3 associated types `AccountId`, `BlockNumber`, and `Nonce`.
 2. Make sure these types have their trait constraints defined in `Config`.

steps/37/README.md

@@ -12,7 +12,7 @@ Let's look at some examples.
 
 ### Trait Functions
 
-We can extend our previous example to show what trait inheritance does with functions
+We can extend our previous example to show what trait inheritance does with functions:
 
 ```rust
 pub trait GetName {
@@ -28,7 +28,7 @@ pub trait SayName: GetName {
 }
 ```
 
-Note how in the definition of `trait SayName`, we reference `GetName` after a colon. This `SayName`, your object must also implement `GetName`. Note that we could even program a "default" implementation of `get_name` by using the `Self::name()` function.
+Note how in the definition of `trait SayName`, we reference `GetName` after a colon. This `SayName`, your object, must also implement `GetName`. Note that we could even program a "default" implementation of `get_name` by using the `Self::name()` function.
 
 So when we implement these traits, it looks like:
 

steps/4/README.md

@@ -10,7 +10,7 @@ We want keep our code organized, so we will not really start building in the `ma
 
 ## Balances
 
-Pretty much every blockchain has logic handles the balances of users on that blockchain.
+Pretty much every blockchain has logic handles that the balances of users on that blockchain.
 
 This Pallet will tell you: how much balance each user has, provide functions which allow users to transfer those balances, and even some low level functions to allow your blockchain system to manipulate those balances if needed. Think for example if you want to mint new tokens which don't already exist.
 

steps/44/README.md

@@ -59,7 +59,7 @@ eprintln!(
 
 This allows you to see the block number, extrinsic number, and the error message whenever there is an extrinsic error. This can be very helpful when you have many blocks being imported each with potentially many extrinsics.
 
-To get the extrinsic number `i`, use you chain the [`enumerate()`](https://doc.rust-lang.org/std/iter/trait.Iterator.html#method.enumerate) function after the `into_iter()`.
+To get the extrinsic number `i`, chain the [`enumerate()`](https://doc.rust-lang.org/std/iter/trait.Iterator.html#method.enumerate) function after the `into_iter()`.
 
 ## Build Your Execute Block Function
 

steps/48/README.md

@@ -42,6 +42,6 @@ This panic will NOT be triggered if there is an error in an extrinsic, as we "sw
 
 Go ahead and use the `Block` type and `execute_block` function to update the logic of your `main` function.
 
-Follow the `TODO`s provided in the template to complete this step
+Follow the `TODO`s provided in the template to complete this step. Note that `execute_block` is now updating the caller's nonce for us.
 
 By the end of this step, your code should compile, test, and run successfully, all without compiler warnings!

steps/52/README.md

@@ -18,7 +18,7 @@ pub enum RuntimeCall {
 
 In this case, we have a variant `RuntimeCall::Balances`, which itself contains a type `balances::Call`. This means we can access all the calls exposed by `balances:Call` under this variant. As we create more pallets or extend our calls, this nested structure will scale very well.
 
-We call the `RuntimeCall` an "outer enum", and the `balances::Call` an "inter enum". This construction of using outer and inter enums is very common in the Polkadot SDK.
+We call the `RuntimeCall` an "outer enum", and the `balances::Call` an "inner enum". This construction of using outer and inner enums is very common in the Polkadot SDK.
 
 ## Re-Dispatching to Pallet
 

steps/57/README.md

@@ -4,7 +4,7 @@ The Proof of Existence Pallet is quite simple, so let's build out the logic need
 
 ## Get Claim
 
-Our Pallet has a simple storage map from some claim content to the owner of that claim.
+Our Pallet has a simple storage map from some claimed content to the owner of that claim.
 
 The `get_claim` function should act as a simple read function returning the `T::AccountId` of the owner, if there is any. In the case we query a claim which has no owner, we should return `None`.
 
@@ -36,8 +36,8 @@ Keeping things in the current state just makes querying for information easier.
 
 To revoke a claim, we need to check two things:
 
-1. The the claim exists.
-2. That the person who wants to revoke the claim is the owner of that claim.
+1. The claim exists.
+2. The person who wants to revoke the claim is the owner of that claim.
 
 You should be able to handle all of this logic by calling the `get_claim` function and using `ok_or` to return an error when the claim does not exist. If the claim does exist, you should be able to directly extract the owner from the state query.
 

steps/68/README.md

@@ -19,7 +19,7 @@ In order to generate the code that we want, we need to keep track of:
 
 These things are tracked with `CallDef` and `CallVariantDef`.
 
-Also, during the parsing process, we might want to check for certain consistencies in the code being parsed. In this case, we require that every callable function muse have `caller` as their first parameter with type `T::AccountId`. This should make sense to you since you have designed a number of different callable functions, and they all follow this pattern.
+Also, during the parsing process, we might want to check for certain consistencies in the code being parsed. In this case, we require that every callable function must have `caller` as their first parameter with type `T::AccountId`. This should make sense to you since you have designed a number of different callable functions, and they all follow this pattern.
 
 This checking logic is handled by `fn check_caller_arg`.