Apply suggestions from code review

Co-authored-by: hsutaiyu <51791408+hsutaiyu@users.noreply.github.com>

Author: EmpieichO

docs/zkEVM/api/check-tx-status.md

@@ -9,7 +9,7 @@ After sending a transaction (TX) to the network using the `eth_sendRawTransactio
 1. `eth_getTransactionByHash`
 2. `eth_getTransactionReceipt`
 
-### Using eth_getTransactionByHash
+### Using `eth_getTransactionByHash`
 
 When checking the TX status using the `eth_getTransactionByHash`, the result can be either one of the following.
 
@@ -21,7 +21,7 @@ When checking the TX status using the `eth_getTransactionByHash`, the result can
 
 - If the fields `block_num` and `block_hash` are NOT null, it means the TX was mined.
 
-### Using eth_getTransactionReceipt
+### Using `eth_getTransactionReceipt`
 
 When checking the TX status using the `eth_getTransactionReceipt`, again the result can either one of the following.
 

docs/zkEVM/concepts/circom-intro-brief.md

@@ -37,13 +37,13 @@ Once obtained, the R1CS can later be used by a zk-SNARK protocol to generate ver
 
 A valid proof attests to the fact that the prover knows an assignment to all wires of the circuit that fulfills all the constraints of the R1CS.
 
-An issue that arises, when applying zero-Knowledge protocols to complex computations such as a circuit describing the logic of a ZK-rollup, is that the number of constraints to be verified can be extremely large.
+An issue that arises, when applying zero-knowledge protocols to complex computations such as a circuit describing the logic of a ZK-rollup, is that the number of constraints to be verified can be extremely large.
 
 CIRCOM was developed for the very purpose of scaling complex Arithmetic circuits by realizing them as combined instantiations of smaller Arithmetic circuits.
 
 ## What is CIRCOM?
 
-CIRCOM is a domain-specific language (DSL) used to define Arithmetic circuits, and it has an associated compiler of Arithmetic circuits to their respective R1CS.
+CIRCOM is a Domain-Specific Language (DSL) used to define Arithmetic circuits, and it has an associated compiler of Arithmetic circuits to their respective R1CS.
 
 ![CIRCOM Overall Context](../../img/zkEVM/02circom-overall-context.png)
 

docs/zkEVM/concepts/generic-state-machine/exec-trace-correct.md

@@ -2,13 +2,13 @@ In this document we discuss how the correctness of the execution trace is ensure
 
 The first step is to build a mechanism for verifying correctness of the execution trace. This requires creating a set of arithmetic constraints that only hold true when the execution trace is correct. These arithmetic constraints are equations that registry values in any two consecutive rows of the correct execution trace, must satisfy.
 
-Similar to the mFibonacci SM, where each state had to conform to polynomial identities, the arithmetic constraints of the generic state machine are translated into polynomial identities, and ultimately be translated into the PIL language.
+Similar to the mFibonacci SM, where each state had to conform to polynomial identities, the arithmetic constraints of the generic state machine are translated into polynomial identities and ultimately into the PIL language.
 
 ## Constructing arithmetic constraints
 
 Since these arithmetic constraints govern state transitions, they express the next state $\big(\mathtt{A'} ,\mathtt{B'}\big)$ in terms of the current state $\big(\texttt{A},\texttt{B}\big)$. That is, in terms of the execution trace, the new registry values are linear combinations of previous registry values, together with constants and free inputs.
 
-We therefore need auxiliary columns for selectors. Like switches that can either be ON or OFF, selectors too can either have a value $\mathtt{1}$ or $\mathtt{0}$, depending on the instruction being executed.
+We therefore need auxiliary columns for selectors. Like switches that can either be _ON_ or _OFF_, selectors too can either have a value $\mathtt{1}$ or $\mathtt{0}$, depending on the instruction being executed.
 
 In continuing with the previous example of a four-instruction state machine,
 
@@ -124,7 +124,7 @@ $$
 
 2. It shall be seen later, in our implementation of a state machine with jumps, that $\texttt{CONST}$ is in fact a committed polynomial rather than a constant polynomial.
 
-3. All the operations in the constraints are carried out $\mathtt{\ modulo }$ the order $p$ of the prime field. The so-called Goldilocks-like Field, with $p = 2^{64} − 2^{32} +1$, is mainly used where 64-bit numbers suffice (see [Plonky2](https://github.com/mir-protocol/plonky2/blob/main/plonky2/plonky2.pdf)). Otherwise, the [BN128 field](https://iden3-docs.readthedocs.io/en/latest/iden3_repos/research/publications/zkproof-standards-workshop-2/baby-jubjub/baby-jubjub.html) is deployed.
+3. All operations in the constraints are carried out $\mathtt{\ modulo }$ the order $p$ of the prime field. The so-called Goldilocks-like field, with $p = 2^{64} − 2^{32} +1$, is mainly used where 64-bit numbers suffice (see [Plonky2](https://github.com/mir-protocol/plonky2/blob/main/plonky2/plonky2.pdf)). Otherwise, the [BN128 field](https://iden3-docs.readthedocs.io/en/latest/iden3_repos/research/publications/zkproof-standards-workshop-2/baby-jubjub/baby-jubjub.html) is used.
 
 In order to match the type of commitment scheme used in the zkEVM, these arithmetic constraints must first be expressed as polynomial identities, which are in turn compiled with PILCOM.
 
@@ -191,7 +191,7 @@ $$
 
 where $\mathtt{op(x) = inA(x) \cdot A(x) + inB(x) \cdot B(x) + inFREE(x) \cdot FREE(x) + CONST(x)}$.
 
-As far as boundary constraints are concerned, we can, for instance,
+As far as boundary constraints are concerned, we can, for instance:
 
 - Make both the free input and the last registry value of $\mathtt{A}$ public.
 

docs/zkEVM/concepts/generic-state-machine/intro-generic-sm.md

@@ -12,9 +12,9 @@ The aim with this document is to explain how the machinery used in the mFibonacc
 
 Think of our state machine as being composed of two parts; the part that has to do with generating the execution trace, while the other part is focused on verifying that the executions were correctly executed.
 
-- The former part is more like the "software" of the state machine, as it is concerned with interpreting program instructions and correctly generating the execution trace. A novel language dubbed the zero-knowledge Assembly (zkASM) language is used in this part.
+- The former part is more like the 'software' of the state machine, as it is concerned with interpreting program instructions and correctly generating the execution trace. A novel language dubbed the zero-knowledge Assembly (zkASM) language is used in this part.
 
-- But the latter part is more like the "hardware" as it consists of a set of arithmetic constraints (or their equivalent, polynomial identities) that every correctly generated execution trace must satisfy. Since these arithmetic constraints are transformed into polynomial identities (via an interpolation process), they are described in a novel language called the polynomial identity language (PIL).
+- But the latter part is more like the 'hardware' as it consists of a set of arithmetic constraints (or their equivalent, polynomial identities) that every correctly generated execution trace must satisfy. Since these arithmetic constraints are transformed into polynomial identities (via an interpolation process), they are described in a novel language called the Polynomial Identity Language (PIL).
 
 ## Generic SM executor
 

docs/zkEVM/concepts/generic-state-machine/program-counter.md

@@ -80,7 +80,7 @@ $$
 
 where $\texttt{offset}$ is provided as part of the jump instructions, $\texttt{JMPZ(addr)}$ and $\texttt{JMP(addr)}$.
 
-We now have the following new columns in the execution trace,
+We now have the following new columns in the execution trace:
 
 $$
 \begin{array}{|l|c|c|c|c|c|c|c|}\hline

docs/zkEVM/concepts/mfibonacci/commitment-scheme.md

@@ -36,14 +36,14 @@ For all practical purposes, such the constructed proof-verification system needs
 
 Proof systems based on testing polynomial identities take advantage of a basic property of polynomials expressed by the [Schwartz-Zippel lemma](https://courses.cs.washington.edu/courses/cse521/17wi/521-lecture-7.pdf).
 
-According to the Schwartz-Zippel lemma;
+According to the Schwartz-Zippel lemma:
 
->For any non-zero polynomial ${Q(X_1, \dots , X_n)}$ on ${n}$ variables with degree ${d}$, and ${S}$ a finite but sufficiently large subset of the field $\mathbb{F}$, then values ${ X_1, \dots , X_n }$ from ${S}$ are independently and uniformly assigned at random, then
+- For any non-zero polynomial ${Q(X_1, \dots , X_n)}$ on ${n}$ variables with degree ${d}$, and ${S}$ a finite but sufficiently large subset of the field $\mathbb{F}$, then values ${ X_1, \dots , X_n }$ from ${S}$ are independently and uniformly assigned at random, then
 ${Pr[Q(X_1, \dots , X_n) = 0] ≤ \dfrac{d}{|S|}}$.
 
 Here's what the Schwartz-Zippel lemma means in the specific case of the mFibonacci state machine:
 
->​If the verifier selects the challenges $\{ \alpha_1, \alpha_2 . . . , \alpha_l \}$ randomly and uniformly, then the probability of the prover finding a false polynomial ${Q'}$ of degree $d$, such that ${Q'(\alpha_j) = 0 = Q(\alpha_j)}$ for all $j \in \{ 1, 2, \dots , l \}$ , is at most ${\dfrac{d}{|S|}}$, which is very small.
+- If the verifier selects the challenges $\{ \alpha_1, \alpha_2 . . . , \alpha_l \}$ randomly and uniformly, then the probability of the prover finding a false polynomial ${Q'}$ of degree $d$, such that ${Q'(\alpha_j) = 0 = Q(\alpha_j)}$ for all $j \in \{ 1, 2, \dots , l \}$ , is at most ${\dfrac{d}{|S|}}$, which is very small.
 
 This speaks of the soundness of our polynomial commitment scheme.
 

docs/zkEVM/concepts/mfibonacci/mfibonacci-example.md

@@ -1,4 +1,4 @@
-Consider a proof-verification scheme, using an arbitrary Polynomial Commitment Scheme, where users have to prove knowledge of the N-th member of a multiplicative Fibonacci series, for specific initial conditions.
+Consider a proof-verification scheme, using an arbitrary Polynomial Commitment Scheme. In this scheme, users must prove knowledge of the $Nth$ member of a multiplicative Fibonacci series for specific initial conditions.
 
 ## What is a multiplicative Fibonacci series?
 
@@ -12,7 +12,7 @@ has the property that the product of every two consecutive members $\mathbf{a_{i
 
 Also, the initial values are specified as $\mathbf{a_0} = 2$ and $\mathbf{a_1} = 1$.
 
-Here are the first ten members of the mFibonacci series,
+Here are the first ten terms of the mFibonacci series,
 
 $$
 \mathbf{ \ \ 2,\ \ 1,\ \ 2,\ \ 2,\ \ 4,\ \ 8,\ \ 32,\ \ 256,\ \ 8192,\ \ 2097152,\ \ \dots }
@@ -220,7 +220,7 @@ In the context of our mFibonacci SM, the verifier can set the initial conditions
 
 Boundary constraints apply to particular registry values, and are used to enforce that the correct initial state was applied.
 
-The idea here is to set up a specific boundary constraint, which the verifier can use to check that correct initial conditions were applied, when the prover was computing a particular N-th term of the mFibonacci series. Yet, the verifier must not disclose any information about the secret values $A_0$ and $B_0$.
+The idea here is to set up a specific boundary constraint, which the verifier can use to check that correct initial conditions were applied, when the prover was computing a particular $Nth$ term of the mFibonacci series. Yet, the verifier must not disclose any information about the secret values $A_0$ and $B_0$.
 
 Therefore, the first thing to do, is removing terms in the identities bearing the initial values $A_0$ and $B_0$. This means modifying our polynomial identities to the ones below;
 
@@ -245,7 +245,7 @@ This logic is valid simply because the computations carried out by the state mac
 
 All computations are carried out in a field $\mathbb{F}_p$ , where $p = \mathtt{2^{64}-2^{32}+1}$, a Goldilocks-like prime number.
 
-Suppose the verifier knows that an mFibonacci series starting with initial values, $A_0$ and $B_0$, yields $A_{\mathtt{1023}} = \mathtt{14\ 823\ 897\ 298\ 192\ 278\ 947}$ as the value of the $\mathtt{1024}$-th term. The verifier can challenge anyone to prove knowledge of the initial condition of the mFibonacci SM to provide three polynomials and the correct $\mathtt{1024}$-th term. That is, the verifier uses the following constraints to verify the prover's submissions;
+Suppose the verifier knows that an mFibonacci series starting with initial values, $A_0$ and $B_0$, yields $A_{\mathtt{1023}} = \mathtt{14\ 823\ 897\ 298\ 192\ 278\ 947}$ as the value of the $\mathtt{1024}$-th term. The verifier can challenge anyone to prove knowledge of the initial condition of the mFibonacci SM to provide three polynomials and the correct $\mathtt{1024}$-th term. That is, the verifier uses the following constraints to verify the prover's submissions:
 
 $$
 \begin{aligned}

docs/zkEVM/concepts/mfibonacci/mfibonacci.md

@@ -21,7 +21,7 @@ The approach involves developing a state machine that enables a prover to genera
 
 ![A Skeletal View of the Design Process](../../../img/zkEVM/fib5-design-approach-outline.png)
 
-The process that leads to achieving such a state machine-based system takes a few steps,
+The process that leads to achieving such a state machine-based system takes a few steps:
 
 - Modeling deterministic computation as a state machine.
 - Specifying the equations that fully describe the state transitions of the state machine, known as arithmetic constraints.

docs/zkEVM/concepts/mfibonacci/pil-stark.md

@@ -4,7 +4,7 @@
 
     The description given here is by no means the architecture of the PIL-STARK system.
 
-Simply put, PIL-STARK is a special STARK that enables,
+Simply put, PIL-STARK is a special STARK that enables:
 
 - The state machine prover (SM-prover) to generate STARK proofs for any state machine written in PIL.
 - The state machine verifier (SM-verifier) to verify STARK proofs generated by the prover.
@@ -31,19 +31,21 @@ The $\texttt{setup executor}$ takes as input the PIL $\texttt{.json}$ file from
 
 ### PIL-STARK setup
 
-The PIL-STARK setup takes as inputs; the PIL $\texttt{.json}$ file from $\texttt{PILCOM}$, the evaluations of the constant polynomials from the $\texttt{setup}$ $\texttt{executor}$, and the STARK configuration information in the form of a $\texttt{starkstruct.json}$ file. It then creates a Merkle tree with the evaluations of all the constant polynomials, called the $\texttt{constTree}$
+The PIL-STARK setup takes the PIL $\texttt{.json}$ file from $\texttt{PILCOM}$, the evaluations of the constant polynomials from the $\texttt{setup}$ $\texttt{executor}$, and the STARK configuration information in the form of a $\texttt{starkstruct.json}$ file as inputs. It then creates a Merkle tree with the evaluations of all the constant polynomials, called the $\texttt{constTree}$
 
 It outputs PIL-STARK parameters; the $\texttt{constTree}$ which is a Merkle tree of evaluations of the constant polynomials, the $\texttt{starkInfo}$ which is a STARK-specific information, and the $\texttt{constRoot}$ which is the root of the $\texttt{constTree}$.
 
-Overall, the setup phase of PIL-STARK takes as inputs; the $\texttt{.pil}$ file describing the state machine and STARK-specific parameters. Its outputs are; the evaluations of the constant polynomials, the $\texttt{constTree}$, the $\texttt{starkInfo}$, the $\texttt{constRoot}$, as well as the PIL $\texttt{.json}$ file from $\texttt{PILCOM}$.
+Overall, the setup phase of PIL-STARK takes the $\texttt{.pil}$ file describing the state machine and STARK-specific parameters as inputs. Its outputs are the evaluations of the constant polynomials, the $\texttt{constTree}$, the $\texttt{starkInfo}$, the $\texttt{constRoot}$, as well as the PIL $\texttt{.json}$ file from $\texttt{PILCOM}$.
 
 We emphasise that the setup phase of PIL-STARK is run only once for a particular $\texttt{.pil}$ file describing the state machine. A change in the $\texttt{.pil}$ file means a fresh setup needs to be executed.
 
 ![PIL-STARK setup](../../../img/zkEVM/fib13-pil-stark-setup.png)
 
 ## PIL-STARK proving phase
 
-The proving phase consists of two main components; the $\texttt{SM-prover}$ $\texttt{executor}$ and the PIL-STARK proof $\texttt{Generator}$.
+The proving phase consists of two main components:
+- the $\texttt{SM-prover}$ $\texttt{executor}$.
+- the PIL-STARK proof $\texttt{Generator}$.
 
 ### SM-prover's executor
 
@@ -57,13 +59,13 @@ However, with every set of inputs, the SM-prover's executor computes correspondi
 
 ### PIL-STARK proof generator
 
-This STARK Proof Generator takes as inputs; the evaluations of the committed polynomials from the SM-prover's executor, the evaluations of the constant polynomials from the setup phase, together with the $\texttt{constTree}$ and the $\texttt{starkInfo}$.
+This STARK Proof Generator takes the evaluations of the committed polynomials from the SM-prover's executor, the evaluations of the constant polynomials from the setup phase, together with the $\texttt{constTree}$ and the $\texttt{starkInfo}$ as inputs.
 
 This is where the evaluations of the committed polynomials, from the SM-prover's executor, are Merkelized. And all elements of the ultimate STARK proof are generated, these include; the witness and the required openings of the committed polynomials.
 
 The output of the STARK Proof Generator is a $\texttt{STARK}$ $\texttt{proof}$ and the $\texttt{publics}$, which are values to be publicised.
 
-For the PIL-STARK proving phase as a whole, also as depicted in Figure 9 below,
+For the PIL-STARK proving phase as a whole, also as depicted in Figure 9 below:
 
 - there are five (5) inputs; the $\texttt{input.json}$ file, the PIL $\texttt{.json}$ file from $\texttt{PILCOM}$, the evaluations of the constant polynomials from the setup phase, as well as the $\texttt{constTree}$ and the $\texttt{starkInfo}$.
 - and there are two (2) outputs; a $\texttt{STARK}$ $\texttt{proof}$ and the $\texttt{publics}$.
@@ -76,7 +78,7 @@ The verification phase is constituted by the PIL-STARK verifier.
 
 As it is common practice amongst zero-knowledge proof-verification systems, the size of the verifier's inputs is very small compared to that of the prover's inputs. For example, while the proving phase takes the whole $\texttt{constTree}$ as one of its inputs, the verifier takes the $\texttt{constRoot}$ instead.
 
-The inputs to the verifier are; the $\texttt{STARK}$ $\texttt{proof}$ and the $\texttt{publics}$ from the prover, together with the $\texttt{starkInfo}$ and the $\texttt{constRoot}$ from the setup phase.
+The $\texttt{STARK}$ $\texttt{proof}$ and the $\texttt{publics}$ from the prover, together with the $\texttt{starkInfo}$ and the $\texttt{constRoot}$ from the setup phase are the inputs for the verifier.
 
 And the verifier's output is either an $\texttt{Accept}$ if the proof is accepted, or a $\texttt{Reject}$ if the proof is rejected.
 

docs/zkEVM/concepts/mfibonacci/verification-scheme.md

@@ -30,7 +30,7 @@ FRI is in fact a Merkle commitment scheme where commitments are roots of Merkle
 
 #### Why is FRI fast?
 
-The FRI protocol is considered fast for the following reasons.
+The FRI protocol is considered fast for the following reasons:
 
 1. Its resemblance of the ubiquitous Fast Fourier Transforms (FFTs).
 2. The strict linearity of the prover's arithmetic complexity.
@@ -43,7 +43,7 @@ We later demonstrate how PIL-STARK is used to prove polynomial identities of the
 
 Before describing PIL-STARK, let's take a look at the novel polynomial identity language (PIL), and some of its distinguishing features.
 
-### Polynomial identity language
+### Polynomial Identity Language (PIL)
 
 PIL is a domain-specific language (DSL) designed for naming polynomials and describing identities that define the computations performed by a state machine.