find replace again

kmurphypolygon · kmurphypolygon · commit 9360c2a3a3d7 · 2024-02-08T20:23:26.000+01:00
diff --git a/docs/cdk/architecture/type-1-prover/intro-t1-prover.md b/docs/cdk/architecture/type-1-prover/intro-t1-prover.md
@@ -1,4 +1,4 @@
-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 used for creating proofs on your ZK-EVM chain. It has been developed in collaboration with the Toposware team.
 
 ## Get started
 
@@ -15,7 +15,7 @@ Vitalik Buterin has since introduced some calibration to EVM-equivalence in his
 
 The types, as outlined by Vitalik, are as follows;
 
-- **Type-1** ZK-EVMs strive for full Ethereum-equivalence. These types do not change anything in the Ethereum stack except adding a zk-prover. They can therefore verify Ethereum and environments that are exactly like Ethereum.
+- **Type 1** ZK-EVMs strive for full Ethereum-equivalence. These types do not change anything in the Ethereum stack except adding a zk-prover. They can therefore verify Ethereum and environments that are exactly like Ethereum.
 - **Type-2** ZK-EVMs aim at full EVM-equivalence instead of Ethereum-equivalence. These ZK-EVMs make some minor changes to the Ethereum stack with the exception of the Application layer. As a result, they are fully compatible with almost all Ethereum apps, and thus offer the same UX as with Ethereum.
 - **Type-2.5** ZK-EVMs endeavor for EVM-equivalence but make changes to gas costs. These ZK-EVMs achieve fast generation of proofs but introduces a few incompatibles.
 - **Type-3** ZK-EVMs seek to be EVM-equivalent but make a few minor changes to the Application layer. These type of ZK-EVMs achieve faster generation of proofs, and are not compatible with most Ethereum apps.
diff --git a/docs/cdk/architecture/type-1-prover/t1-architecture.md b/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.
diff --git a/docs/cdk/architecture/type-1-prover/t1-cpu-component.md b/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. 
 
diff --git a/docs/cdk/architecture/type-1-prover/t1-design-challenge.md b/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.
   
diff --git a/docs/cdk/architecture/type-1-prover/testing-and-proving-costs.md b/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.
 
diff --git a/docs/cdk/how-to/deploy-t1-prover-devnet.md b/docs/cdk/how-to/deploy-t1-prover-devnet.md
@@ -58,9 +58,9 @@ Running a devnet like this provides the best way to understand Ethereum proof-of
 -   The Prysm client's REST APIs are available at `http://beacon-chain:3500`. For more info on what these APIs are, see [here](https://ethereum.github.io/beacon-APIs/)
 -   The Prysm client also exposes a gRPC API at `http://beacon-chain:4000`.
 
-## Type-1 prover testing procedure
+## Type 1 prover testing procedure
 
-The aim of this devnet setup is to use Polygon Type-1 Prover to test Erigon state witnesses.
+The aim of this devnet setup is to use Polygon Type 1 Prover to test Erigon state witnesses.
 
 The following steps create some test data.
 
