Groth16 and PLONK dominate SNARK deployments. STARKs replace trusted setup with transparency and replace pairing assumptions with hash-based security.

This demo walks from AIR traces to FRI folding, then runs a complete educational STARK protocol in the browser over a small field. Toy parameters are clearly labeled and not production secure.

STARK Paper (2018/046) FRI Paper (ICALP 2018) SNARK Arena
EXHIBIT 01Orientation

STARKs vs SNARKs: Key Differences

Transparent setup: Groth16 and PLONK rely on trusted setup artifacts. STARKs replace that with public randomness derived from transcript hashing, with no toxic waste ceremony.

Post-quantum conjectured security: pairing-based SNARK assumptions are vulnerable to Shor-style quantum attacks, while STARK security reduces to collision resistance of hash functions plus FRI soundness assumptions.

Scalability profile: STARK provers target quasi-linear behavior in computation size and polylogarithmic verification.

Cost: proof size is much larger. Typical STARK proofs are roughly 45-200KB, while Groth16 can be 128 bytes.

Stack: AIR constraints + FRI low-degree testing + transcript hash commitments.

Why this matters: StarkNet, StarkEx, Polygon Miden, and Risc Zero all rely on STARK architecture because transparency and post-quantum posture outweigh proof size for their use cases.
SNARK Arena (Groth16 / PLONK)
EXHIBIT 02AIR + Fibonacci

Arithmetic Intermediate Representation (AIR)

Educational STARK over small field: p = 2^31 - 1, short traces, toy security only.

AIR models computation as a trace of field elements and transition constraints between adjacent rows.

For Fibonacci, row i is (a, b). Constraints: next_a = b and next_b = a + b mod p, with boundary row(0) = (1, 1).

Interactive Fibonacci AIR
Ready.
What verifier does not see
  • Full execution trace
  • Most intermediate Fibonacci values
  • Prover internal randomness
Trace table
Constraints and proof transcript

            

          

        

        
Why this matters: AIR is the compilation target for StarkNet Cairo, Miden VM, and Risc Zero zkVM-style execution traces.

      


      

        
EXHIBIT 03FRI Visualizer

        
FRI: The Heart of STARKs

        
Educational FRI rounds: real SHA-256 Merkle commitments over toy domains.

        

          

            
FRI Controls

            

              
              
              

                
                
                
              

              
Awaiting commit.

            

          

          

            
Proof size estimate

            

              

              
Approximate formula: queries x path length x 32-byte hashes per round.

            

          

        

        

          
FRI transcript

          

        

        
Why this matters: FRI gives transparent low-degree testing using only hash commitments and verifier challenges, removing trusted setup ceremonies.

      


      

        
EXHIBIT 04Proof Size Tradeoff

        
Proof Size: The STARK Tradeoff

        

          
Real-world benchmark style comparison

          

            

          

        

        

          
Log-scale proof size chart (bytes)

          

        

        

          
Recursive STARK aggregation compresses many proofs into one L1-submitted proof. This is central to StarkNet and other rollup stacks.

          
Fiat-Shamir converts verifier randomness into transcript-derived hash challenges, making the protocol non-interactive in the random oracle model.

        

        
Why this matters: 100KB is expensive on-chain but trivial off-chain. The practical question is whether trust minimization and post-quantum posture justify the byte overhead.

      


      

        
EXHIBIT 05End-to-End Toy STARK

        
Prove and Verify in Browser

        
Toy STARK for education: p = 2^31 - 1, trace length 16, 3 folds, 4 queries/round, roughly 16-bit toy security.

        

          

            
Protocol run

            

              
              
              

                
                
                
              

              
No proof generated yet.

            

          

          

            
Protocol phases

            

              
    
                
  1. Witness/trace generation
    2. 
                
  2. LDE + Merkle commitment
    3. 
                
  3. Constraint polynomial evaluation
    4. 
                
  4. FRI rounds and queries
    5. 
                
  5. Proof assembly
    6. 
                
  6. Verifier checks
    7. 
              

            

          

        

        

          
Proof object and verification log

          

        

        
Why this matters: even toy runs show how only a few queried positions can catch inconsistent traces with high probability.

      


      

        
EXHIBIT 06Production Deployments

        
STARKs in Production

        

          

            
A. StarkNet

            
Cairo VM execution is compiled to AIR, proven with STARKs, recursively aggregated, and settled on Ethereum.

          

          

            
B. StarkEx

            
Application-specific scaling for exchanges and games, including dYdX v3, ImmutableX, and Sorare deployments.

          

          

            
C. Risc Zero

            
RISC-V zkVM proving general computation with STARK internals, commonly paired with SNARK wrapping for compact on-chain verification.

          

          

            
D. Polygon Miden

            
STARK-based VM with AIR constraints and recursion pipeline for compressed proofs.

          

        

        

          
Cross-demo links

          

            SNARK Arena
            ZK Proof Lab
            Pairing Gate
            Crypto Compare
          

        

        
Why this matters: STARKs are deployed infrastructure for scalability and integrity proofs, not just research prototypes.