chore: proofreading the docs (#1093)

* Update EVM_Circuit.md

* Update Tx_Circuit.md

Author: Gakunt

docs/EVM_Circuit.md

@@ -22,7 +22,7 @@ The [Ethereum Virtual Machine] (EVM) is a state machine that defines the rules o
 
 The execution trace consists of each step of execution defined by the opcode. EVM Circuit aims at constructing a constraint system corresponding to this execution trace, that can be proved by some backend zk-proof system such as Halo2. 
 
-The high-level design idea of EVM Circuit is somewhat reminiscent of the design of EVM itself (such as [go-ethereum]). In go-ethereum, an `Intepreter` loops over all instruction opcodes along the execution trace. At each instruction, the `Intepreter` helps to check relevant context information such as gas, stack, memory etc., and then sends the opcode to a `JumpTable` from which it fetches detailed `operation` that this opcode should do. 
+The high-level design idea of EVM Circuit is somewhat reminiscent of the design of EVM itself (such as [go-ethereum]). In go-ethereum, an `Interpreter` loops over all instruction opcodes along the execution trace. At each instruction, the `Interpreter` helps to check relevant context information such as gas, stack, memory etc., and then sends the opcode to a `JumpTable` from which it fetches detailed `operation` that this opcode should do. 
 
 Analogously, in EVM Circuit, we build <i>execution steps</i> according to the steps in the execution trace, with witnesses for both the opcode and the execution context. For each execution step, a set of constraints is imposed to check context information. For each opcode, a set of constraints is imposed to check the opcode's behavior. Within an execution trace, the same opcode should have the same constraints. We use a selector to "turn on" all steps for the same opcode within a trace and we prove their behavior using our backend proof system. This is possible thanks to how our backend proof system (Halo2) works. The overall proof is obtained by applying this scheme to the list of all opcodes that appear in the execution trace.
 
@@ -334,7 +334,7 @@ Then the constraints are
 $b=\mu_{s}[1]$, $n=\mu_{s}[2]$, 
 $r=\mu_{s}'[0]$;
     - Exceptions: 
-        - 1. stack undeflow: $1022 \leq$ stack\_pointer $\leq 1024$; 
+        - 1. stack underflow: $1022 \leq$ stack\_pointer $\leq 1024$; 
         - 2. out of gas: Remaining gas is not enough.
 
 

docs/Tx_Circuit.md

@@ -181,7 +181,7 @@ Assign an empty row first, then followed by each tx's data fields except calldat
     - Lookup RLP table to validate the value correspond to any of these tags with the corresponding hash format `L1MsgHash`(for `tx_type==L1Msg`) or `TxHashPreEip155` (for `tx_type==PreEip155`) or `TxHashEip155` (for `tx_type==Eip155`).
 
 - lookup to sig table for signature information `(msg_hash_rlc, v, r, s, sv_address)`
-    - triggerd with tx_tag is ChainID and `is_l1_msg==false`;
+    - triggered with tx_tag is ChainID and `is_l1_msg==false`;
     - lookup `(msg_hash_rlc=TxSignHash, v, r, s, sv_address)` to sig_table. `v` is determined based on `chain_id` and `ty_type` being `Eip155` or `PreEip155`.
 
 - lookup to Keccak table for TxSign and TxHash data length and hash result (LookupCondition::Keccak)