@zpoken.near [Posted on DevHub](https://near.social/#/devgovgigs.near/widget/Post?id=1019) ## Solution: ZK Light Client | June - July 2023 Report ###### Requested amount: 28000 USDC ###### Requested sponsor: @neardevgov.near During our research and implementation of ZK Light Client in June - July we have following results: Different proof systems have a vast list of features and limitations. The Plonky2 proof system was initially chosen because of its ability to create recursive proofs. This makes it possible to create compact proofs of large computations and easily accommodate various private and public inputs. However, during testing, it turned out that on-chain verification of such proofs requires too much gas in the Ethereum network. It is closely corresponding with other research and previous calculations. Therefore, we spent a time researching other proof systems that have a cheaper way of verifying on the blockchain. Of these systems, only Circom was affordable and had the ability to integrate another proof system into it. The gas price could be explained by the small proof size, types of underlying computations, and number of constraints. That is why we decided to use Circom. To implement the transition between systems, you need to create a circuit in Circom that verifies computation of proof verification of Plonky2. The exact approach of nested verification is the following: 1. Create Plonky2 proof of the desired computation: - Build circuit. - Generate proof. - Convert circuit and proof into JSON for Circom input. 2. Create Circom proof of the Plonky2 verification: - Generate trusted setup. Groth16 requires a separate trusted setup for each circuit. This generates a common reference string (CRS), which is stored in a .zkey file. - Verify final zkey. - Export verification key. The verifier does not need the full zkey to verify a Groth16 proof. They only require a shorter verification key. - Generate witness for Plonky2 data (1.c). - Generate proof with witness and verification key. 3. Write a verifier program for Circom verification. 4. Verify on-chain Circom proof that verifies validity of Plonky2 circuit with corresponding data. Circom implementation of Plonky2 verification requires following the exact algorithm. The best way to accomplish it is to break down verification to separate circuits that copy behavior of different modules or even functions used in the Plonky2 library. For instance, All FRI completed inside one Circom circuit. Almost every library function from that module is implemented as a template (circuit function analogy) in Circom. The main problem of Circom implementation is the abundance of signals to provide all data movement and operations. This leads to a large size of the final circuit and corresponds to an extremely long ZKEY generation – 3+ hours on a production server with 128 GB of RAM. Full report: https://github.com/ZpokenWeb3/zk-light-client-implementation/blob/main/reports/Report%2010.08.2023%20ZKP%20for%20Near%20Blocks%20Proving.pdf Feel free to ask us any questions in Reply to this post.