Path: blob/main/frontier/10-snarks-starks/sage/10e-fri-protocol.ipynb
483 views
Notebook 10e: The FRI Protocol
Module 10: SNARKs and STARKs
Motivating Question. Groth16 gives us tiny proofs, but requires a trusted setup, if the toxic waste leaks, anyone can forge. Can we build a proof system where there's nothing to trust? The FRI protocol (Fast Reed-Solomon Interactive Oracle Proof of Proximity) is the engine behind STARKs. It lets a prover convince a verifier that a function is "close to" a low-degree polynomial, using only hashing, no elliptic curves, no pairings, no toxic waste.
Prerequisites. You should be comfortable with:
Polynomial evaluation and interpolation (Module 02)
The QAP divisibility check: polynomials encode computation (Notebook 10c)
Groth16's trusted-setup trade-off (Notebook 10d)
Learning objectives. By the end of this notebook you will be able to:
Understand Reed-Solomon codes and why "low degree" means "valid codeword."
Decompose a polynomial into even and odd parts.
Perform FRI folding rounds that halve the polynomial degree.
Walk through a complete mini-FRI protocol with Merkle commitments.
See why FRI eliminates the need for a trusted setup.
1. Reed-Solomon Codes: Polynomials as Error-Correcting Codes
Bridge from Notebook 10d. Groth16 encodes polynomial evaluations as curve points and uses pairings to check the QAP equation. FRI takes a completely different approach: encode polynomial evaluations as a vector of field elements and use algebraic structure to prove it came from a low-degree polynomial.
A Reed-Solomon code is simple: evaluate a polynomial of degree on a domain of size . The resulting vector of evaluations is a codeword.
The rate controls redundancy. If (blowup factor 4), the codeword is 4x longer than necessary, providing strong error detection.
Checkpoint 1. A Reed-Solomon codeword is just a polynomial evaluated on a structured domain. The key property: if you change any evaluation in a valid codeword, the result is no longer a valid codeword (it doesn't come from a degree- polynomial). FRI exploits this: proving a function is low-degree is equivalent to proving it's a valid RS codeword.
2. Even-Odd Decomposition
The core trick of FRI is splitting a polynomial into its even and odd parts:
For example, becomes:
Even part: (coefficients of )
Odd part: (coefficients of )
Check: ✓
The key observation: and each have degree , half the degree.
3. One Round of FRI Folding
The verifier sends a random challenge . The prover computes the folded polynomial:
This is a random linear combination of and , so:
, the degree halves!
The domain also shrinks:
Why does the domain shrink? Because and square to the same value (they're negatives of each other: ). So squaring maps points to points.
Checkpoint 2. The verifier doesn't need the polynomial itself, just two evaluations and to check one folding step. This is what makes FRI an interactive oracle proof: the prover commits to evaluations (via Merkle trees), and the verifier spot-checks consistency.
4. Full FRI: Fold Until Constant
Repeat the folding until we reach a constant polynomial (degree 0). For our degree-3 polynomial:
| Round | Degree | Domain size | Challenge |
|---|---|---|---|
| 0 | 3 | 16 | , |
| 1 | 1 | 8 | |
| 2 | 0 | 4 |
After round 2, the polynomial is constant, the prover just sends this value.
Misconception alert. "FRI proves that is a low-degree polynomial." Not exactly, FRI proves that is close to a low-degree polynomial (a proximity test). In STARK usage this distinction doesn't matter because exact equality is enforced by the constraint system, but the formal guarantee is proximity.
5. Merkle Commitments: The Oracle Model
In each round, the prover commits to evaluations using a Merkle tree. This turns the interactive protocol into a non-interactive one (via Fiat-Shamir):
Hash all evaluations into a Merkle tree, send the root
Derive challenge from the root (Fiat-Shamir)
When verifier queries positions, prover provides values + Merkle proofs
The verifier only checks positions, this gives logarithmic verification time.
6. FRI Verification: Spot-Check Consistency
The verifier picks random query positions and checks that each folding step is consistent. For each query index :
Look up and , these are "paired" positions (negatives of each other)
Compute the expected from the folding formula
Compare with the committed value of at that position
Repeat for each folding round
Checkpoint 3. Each query costs the verifier work (one check per folding round). With queries, the soundness error is where depends on the rate. For and 80 queries, the probability of a cheating prover fooling the verifier is negligible ().
7. Catching a Cheater
What happens if the prover tries to commit to a high-degree function (not a valid RS codeword)?
8. Putting It All Together: A Complete Mini-FRI
Let's run a complete FRI protocol end-to-end with all the steps labeled.
9. Why FRI Matters for STARKs
FRI is the polynomial commitment scheme used in STARKs. Here's how it fits into the bigger picture:
| Step | SNARK (Groth16) | STARK |
|---|---|---|
| Computation → constraints | Arithmetic circuit → R1CS | Arithmetic circuit → AIR (Algebraic Intermediate Representation) |
| Constraints → polynomial | R1CS → QAP | AIR → composition polynomial |
| Polynomial commitment | Trusted setup (CRS + pairings) | FRI (hash-based, no setup) |
| Verification | 3 pairings | Merkle proofs + hash checks |
Key Properties of FRI
| Property | Value |
|---|---|
| Trust assumption | None (transparent) |
| Cryptographic assumption | Collision-resistant hash function only |
| Quantum resistance | Yes (no discrete log or pairing) |
| Proof size | |
| Verification time | |
| Prover time |
Crypto foreshadowing. The next notebook compares SNARKs and STARKs head-to-head. The key trade-off: Groth16 has constant-size proofs (192 bytes) but needs a trusted setup. STARKs (via FRI) have larger proofs ($\sim$50-200 KB) but are transparent and quantum-resistant.
10. Exercises
Exercise 1 (Worked): Manual Folding
Problem. Take . Split it into even/odd parts and fold with .
Solution:
Exercise 2 (Guided): FRI with Different Rate
Problem. Run FRI on using a domain of size 32 (rate ). Compare the number of rounds with the rate- case.
Fill in the TODOs:
Exercise 3 (Independent): Degree-7 FRI
Problem.
Create a random polynomial of degree 7 over .
Choose an appropriate domain size (what should the blowup factor be?).
Run the full FRI protocol and verify it accepts.
How many folding rounds are needed? How many Merkle commitments does the prover send?
Summary
| Concept | Key Fact |
|---|---|
| Reed-Solomon code | Evaluations of degree- polynomial on domain ; low degree ↔ valid codeword |
| Even-odd split | ; each half has half the degree |
| FRI folding | ; random from verifier |
| Domain halving | ; squaring maps to same point |
| Merkle commitment | Hash evaluations into tree; prover can't change values after commit |
| Verification | Spot-check queries, each checking folding steps |
| Transparency | No trusted setup, only hash functions needed |
FRI is the heart of STARKs: it replaces the pairing-based polynomial commitment of SNARKs with a purely hash-based one. The trade-off is larger proofs ( vs constant), but with no trusted setup and post-quantum security.
Next: 10f: STARKs vs SNARKs