This thesis is a comprehensive writeup on Plonky2. As you may know, zero-knowledge proofs (especially in their modern forms as zk-SNARKs and zk-STARKs) are evolving rapidly both in academia and in the industry. In the industry-focused zk world, there's a strong emphasis on performance and real-world efficiency, often demonstrated through benchmarking implementations. However, the available documentation and related papers are often poorly written or incomplete. Typically, they outline which cryptographic modules are used in a given SNARK and briefly describe how they fit together, but they often leave out a deeper explanation of why these choices work, leaving the reader to figure it out on their own.
Plonky2 is a prime example of this situation. It is a powerful zero-knowledge proof system that aims to merge the best features of SNARKs and STARKs, namely succinctness and transparency. This combination makes Plonky2 one of the most promising tools for recursive proofs. While it may seem exciting at first glance, a deeper exploration quickly reveals the complexity and confusion surrounding its inner workings.
Recursive proofs are one of the core innovations that make Plonky2 particularly compelling. zk-SNARKs produce a succinct proof attesting to the correctness of a given computation, but recursive SNARKs take this a step further. They allow a proof to contain and verify another proof. In practice, this means that rather than verifying a large computation all at once, we can prove it in steps, with each step verifying the previous one. This enables incremental and composable verification of long or indefinite computations, which is especially useful when the total computation cannot be known or stored upfront. Such recursive composition is what allows systems like Plonky2 to efficiently construct proofs for things like blockchain state updates, rollups, or vote tallying, one step at a time.
In this thesis, I break down how Plonky2 operates, examine its individual components, and trace the reasoning behind their selection by referencing prior related work. Each module and technique is situated within the broader context of previous constructions, providing clarity not just about how Plonky2 works, but why it was built this way. This case study serves not only as an in-depth explanation of Plonky2 itself but also as a gateway for understanding modern recursive zk-SNARKs more generally, making it a helpful real-world example for those entering the zero-knowledge space.