How To Design A Better Proof Recursion Scheme?

Almost all the problems encountered in the zkRollup and zkEVM tracks are essentially algorithmic problems. The main reason why ZK-Proof hardware acceleration is frequently mentioned is that current algorithms are generally slow.

In order to avoid falling into the embarrassing situation of “the algorithm is not enough, the hardware is used to make up,” we should solve the problem from the essence of the algorithm. Designing an exquisite delivery-proof recursion scheme is the key to solving this problem.

With the continuous development of smart contracts, more and more Web3 applications are gradually coming out, and the transaction volume of traditional Layer 1, such as Ethereum, is rising rapidly, and congestion may occur at any time. How to obtain higher efficiency while ensuring the security provided by Layer 1 has become an urgent problem to be solved.

For Ethereum, zkRollup uses the zero-knowledge proof algorithm as the underlying component to move the expensive calculations that originally needed to be performed on Layer 1 off-chain and provide proof of execution correctness to the chain. The track includes projects such as StarkWare, zkSync, Scroll, and Fox Tech.

In fact, in the design of zkRollup, there are very high requirements for efficiency: it is hoped that the submitted proof value is small enough, can reduce the amount of calculation of Layer 1. In order to obtain a sufficiently small proof length, each zkRollup project is improving the algorithm and architecture design. For example, Fox has developed its proof algorithm FOAKS in combination with the latest zero-knowledge proof algorithm to obtain the optimal proof time and proof length.

In addition, in the stage of verifying proofs, the most trivial means is to generate proofs linearly and verify them sequentially. In order to improve efficiency, the first thing everyone thinks of is to pack multiple proofs into one proof, commonly referred to as Proof Aggregation.

Intuitively speaking, verifying the proofs generated by zkEVM is a linear process, and the Verifier needs to verify each generated proof value in turn. However, the efficiency of this verification method is relatively low, and the communication overhead is relatively large. For the zkRollup scenario, higher verifier-side overhead means more Layer 1 calculations, which will also lead to higher Gas fees.

Let’s look at an example first: Alice wants to prove to the world that she went to Fox Park from the 1st to the 7th of this month. For this reason, she can take a photo in the park with the day’s newspaper on each day from the 1st to the 7th, and these seven photos will become proof.

Putting seven photos directly into an envelope in the above example is proof aggregation in an intuitive sense, which corresponds to connecting different proofs together and verifying them linearly in sequence, that is, verifying the first proof first and then verifying the second proof.

Two proofs and subsequent proofs. The problem is that this approach will neither change the size of the proof nor the time of the proof, which is the same as proving and verifying one by one. If you want to achieve logarithmic space compression, you need to use the Proof Recursion mentioned below.

Proof recursion scheme used by Halo2 and STARK

In order to better explain what a recursive proof is, let’s go back to the above example.

Alice’s seven pictures are seven proofs. Now consider merging them, so Alice can take a photo on the 1st, take this photo on the 2nd and the newspaper on the 2nd, and take the photo on the 2nd and the newspaper on the 3rd photo. By analogy, Alice took the last photo on the 7th with the photo of the 6th and the newspaper on the 7th, and other friends can verify that they are on the 1st to 7th when they see the last photo of the 7th.

Alice all went to the park. It can be seen that the previous seven proof photos have been compressed into one. And a key skill in this process is “photos containing photos,” which is equivalent to recursively nesting previous photos into subsequent photos. It’s different from putting together a lot of photos and taking one photo.

The recursive proof trick of zkRollup can greatly compress the proof size. Specifically, each transaction will generate proof. We set the original transaction calculation circuit as C0, P0 as the correctness proof of C0, and V0 as the calculation process of verifying P0.

Prover also converts V0 into the corresponding circuit, denoted as C0′. Currently, for the proof calculation process, C1 of another transaction, the circuits of C0′ and C1 can be merged. In this way, once the correctness proof P1 of the merged circuit is verified, it is equivalent to verifying the above two circuits at the same time. The correctness of the transaction, that is, the compression, is achieved.

