fix: several typos in the docs (#1028)

* fix typos README.md

* fix typo README.md

* fix typos Bytecode_Circuit.md

* fix typo EVM_Circuit.md

* fix typo Keccak_Circuit.md

Author: tudorpintea999

aggregator/README.md

@@ -36,7 +36,7 @@ c_i.post_state_root == c_{i+1}.prev_state_root
 for $i \in [1, k-1]$.
 
 ## Padded chunk
-A __padded chunk__ is a chunk that repeats last valid chunk. It is used for padding. 
+A __padded chunk__ is a chunk that repeats the last valid chunk. It is used for padding. 
 If $k< n$, $(n-k)$ padded chunks are padded to the list. A padded chunk has the same data fields as the last real chunk, and the parameters are set as
 - state root before this chunk: `c_{k}.prev_state_root`
 - state root after this chunk: `c_{k}.post_state_root`
@@ -97,7 +97,7 @@ for i in 1 ... n
     chunk_pi_hash   := keccak(chain_id || prev_state_root || post_state_root || withdraw_root || chunk_data_hash)
 ```
 
-This is done by compute the RLCs of chunk[i]'s data_hash for `i=0..k`, and then check the RLC matches the one from the keccak table.
+This is done by computing the RLCs of chunk[i]'s data_hash for `i=0..k`, and then check the RLC matches the one from the keccak table.
 
 4. chunks are continuous when they are not padded: they are linked via the state roots.
 
@@ -106,7 +106,7 @@ for i in 1 ... k-1
     c_i.post_state_root == c_{i+1}.prev_state_root
 ```
 
-5. All the chunks use a same chain id. __Static__.
+5. All the chunks use the same chain id. __Static__.
 ```
 for i in 1 ... n
     batch.chain_id == chunk[i].chain_id
@@ -119,7 +119,7 @@ for i in 1 ... n:
         chunk[i]'s chunk_pi_hash_rlc_cells == chunk[i-1].chunk_pi_hash_rlc_cells
 ```
 This is done via comparing the `data_rlc` of `chunk_{i-1}` and ` chunk_{i}`.
-7. the hash input length are correct
+7. the hash input length is correct
 - first MAX_AGG_SNARKS + 1 hashes all have 136 bytes input
 - batch's data_hash length is 32 * number_of_valid_snarks
 8. batch data hash is correct w.r.t. its RLCs
@@ -131,7 +131,7 @@ This is done via comparing the `data_rlc` of `chunk_{i-1}` and ` chunk_{i}`.
 ![Dynamic_inputs](./figures/hash_table.jpg)
 
 
-Our keccak table uses $2^{19}$ rows. Each keccak round takes `300` rows. When the number of round is is less than $2^{19}/300$, the cell manager will fill in the rest of the rows with dummy hashes. 
+Our keccak table uses $2^{19}$ rows. Each keccak round takes `300` rows. When the number of round is less than $2^{19}/300$, the cell manager will fill in the rest of the rows with dummy hashes. 
 
 The only hash that uses dynamic number of rounds is the last hash. 
 Suppose we target for `MAX_AGG_SNARK = 10`. Then, the last hash function will take no more than `32 * 10 /136 = 3` rounds. 
@@ -154,4 +154,4 @@ For the output of the final data hash
 |9,10          | 64                  | 0, 0, 1|
 
 Additional checks for dummy chunk
-- if `is_padding` for `i`-th chunk, we constrain `chunk[i]'s chunk_pi_hash_rlc_cells == chunk[i-1].chunk_pi_hash_rlc_cells`
+- if `is_padding` for `i`-th chunk, we constrain `chunk[i]'s chunk_pi_hash_rlc_cells == chunk[i-1].chunk_pi_hash_rlc_cells`

bus-mapping/README.md

@@ -27,7 +27,7 @@ prover to pick any location here and in the EVM proof confirm it is correct.
 time. It checks the validity of these opcodes. It also confirms that for
 each of these opcodes the state proof performed the correct operation.
 
-Only after verifying both proofs are we confident that that Ethereum block
+Only after verifying both proofs are we confident that the Ethereum block
 is executed correctly.
 
 ### Bus Mapping

docs/Bytecode_Circuit.md

@@ -15,7 +15,7 @@ The EVM Circuit needs to lookup to the bytecode table that stores the correct by
 |RLC of hash's little-endian bytes using evm_word randomness|BytecodeFieldTag::Header|0|0|len of bytes|
 |RLC of hash's little-endian bytes using evm_word randomness|BytecodeFieldTag::Byte|idx|true when the byte is not an argument to a PUSHx instruction|byte|
 
-Here `Header` is used to seperate bytecodes.
+Here `Header` is used to separate bytecodes.
 
 ## Purpose of the Bytecode Circuit
 
@@ -98,5 +98,5 @@ Here
     - when `tag` is `byte`, then lookup to push_table for `(value, push_data_size)`
 
 - correct propagation of each row within one bytecode
-    - when `tag` transits from `byte` to `byte`, then `length` and `hash` remain the same, `index` increse by 1, `value_rlc` accumulates, and for push data `push_data_left` decay by 1, for code `push_data_left` remains the same as `push_data_size`
+    - when `tag` transits from `byte` to `byte`, then `length` and `hash` remain the same, `index` increases by 1, `value_rlc` accumulates, and for push data `push_data_left` decay by 1, for code `push_data_left` remains the same as `push_data_size`
 

docs/EVM_Circuit.md

@@ -29,7 +29,7 @@ Analogously, in EVM Circuit, we build <i>execution steps</i> according to the st
 
 ## Architecture
 
-We decompose the execution trace into execution steps and impose constraints for each step/step state transition. A `Step` contains two parts: `StepState` carries the execution step and its context information; and `CellManager` helps to fill the step's information as witnesses into the circuit's cells. An API layer `ConstraintBuilder` is built upon the backend proof system (Halo2) to impose constraints. The oveall architecture looks as follows:
+We decompose the execution trace into execution steps and impose constraints for each step/step state transition. A `Step` contains two parts: `StepState` carries the execution step and its context information; and `CellManager` helps to fill the step's information as witnesses into the circuit's cells. An API layer `ConstraintBuilder` is built upon the backend proof system (Halo2) to impose constraints. The overall architecture looks as follows:
 
 ```mermaid
 stateDiagram
@@ -362,4 +362,4 @@ For RETURNDATACOPY opcode, EVM Circuit does the following type of constraint che
 - `SameContextGadget`
     - opcodeID checks: opId $==$ OpcodeId(0x3e);
     - state transition: rw_counter+, stack\_pointer+3, pc+1, gas -(op_cost+memory expansion cost), memory expand to next memory word size.
- 
+ 

docs/Keccak_Circuit.md

@@ -65,7 +65,7 @@ Cyclic shift offset constants $r[x,y]$ are picked according to the following tab
 | $y=4$ | 56 | 14 | 18 | 2  | 61 |
 | $y=3$ | 21 | 8  | 41 | 45 | 15 |
 
-Round constants $RC[k]$ are also given, in hexiadecimal notion it looks like:
+Round constants $RC[k]$ are also given, in hexadecimal notion it looks like:
 
 $$\begin{array}{ll}
 RC[ 0] & \verb"0x0000000000000001" 
@@ -226,7 +226,7 @@ The parts splitted from the word is then determined bit-by-bit from `target_size
 - `uniform` is true, then the remaining `rot`-sized bits [63-`rot`+1,...,63] are divided by `part_size` plus a remainder, and first 64-`rot` bits are determined by a section compensating previous remainder, plus divide by `part_size`, and plus the remainder from `target_size` division; 
 - `uniform` is false, then the remaining `rot`-sized bits [63-`rot`+1,...,63] are divided by `part_size` plus remainder, and first 64-`rot` bits determined by `part_size` plus a remainder.
 
-The way we do the above split when `uniform` is true enables an optimization shown below, where after rotation the front and tail remainders combined together becomes an inverval of length `part_size`:
+The way we do the above split when `uniform` is true enables an optimization shown below, where after rotation the front and tail remainders combined together becomes an interval of length `part_size`:
 
 ![split_normalize_true](https://hackmd.io/_uploads/S1V-8qoKn.png)
 
@@ -350,7 +350,7 @@ $$os[i][j]=s[i][j]+bc[(i+4)\mod 5]+\text{rot}(bc[(i+1)\mod 5], 1) $$ and set it
 
 #### Rationale 
 - <i>Soundness</i>: Use the symbols in the previous section on Keccak-f permutation function, it can be checked that $C[x]$ is the same as the parity of $A[x,0]+A[x,1]+...+A[x,4]$. So this is what $bc[i]$ checks at the `normalize_6` table lookup step. 
-In a same rationale, $os[i][j]$ after normalization stands for the parity of $A[x,y]\oplus D[x]$. This normalization is postponed to $\rho/\pi$-step using `normalize_4` table lookup. 
+In the same rationale, $os[i][j]$ after normalization stands for the parity of $A[x,y]\oplus D[x]$. This normalization is postponed to $\rho/\pi$-step using `normalize_4` table lookup. 
 - <i>Completeness</i>: Since $C[x]$ is the same as the parity of $A[x,0]+A[x,1]+...+A[x,4]$, any selection of witnesses that satisfy original $\theta$-step in the Section on Keccak-f permutation function will pass the constraints.
 
 ### rho/pi-step