Docs improvement

docs/Modexp_Circuit.md

@@ -144,7 +144,7 @@ Circuit uses 2-rows for one custom-gate constraint, with layout as follows:
 
 Note that the above table is a demonstration of how a custom-gate is layouted. The None terms simply stands for the fact that the custom-gate does not touch these cells. It does not mean that the circuit is layouted without these cells being filled with valid values. One can think of the actual circuit layout as the above shaped custom-gate (throwing away the None cells) falling down as in a tetris game. 
 
-Here `l0`, `l1`, `l2`, `l3`, `d` are advice columns (5 advice columns) and rest are fixed columns (12 fixed columns). The context of each cell is explained as follows:
+Here `l0`, `l1`, `l2`, `l3`, `d` are advice columns (5 advice columns) and the rest are fixed columns (12 fixed columns). The context of each cell is explained as follows:
 
 - `l0`-`l3` stand for the 4 limbs in decomposing a U256 `Number`; 
 - `d` is a limb term;

docs/Public_Input_Circuit.md

@@ -81,7 +81,7 @@ Finally `pi_hash` is the Keccak256 hash of `pi_bytes`.
 
 ## The Purpose of Public Input Circuit
 
-The above `pi_bytes` is assigned to the PI Circuit byte-by-byte. The PI Circuit aims to check the correctness of `pi_bytes` by looking up to the Keccak table for `pi_hash` and compare the `pi_hash` with a given instance of the `pi_hash`. 
+The above `pi_bytes` is assigned to the PI Circuit byte-by-byte. The PI Circuit aims to check the correctness of `pi_bytes` by looking up to the Keccak table for `pi_hash` and comparing the `pi_hash` with a given instance of the `pi_hash`. 
 
 Since the [Keccak table](https://github.com/scroll-tech/zkevm-circuits/blob/925f6fc423af6b733a36b544289b4514fc9faecb/zkevm-circuits/src/table.rs#L1289) only records input RLC and output RLC, to perform the lookup, PI Circuit must record the RLC accumulation of input bytes and (hash) output bytes. This induces further checks about the correctness of these RLC accumulations. These accumulation columns are also re-used to store Keccak input rlc and output rlcs, so they induce many copy constraints. Furthermore, some of the public input data fields such as block context, tx hashes, chain_id, coinbase, difficulty are having connection with the block table and tx table, so copy constraints with them are also established.
 

docs/Sig_Circuit.md

@@ -45,7 +45,7 @@ The Sig Circuit aims at proving the correctness of SigTable. This mainly include
     - `msg_hash_cells`: byte cells for `msg_hash`;
     - `pk_cells`: byte cells for the EC coordinates of public key;
     - `address`: RLC of `pk_hash` last 20 bytes;
-    - `is_address_zero`: check if address is zero;
+    - `is_address_zero`: check if the address is zero;
     - `r_cells`, `s_cells`: byte cells for signatures `r` and `s`.
 
 During the process of sign data decomposition, checks of CRT integer decomposition into limbs of size `[88,88,80]` are done for `msg_hash` and public key's EC coordinates. 

docs/State_Circuit.md

@@ -49,7 +49,7 @@ The `tag` column (RwTable Tag) in the `rw_table` is used to specify the above rw
 |rw_counter|is_write|RwTableTag::AccountStorage|tx_id|account_address|None|RLC storage_key in le bytes|RLC value's le bytes|RLC value_prev's le bytes|only used for AccountStorage::tx_id which moved to key1, but actually the current code assigns 0|RLC committed_value's le bytes|
 |rw_counter|is_write|RwTableTag::AccountDestructed|None|account_address|None|None|is_destructed|is_destructed_prev|0|None|
 |rw_counter|is_write|RwTableTag::CallContext|call_id|None|CallContextFieldTag::{RwCounterEndOfReversion, CallerID, TxID, Depth, CallerAddress, CalleeAddress, CallDataOffset, CallDataLength, ReturnDataOffset, ReturnDataLength, Value, IsSuccess, IsPersistent, IsStatic, LastCalleeID, LastCalleeReturnDataOffset, LastCalleeReturnDataLength, IsRoot, IsCreate, CodeHash, ProgramCounter, StackPointer, GasLeft, MemorySize, ReversibleWriteCounter}|None|value or RLC value's le bytes if CallContextFieldTag == {CodeHash, Value}|None|0|None|
-|rw_counter|is_write|RwTableTag::Stack|call_id|stack_pointer to big endian bytes last 20 bytes as address|None|None|RLC value's le bytes|None|0|None|
+|rw_counter|is_write|RwTableTag::Stack|call_id|stack_pointer to big-endian bytes last 20 bytes as address|None|None|RLC value's le bytes|None|0|None|
 |rw_counter|is_write|RwTableTag::Memory|call_id|memory_address|None|None|byte|None|0|None|
 |rw_counter|is_write|RwTableTag::TxLog|tx_id|(index, field_tag, log_id) built into tx_log address|TxLogFieldTag::{Address, Topic, Data}, it is None in actual table and field tag info enters address|None|value or RLC value's le byte if TxLogFieldTag == {Topic}|None|0|None|
 |rw_counter|is_write|RwTableTag::TxReceipt|tx_id|None|TxReceiptFieldTag::{PostStateOrStatus, LogLength, CumulativeGasUsed}|None|value|None|0|None|

docs/Tx_Circuit.md

@@ -39,7 +39,7 @@ A transaction can be a contract creation or a message call. For contract creatio
 
 ### Types of Transactions
 
-Besides legacy transaction, there are also other types of transactions such as [EIP155], [EIP2930] ([EIP2718] type `0x01`) and [EIP1559] ([EIP2718] type `0x02`). They differ by their details in tx information and their signing process. 
+Besides legacy transactions, there are also other types of transactions such as [EIP155], [EIP2930] ([EIP2718] type `0x01`) and [EIP1559] ([EIP2718] type `0x02`). They differ by their details in tx information and their signing process. 
 
 For example, in the above legacy transaction the ECDSA signature `(r,s)` is obtained by signing with message `RLP([nonce, gasprice, startgas, to, value, data])` and the private key of the EOA account that initiates this tx. In this case `v` is 27 or 28; instead, in EIP155 the sign message becomes `RLP([nonce, gasprice, startgas, to, value, data, chainid, 0, 0])` and `v` is `ChainID*2+35` or `ChainID*2+36`. 
 
@@ -74,7 +74,7 @@ According to the [EllipticCurveDigitalSignatureAlgorithm] (ECDSA), the signature
 
 The recovery id `v` is then computed from the parity of the `y` component of the EC point corresponding to `x` component being `r`. The `public_key` can be recovered from `(v,r,s)` and `msg_hash` using `ecrecover`, which further determines the caller address as `caller_address=keccak(public_key)[-20:]` (because this is the way account address is created, which is derived from its public key). Notice that only EOA address can initiate a tx and contract address cannot, because contract address is not calculated from public key but from nonce and EOA address. Also notice that EOA account's private key are elliptic-curve pre-images of public key and are thus hidden, while the public key can be calculated from the private key.
 
-In the Tx Circuit, validation of correct signature is made through lookup to the sig table; validation of correct RLP is made through lookup to the RLP table; and validation of correct has is made through lookup to the Keccak table.
+In the Tx Circuit, validation of the correct signature is made through lookup to the sig table; validation of correct RLP is made through lookup to the RLP table; and validation of correct has is made through lookup to the Keccak table.
 
 
 ## The Purpose of Tx Circuit
@@ -155,7 +155,7 @@ Assign an empty row first, then followed by each tx's data fields except calldat
     - `is_none` is boolean;
     - `tx_type` among `PreEip155`, `Eip155` and `L1Msg`;
     - `rlp_tag` is corresponding to tx_tag in a correct way (for some tx_tag the corresponding `rlp_tag` is none, for some other tx_tag this correspondence is just identical with possible name changes);
-    - If CalleeAddress has value none, then IsCreate (next row) will be also none;
+    - If CalleeAddress has value none, then IsCreate (next row) will also be none;
     - if `is_none` is true at current row, then value ==0;
     - if CallData is none, then both CallDataLength and CallDataGasCost must be none value; otherwise, CallDataLength must have non-zero value;
     - for L1Msg type tx, tx gas cost is 0.