Looking back at the above process, it can be found that the principle of compression is to convert the process of verification and proof into a circuit and then generate “proof for the proof” so from this perspective, it is an operation that can continuously recurse downwards, so Also known as a recursive proof.

The Proof Recursion scheme adopted by Halo2 and STARK can generate proofs in parallel and combine multiple proofs, so that the correctness of multiple transaction executions can be verified while verifying a proof value, which can compress the calculation overhead, thereby greatly improve the efficiency of the system.

However, such optimization still stays at the level above the specific zero-knowledge proof algorithm. In order to further improve efficiency, we need lower-level optimization and innovation. The FOAKS algorithm designed by Fox does this by applying recursive ideas inside a proof to this point.

Proof recursion scheme used by FOAKS

Fox Tech is a zkEVM-based zkRollup project. In its proof system, the technique of recursive proof is also used, but the connotation is different from the above-mentioned recursive method. The main difference is that Fox uses the idea of Recursion inside a proof. In order to express the core idea of the recursive proof used by Fox to continuously reduce the problem to be proved until the reduced problem is simple enough, we need to give another example.

In the above example, Alice proves that she went to Fox Park on a certain day by taking a photo, so Bob puts forward a different suggestion. He thinks that the problem of proving that Alice has been to the park can be reduced to proving that Alice’s mobile phone has been to the park. And proving this matter can be reduced to proving that the location of Alice’s mobile phone is within the scope of the park.

Therefore, in order to prove that Alice has been to the park, she only needs to send a location with her mobile phone while she is in the park. In this way, the size of the proof is changed from a photo (very high-dimensional data) to 3-dimensional data (latitude, longitude, and time), effectively saving costs.

This example is not entirely appropriate because some people may question that Alice’s mobile phone has been to Fox Park does not mean that Alice has been there, but in actual situations, this reduction process is strictly mathematical.

Specifically, the use of Fox’s recursive proof is recursion at the circuit level. When performing zero-knowledge proof, we will write the problem to be proved into a circuit and then calculate some equations that need to be satisfied through the circuit. And instead of showing that these equations are satisfied, we write these equations as circuits again, and so on, until finally, the equations to prove satisfaction become simple enough that we can easily prove it directly.

From this process, we can see that this is closer to the meaning of “recursion.” It is worth mentioning that not all algorithms can use this recursive technique, assuming that each recursion will change the proof of complexity O(n) into a proof of O(f(n)) and the calculation of the recursive process itself.

The complexity is O(g(n)), then the total computational complexity becomes O1(n)=O(f(n))+O(g(n)) after one recursion, and O2(n) after two recursions )=O(f(f(n)))+O(g(n))+O(g(f(n))), after three times it is O3(n)=O(f(f(f(n) )))+O(g(n))+O(g(f(n)))+O(g(f(f(n)))), …, and so on.

Therefore, such a recursive technique can work effectively only when the two functions of f and g corresponding to the characteristics of the algorithm satisfy Ok(n)<O(n) for a certain k. In Fox, this recursive technique is effectively used to compress the proof complexity.

Conclusion

The complexity of the proof has always been one of the most important keys in the application of zero-knowledge proofs. The nature of the proof complexity will become more and more important as the things to be proved become more and more complex, especially in giant ZK applications like zkEVM.

In the scenario, the complexity of proof will have a decisive impact on product performance and user experience. Among the many ways to reduce the complexity of the final proof, the optimization of the core algorithm is the most important.

Fox has designed an exquisite delivery proof scheme based on the most cutting-edge algorithm and uses this technology to create the most suitable zkEVM. The ZK-FOAKS algorithm is expected to become the performance leader in the zkRollup industry.

DISCLAIMER: The Information on this website is provided as general market commentary and does not constitute investment advice. We encourage you to do your own research before investing.

Join us to keep track of news: https://linktr.ee/coincu

Harold

Coincu News