Follow every step from a coin-flip challenge to a rollup proof, so you can tell a sound construction from a broken one yourself.
You can already call a zero-knowledge library. You hand it a witness, you get a few hundred bytes back, a verifier returns true, and you have no idea why anyone should believe it. That gap gets uncomfortable the moment you have to choose a proof system, review someone else’s circuit, or defend a scheme that claims to leak nothing. This course closes it with mathematics you can check by hand. You begin with the groups, finite fields and polynomials every construction reuses, build the three-round Sigma protocol, make it non-interactive with the Fiat-Shamir transform, then commit to polynomials using KZG and FRI. From there you rewrite a program as a Rank-1 Constraint System (R1CS), lift it into a Quadratic Arithmetic Program, and follow it into Groth16 and PLONK — the succinct non-interactive arguments of knowledge (SNARKs) — and into STARKs, the scalable transparent arguments that need no trusted setup. Every step is worked in Python with small primes and printable witnesses, and every step ends by corrupting the witness so you watch the check fail.
Built by Lakshya Kumar
Paste this into any AI chat. Fill in the bracketed parts with your context — you'll get back a straight answer on whether this belongs on your plate.
We grant free access case-by-case — students, career-switchers, builders on a tight budget. Sign in to send us a note.
Sign in to applyFinished the tasks? Take the prompt to your AI and get tested on it. We copy the prompt and open the app — just paste it in.
A handful of random questions can pin down a claim no verifier could ever check alone — that trick is the root of everything that follows.
The 3-round commit-challenge-response template that powers Schnorr, ring signatures, and every classical proof of knowledge.
Swap the live verifier for a hash function and your interactive protocol becomes a signature anyone can check later, offline.
This is the piece every modern proof shrinks down to; pick the wrong one and you inherit a trusted setup or a proof ten times too big.
Nothing gets proved until your computation is rewritten as multiplication constraints — this is where the maths meets your actual code.
Thousands of constraints collapse into a single divisibility test, and that collapse is what makes a proof short enough to post on-chain.
Three group elements settle the whole claim — the price is a setup ceremony that must be run honestly, once, for every circuit you ship.
Change the circuit without redoing the ceremony — the reason most production rollups reached for this system instead of Groth16.
Hashes replace pairings, so there is no ceremony to trust and nothing a quantum computer breaks — the cost is a far larger proof.
Complete all modules, then submit the required number of capstone projects. Each must earn a passing rating from an admin reviewer.
Choose one: implement the Schnorr identification protocol and convert to a Fiat-Shamir NIZK with a special-soundness extractor; implement a Groth16 verifier in Python that checks the pairing equation for a given R1CS and proof; or implement PLONK gate satisfaction for a 3-gate circuit with permutation argument. Include a 6–8 page analysis of completeness, soundness, and zero-knowledge.
I'm studying ZKP Mathematics: interactive proof systems, Sigma protocols, special soundness, the Fiat-Shamir transform, Pedersen commitments, KZG polynomial commitments, R1CS, QAPs, Groth16, PLONK (permutation argument), and STARKs (FRI, AIR, recursive composition). Context: 1. My goal: [e.g. "understand zkRollups", "build circuits in Circom/Noir", "audit a ZK protocol"] 2. My background: [e.g. "completed Cryptography module", "blockchain engineer using ZK libraries"] 3. One thing I'm stuck on: [e.g. "how does the QAP satisfiability check prevent cheating?", "what does zero-knowledge formally mean?"] Answer: - For (3): give a precise definition then a counterexample showing what breaks without it. - What's the most important module for my goal? - What's the key mathematical insight separating Groth16 from PLONK from STARKs?
Implement KZG (or FRI) polynomial commitment from scratch. Commit to a degree-N polynomial; open at a point; verify the proof. Benchmark commitment, opening, and verification at N=128, 1024, 8192.
Translate a simple computation (Poseidon-style hash) into Plonk-style custom gates with copy constraints. Document the gate count, the witness layout, and the constraint system. Compare to an R1CS arithmetization of the same computation.
Run a 3-party trusted setup ceremony for a small Groth16 circuit: each party contributes randomness, verifies the previous transcript, and produces a new transcript. Generate proofs with the resulting CRS. Document the security properties.
Implement a small STARK proof for a Fibonacci sequence (10-step). Use FFT-based polynomial operations, FRI commitment, and Merkle verification. Verify the proof's soundness via tampered-witness experiments.
Excellent intuitive walkthrough from R1CS to Groth16. Read before Module 7.