When the Threat Model Knows Zero: Auditing Assumptions in Zero-Knowledge Proof Systems

Zero-knowledge proofs (ZKPs) are often sold as a cryptographic silver bullet: they let a prover convince a verifier of a statement without revealing anything beyond its truth. But every ZKP system rests on a stack of assumptions — about the prover, the verifier, the setup, the random oracle, the underlying curve, and more. When those assumptions don't hold in practice, the proof's guarantees collapse. This article is for engineers and security reviewers who already understand the basics of ZKPs and need a structured way to audit the assumptions in their threat models. We'll walk through what to check, what tools to use, and what to do when an assumption turns out to be invalid.

What Assumptions Are We Talking About?

Let's start by naming the assumptions that typically hide in a ZKP threat model. The most common ones include:

• Honest verifier: The verifier follows the protocol correctly and does not collude with the prover.
• Trusted setup: The setup ceremony was performed honestly and the toxic waste was destroyed.
• Random oracle model (ROM): Hash functions behave like truly random oracles, with no exploitable structure.
• Knowledge soundness: The prover cannot produce a valid proof without knowing a valid witness.
• Zero knowledge: The proof reveals no information about the witness beyond the statement's truth.
• Underlying primitives: The elliptic curve, pairing, and hash functions are secure against known attacks.

Each of these can be violated in ways that break the system. For example, if the verifier is not honest (e.g., they choose challenges adaptively), a proof system that assumes an honest verifier may leak information. Similarly, if the trusted setup is compromised, the prover can forge proofs for false statements. The first step in auditing is to make every assumption explicit and then assess its plausibility in your deployment context.

Why Assumptions Matter More in ZKPs Than in Traditional Crypto

Traditional cryptographic protocols (like TLS) are well-studied and have standard assumptions that are widely accepted. ZKPs, by contrast, are newer, more varied, and often rely on less-validated assumptions. For instance, many ZKPs use the random oracle model, which is known to be uninstantiable in theory — yet we use hash functions in practice. That gap is a risk that threat models must acknowledge. Additionally, the complexity of ZKP circuits means that implementation bugs (like under-constrained gates) can create hidden assumptions about the circuit's correctness. Auditing assumptions is not just a theoretical exercise; it directly affects whether your system is secure against real adversaries.

Mapping Assumptions to Your System Architecture

Before you can audit assumptions, you need a clear picture of where they live in your system. We recommend drawing a data-flow diagram that includes the prover, verifier, setup ceremony, smart contract (if any), and any off-chain components. For each arrow or interaction, ask: what does this step assume about the other party? For example, in a zk-rollup, the sequencer (prover) submits a batch proof to the on-chain verifier. The verifier assumes the sequencer is economically rational and will not produce invalid proofs because they would be slashed. But what if the sequencer can collude with a validator? That assumption might be violated. By mapping assumptions to components, you can prioritize which ones to test or mitigate.

A Concrete Example: Groth16's Trusted Setup

Groth16 requires a one-time trusted setup per circuit. The assumption is that at least one participant in the ceremony is honest and that the toxic waste (the secret randomness) is destroyed. In practice, ceremonies like the one for Zcash use multi-party computation (MPC) to reduce the risk, but the assumption remains: if all participants collude or if the randomness is leaked, the system is broken. When auditing, check whether the ceremony's transcript is publicly verifiable, whether enough participants were involved, and whether the waste disposal is documented. If the setup is reused across circuits (as in some universal setups), the assumptions change — now you need to trust the setup for all circuits, not just one.

Random Oracle Instantiation

Most ZKPs use the Fiat-Shamir heuristic to make interactive proofs non-interactive. This replaces the verifier's random challenge with a hash of the transcript. The assumption is that the hash function behaves like a random oracle. But real hash functions have structure (e.g., length extension in SHA-256, though SHA-3 is not vulnerable). In practice, using SHA-256 for Fiat-Shamir is considered safe, but the threat model should note that a breakthrough in hash function cryptanalysis could break the proof's soundness. We recommend using a hash function that is collision-resistant and has no known structural weaknesses, and documenting that choice.

Auditing the Assumption Stack Step by Step

Here is a workflow for auditing assumptions in a ZKP system. We assume you have access to the circuit source code, the proving system's implementation, and the deployment configuration.

1. List all assumptions explicitly. Go through the protocol specification and threat model document. Write down every assumption, even those that seem obvious. Categorize them by type (cryptographic, operational, economic, etc.).
2. Assess each assumption's plausibility. For each assumption, ask: how likely is it to be violated in our threat model? Use a simple scale (high/medium/low). For example, if the verifier is a smart contract on Ethereum, the assumption that the verifier is honest is high — the EVM executes code deterministically. But if the verifier is a human operator, the assumption is low.
3. Identify mitigations. For assumptions that are not plausible, what can you do? You might switch to a different proof system (e.g., from Groth16 to PLONK, which does not require a per-circuit trusted setup), use a transparent setup, or add economic penalties for misbehavior.
4. Test the assumptions. Some assumptions can be tested. For example, you can fuzz the verifier to see if it accepts malformed proofs. You can check the setup ceremony transcript for anomalies. For economic assumptions, simulate scenarios where the incentive is skewed.
5. Document and review. Write down the results of your audit, including which assumptions are accepted, which are mitigated, and which are open risks. Review this with the team and update the threat model.

Tools That Help

