A Common Reference String (CRS) is a public, uniformly distributed string of structured parameters shared between a prover and verifier to enable a non-interactive zero-knowledge proof system. It is generated during a trusted setup ceremony and serves as a global, reusable reference that replaces the need for interactive back-and-forth communication between the two parties.
Glossary
Common Reference String (CRS)
A public string of structured parameters generated during a trusted setup that is shared between the prover and verifier to enable non-interactive zero-knowledge proofs.
CRYPTOGRAPHIC PARAMETER
What is Common Reference String (CRS)?
A Common Reference String (CRS) is a public string of structured parameters generated during a trusted setup that is shared between the prover and verifier to enable non-interactive zero-knowledge proofs.
The security of the entire proof system depends on the integrity of the CRS generation process. If the secret randomness used to create the CRS—often called toxic waste—is not destroyed, a malicious actor could forge fraudulent proofs. Modern constructions like universal setup and transparent setup schemes aim to minimize or eliminate the risks associated with this single point of failure.
CRS FUNDAMENTALS
Key Properties of a Common Reference String
A Common Reference String (CRS) is a shared public parameter generated during a trusted setup that enables non-interactive zero-knowledge proofs. Its properties directly determine the security, efficiency, and trust assumptions of the entire proving system.
01
Uniform Randomness
The CRS must be sampled from a uniformly random distribution over the parameter space. Any detectable bias or structure in the string can be exploited by a malicious prover to forge proofs. In pairing-based systems like Groth16, the CRS consists of elliptic curve group elements raised to random powers of a secret scalar, ensuring the discrete log relationship between elements remains hidden if the randomness is properly generated.
256-bit
Minimum Entropy Required
02
Structured vs. Unstructured
A structured reference string (SRS) contains encoded powers of a secret value, enabling efficient polynomial commitment schemes like KZG. This structure allows constant-size proofs but introduces a toxic waste problem. An unstructured CRS is a uniform random string with no hidden relationships, used in systems like zkSTARKs, which rely solely on collision-resistant hash functions and require no trusted setup at all.
O(1)
Proof Size with Structured CRS
O(log² n)
Proof Size with Unstructured CRS
03
Toxic Waste Management
The toxic waste is the secret randomness used to generate a structured CRS. Knowledge of this secret allows an adversary to construct fraudulent proofs that pass verification. The standard mitigation is a multi-party computation (MPC) ceremony where participants sequentially contribute entropy. Security holds if at least one participant destroys their contribution. Systems like Plonk use a universal setup, requiring only a single ceremony for all circuits up to a bounded size.
1-of-N
Honest Participant Assumption
04
Updatability
An updatable CRS allows new participants to contribute fresh randomness to an existing structured reference string without restarting the ceremony. Each update multiplies the existing parameters by a new secret scalar, preserving the structure while refreshing the security guarantee. This property is critical for long-lived systems where the original setup participants may no longer be trusted, enabling continuous security reinforcement without circuit redeployment.
Unbounded
Number of Allowed Updates
05
Circuit-Specific vs. Universal
A circuit-specific CRS is generated for a single arithmetic circuit and cannot be reused. Groth16 requires this, producing minimal proof sizes but necessitating a new ceremony per application. A universal CRS supports any circuit up to a pre-defined maximum size. Plonk and Marlin use universal setups, enabling developers to deploy new circuits without repeating the trusted setup, dramatically improving developer velocity and reducing operational overhead.
~200 bytes
Groth16 Proof Size
~400 bytes
Plonk Proof Size
06
Subversion Resistance
A subversion-resistant or subversion-zero-knowledge CRS guarantees security even if the CRS was generated maliciously. Traditional systems assume the CRS is honestly generated. Subversion-resistant constructions, such as those based on non-malleable commitments or dual-mode systems, ensure that a maliciously biased CRS either fails to produce valid proofs or preserves zero-knowledge regardless. This property is essential for high-assurance deployments where the setup ceremony's integrity cannot be fully guaranteed.
Zero
Trust Assumptions Required
TRUSTED SETUP TAXONOMY
CRS Types: Circuit-Specific vs. Universal vs. Transparent
Comparison of Common Reference String generation paradigms based on reusability, security assumptions, and protocol compatibility.
| Feature | Circuit-Specific | Universal | Transparent |
|---|---|---|---|
Setup Reusability | Single circuit only | Any circuit up to size bound | All circuits, no bound |
Requires Trusted Setup Ceremony | |||
Toxic Waste Risk | Per-circuit secret | One-time secret | No toxic waste |
Post-Quantum Security | |||
Proof Size | Smallest (128-256 bytes) | Small (400-800 bytes) | Larger (40-200 KB) |
Verification Cost | Lowest (3-5 pairings) | Low (1-2 pairings) | Moderate (hashing) |
Example Protocol | Groth16 | Plonk | FRI-based STARKs |
Parameter Generation | Circuit-dependent MPC | Single MPC ceremony | Public randomness |
COMMON REFERENCE STRING
Frequently Asked Questions
Clear, technical answers to the most common questions about the Common Reference String (CRS), its role in zero-knowledge proof systems, and the security implications of its generation.
A Common Reference String (CRS) is a public set of structured parameters generated during a trusted setup ceremony that is shared between a prover and a verifier to enable non-interactive zero-knowledge proofs. It functions as a shared cryptographic "bulletin board" that replaces the back-and-forth interaction required in interactive proof systems. The CRS encodes the specific arithmetic circuit or constraint system being proven, embedding trapdoor values that allow a prover to construct a valid proof efficiently. Crucially, the verifier uses a separate, derived verification key from the same setup to check the proof's validity without ever learning the trapdoor. The security of the entire system hinges on the assumption that the "toxic waste"—the random secrets used to generate the CRS—was generated and then irrecoverably destroyed by all participants in the setup ceremony.
Enabling Efficiency, Speed & Accuracy
Intelligent Analysis, Decision & Execution
We build AI systems for teams that need search across company data, workflow automation across tools, or AI features inside products and internal software.
Talk to Us
Search across company data
Give teams answers from docs, tickets, runbooks, and product data with sources and permissions.
Useful when people spend too long searching or get different answers from different systems.
Enterprise searchRAGPermissions
Read more
Automate internal workflows
Use AI to route work, draft outputs, trigger actions, and keep approvals and logs in place.
Useful when repetitive work moves across multiple tools and teams.
AI agentsWorkflow automationGovernance
Read more
Add AI to products and internal tools
Build assistants, guided actions, or decision support into the software your team or customers already use.
Useful when AI needs to be part of the product, not a separate tool.
AI integrationDecision supportModel routing
Read more
About the author
Prasad Kumkar
CEO & MD, Inference Systems
Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.
His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.
LinkedIn
Limited slotsGet a Free AI Consultation
Partnered with leading AI, data, and software stack.
How We Work
Custom AI workflows for your Business
One-fit-all AI don't work for modern businesses. At Inferensys, we aim to understand your business & custom requirements; which we use to define most efficient agentic workflows, the data, and the tools for your business.
01
Review the use case
We understand the task, the users, and where AI can actually help.
Read more02
Pick the right approach
We define what needs search, automation, or product integration.
Read more03
Build the first useful version
We implement the part that proves the value first.
Read more04
Improve from there
We add the checks and visibility needed to keep it useful.
Read moreThe first call is a practical review of your use case and the right next step.
Talk to Us