Fix zkEVM EGP - 2 equations

Author: EmpieichO

docs/cdk/architecture/type-1-prover/intro-t1-prover.md

@@ -1,11 +1,11 @@
-The Polygon Type 1 Prover is a zk-evm proving component used for creating proofs on your ZK-EVM chain. It has been developed in collaboration with the Toposware team.
+The Polygon type 1 prover is a ZK-EVM proving component capable of generating proofs for Ethereum blocks. It has been developed in collaboration with the Toposware team.
 
 !!! info
-    The Polygon Type 1 Prover is not yet ready for full implementation into a CDK stack.
+    The [Polygon type 1 prover](https://github.com/0xPolygonZero/zk_evm) is not yet ready for full implementation into a CDK stack.
 
 ## Get started
 
-If you want to get up and running quickly, follow the [how to deploy the Type 1 Prover guide](../../how-to/deploy-t1-prover.md).
+If you want to get up and running quickly, follow the [how to deploy the type 1 prover guide](../../how-to/deploy-t1-prover.md).
 
 !!! warning
     Throughout this section, we refer to ZK-EVM chains in a general sense and this should not be confused with Polygon's zkEVM product which is a specific example of a ZK-EVM.
@@ -30,4 +30,4 @@ The figure below gives a visual summary of the types, contrasting compatibility
 
 Ultimately, choosing which type of ZK-EVM to develop involves a trade-off between EVM-equivalence and performance.
 
-The challenge this poses for developers who favor exact Ethereum-equivalence is to devise ingenious designs and clever techniques to implement faster zk-provers. Vitalik mentions one mitigation strategy to improve proof generation times: cleverly engineered, and massively parallelized provers.
+The challenge this poses for developers who favor exact Ethereum-equivalence is to devise ingenious designs and clever techniques to implement faster zk-provers. Vitalik mentions one mitigation strategy to improve proof generation times: cleverly engineered, and massively parallelized provers.

docs/cdk/architecture/type-1-prover/t1-architecture.md

@@ -1,4 +1,4 @@
-The Polygon Type 1 Prover is designed for efficient implementation of STARK proofs and verification of Ethereum transactions. It achieves efficiency by restricting the Algebraic Intermediate Representation (AIR) to constraints of degree 3.
+The Polygon type 1 prover is designed for efficient implementation of STARK proofs and verification of Ethereum transactions. It achieves efficiency by restricting the Algebraic Intermediate Representation (AIR) to constraints of degree 3.
 
 The execution trace needed to generate a STARK proof can be assimilated to a large matrix, where columns are registers and each row represents a view of the registers at a given time.
 
@@ -25,19 +25,19 @@ In addition to the constraints of each module, this design requires an additiona
 
 For this reason, this design utilizes _Cross-table lookups_ (CTLs), based on a [logUp argument](https://eprint.iacr.org/2022/1530.pdf) designed by Ulrich Haböck, to cheaply add copy-constraints in the overall system.
 
-The Polygon Type 1 Prover uses a central component dubbed the **CPU** to orchestrate the entire flow of data that occurs among the STARK modules during execution of EVM transactions. The CPU dispatches instructions and inputs to specific STARK modules, as well as fetches their corresponding outputs.
+The Polygon type 1 prover uses a central component dubbed the **CPU** to orchestrate the entire flow of data that occurs among the STARK modules during execution of EVM transactions. The CPU dispatches instructions and inputs to specific STARK modules, as well as fetches their corresponding outputs.
 
 Note here that “dispatching” and “fetching” means that initial values and final values resulting from a given operation are being copied with the CTLs to and from the targeted STARK module.
 
 ## Prover primitives
 
-We now look at the cryptographic primitives used to engineer the Polygon Type 1 Prover, which is a custom-built prover capable of tracing, proving, and verifying the execution of the EVM through all state changes.
+We now look at the cryptographic primitives used to engineer the Polygon type 1 prover, which is a custom-built prover capable of tracing, proving, and verifying the execution of the EVM through all state changes.
 
 The proving and verification process is made possible by the zero-knowledge (ZK) technology. In particular, a combination of STARK[^1] and SNARK[^2], proving and verification schemes, respectively.
 
 ### STARK for proving
 
-The Polygon Type 1 Prover implements a STARK proving scheme, a robust cryptographic technique with fast proving time.
+The Polygon type 1 prover implements a STARK proving scheme, a robust cryptographic technique with fast proving time.
 
 Such a scheme has a proving component, called the STARK prover, and a verifying component called the STARK verifier. A proof produced by the STARK prover is referred to as a STARK proof.
 
@@ -49,20 +49,20 @@ Ultimately, this SNARK proof can stand alone or be combined with preceding block
 
 ### Plonky2 SNARK for verification
 
-The Polygon Type 1 Prover implements a SNARK called [Plonky2](https://github.com/0xPolygonZero/plonky2), which is a SNARK designed for fast recursive proofs composition. Although the math is based on [TurboPLONK](https://docs.zkproof.org/pages/standards/accepted-workshop3/proposal-turbo_plonk.pdf), it replaces the polynomial commitment scheme of [PLONK](https://eprint.iacr.org/2019/953) with a scheme based on [FRI](https://drops.dagstuhl.de/storage/00lipics/lipics-vol107-icalp2018/LIPIcs.ICALP.2018.14/LIPIcs.ICALP.2018.14.pdf). This allows encoding the witness in 64-bit words, represented as field elements of a low-characteristic field.
+The Polygon type 1 prover implements a SNARK called [Plonky2](https://github.com/0xPolygonZero/plonky2), which is a SNARK designed for fast recursive proofs composition. Although the math is based on [TurboPLONK](https://docs.zkproof.org/pages/standards/accepted-workshop3/proposal-turbo_plonk.pdf), it replaces the polynomial commitment scheme of [PLONK](https://eprint.iacr.org/2019/953) with a scheme based on [FRI](https://drops.dagstuhl.de/storage/00lipics/lipics-vol107-icalp2018/LIPIcs.ICALP.2018.14/LIPIcs.ICALP.2018.14.pdf). This allows encoding the witness in 64-bit words, represented as field elements of a low-characteristic field.
 
 The field used, denoted by $\mathbb{F}_p$ , is called Goldilocks. It is a prime field where the prime $p$ is of the form $p = 2^{64} - 2^{32} + 1$.
 
 Since SNARKs are succinct, a Plonky2 proof is published as the validity proof that attests to the integrity of a number of aggregated STARK proofs. This results in reduced verification costs.
 
-This innovative approach holds the promise of a succinct, verifiable chain state, marking a significant milestone in the quest for blockchain verifiability, scalability, and integrity. It is the very innovation that plays a central role in the Polygon Type 1 Prover.
+This innovative approach holds the promise of a succinct, verifiable chain state, marking a significant milestone in the quest for blockchain verifiability, scalability, and integrity. It is the very innovation that plays a central role in the Polygon type 1 prover.
 
 !!! info "Further reading"
 
     - The STARK modules, which are also referred to as **STARK tables**, have been documented in the Github repo [here](https://github.com/0xPolygonZero/plonky2/tree/main/evm/spec/tables). 
     - We have documented [the CPU component](t1-cpu-component.md) while the CPU logic documentation can be found in the [repo](https://github.com/0xPolygonZero/plonky2/blob/main/evm/spec/cpulogic.tex).
     - In order to complete the STARK framework, read more about the [cross-table lookups (CTLs) and the CTL protocol](t1-ctl-protocol.md) and [range-checks](t1-rangechecks.md).
-    - Details on **Merkle Patricia tries** and how they are used in the Polygon Type 1 Prover can be found [here](https://github.com/0xPolygonZero/plonky2/blob/main/evm/spec/mpts.tex). Included are outlines on the prover's internal memory, data encoding and hashing, and prover input format.
+    - Details on **Merkle Patricia tries** and how they are used in the Polygon type 1 prover can be found [here](https://github.com/0xPolygonZero/plonky2/blob/main/evm/spec/mpts.tex). Included are outlines on the prover's internal memory, data encoding and hashing, and prover input format.
 
 [^1]: STARK is short for Scalable Transparent Argument of Knowledge
 [^2]: SNARK is short for Succinct Non-interactive Argument of Knowledge.

docs/cdk/architecture/type-1-prover/t1-cpu-component.md

@@ -1,4 +1,4 @@
-The CPU is the central component of the Polygon Type 1 Prover. Like any central processing unit, it reads instructions, executes them, and modifies the state (registers and the memory) accordingly. 
+The CPU is the central component of the Polygon type 1 prover. Like any central processing unit, it reads instructions, executes them, and modifies the state (registers and the memory) accordingly. 
 
 Other complex instructions, such as Keccak hashing, are delegated to specialized STARK tables. 
 

docs/cdk/architecture/type-1-prover/t1-design-challenge.md

@@ -1,4 +1,4 @@
-The EVM wasn't designed with zero-knowledge proving and verification in mind, and this makes the design of an efficient Type 1 prover extremely challenging.
+The EVM wasn't designed with zero-knowledge proving and verification in mind, and this makes the design of an efficient type 1 prover extremely challenging.
 
 Some of the challenges stem from the way the EVM is implemented. Here are some of the discrepancies that occur when deploying the most common zero-knowledge primitives to the EVM.
 

docs/cdk/architecture/type-1-prover/testing-and-proving-costs.md

@@ -1,12 +1,12 @@
 ### Testing the prover
 
-Find a parser and test runner for testing compatible and common Ethereum full node tests against the Polygon Type 1 Prover [here](https://github.com/0xPolygonZero/evm-tests).
+Find a parser and test runner for testing compatible and common Ethereum full node tests against the Polygon type 1 prover [here](https://github.com/0xPolygonZero/evm-tests).
 
 The prover passes all relevant and official [Ethereum tests](https://github.com/ethereum/tests/).
 
 ### Proving costs
 
-Instead of presenting gas costs, we focus on the cost of proving EVM transactions with the Polygon Type 1 Prover.
+Instead of presenting gas costs, we focus on the cost of proving EVM transactions with the Polygon type 1 prover.
 
 Since the prover is more like a 'CPU' for the EVM, it makes sense to look at proving costs per VM instance used, as opposed to TPS or other benchmarks.