Fix: typos (privacy-scaling-explorations#402)

* Fix: typos

* Fix: typos

* Fix: typos

* Fix: typos

* Fix: typos

* Fix: typo

* Fix: typos

Author: omahs

Diff for: specs/bytecode-proof.md

@@ -45,7 +45,7 @@ The circuit starts by adding a row that contains the bytecode length using `tag
 
 Then it runs over all the bytes of the bytecode in order starting at the byte at position `0`.
 Each following row unrolls a single byte (using `tag = Byte` and `value = the actual byte value`) of the bytecode while also storing its position
-(`index`), the code hash it's part of (`hash`), and if it is code or not
+(`index`), the code hash its part of (`hash`), and if it is code or not
 (`is_code`). Also `push_data_size` is filled to match the push table, and `push_data_left` is computed.
 
 All byte data is accumulated per byte (with one byte per row) into `value_rlc` as follows, where r is a challenge:
@@ -68,7 +68,7 @@ next.push_data_left := cur.byte_push_size if cur.is_code else cur.push_data_left
 
 The fixed columns `q_first` and `q_last` should be zero for all rows, except the first one where `q_first := 1` and the last one where `q_last := 1`.
 
-## Circuit constrains
+## Circuit constraints
 
 All circuit constraints are based on the current row (`cur`) and the `next` row.
 
@@ -100,7 +100,7 @@ This way we make sure is_code and next.push_data_left have the right values.
 
 ### cur.tag == Header and next.tag == Header
 
-We are in a transition from a empty bytecode to the begining of another bytecode that could be empty or not.
+We are in a transition from a empty bytecode to the beginning of another bytecode that could be empty or not.
 
 Hence:
 ```
@@ -110,7 +110,7 @@ assert cur.hash == EMPTY_HASH
 
 ### cur.tag == Header and next.tag == Byte
 
-We are at the begining of a non-empty bytecode.
+We are at the beginning of a non-empty bytecode.
 
 Hence:
 

Diff for: specs/copy-proof.md

@@ -34,7 +34,7 @@ First, the circuit adds common constraints that applied to every rows in the cir
     - `Address` increase by 1 in the next copy step.
 - The transition constraints for `RwCounter` and `RwcIncreaseLeft` column
     - define `rw_diff` to be 1 if the `Type` is `Memory` or `TxLog` and `Padding` is 0 in the current row; otherwise 0.
-    - when it's not the last row in a copy event (`is_last == 0`), `RwCounter` increases by `rw_diff` and `RwcIncreaseLeft` decrases by `rw_diff`.
+    - when it's not the last row in a copy event (`is_last == 0`), `RwCounter` increases by `rw_diff` and `RwcIncreaseLeft` decreases by `rw_diff`.
     - over all rows, the `rlc_acc` remains the same.
     - when it's the last row in a copy event (`is_last == 1`), `RwcIncreaseLeft` is equal to `rw_diff`.
     - when it's the last row of a copy event (`is_last == 1`) and `is_rlc_acc == 1`, the row `value` should equal the row `rlc_acc`.

Diff for: specs/evm-proof.md

@@ -2,7 +2,7 @@
 
 The EVM proof argues the transition of state trie root is valid by verifying all the included transactions in a block have correct execution results.
 
-EVM circuit re-implements the EVM, but in a perspective of verification, which means the prover can help provide hints as long as it's does not contradict the result. For example, the prover can give hints about if this call is going to revert or not, or if this opcode encounters an error or not, then the EVM circuit can verify that execution results is correct.
+EVM circuit re-implements the EVM, but in a perspective of verification, which means the prover can help provide hints as long as it does not contradict the result. For example, the prover can give hints about if this call is going to revert or not, or if this opcode encounters an error or not, then the EVM circuit can verify that execution results is correct.
 
 The included transactions in a block could be simple ether transfers, contract creations, or contract interactions, and because each transaction has variable execution trace, we can't have fixed circuit layout to verify specific logic in specific region, we instead need a chip to be able to verify all possible logics, and this chip repeats itself to fill the whole circuit.
 
@@ -24,7 +24,7 @@ We call the list of random read-write access records `BusMapping` because it act
 | Target                                | Index             | Accessible By   | Description                                                        |
 | ------------------------------------- | ----------------- | --------------- | ------------------------------------------------------------------ |
 | [`Block`](#Block)                     | `{enum}`          | `Read`          | Block constant decided before executing the block                  |
-| [`BlockHash`](#BlockHash)             | `{index}`         | `Read`          | Previous 256 block hashes as a encoded word array                  |
+| [`BlockHash`](#BlockHash)             | `{index}`         | `Read`          | Previous 256 block hashes as an encoded word array                  |
 | [`AccountNonce`](#AccountNonce)       | `{address}`       | `Read`, `Write` | Account's nonce                                                    |
 | [`AccountBalance`](#AccountBalance)   | `{address}`       | `Read`, `Write` | Account's balance                                                  |
 | [`AccountCodeHash`](#AccountCodeHash) | `{address}`       | `Read`, `Write` | Account's code hash                                                |
@@ -34,7 +34,7 @@ We call the list of random read-write access records `BusMapping` because it act
 | [`CallCalldata`](#CallCalldata)       | `{id}.{index}`    | `Read`          | Call's calldata as a byte array (only for EOA calls)               |
 | [`CallSignature`](#CallSignature)     | `{id}.{index}`    | `Read`          | Call's signature as a byte array (only for EOA calls)              |
 | [`CallState`](#CallState)             | `{id}.{enum}`     | `Read`, `Write` | Call's internal state                                              |
-| [`CallStateStack`](#CallStateStack)   | `{id}.{index}`    | `Read`, `Write` | Call's stack as a encoded word array                               |
+| [`CallStateStack`](#CallStateStack)   | `{id}.{index}`    | `Read`, `Write` | Call's stack as an encoded word array                               |
 | [`CallStateMemory`](#CallStateMemory) | `{id}.{index}`    | `Read`, `Write` | Call's memory as a byte array                                      |
 
 ## Circuit Constraints
@@ -78,7 +78,7 @@ Since only `code_hash` encodes account existence, we must be careful to never
 read (lookup) another account property unless we have checked that the account
 exists.  This is because the RwTable in the State Circuit has all the entries
 sorted by [Tag, FieldTag], so `CodeHash`, `Nonce` and `Balance` are treated
-independently, which means that a lookup to `Nonce` or `Balance` could suceed
+independently, which means that a lookup to `Nonce` or `Balance` could succeed
 on a non-existing account if the account is created afterwards.  For this
 reason we must guarantee that:
 - A `Nonce` and `Balance` lookup to an account must only be performed if we

Diff for: specs/public_inputs.md

@@ -117,7 +117,7 @@ synchronize the State Trie.
 ## Data to synchronize the State Trie
 
 In order to synchronize the State Trie after a new block (assuming we have the state
-of the previous block), we need the at least the following data:
+of the previous block), we need at least the following data:
 
 - For each tx
     - GasPrice: 256 bits
@@ -188,7 +188,7 @@ later be "uncompressed" (opened) from a contract.
 
 The commitment defined in EIP 4844 uses a different field than our circuits, so
 opening it in a circuit is very expensive.  Instead, we must prove the equivalence
-of the committed raw public inputs (outisde of the circuits) with the witnessed
+of the committed raw public inputs (outside of the circuits) with the witnessed
 raw public inputs (inside the circuits), with the help of the PublicInputs
 circuit.
 
@@ -220,7 +220,7 @@ Notes:
 - With this approach, once we cross the `Aggregation0` circuit, the verification cost of each proof is independent of the "real" number of public inputs (i.e. the number of transactions, the size of call data, the number of block fields, etc.)
 - Calculating an RLC of values in a contract is cheap (it just needs `MULMOD`, `ADDMOD`)
 
-The following diagram shows the the public input approach using the RLC shortcut:
+The following diagram shows the public input approach using the RLC shortcut:
 
 ![](./public_inputs.rev1.png)
 

Diff for: specs/super_circuit.md

@@ -25,7 +25,7 @@ shared among all of them. It contains the following circuits:
  - [x] Copy Table
  - [x] Block Table
 
-The following diagram shows the relation between this circuits and tables:
+The following diagram shows the relation between these circuits and tables:
 ![](./super_circuit.png)
 
 **Note**: There are some smaller sub-circuits, like the ECDSA circuit and opcode related
@@ -34,6 +34,6 @@ Circuits, so they are not shown in the diagram for clarity.
 
 Putting together all sub-circuits in one allows them to easily make lookups to whatever table is
 necessary without the need of having them copied. The main drawback is that the Super Circuit proof
-is very large, and therefore its verification its costly. To alleviate this problem a new circuit is
+is very large, and therefore its verification is costly. To alleviate this problem a new circuit is
 introduced: the Root Circuit, whose function is to verify the Super Circuit proof, generating a much
 smaller proof which is cheaper to verify.

Diff for: specs/transactions-proof.md

@@ -7,7 +7,7 @@ to the EVM proof via the transactions table.
 
 ## Transaction encoding
 
-Different types of transaction encoding exists.  On the first iteration of the zkEVM we will only support Legacy transactions with EIP-155.  We plan to add support for Non-Legacy (EIP-2718) transactions later.
+Different types of transaction encoding exist.  On the first iteration of the zkEVM we will only support Legacy transactions with EIP-155.  We plan to add support for Non-Legacy (EIP-2718) transactions later.
 
 ### Legacy type:
 
@@ -143,12 +143,12 @@ difference in usage compared to the Tx Circuit:
 
 1. The lookup table needs to be defined in the MPT for these Tx Circuit
    particular lookups (which are separate from the State Trie and Account
-   Storage Lookups).  Here we're building a trie from scratch and getting it's
+   Storage Lookups).  Here we're building a trie from scratch and getting its
    root.
 2. While the State Trie and Account Storage Trie inserts use leafs that are
    bounded in size, for the Transactions Trie, the leafs are the RLP of the
-   Transaction, which contain a variable size calldata.  This means that the
-   MPT circuit needs to accomodate variable length leaf values.
+   Transaction, which contains a variable size calldata.  This means that the
+   MPT circuit needs to accommodate variable length leaf values.
 
 Once the first iteration of the MPT (the one that fulfills the needs of the
 State Circuit lookups) is finished, we'll work on this.

Diff for: specs/word-encoding.md

@@ -60,7 +60,7 @@ word8s = [
 
 The 256 bit word is represented as a random linear combination of its 8 bit words.
 
-The commitment check should gurantee the 32 chunks in 8 bit range.
+The commitment check should guarantee the 32 chunks in 8 bit range.
 
 ## Addition
 
@@ -90,7 +90,7 @@ This checks the the relations of `a256 > b256`, `a256 < b256`, `a256 == b256`
 
 We group 8 bit chunks to 16 bit chunks to optimize the table.
 
-The `result` carries the conclusion of the comparision from the higher siganificant chunks all the way down.
+The `result` carries the conclusion of the comparison from the higher significant chunks all the way down.
 
 Example: