my-rusty-plonk is a small educational Rust project focused on a minimal subset of proving system building blocks.
It is intentionally scoped as a toy, not a full PLONK implementation because I just wanted to get a good grasp of the internals of the protocol.
The goal is to model core ideas cleanly and keep the code readable.
The active toy implementation is under src/my_plonk.
I built this to better understand how proving system abstractions map to real code, because just by reading a professional implementation I couldn't get a good sense of what is being done and at the same time reading only a paper is not really useful for me. I prefer to build and learn this way.
It is also a way to practice implementing algebraic components in Rust and to explore the bridge between cryptographic theory and software structure.
- Finite field arithmetic over a toy prime field (
mod 101) - Polynomial representation with evaluation, addition, scalar multiplication, and multiplication
- Tiny row-based constraints with two gate types:
a + b = canda * b = c - Minimal toy proof/check flow:
prove(circuit, witness) -> Proofandverify(circuit, proof) -> bool - Runnable demo via
cargo runusing themy_plonkmodules
- No polynomial commitments (KZG/FRI)
- No Fiat-Shamir transcript
- No PLONK permutation argument (this is a key part that I ommited)
- No lookup arguments
- No zero-knowledge masking/blinding (because of the small field 😃)
- No elliptic-curve cryptography in the toy version (altough could be a great future addition).
The src/ark_plonk/ folder is kept as a separate, in progress implementation track aimed at a more protocol-accurate PLONK-style system over time.
That track is still under construction and is not the active path used by cargo run.
cargo runcargo testThe demo circuit has two rows:
Addgate with witness(a, b, c) = (3, 4, 7)checks3 + 4 = 7Mulgate with witness(a, b, c) = (5, 6, 30)checks5 * 6 = 30
The toy Proof stores row-wise evaluation artifacts and a simple checksum.
The verifier recomputes those values and rejects modified or inconsistent proof data.
- Commitment schemes
- Permutation checks
- Transcript logic
- Better circuit abstractions
- Stronger field and domain support
- Good elliptic curve usage
- RareSkills, for educational material (man I love the zkBook ❤)
- zkSecurity, for educational resources that informed the structure and learning path in this project