# STARKs eliminate trusted setup risk through transparent randomness and hash-based security Scalable Transparent Arguments of Knowledge (STARKs) make a fundamentally different cryptographic choice from SNARKs: they rely on collision-resistant hash functions (e.g., SHA-256) and public randomness rather than elliptic curve pairings and secret ceremony parameters. **Consequences of this choice:** **No trusted setup** — STARK proofs are generated using only public randomness. There is no Common Reference String (CRS) to generate, no toxic waste to destroy, and no 1-of-N honesty assumption. Any party can verify the setup parameters directly from the public specification. **Post-quantum security** — Elliptic curve discrete logarithm problems (on which SNARKs rely) are believed to be solvable by sufficiently powerful quantum computers via Shor's algorithm. Hash functions (SHA-256, Poseidon) are believed to be quantum-resistant, making STARKs secure even under a quantum adversary. SNARKs — including [[Groth16 trusted setup generates toxic waste enabling proof forgery if any ceremony participant fails to destroy their contribution]] — lose their security if quantum computing advances. **The cost:** STARK proofs are dramatically larger (tens of kilobytes vs. hundreds of bytes for Groth16) and verification is slower and more expensive on-chain. A STARK proof verifying on L1 Ethereum requires significant gas relative to a Groth16 proof. **The practical resolution:** Because [[SNARK-wrapped STARK architectures reintroduce trusted setup requirements to achieve on-chain proof size efficiency]], most production ZK rollups (StarkWare's L2, Polygon) wrap STARK proofs in SNARKs for L1 settlement. This preserves STARK's fast proving characteristics while achieving SNARK's small on-chain footprint — at the cost of reintroducing the trusted setup STARK was designed to eliminate. The transparency of STARK verification also means that STARK-based systems are more auditable at the proof-system level — the verification algorithm can be inspected and formally specified without secret parameters. This matters for [[the ZK security stack spans four layers where a vulnerability in any single layer breaks overall system guarantees]], because STARK's backend layer is publicly inspectable in a way Groth16's is not. --- Relevant Notes: - [[Groth16 trusted setup generates toxic waste enabling proof forgery if any ceremony participant fails to destroy their contribution]] — the setup risk that STARKs eliminate - [[SNARK-wrapped STARK architectures reintroduce trusted setup requirements to achieve on-chain proof size efficiency]] — how the industry navigates the size tradeoff - [[the ZK security stack spans four layers where a vulnerability in any single layer breaks overall system guarantees]] — STARK's transparent backend is one of four independent layers Topics: - [[vulnerability-patterns]] - [[index]]