diff --git a/docs/cdk/how-to/deploy-t1-prover.md b/docs/cdk/how-to/deploy-t1-prover.md
@@ -1,4 +1,4 @@
-This document shows you how to run the Polygon Type-1 Prover, specifically for proving transactions, but with the option to test full blocks of less than 4M gas, which means it is similar to [`eth-proof`](https://github.com/wborgeaud/eth-proof) but for transaction proofs.
+This document shows you how to run the Polygon Type 1 Prover, specifically for proving transactions, but with the option to test full blocks of less than 4M gas, which means it is similar to [`eth-proof`](https://github.com/wborgeaud/eth-proof) but for transaction proofs.
 
 ## Quick start
 
diff --git a/docs/cdk/index.md b/docs/cdk/index.md
@@ -20,11 +20,11 @@ hide:
 
 <div class="grid-container">
    <div class="grid-item">
-      <a href="./architecture/type-1-prover/intro-t1-prover">
+      <a href="./architecture/Type 1-prover/intro-t1-prover">
          <div class="product-list-item-header">
-            <div class="feature-card-heading">Polygon Type-1 Prover</div>
+            <div class="feature-card-heading">Polygon Type 1 Prover</div>
          </div>
-         <p class="feature-paragraph">Find out about the Polygon Type-1 Prover component.</p>
+         <p class="feature-paragraph">Find out about the Polygon Type 1 Prover component.</p>
       </a>
    </div>
    <div class="grid-item">
diff --git a/docs/zkEVM/architecture/protocol/zkevm-bridge/exit-tree.md b/docs/zkEVM/architecture/protocol/zkevm-bridge/exit-tree.md
@@ -2,7 +2,7 @@ The zkEVM's Bridge SC utilizes a special Merkle Tree called Exit Tree for each o
 
 The term Exit Tree refers to an append-only Sparse Merkle Tree (SMT) whose leaf nodes record information about assets being transferred out of the network. Exit Trees of depth 32 are used by Polygon zkEVM.
 
-From now on, a leaf of an exit tree is referred to as a exit leaf. Exit leaves are classified into two types: type 0 for recording asset(s) information and type 1 for recording messaging information.
+From now on, a leaf of an exit tree is referred to as a exit leaf. Exit leaves are classified into two types: type 0 for recording asset(s) information and Type 1 for recording messaging information.
 
 An exit leaf, in particular, is a Keccak256 hash of the ABI encoded packed structure with the following parameters:
 
diff --git a/mkdocs.yml b/mkdocs.yml
@@ -81,18 +81,18 @@ nav:
               - Start services: cdk/get-started/deploy-rollup/start-services.md
         - Connect to CDK testnet: cdk/get-started/connect-testnet.md
       - How to:
-        - Run type-1 prover quickly: cdk/how-to/deploy-t1-prover.md
-        - Deploy type-1 prover on devnet: cdk/how-to/deploy-t1-prover-devnet.md
+        - Run Type 1 prover quickly: cdk/how-to/deploy-t1-prover.md
+        - Deploy Type 1 prover on devnet: cdk/how-to/deploy-t1-prover-devnet.md
         - Manage allowlists with policies: cdk/how-to/manage-policies.md
       - Architecture:
-        - Polgon Polygon Type-1 Prover:
-          - Introduction and definitions: cdk/architecture/type-1-prover/intro-t1-prover.md
-          - Type-1 design challenges: cdk/architecture/type-1-prover/t1-design-challenge.md
-          - Architectural overview: cdk/architecture/type-1-prover/t1-architecture.md
-          - Tests and proving costs: cdk/architecture/type-1-prover/testing-and-proving-costs.md
-          - CPU component: cdk/architecture/type-1-prover/t1-cpu-component.md
-          - CTL protocol: cdk/architecture/type-1-prover/t1-ctl-protocol.md
-          - Range checks: cdk/architecture/type-1-prover/t1-rangechecks.md
+        - Polgon Polygon Type 1 Prover:
+          - Introduction and definitions: cdk/architecture/Type 1-prover/intro-t1-prover.md
+          - Type 1 design challenges: cdk/architecture/Type 1-prover/t1-design-challenge.md
+          - Architectural overview: cdk/architecture/Type 1-prover/t1-architecture.md
+          - Tests and proving costs: cdk/architecture/Type 1-prover/testing-and-proving-costs.md
+          - CPU component: cdk/architecture/Type 1-prover/t1-cpu-component.md
+          - CTL protocol: cdk/architecture/Type 1-prover/t1-ctl-protocol.md
+          - Range checks: cdk/architecture/Type 1-prover/t1-rangechecks.md
         - DAC: cdk/architecture/dac.md
       - Specification:
         - Validium vs rollup: cdk/spec/validium-vs-rollup.md

Original file line number	Diff line number	Diff line change
`@@ -1,4 +1,4 @@`
`1`		`-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.`
	`1`	`+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.`
`2`	`2`
`3`	`3`	`Other complex instructions, such as Keccak hashing, are delegated to specialized STARK tables.`
`4`	`4`
Original file line number	Diff line number	Diff line change
`@@ -1,4 +1,4 @@`
`1`		`-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.`
	`1`	`+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.`
`2`	`2`
`3`	`3`	`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.`
`4`	`4`
Original file line number	Diff line number	Diff line change
`@@ -1,4 +1,4 @@`
`1`		-This document shows you how to run the Polygon Type-1 Prover, specifically for proving transactions, but with the option to test full blocks of less than 4M gas, which means it is similar to [`eth-proof`](https://github.com/wborgeaud/eth-proof) but for transaction proofs.
	`1`	+This document shows you how to run the Polygon Type 1 Prover, specifically for proving transactions, but with the option to test full blocks of less than 4M gas, which means it is similar to [`eth-proof`](https://github.com/wborgeaud/eth-proof) but for transaction proofs.
`2`	`2`
`3`	`3`	`## Quick start`
`4`	`4`