Guy

For anyone starting to study ZK, I still believe Pinocchio/Groth16 is the best place to start. You need some background, but finite fields and elliptic curve cryptography are already familiar territory for much of the Web3 community. Groth16 is non-interactive, so it doesn't need Fiat–Shamir. It doesn't need commitment schemes either. And the core idea isn't that complicated, especially if you learn Pinocchio first. Some people think Groth16 is outdated. I disagree. Even if it is, I think it provides a solid foundation for understanding what a SNARK is, and, just as importantly, why we need to go beyond Groth16.

One interesting thing about writing about PLONK for the ZK Book is that you need to introduce concepts that weren’t necessary for Groth16, such as roots of unity, permutations, IOPs, polynomial commitment schemes, and the Fiat-Shamir transform. At this point, PLONK complements what you learned with Groth16. It also introduces Plonkish arithmetization to those who have already studied R1CS. Later, when you get to STARKs, you need to dive deeper into coding theory to understand FRI, as well as learn a new arithmetization, AIR, which is better suited for proving structured computations. And this just for SNARKs based on univariate polynomials.

While studying PLONK, I came across several resources, and I would recommend two of them in particular: the LambdaClass article and a lecture by Dan Boneh for a 2023 MOOC. David Wong also has a series of short videos that are well worth watching. The LambdaClass article is the best one, in my opinion, because it lays out all the calculations in detail. It doesn't present a simplified version or try to explain things through heuristics. However, it can be a difficult read, and some steps lack motivation. I wasn't particularly fond of some other articles and series on PLONK. They try to make things easier by explaining highly simplified versions that have little connection to actual practice, or they simply provide a set of recipes to follow. PLONK is not easy, especially its copy constraints. The problem isn't the general idea, but the details. Why cosets? Why are the permutation functions defined this way? Why do we need the accumulator? One problem with many mathematical articles is that their answer often boils down to: "Trust me, bro, this works."