Several tools can assist in auditing ZKP assumptions. Circom's compiler can detect some under-constrained signals. SnarkJS allows you to verify the setup ceremony's transcript. For PLONK-based systems, you can use the Halo2 library's built-in checks. We also recommend using static analysis tools like Ecne (for circuit constraints) and ZK Audit frameworks that check for common vulnerabilities. None of these tools replace human reasoning, but they can catch obvious mistakes.

Common Pitfalls and How to Avoid Them

Even experienced teams make mistakes. Here are the most common pitfalls we see in ZKP threat models.

Under-Constrained Circuits

A circuit that does not enforce all necessary constraints can allow a prover to construct a valid proof for a false statement. For example, a circuit that checks a hash but does not constrain the hash output to match a public value. This is essentially an assumption that the prover will not exploit missing constraints. To avoid this, use formal verification tools to check that the circuit's constraints are complete. Write test cases that try to prove false statements and verify they are rejected.

Trusted Setup Toxic Waste

If the toxic waste from a trusted setup is not destroyed, anyone with access can forge proofs. The assumption that it was destroyed is often implicit. We recommend requiring a documented destruction ceremony with multiple witnesses, and using a setup that supports public verifiability of the destruction (e.g., via a transparency log).

Ignoring the Verifier's Capabilities

Some ZKPs assume the verifier has bounded computational resources (e.g., can only run a certain number of steps). If the verifier is a smart contract with gas limits, this assumption is real. But if the verifier is a server, the assumption might be violated by a denial-of-service attack that forces the verifier to drop proofs. Always consider the verifier's operational context.

Over-Reliance on Random Oracle Model

While the ROM is widely used, it is not a guarantee. If a hash function is broken, the proof system could lose soundness. We recommend using hash functions that are resistant to known attacks (e.g., SHA-3 or BLAKE2) and monitoring cryptanalysis literature. For high-security applications, consider using a proof system that does not rely on the ROM, such as those based on linear PCPs (though they are less efficient).

Variations for Different Constraints

Not all ZKP deployments are the same. Here we discuss how assumptions change under different constraints.

Resource-Constrained Provers

If the prover is a mobile device or IoT sensor, the assumption that it can generate proofs quickly may be false. In such cases, you might use a more efficient proof system like Bulletproofs (which have logarithmic-sized proofs but linear verification) or delegate proof generation to a server. The threat model must then account for the trust placed in that server.

Public vs. Private Verifiers

When the verifier is a public blockchain (e.g., Ethereum), the assumption that the verifier is honest is strong because the protocol is enforced by consensus. But when the verifier is a single entity (e.g., a company's API), the assumption is weaker. In the latter case, consider using a proof system that is publicly verifiable (anyone can check) to reduce trust.

Recursive Proofs

In recursive ZKPs (e.g., Halo2's recursion), the assumption that each layer's proof is correct compounds. A bug in the recursion circuit can break the entire chain. Auditing recursive proofs requires checking that the verification circuit itself is correct, which is a meta-assumption. We recommend using verified recursion libraries and testing with small recursion depths first.

Privacy vs. Scalability Trade-offs

Some ZKP systems prioritize privacy (e.g., zk-SNARKs for anonymous payments) while others prioritize scalability (e.g., zk-rollups). The assumptions differ: privacy-focused systems must ensure zero knowledge even against active adversaries, while scalability-focused systems may relax zero knowledge for efficiency (e.g., using transparent proofs). Know which property is critical and audit accordingly.

FAQ: Assumption Auditing in Practice

Q: How do I know if my trusted setup is safe? A: Check the ceremony transcript for public verifiability. Ensure that at least one participant was honest (you can verify this if the MPC protocol is secure against a dishonest majority). If the setup is reused, verify that the same toxic waste was not used for multiple circuits.

Q: What if I cannot verify the setup ceremony? A: Then you are assuming it was honest. Consider using a transparent setup (e.g., STARKs or PLONK with a universal setup) to eliminate this assumption.

Q: Can I use a hash function that is not collision-resistant? A: No. Collision resistance is necessary for soundness in most ZKPs. If you use a broken hash, an adversary can create collisions that lead to false proofs. Always use a hash function that is considered secure by the cryptographic community.

Q: How often should I re-audit assumptions? A: Whenever the system changes (e.g., new circuit, new verifier, new deployment) or when new cryptographic attacks are published. At a minimum, review assumptions annually.

Q: What is the biggest mistake teams make? A: Assuming that because a ZKP is "zero-knowledge," it is automatically secure against all attacks. The proof system is only one part of the security model; the application logic, key management, and operational practices matter just as much.

Next Steps for Your Audit

By now, you should have a clear process for auditing assumptions in your ZKP system. Here are three concrete actions to take next week:

1. Write down every assumption in your current threat model. Use the categories we discussed: cryptographic, operational, economic, and implementation.
2. For each assumption, assign a risk level and identify at least one mitigation or test. If an assumption is unmitigated and high-risk, consider changing the proof system or adding a fallback.
3. Run a test that deliberately violates one assumption (e.g., feed a malformed proof to the verifier) and see if the system fails gracefully. Document the result.

Auditing assumptions is not a one-time task; it is a discipline that should be integrated into your development lifecycle. As the ZKP landscape evolves, new assumptions (and attacks on old ones) will emerge. Stay informed, stay skeptical, and keep your threat model honest.