Merge pull request 0xPolygon#400 from 0xPolygon/learn/plonky

Learn: Plonky page

Author: kmurphypolygon

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.
 

docs/cdk/index.md

@@ -22,9 +22,9 @@ hide:
    <div class="grid-item">
       <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">

docs/cdk/overview.md

@@ -1,3 +1,7 @@
+---
+comments: true
+---
+
 Polygon Chain Development Kit (CDK) is a modular, open source software toolkit for blockchain developers which supports the installation and configuration of a variety of chain architectures. Polygon CDK empowers developers to launch new L2 chains running Polygon zkEVM technology on Ethereum or, in the future, transition existing Layer 1 (L1) chains into ZK-EVM L2s. 
 
 !!! warning "ZK-EVM versus zkEVM - term usage"

docs/cdk/version-matrix.md

@@ -1,4 +1,5 @@
 ---
+comments: true
 hide:
 - toc
 ---

docs/learn/index.md

@@ -45,6 +45,14 @@ hide:
          </div>
          <p class="feature-paragraph">Polygon security, bug bounties, and more.</p>
       </a>
+   </div>
+    <div class="grid-item">
+      <a href="./plonky">
+         <div class="product-list-item-header">
+            <div class="feature-card-heading">Plonky 2 & 3</div>
+         </div>
+         <p class="feature-paragraph">State-of-the-art cryptography libraries for developers.</p>
+      </a>
    </div>
     <div class="grid-item">
       <a href="./polygon-protocols">
@@ -57,7 +65,7 @@ hide:
    <div class="grid-item">
       <a href="./welcome">
          <div class="product-list-item-header">
-            <div class="feature-card-heading">Welcome to Polygon innovation and design</div>
+            <div class="feature-card-heading">Polygon innovation and design</div>
          </div>
          <p class="feature-paragraph">Find out what to expect from the Polygon Knowledge Layer Learn section.</p>
       </a>

docs/learn/plonky.md

@@ -0,0 +1,41 @@
+---
+comments: true
+---
+
+Plonky 2 & 3 are active research efforts into the development of libraries containing performant cryptographic functions for use in zero-knowledge proof systems.
+
+[Plonky](https://github.com/0xPolygonZero/plonky?tab=readme-ov-file) was Polygon's original implementation of a zk-SNARK computational cryptographic library based on [Plonk](https://eprint.iacr.org/2019/953) with some customizations. The original library was decommissioned in 2021 to be replaced by Plonky2.
+
+## Plonky 2
+
+Plonky2 is a performant Rust library of cryptographic functions that includes a SNARK implementation based on techniques from [Plonk](https://eprint.iacr.org/2019/953) and [FRI](https://drops.dagstuhl.de/storage/00lipics/lipics-vol107-icalp2018/LIPIcs.ICALP.2018.14/LIPIcs.ICALP.2018.14.pdf) as well as tools such as Starky. 
+
+The library has an emphasis on fast recursive techniques.
+
+Polygon's [type 1 prover](../cdk/architecture/type-1-prover/intro-t1-prover.md) system uses the Plonky2 library.
+
+### Examples
+
+The Polygon [Plonky2](https://github.com/0xPolygonZero/plonky2) repo provides some example functions that you can try out:
+
+- [`factorial`](https://github.com/0xPolygonZero/plonky2/blob/main/plonky2/examples/factorial.rs): Proving knowledge of 100 factorial.
+- [`fibonacci`](https://github.com/0xPolygonZero/plonky2/blob/main/plonky2/examples/fibonacci.rs): Proving knowledge of the hundredth Fibonacci number.
+- [`range_check`](https://github.com/0xPolygonZero/plonky2/blob/main/plonky2/examples/range_check.rs): Proving that a field element is in a given range.
+- [`square_root`](https://github.com/0xPolygonZero/plonky2/blob/main/plonky2/examples/square_root.rs): Proving knowledge of the square root of a given field element
+
+!!! tip "More info"
+    - Check out the [Plonky2 tutorial](https://polymerlabs.medium.com/a-tutorial-on-writing-zk-proofs-with-plonky2-part-i-be5812f6b798) for more information on the library and how to use it.
+    - Check out the [Plonky2 whitepaper](https://github.com/0xPolygonZero/plonky2/blob/main/plonky2/plonky2.pdf).
+
+## Plonky 3
+
+Plonky3 is an ongoing effort to provide a new and enhanced cryptographic library which aims to further improve on the speed and efficiency of recursive zero-knowledge proofs. It contains optimizations for newer CPU specifications.
+
+It implements polynomial IOPs, such as PLONK and STARKS, and commitment schemes such as [Brakedown](https://eprint.iacr.org/2021/1043.pdf). Check out the [Plonky3 README](https://github.com/Plonky3/Plonky3) for an update on what is included.
+
+Head over to the [Polygon Plonky3 repo](https://github.com/Plonky3/Plonky3) and try it out yourself.
+
+!!! tip "Learn more about Plonky 1, 2, and 3"
+    Watch the [Polygon Zero team's introduction to Plonky](https://www.youtube.com/watch?v=v9xZrhAuTio) on YouTube.
+
+</br>