A Common Reference String (CRS), also known as a structured reference string or public parameters, is a set of public, cryptographically secure values generated in a trusted setup ceremony and used as a foundational input for creating and verifying zero-knowledge proofs (ZKPs), particularly zk-SNARKs. This string acts as a shared, public anchor of trust, allowing a prover to generate a succinct proof that a statement is true and a verifier to check that proof's validity efficiently, without needing the original private data. The security of the entire proof system depends on the CRS being generated correctly and its toxic waste—secret parameters used in its creation—being securely destroyed.
LABS
Glossary
Common Reference String (CRS)
A Common Reference String (CRS) is a public, shared parameter set generated during a trusted setup ceremony, used to initialize and verify zero-knowledge proof systems like zk-SNARKs.
Chainscore © 2026
definition
CRYPTOGRAPHIC PRIMITIVE
What is Common Reference String (CRS)?
A foundational component in advanced cryptographic proof systems, enabling the verification of complex computations without revealing the underlying data.
The generation of a CRS is a critical and sensitive process known as a trusted setup. In this multi-party ceremony, participants collaboratively contribute randomness to produce the final public string. The security model assumes that if at least one participant is honest and destroys their secret contribution, the resulting CRS is secure. This process is foundational for systems like Zcash, which pioneered its use for private transactions. The CRS enables the prover to construct proofs using elliptic curve pairings and polynomial commitments, creating a short proof that can be verified in constant time, regardless of the complexity of the original computation.
In practice, the CRS is divided into two main parts: a proving key and a verification key. The prover uses the proving key to generate the proof, while the verifier uses the verification key to check it. This separation optimizes performance for each role. A significant limitation of CRS-based systems is their trusted setup assumption; if the ceremony is compromised, an adversary could create false proofs. This has led to research into transparent setups, like those used in zk-STARKs, which do not require a CRS. Despite this, CRS-based zk-SNARKs remain dominant for their extreme proof succinctness and verification speed in blockchain scaling solutions and privacy applications.
how-it-works
CRYPTOGRAPHIC PRIMER
How a Common Reference String (CRS) Works
A technical deep dive into the foundational setup parameter used in zero-knowledge proof systems like zk-SNARKs, explaining its role, generation, and security implications.
A Common Reference String (CRS), also known as a structured reference string or public parameters, is a set of cryptographically secure public parameters generated during a one-time trusted setup ceremony and used by all participants in a zero-knowledge proof (ZKP) system, such as zk-SNARKs, to generate and verify proofs. This string acts as a shared, foundational anchor that encodes the constraints of the specific computational problem being proved, enabling the prover to construct a proof and the verifier to check it without revealing any underlying secret data. Its structured nature, often involving elliptic curve points, is crucial for the proof system's efficiency and security.
The generation of the CRS is a critical and sensitive process known as the trusted setup. In this phase, one or multiple participants contribute random secret values, often called toxic waste or the secret trapdoor, to collaboratively compute the public parameters. The security of the entire ZKP system hinges on the permanent deletion of these secrets; if any participant retains them, they could potentially forge false proofs. Modern systems use multi-party computation (MPC) ceremonies, like the one for Zcash's Sapling protocol, to distribute trust among many parties, making it statistically improbable that all would collude to compromise the system.
In practice, the CRS is used in two distinct phases: the proving key and the verification key. The proving key, derived from the CRS, is used by the prover to generate a proof for a specific witness (private input) to a statement. The verification key, also derived from the CRS, is used by any verifier to check the proof's validity in constant time, regardless of the complexity of the original computation. This separation is what allows zk-SNARKs to be so succinct and efficient for verification on-chain, as the verifier only needs the short proof and the pre-computed verification key.
The major security consideration for a CRS is the requirement for trusted setup. While MPC ceremonies mitigate the risk, the concept introduces a cryptographic assumption not present in transparent proof systems like zk-STARKs. Furthermore, the CRS is typically circuit-specific, meaning a new setup is required for each distinct program or smart contract logic being verified. Projects address this through universal or updatable reference strings, such as those used by PLONK and Marlin, which allow a single setup to be used for many different programs, enhancing flexibility and reducing the need for repeated ceremonies.
key-features
CRYPTOGRAPHIC FOUNDATION
Key Features of a CRS
A Common Reference String (CRS) is a foundational, public parameter used in advanced cryptographic protocols like zk-SNARKs. These features define its role in enabling secure, trustless computation.
01
Public, Trusted Setup
The CRS is a public string generated in a one-time, multi-party ceremony. This process, known as a trusted setup, is critical because if the ceremony's secret randomness is compromised, the entire system's security fails. Once generated, the CRS is published for anyone to verify proofs, eliminating the need for a trusted prover.
02
Enables Succinct Proofs
The primary function of a CRS is to allow a prover to generate a zk-SNARK proof that is extremely small and fast to verify. This proof can confirm the correctness of a complex computation (like a blockchain transaction) without revealing any of the underlying data, enabling both privacy and scalability.
03
Structured Reference String (SRS)
In many modern zk-SNARK systems like Groth16, the CRS is more specifically a Structured Reference String. It contains precomputed elliptic curve points that are structured to efficiently support the specific polynomial commitments and pairings required for proof generation and verification.
04
Universal vs. Specific
A CRS can be circuit-specific, tailored for a single application (e.g., a specific privacy transaction), or universal (often called a Universal Reference String or URS). A URS, used in protocols like PLONK, can support many different circuits, offering greater flexibility and reusability after the initial setup.
05
Verifier & Prover Keys
The master CRS is often split into two derived components:
- Proving Key: Used by the prover to generate proofs.
- Verification Key: A smaller subset used by the verifier to check proofs. This separation optimizes performance, as verifiers only need the lightweight verification key.
06
Foundation for Applications
The CRS is the bedrock for critical blockchain scaling and privacy solutions:
- zk-Rollups (e.g., zkSync, StarkNet) use it to generate validity proofs for batched transactions.
- Private Transactions (e.g., Zcash's original Sprout protocol) rely on it to shield transaction details.
- On-chain Verifiable Computation uses it to prove arbitrary program execution.
trusted-setup-ceremony
CRS GENERATION
The Trusted Setup Ceremony
A trusted setup ceremony is a cryptographic procedure where a group of participants collaboratively generates the foundational parameters, known as the Common Reference String (CRS), required for a zero-knowledge proof system.
A trusted setup ceremony is a multi-party computation (MPC) protocol designed to generate the Common Reference String (CRS) or Structured Reference String (SRS) for advanced cryptographic systems like zk-SNARKs. The core objective is to eliminate the need for a single trusted party by distributing the generation of secret parameters among many participants. If at least one participant is honest and destroys their secret contribution, the final CRS remains secure. This process is also known as a powers-of-tau ceremony or MPC ceremony, with its security model termed the "1-of-N" trust assumption.
The ceremony is necessary because the initial secret parameters, often called toxic waste, could be used to forge fraudulent proofs if known. By performing the setup in a decentralized manner, the risk is mitigated. Each participant sequentially receives the current state of the parameters, applies a transformation using their own secret randomness, and publishes an updated version. The final output is a public CRS that contains no usable information about the individual secrets, provided at least one contribution remains private. Major blockchain implementations, such as Zcash's original Sprout ceremony and the perpetual Perpetual Powers of Tau, have utilized this method.
While a significant security improvement over a single-party setup, the ceremony is not without critiques. It introduces logistical complexity and requires participants to perform computations correctly and verifiably. Furthermore, the trust assumption shifts from one entity to the hope that at least one participant in a potentially large group acted honestly—a model considered sufficiently secure for many applications but not perfectly trustless. The ceremony's security also depends on robust verifiable computation to ensure each step was performed correctly without leaking secrets.
ecosystem-usage
CRS
Ecosystem Usage & Protocols
The Common Reference String (CRS) is a foundational cryptographic element used by zk-SNARKs and other zero-knowledge proof systems. It is a public, structured string of data that is required to both generate and verify proofs.
01
Core Cryptographic Function
The Common Reference String (CRS) is a public parameter generated during a trusted setup ceremony. It contains the encrypted evaluation keys for a specific circuit, enabling a prover to construct a proof and a verifier to check it. Without the CRS, the zero-knowledge proof system cannot function.
02
Trusted Setup Requirement
The security of the CRS relies on a trusted setup ceremony, where multiple participants contribute randomness to generate it. The critical assumption is that at least one participant was honest and destroyed their secret "toxic waste." If all participants collude, they could create fraudulent proofs. This makes the ceremony a crucial security event for protocols like Zcash (Sprout) and Tornado Cash.
03
zk-SNARKs vs. zk-STARKs
A key differentiator between proof systems is their reliance on a CRS:
- zk-SNARKs (Succinct Non-Interactive ARguments of Knowledge) require a trusted setup to generate a CRS.
- zk-STARKs (Scalable Transparent ARguments of Knowledge) are transparent and do not require a trusted setup or CRS, using publicly verifiable randomness instead.
04
Universal vs. Circuit-Specific
CRS implementations vary in scope:
- Circuit-Specific CRS: Created for a single program/circuit (e.g., a specific privacy pool). More efficient but requires a new trusted setup for each circuit.
- Universal CRS (or Structured Reference String - SRS): A single setup can be used for a large class of circuits. Used by Groth16 and Plonk-based systems, enabling more flexible application development.
05
Real-World Protocol Examples
Major protocols that depend on a CRS include:
- Zcash (Sprout & Sapling): Used multi-party ceremonies (Powers of Tau) to generate the CRS for its shielded transactions.
- Tornado Cash: Relied on a trusted setup for its anonymity pools.
- Aztec Network: Uses a Universal SRS for its zk-rollup.
- Filecoin: Employed a large-scale trusted setup for its storage proofs.
06
Evolution & Perpetual Powers of Tau
To mitigate the one-time risk of trusted setups, the community has developed Perpetual Powers of Tau ceremonies. These are ongoing, contributor-based setups that aim to create a universal, reusable CRS that accumulates entropy over time. This model, used by projects like Semaphore, allows new applications to leverage a CRS with a high degree of assumed security without running their own ceremony.
TRUSTED SETUP COMPARISON
CRS vs. Alternative Setup Models
A comparison of the Common Reference String (CRS) model against other major approaches for generating cryptographic parameters in zk-SNARKs and related protocols.
| Feature / Property | Common Reference String (CRS) | Transparent Setup | Updatable Reference String |
|---|---|---|---|
Setup Ceremony | |||
Trust Assumption | 1-of-N honest participant | None (trustless) | 1-of-N honest participant per update |
Toxic Waste | Generated and must be destroyed | Not generated | Generated and must be destroyed per update |
Prover Key Size | Small (KB-MB) | Large (GB+) | Small (KB-MB) |
Verifier Key Size | Tiny (KB) | Large (GB+) | Tiny (KB) |
Post-Quantum Security | Varies (some are PQ) | ||
Example Protocols | Groth16, PLONK | STARKs, Bulletproofs | Perpetual Powers of Tau, Sonic |
security-considerations
COMMON REFERENCE STRING (CRS)
Security Considerations & Risks
The Common Reference String (CRS) is a foundational cryptographic element in zk-SNARKs, but its generation and use introduce critical security assumptions and attack vectors.
01
Trusted Setup & Toxic Waste
The primary security risk of a CRS is the requirement for a trusted setup ceremony. During generation, participants create and must destroy secret parameters known as toxic waste. If any participant retains this waste, they can forge proofs, compromising the entire system's integrity. This creates a persistent, foundational trust assumption.
02
Subversion Attacks
A subversion attack occurs if the CRS itself is maliciously generated, bypassing the need for toxic waste. A corrupt setup can embed a trapdoor known only to the attacker, allowing them to create valid proofs for false statements. Defenses include universal setups (reusable across circuits) and transparent setups (no secrets required, as used in STARKs).
03
Upgradeability & Long-Term Security
A CRS is typically generated for a specific zk-SNARK circuit. If the protocol logic needs updating, a new trusted setup is required, which is operationally complex and risky. This limits upgradeability and creates long-term security dependencies. The system's security is only as strong as the oldest, weakest participant in its setup ceremony.
05
Contrast with Transparent Proof Systems
The security model of a CRS-dependent zk-SNARK is fundamentally different from transparent proof systems like zk-STARKs or Bulletproofs. These systems require no trusted setup and their public parameters are generated from public randomness, eliminating the toxic waste problem and subversion attacks entirely, at the cost of larger proof sizes.
06
Ceremony Best Practices & Auditing
To maximize security, trusted setups employ multi-party computation (MPC) ceremonies with many diverse participants. Best practices include:
- Sequential ceremonies where each participant adds entropy.
- Use of secure, audited hardware.
- Public attestations and cryptographic audits of the final CRS.
- Destruction of all intermediate materials. The success of these measures relies heavily on social consensus and participant honesty.
DEBUNKING MYTHS
Common Misconceptions About CRS
The Common Reference String (CRS) is a foundational component of many zero-knowledge proof systems, but its role and properties are often misunderstood. This section clarifies key technical points to separate fact from fiction.
Yes, the generation of a Common Reference String (CRS) is a trusted setup ceremony. This process involves one or more participants generating secret parameters that are subsequently destroyed, leaving only the public CRS. The critical security assumption is that at least one participant was honest and successfully deleted their secret 'toxic waste'. If all participants collude, they could potentially create fraudulent proofs. Protocols like Zcash's original Sapling ceremony and the Perpetual Powers of Tau are high-profile examples of multi-party computations (MPC) designed to decentralize this trust.
CRS
Technical Deep Dive
A Common Reference String (CRS) is a foundational cryptographic primitive used in zero-knowledge proof systems, particularly zk-SNARKs, to generate the public parameters required for proof generation and verification.
A Common Reference String (CRS) is a set of public parameters, generated in a one-time trusted setup ceremony, that is used by both the prover and verifier in a zk-SNARK proof system. It works by providing the structured reference string needed to evaluate polynomial commitments and verify proofs without revealing the underlying secret values used in its creation. The prover uses the CRS to construct a proof, and the verifier uses the same CRS to check the proof's validity. Its security relies on the trusted setup assumption that the original secret randomness, or 'toxic waste', used to generate the CRS was securely destroyed.
Key Components:
- Evaluation Key: Used by the prover to generate the proof.
- Verification Key: Used by the verifier to check the proof.
- Structured Reference String (SRS): A more modern term often used interchangeably with CRS, emphasizing its structured, reusable nature.
COMMON REFERENCE STRING
Frequently Asked Questions (FAQ)
A Common Reference String (CRS) is a foundational cryptographic element used in zero-knowledge proof systems. This FAQ addresses its purpose, security model, and practical implications for developers.
A Common Reference String (CRS) is a public, structured string of data that serves as a shared, trusted parameter for generating and verifying zero-knowledge proofs, particularly in zk-SNARKs (Succinct Non-Interactive Arguments of Knowledge). It is generated in a one-time, trusted setup ceremony and is essential for establishing the cryptographic foundation that allows a prover to convince a verifier of a statement's truth without revealing the underlying information. The security of the entire proof system depends on the CRS being generated correctly, as anyone with knowledge of its secret 'toxic waste' could create fraudulent proofs.
ENQUIRY
Get In Touch
today.
Our experts will offer a free quote and a 30min call to discuss your project.
NDA Protected
Confidentiality24h Response
Time to ValueDirectly to Engineering Team
No Sales Fluff10+
Protocols Shipped
$20M+
TVL Overall