These are not ideas, just a collection of my(No cryptography background) experiences while learning Groth16, Plonk, Stark. # How and Why Zk-Snark works (2019) The paper with the specified title is a very good introduction on how zk snarks works. It felt very thorough, easy to follow. Following through you end up with ability to build a zk system yourself. Highly recommend to anyone starting out. At the end there are some cryptography blackbox involved like pairing. I still don't know the math/algo behind pairing only the name "weil pairing". And that's okay my intention was to specifically focus on zk, otherwise you'd endup lost in the vast world of number theory and abstract algebra. # Abstract algebra C Pinter Book This is a very good book for self studying abstract algebra. But once I tried to rush the book, and it felt very annoying. The theory on each chapters are very short and quick read (20-30 min) max. Then you have 7 section exercises with 7-8 exercise per section that's roughly 50+ exercise per chapter. It's 20 min of theory per chapter then followed by excruciating 5-6 days of solving excercise. I'm still going through with it. But one thing that changed or something I realized is that, these exercises are not for "**space repetition**" but rather practice for improving my mathematical reasoning. Now I focus less on actually solving those exercises and more on trying to reason my way out. That has been much fulfilling. I'd definitely not recommend the book to someone who's not willing to put in atleast an hour for 5-6 month straight. The book does seem to lack good amount of content aswell, but overall if you have time it's a must go to book. After I complete it, i'm planning to pick up some book on algebraic geometry, but that may take some time. # Groth16 Groth16 felt very much similar to the whole "**How and Why zk snark works**" paper. The constructions were very similar. I don't remember much but, it was all about powers of tau ceremony, and use the contributed randomness to generate SRS. Then you split the SRS component to be used as proving and verification key which is used by prover and verifier to verify the polynomials. Math is quite simple and easy enough to derive. Proof sizes are small, additionally the same cryptographic black box pairing, elliptical curves. Every thing was about quotient polynomial and verifying it's validity. Wierdly proper write up on groth16 were quite few (probably has improved), didn't like the moonmath manual write up. Rareskill, lamdaclass, risencrypto has very good writeup on groth16. Only problem with it felt like trusted setup, otherwise is very succinct. PS. Groth16 paper was absolutely horrible (from reading perspective). Maybe it's academia thing, but was unreadable to me. # PLONK Learning plonk was confusing and very big step up of complexity from groth16. In groth16 you just needed R1CS -> QAP then simple proof system. Plonk was like walking on a pike for some wierd reason. Thankfully mayazk had a good writeup on necessary pieces to explain plonk's every round. Prior to plonk, risen crypto's blog on KZG is a must. Working parts on plonk was much larger, you had to satisfy gate constraints then permutation constraints, then batch things up efficiently with few tricks like Maller optimization. There are many nuance tricks that you only realize when you actually implement plonk. PLONK paper with some effor is much much readable than groth16. With so much complexity and moving parts you end up with reusable setup bounded by some degree or number of gates. Which also is in a way a constraint because you need dummy gates if your circuit size is smaller. Fiat shamir is in principle very easy to implement but, alot of soundness attacks may come from improper implementation of fiat shamir which I don't know the entire details of. Notable culture of the industry is to make variation of plonk with plonk as suffix, eg: goblinplonk, hyperplonk, turboplonk etc. # STARK I'm still working my way in stark, but stark feels way simpler in construction, in comparison to plonk. It is in a way much elegant on how it achieves validity without trusted setup. Of course the tradeoff is obviously the proof size is too large. But that i believe is solvable. STARK is much simpler in a sense, you do arithmetization to get bunch of constraints: boundary and other constraints.Then you reformulate the constraints into problem of closeness to low degree polynomial. You do some merkle commitments and slap FRI on top of it to get a sound protocol. It's a much simpler approach, only in hindsight. Because the complexity lies on soundness, wierdly it's also tied the efficiency of the protocol itself. The base conjecture is known as proximity gap of reed solomon codes. It focuses on how if RS codes are close to polynomial of low degree, then the folded code is also close to low degree. Respecively, if RS codes are delta far aka far from polynomial of low degree then folded codes are also far from low degree polynomial. Every round of FRI you end up computing large no of merkle proof of vector commitment then fold on a smaller domain and so on. The larger the number of rounds the more sound the protocol is but you get larger proofs. But this does give a direction on how to get an ideal FRI. Assume we have some code **X** which is closer to low low degree polynomial remains close when folded just like RS codes but in the case when the code are far from low degree polynomial the codes get much much farther after folding procedure. In that way we'll be quite sure with fewer rounds of FRI that the RS code is close to low degree polynomial or now. Sounds easy, but even proving proxmitiy gap for RS code is non trivial. But I do hope we'll find the **X** code and solve zk. Could just only be my naive assumption though. It was naive. Does such code even exist while still with good rate and distance. Does bounds even allow it? All i'm left is with questions. The space is too vast, better to reason about what parameters you need to optimize for then explore associated asymptotic bounds. # Applied zk ZK research is very hard. Applied zk is not easy either. The biggest issue is that we don't have an ideal DSL for zk. Anything beyond Circom and Noir is just nightmare. Haven't checked out how Cairo has improved recently, but 2-3 years ago Cairo was a complete nightmare. Noir feels very much like rust, don't have much experience with it but the i believe the proof size are much larger. Circom is mostly groth16 and plonk. Therefore is ideal for efficient verification onchain. But Circom is hard to write, it's very easy to end up with code full of vulnerabilities like underconstraint circuit. Even understanding what you're doing in circom is much easier once you have studied and written a proof system or two. Otherwise, it's very hard to gain an intuition about what constraint is, what witness is, what even is a setup? etc. Ofcourse you can't end the conversation without talking about ZKVM. Would love to work on and learn more about ZKVMs. They are very expensive though, compared with cricom groth16, but they do allow user to easily prove program written in normal languages like rust. UX wise it's much friendlier, intuitive, no headache of writing and worrying about circuits. You're as secure as the zkvm itself. It's effectively some form of stark with recursion and groth16 at the end, atleast RISC 0's zkvm works that way i presume. As long as you don't have the ideal cheapest zk system, you'll always end up with either choosing DSL like circom,noir vs ZKVM like SP1, Risc0, Jolt etc. # Things that I don't know There's alot of things that I don't know like: folding, aggregation, recursion, zkvm, sumcheck, gkr, binary fields, multivariate polynomial proof system, high performance snarks on gpu/dedicated chips, other commitment schemes, zk friendly hash functions etc. I wonder how much you really need, every day you get something new like lattice based snarks, lattice folds etc. Design space has gotten much larger, and the resources has gotten much thinner. I mean it's almost 2026 it's still hard to find decent resource on PLONK which came out in 2019. # What I would like there to be more One thing I'd like people to talk about more is this simple abstraction like Linear PCP, Polynomial IOP, IP, Random oracle etc. It's quick to get lost if you don't know what these protocols are from the outside. I think there should be more explanations on abstractions like choice of fields, choice of commitment schemes, proof system categorization etc. I'd also like If the community in applied and theoretical zk were more active, it's very close to dead now except few like zkhack.