Path: blob/main/frontier/10-snarks-starks/connect/starks-starknet.ipynb
483 views
Connect: STARKs in StarkNet
Module 10 | Real-World Connections
StarkNet processes transactions off-chain and posts STARK proofs to Ethereum for verification.
Introduction
StarkNet is a ZK rollup on Ethereum: it executes transactions off-chain, generates a STARK proof that all transactions were executed correctly, and posts only the proof to Ethereum. This achieves:
| Property | Ethereum L1 | StarkNet L2 |
|---|---|---|
| Execution | On-chain (every node) | Off-chain (prover only) |
| Verification | Re-execute | Verify STARK proof |
| Throughput | ~15 TPS | ~100-1000+ TPS |
| Cost per tx | $1-50 | $0.01-0.10 |
| Trust model | Consensus | Math (no trusted setup) |
The STARK proof system uses the FRI protocol (Notebook 10e) as its polynomial commitment scheme, achieving transparency (no trusted setup) and quantum resistance.
STARKs vs SNARKs in Practice
| Feature | Groth16 (SNARK) | STARK |
|---|---|---|
| Trusted setup | Yes (circuit-specific ceremony) | No (transparent) |
| Proof size | 192 bytes | ~50-200 KB |
| Verification time | ~5 ms (3 pairings) | ~10-50 ms (hash checks) |
| Prover time | ||
| Crypto assumption | Pairings, DLP | Hash functions only |
| Quantum resistance | No | Yes |
| Proof aggregation | Hard | Natural (recursive STARKs) |
StarkNet chose STARKs because:
No trusted setup needed (critical for decentralization)
Quantum resistance (future-proofing)
Fast prover for large computations
Natural recursion for batching proofs
The FRI Protocol in Action
StarkNet's prover now runs FRI on the composition polynomial to prove it is low-degree. This is the connection to Notebook 10e:
Evaluate the composition polynomial on a larger domain (blowup factor 4-8)
Commit via Merkle tree
Fold repeatedly, halving the degree each round
Verify by spot-checking consistency of folding steps
The proof consists of Merkle roots and authentication paths.
Recursive STARKs and SHARP
StarkNet uses SHARP (Shared Prover) to batch multiple transactions into one proof:
Collect 100-1000 transactions
Execute them all, producing a large execution trace
Generate ONE STARK proof for the entire batch
Post the proof to Ethereum L1
For even more efficiency, StarkNet uses recursive STARKs: prove that you verified a previous STARK proof, compressing multiple proofs into one.
Cairo: StarkNet's STARK-Native Language
StarkNet programs are written in Cairo, a language designed to produce execution traces that are efficient for STARK proving:
Every Cairo program compiles to an algebraic execution trace
The trace satisfies AIR constraints (Algebraic Intermediate Representation)
The constraints are checked by FRI polynomial proximity testing
Cairo's computational model is based on a register machine where all operations are field arithmetic over a large prime field ( in production).
Summary
| Concept | Key idea |
|---|---|
| Cairo programs | Produce algebraic execution traces that are natural inputs to the STARK pipeline |
| AIR constraints | Enforce computational correctness as polynomial identities over the trace |
| FRI protocol | Proves the composition polynomial is low-degree, confirming all constraints hold |
| Transparency | No trusted setup needed. All verifier randomness comes from Fiat-Shamir hashing |
| SHARP batching | Thousands of transactions compressed into a single proof posted to Ethereum |
| Recursive STARKs | Multiple proofs compressed into one, further reducing L1 costs |
The trade-off vs Groth16: proofs are larger (~100 KB vs 192 bytes), but transparency and quantum resistance make STARKs attractive for large-scale rollups.
Back to Module 10: SNARKs and STARKs