Trusted Setup Ceremony

A succinct non-interactive argument of knowledge that enables one party to prove possession of certain information without revealing it. zk-SNARKs require a trusted setup ceremony to generate a common reference string (CRS) used for both proof generation and verification. The CRS is derived from secret randomness that must be destroyed to prevent proof forgery. Key properties:

• Succinctness: Proofs are small (often < 300 bytes) and verifiable in milliseconds
• Non-interactive: No back-and-forth communication between prover and verifier
• Constant-size proofs: Verification time remains constant regardless of computation complexity
• Used in privacy-preserving blockchains like Zcash and scaling solutions like zkSync Era

A shared, publicly available string of structured parameters generated during the trusted setup ceremony that both the prover and verifier use in a zk-SNARK protocol. The CRS encodes the circuit-specific structure of the computation being proven. Critical security properties:

• Generated through a multi-party computation (MPC) protocol where participants contribute randomness sequentially
• If any single participant destroys their contribution (the 'toxic waste'), the entire setup is secure
• The CRS must be circuit-specific—each new application requires its own ceremony
• Size can range from megabytes to gigabytes depending on circuit complexity
• Also called the proving key and verification key pair

The operational protocol by which multiple participants collaboratively generate the CRS without any single party ever holding the complete secret. The ceremony proceeds in sequential rounds:

• Each participant receives the accumulated CRS from the previous round
• They generate fresh randomness locally, mix it into the CRS, and output an updated version
• The 'toxic waste'—the random values used—is destroyed immediately after contribution
• Liveness requirement: Participants must be available in sequence; a dropout halts progress until a replacement is found
• Verification scripts allow public auditing that each contribution was performed correctly
• Notable ceremonies: Zcash's Powers of Tau (2017-2018) involved hundreds of participants worldwide

A specific type of universal trusted setup that generates a CRS usable across multiple circuits, not just one. Named after the mathematical structure of the setup—computing successive powers of a secret value τ (tau). Key characteristics:

• Universal: The output can be adapted for any circuit up to a certain size bound
• Updatable: New participants can add their randomness to an existing setup without restarting
• The ceremony computes [τ¹·G, τ²·G, ..., τⁿ·G] where G is an elliptic curve generator
• Ethereum's KZG Ceremony (2022-2023) was a Powers of Tau setup for proto-danksharding, collecting contributions from over 140,000 participants
• Eliminates the need for per-application ceremonies, dramatically improving developer experience

The colloquial term for the secret randomness contributed by each participant during a trusted setup ceremony. If recovered by an adversary, this data enables the creation of convincing but fraudulent proofs that would pass verification undetected. Security model:

• A 1-of-N trust assumption: only one honest participant needs to destroy their toxic waste for the entire system to be secure
• Participants are instructed to perform the ceremony on air-gapped machines and destroy all traces afterward
• Some ceremonies use ephemeral hardware (e.g., burning laptops, destroying USB drives) to guarantee destruction
• The term originated in the Zcash community and is now standard across cryptographic engineering
• Contrast with zk-STARKs, which eliminate toxic waste entirely by using collision-resistant hash functions instead of trusted setups

A scalable transparent argument of knowledge that eliminates the trusted setup ceremony entirely. Unlike zk-SNARKs, zk-STARKs rely on collision-resistant hash functions and information-theoretic security rather than elliptic curve pairings. Key differentiators:

• Transparent setup: No toxic waste; the public parameters are generated from public randomness
• Post-quantum security: Resistant to attacks by quantum computers, unlike pairing-based SNARKs
• Scalability: Proof generation and verification scale quasi-linearly with computation size
• Larger proofs: STARK proofs are typically 40-200 KB vs. SNARK proofs at < 1 KB
• Developed by Eli Ben-Sasson and team; used by StarkWare for StarkNet and StarkEx scaling solutions