Fix Typos (#317)

docs/client.md

@@ -4,14 +4,14 @@ In the world of L2s it is a common pattern when a certain computation (e.g. stat
 - First time to get the result and return it to the user (fast execution backend)
 - Second time to generate a validity proof (slow execution backend)
 
-The primary reason for compute things twice is that we want to serve users as fast as possible, while a proper verifiable run can be run in the background for a longer time period. On top of that, sometimes we need to look ahead into the future to reduce the complexity of the verifiable program. In practice that means we pass the result of the first (fast) run as arguments of the second (slow) run.
+The primary reason for computing things twice is that we want to serve users as fast as possible, while a proper verifiable run can be run in the background for a longer time period. On top of that, sometimes we need to look ahead into the future to reduce the complexity of the verifiable program. In practice that means we pass the result of the first (fast) run as arguments of the second (slow) run.
 
 ## What is Raito
 
 Having this dual-run model in mind we can now define what Raito is.
 
 Raito is a verifiable program that in its turn validates that a given Bitcoin block is valid (full consensus validation).  
-So it does the very same checks as a Bitcoin Core node but in such a way that its possible to generate a succinct proof of a fact that a particular Bitcoin block is valid.
+So it does the very same checks as a Bitcoin Core node but in such a way that it is possible to generate a succinct proof of a fact that a particular Bitcoin block is valid.
 
 ## How to use
 

docs/utreexo.md

@@ -54,7 +54,7 @@ More specifically, stump consists of roots and the number of leaves (as we know
 
 Note that previously we had either a root or "null" for every row in the forest, but in stump we have to use a different approach to determine to which row a particular root belongs. A simple rule is if the row length is even we skip it, otherwise (odd) the root is added. Another way to see this is to look at the binary representation of the leaves number and for each "1" there should be a root in the according row.
 
-Also it's worth noting that before "null" was indicating a missing roots whereas in stump empty root just means its children are empty too.
+Also it's worth noting that before "null" was indicating missing roots whereas in stump empty root just means its children are empty too.
 
 ## Batch proof
 

packages/consensus/src/types/chain_state.cairo

@@ -1,4 +1,4 @@
-//! Chain state is a minimal subset of data required to unambiguosly
+//! Chain state is a minimal subset of data required to unambiguously
 //! define a particular blockchain starting at the genesis.
 //!
 //! Chain state alone is not enough to do full block validation, however

packages/consensus/src/types/utxo_set.cairo

@@ -1,7 +1,7 @@
 //! Unspent transaction output set contains outputs from the previous blocks
 //! that can be referenced in the transaction inputs.
 //!
-//! UTXO set is very large hence it is infeasible to pass it entirely as a program input.
+//! UTXO set is enormous hence it is infeasible to pass it entirely as a program input.
 //! Instead we provide only a subset of outputs that are:
 //!   - going to be spent in the validated blocks
 //!   - created in the previous blocks (i.e. are not spent in the same block)

packages/consensus/src/validation/transaction.cairo

@@ -109,7 +109,7 @@ fn compute_transaction_fee(
     Result::Ok(total_input_amount - total_output_amount)
 }
 
-/// Ensures than coinbase output is old enough to be spent.
+/// Ensures that coinbase output is old enough to be spent.
 fn validate_coinbase_maturity(output_height: u32, block_height: u32) -> Result<(), ByteArray> {
     if block_height < output_height + 100 {
         return Result::Err(

packages/utils/src/hash.cairo

@@ -97,7 +97,8 @@ pub impl U256IntoDigest of Into<u256, Digest> {
     }
 }
 
-/// `Into` implementation that converts a `Digest` value into a `u256` type and reverse bytes order.
+/// `Into` implementation that converts a `Digest` value into a `u256` type and reverses bytes
+/// order.
 /// `Digest` is little-endian order, while `u256` is big-endian like in explorer.
 pub impl DigestIntoU256 of Into<Digest, u256> {
     fn into(self: Digest) -> u256 {