Type-1 prover - deploy guide added

EmpieichO · EmpieichO · commit 428fda1ebe73 · 2024-01-30T10:42:06.000+02:00
diff --git a/docs/img/learn/gcp-vm-instance-price.png b/docs/img/learn/gcp-vm-instance-price.png
diff --git a/docs/learn/type-1-prover/deploy-t1-prover.md b/docs/learn/type-1-prover/deploy-t1-prover.md
@@ -1,4 +1,4 @@
-This document provides guidelines on how to run Polygon Zero's Type-1 prover, specifically for proving transactions, but with the option to test full blocks of less than 4M gas.
+This document provides guidelines on how to run Polygon Type-1 prover, specifically for proving transactions, but with the option to test full blocks of less than 4M gas.
 So, it is similar to [`eth-proof`](https://github.com/wborgeaud/eth-proof) but for transaction proofs.
 
 ## Quick Start
@@ -7,7 +7,9 @@ There two ways to run this prover. The simplest way to get started is
 to use the `in-memory` runtime of
 [Paladin](https://github.com/0xPolygonZero/paladin). This requires
 very little setup, but it's not really suitable for a large scale
-test. The other method for testing the prover is to leverage an
+test. 
+
+The other method for testing the prover is to leverage an
 [AMQP](https://en.wikipedia.org/wiki/Advanced_Message_Queuing_Protocol)
 like [RabbitMQ](https://en.wikipedia.org/wiki/RabbitMQ) to distribute
 workload over many workers.
@@ -19,6 +21,8 @@ workload over many workers.
 
 ### Setup
 
+Start by cloning this repo [here](https://github.com/0xPolygonZero/eth-tx-proof/tree/jhilliard/deployment).
+
 Before running the prover, you'll need to compile the
 application. This command should do the trick:
 
@@ -79,7 +83,7 @@ thumb, you'd probably want at least 8 cores per worker.
 Proving in a distributed compute environment depends on an AMQP
 server. We're not going to cover the setup of RabbitMQ, but assuming
 you have something like that available you can run a "leader" which
-distribute proving tasks to a collection of "workers" which actually
+distributes proving tasks to a collection of "workers" which actually
 do the proving work.
 
 In order to run the workers, you'll use a command like:
@@ -99,7 +103,7 @@ paladin-worker --runtime amqp --amqp-uri=amqp://localhost:5672
 This will start the worker and have it await tasks. Depending on the
 size of your machine, you may be able to run several workers on the
 same operating system. An example [systemd
-service](./deploy/paladin-worker@.service) is included. Once that
+service](https://github.com/0xPolygonZero/eth-tx-proof/blob/jhilliard/deployment/deploy/paladin-worker@.service) is included. Once that
 service is installed, you could enable and start 16 workers on the
 same VM like this:
 
@@ -121,27 +125,3 @@ paladin-leader prove \
 This command will run the same way as the `in-memory` mode except that
 the leader itself isn't doing the work. The separate worker processes
 are doing the heavy lifting.
-
-
-## Proving costs
-
-It makes sense to look at the proving costs, as opposed to TPS. 
-
-
-Based on a GCP's 3-year commitment price on a t2d-standard-60 machine, where each vCPU has 4GB memory:
-
-- $0.012376$ USD / vCPU hour
-- $0.001659$ USD / GB hour
-
- We obtain, $(60 \times 0.012376) + (240 \times 0.001659) = 1.14072$ USD. 
-
-| Block Number                                    | Transactions | Gas        | Proof Time (minutes) | Total Cost | Cost Per Tx |
-| ----------------------------------------------- | ------------ | ---------- | -------------------- | ---------- | ----------- |
-| [17106222](https://etherscan.io/block/17106222) | 105          | 10,781,405 | 44.17                | $0.235     | $0.0022     |
-| [17095624](https://etherscan.io/block/17095624) | 163          | 12,684,901 | 78.12                | $0.415     | $0.0025     |
-| [17735424](https://etherscan.io/block/17735424) | 182          | 16,580,448 | 100.52               | $0.534     | $0.0029     |
-
-
-
-
-
diff --git a/docs/learn/type-1-prover/index.md b/docs/learn/type-1-prover/index.md
@@ -0,0 +1,5 @@
+This document provides details of Polygon type-1 prover, which is a proving scheme deployed for the type-1 zkEVM developed in collaboration with the Toposware team.
+
+As per the definition of zkEVM types, it's a type-1 zkEVM as it aims at proving and enabling verification of the EVM's computational integrity.
+
+Since the design of a prover used in any zkEVM is closely related to the type of the zkEVM, this document starts with a brief discussion on the different types of zkEVMs.
diff --git a/docs/learn/type-1-prover/intro-t1-prover.md b/docs/learn/type-1-prover/intro-t1-prover.md
@@ -1,12 +1,3 @@
-This document provides details of the Polygon Zero's Type-1 zkEVM prover, which is a proving scheme deployed for the Type-1 zkEVM developed in collaboration with the Toposware team.
-
-As per definition of zkEVM types, the Polygon Zero's zkEVM is a type-1 as it aims at proving and enabling verification of the EVM's computational integrity.
-
-Since the design of a prover used in any zkEVM is closely related to the type of the zkEVM, this document starts with a brief discussion on the different types of zkEVMs.
-
-
-## Types of zkEVMs
-
 The emergence of various zkEVMs ignited the debate of how 'equivalent' is a given zkEVM to the Ethereum virtual machine (EVM).
 
 Vitalik Buterin has since introduced some calibration to EVM-equivalence in his article, "[The different types of zkEVMs](https://vitalik.eth.limo/general/2022/08/04/zkevm.html)". He made a distinction among five types of zkEVMs, which boils down to the inevitable trade-off between Ethereum equivalence and the efficacy of the zero-knowledge proving scheme involved. For brevity, we refer to this proving scheme as the zk-prover or simply, prover.
diff --git a/docs/learn/type-1-prover/t1-architecture.md b/docs/learn/type-1-prover/t1-architecture.md
@@ -1,4 +1,4 @@
-Polygon Zero's Type-1 zkEVM is designed for efficient implementation of the STARK proving and verification of Ethereum transactions. It achieves efficiency by restricting the Algebraic Intermediate Representation (AIR) to constraints of degree 3.
+Polygon Type-1 zkEVM is designed for efficient implementation of the STARK proving 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.
 
@@ -26,21 +26,21 @@ 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.
 
-Polygon Zero's Type-1 zkEVM 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.
+Polygon Type-1 zkEVM 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
 
-This document discusses the cryptographic primitives used to engineer the Polygon Zero's Type-1 zkEVM, which is a custom-built zkEVM capable of tracing, proving and verifying the execution of the EVM through all state changes.
+This document discusses the cryptographic primitives used to engineer Polygon Type-1 zkEVM, which is a custom-built zkEVM 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
 
-Polygon Zero's Type-1 zkEVM prover implements a STARK proving scheme, a robust cryptographic technique with fast proving time.
+Polygon Type-1 zkEVM 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.
 
@@ -52,25 +52,24 @@ Ultimately, this SNARK proof can stand alone or be combined with preceding block
 
 #### Plonky2 SNARK for verification
 
-The Polygon Zero's Type-1 prover implements a SNARK called [Plonky2](https://github.com/0xPolygonZero/plonky2), which is a SNARK designed for fast recursive proofs composition. Although its arithmetization 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.
+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 its arithmetization 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 Zero's Type-1 zkEVM.
-
+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 Polygon Type-1 zkEVM.
 
 
 ### Documentation remarks
 
-The documentation of the Polygon Zero's Type-1 zkEVM is still WIP, some of the documents are in the Github repo.
+The documentation of Polygon Type-1 zkEVM is still WIP, some of the documents are in the Github repo.
 
 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). The **CPU component** is documented below, while the **CPU logic** is in the [repo](https://github.com/0xPolygonZero/plonky2/blob/main/evm/spec/cpulogic.tex).
 
 In order to complete the STARK framework, the cross-table lookups (CTLs) and the **CTL protocol** can be found in this document, while **range-checks** are also discussed below.
 
-Details on **Merkle Patricia tries** and how they are used in the Polygon Zero's Type-1 zkEVM, can be found [here](https://github.com/0xPolygonZero/plonky2/blob/main/evm/spec/mpts.tex). Included in there 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 Polygon Type-1 zkEVM, can be found [here](https://github.com/0xPolygonZero/plonky2/blob/main/evm/spec/mpts.tex). Included in there are outlines on the prover's internal memory, data encoding and hashing, and prover input format.
 
 
 
diff --git a/docs/learn/type-1-prover/t1-cpu-component.md b/docs/learn/type-1-prover/t1-cpu-component.md
@@ -1,4 +1,4 @@
-The CPU is the central component of the Polygon Zero zkEVM. 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 Polygon Zero zkEVM. 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 specialist STARK tables. 
 
diff --git a/docs/learn/type-1-prover/t1-ctl-protocol.md b/docs/learn/type-1-prover/t1-ctl-protocol.md
@@ -24,11 +24,9 @@ Note that, for the sake of efficiency, the $S_1$ and $S_2$ tables are first redu
 
 And thus, this check is tantamount to ensuring that the rows of the $S_1$ table involving $Op$ are but permutations of the rows of $S_2$ that carry out $Op$.
 
-
 ![Figure: CTL permutation check](../../img/learn/t1-prover-ctl-perm-check.png)
 
 
-
 ### How the CLT proof works
 
 As outlined in the above example, verifying that shared values among STARK tables are not tampered with amounts to proving that rows of reduced STARK tables are permutations of each other.
@@ -99,19 +97,17 @@ The above three steps turn the CTL argument into a [LogUp lookup argument](https
 
 which checks for equality between $S_1'$ and $S_2'$.
 
-    
-
 
 ### CTL protocol summary
 
-The cross-table protocol can be surmised as follows. 
+The cross-table protocol can be summarized as follows. 
 
 For any STARK table $S$, the prover:
   
 -  Constructs the `looking sums`, which are the running sums $\{Z_j^l\}$ for each table looking into $S$.
 - Constructs the `looked sum`, which is the running sum $Z^S$ for $S$.
-- Sends the all final values $\{Z_{j,0}^l\}$ and $Z_0^S$ to the verifier.
-- Sends a commitment to the `looking sums` $\{Z_{j}^l\}$ and the `looked sum` $Z^S$ to the verifier.   
+- Sends all the final values $\{Z_{j,0}^l\}$ and $Z_0^S$ to the verifier.
+- Sends a commitment to the `looking sums` $\{Z_{j}^l\}$ and the `looked sum` $Z^S$ to the verifier.
 
 On the other side, and for the same STARK table $S$, the verifier:
   
diff --git a/docs/learn/type-1-prover/t1-design-challenge.md b/docs/learn/type-1-prover/t1-design-challenge.md
@@ -22,8 +22,7 @@ Some of the challenges stem from the way the EVM is implemented. Here are some o
 
     While Keccak is fairly efficient on a CPU, since Plonky2 implements polynomials of degree 3, Keccak operations would need to be expressed as constraints of degree 3. This results in an extremely heavy Algebraic Intermediate Representation (AIR) compared to some of the most recent [STARK-friendly](https://eprint.iacr.org/2020/948.pdf) hash functions, tailored specifically for zero-knowledge proving systems.
 
-    Although the EVM supports precompiles of hash functions such as SHA2-256, RIPEMD-160, and Blake2f, they are all quite heavy for our proving system.
+    Although the EVM supports precompiles of hash functions such as SHA2-256, RIPEMD-160, and Blake2f, they are all quite heavy for a ZK proving system.
   
   4. **State representation**: Ethereum uses Merkle Patricia Tries with RLP encoding. Both of these are not zero-knowledge-friendly primitives, and incur huge overheads on transaction processing within a zkEVM context.
-
   
diff --git a/docs/learn/type-1-prover/testing-and-proving-costs.md b/docs/learn/type-1-prover/testing-and-proving-costs.md
@@ -0,0 +1,31 @@
+### Testing the zkEVM 
+
+Find a parser and test runner for testing compatible and common Ethereum full node tests against Polygon type-1 zkEVM, here https://github.com/0xPolygonZero/evm-tests.
+
+Polygon type-1 zkEVM 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 Polygon type-1 prover.
+
+Since Polygon type-1 zkEVM 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.
+
+Consider the table below for prices of GCP's specific instances, taken from [here](https://cloud.google.com/compute/all-pricing), and webpage accessed on the 29th January, 2024. 
+
+![Figure: GCP's vm instance price](../../img/learn/gcp-vm-instance-price.png)
+
+Take the example of a t2d-standard-60 GCP instance, where each vCPU has 4GB memory, based on GCP's Spot prices:
+
+- 0.00346 USD / vCPU hour
+- 0.000463 USD / GB hour
+
+We obtain the following hourly cost, $(60 \times 0.00346) + (240 \times 0.000463) = 0.31872$ USD per hour. 
+The total cost per block is given by: $\texttt{(Proving time per hr)} \times 0.31872$.
+
+The table below displays proving costs per transaction per hour.
+
+| Block number                                    | Transactions | Gas        | Proof time (minutes) | Total cost (USD) | Cost per tx (USD)|
+| ----------------------------------------------- | ------------ | ---------- | -------------------- | ---------- | ----------- |
+| [17106222](https://etherscan.io/block/17106222) | 105          | 10,781,405 | 44.17                | $0.235     | $0.0022     |
+| [17095624](https://etherscan.io/block/17095624) | 163          | 12,684,901 | 78.12                | $0.415     | $0.0025     |
+| [17735424](https://etherscan.io/block/17735424) | 182          | 16,580,448 | 100.52               | $0.534     | $0.0029     |
diff --git a/mkdocs.yml b/mkdocs.yml
@@ -552,11 +552,13 @@ nav:
       - Aggregation layer: learn/agglayer.md
       - Polygon protocols: learn/polygon-protocols.md
       - Polygon 2.0 architecture: learn/deep-dive-arch.md
-      - Polygon Zero type-1 zkEVM: 
-          - Introduction: learn/type-1-prover/intro-t1-prover.md
+      - Polygon type-1 zkEVM:
+          - Polygon type-1 zkEVM: learn/type-1-prover/index.md 
+          - Types of zkEVMs: learn/type-1-prover/intro-t1-prover.md
           - Type-1 design challenges: learn/type-1-prover/t1-design-challenge.md
           - Architectural overview: learn/type-1-prover/t1-architecture.md
           - How to run the type-1 prover: learn/type-1-prover/deploy-t1-prover.md
+          - Tests and proving costs: learn/type-1-prover/testing-and-proving-costs.md
           - CPU component: learn/type-1-prover/t1-cpu-component.md
           - CTL protocol: learn/type-1-prover/t1-ctl-protocol.md
           - Range checks: learn/type-1-prover/t1-rangechecks.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 Zero zkEVM. 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 Polygon Zero zkEVM. 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 specialist STARK tables.`
`4`	`4`