Zero-Knowledge Proof Validator
Validate zero-knowledge circuit syntax and detect likely unsound constraints.
ZK-Proof Circuit Validator
Estimate Zero-Knowledge circuit constraints and prover memory requirements.
ZK Circuit Math: Groth16 requires a Trusted Setup (CRS) but generates constant ~128-byte proofs. STARKs are post-quantum secure but verification gas is 8x higher than SNARKs on Ethereum L1.
| Hardware Memory | 2 GB RAM |
| Security Level | ~128-bit |
| Verification Gas | 200,000 units |
Groth16, PLONK, and STARK: What the Choice Actually Costs You
The three proof systems this tool models make fundamentally different trade-offs between setup trust requirements, proof size, constraint overhead, and on-chain verification cost. Groth16 requires a circuit-specific trusted setup ceremony — a multi-party computation that generates a structured reference string tied to your exact circuit. If the circuit changes, the ceremony must be repeated. This constraint produces the smallest proof size on Ethereum (approximately 128 bytes for the verification key components) and the lowest gas cost for on-chain verification. It is the dominant choice for production ZK applications where circuits are stable, including Zcash and most zkEVM implementations. PLONK uses a universal trusted setup — one ceremony covers any circuit that fits within the SRS size parameter, so circuit changes do not require a new ceremony. Proof size is roughly 300 to 400 bytes and constraint overhead is 1.3 times Groth16 for the same logical operations. PLONK is preferred when circuits are in active development or when the cost of organising a per-circuit ceremony is prohibitive. STARK requires no trusted setup at all — security relies entirely on cryptographic hash functions, making it post-quantum resistant. The trade-off is that proof sizes are orders of magnitude larger than Groth16 or PLONK (typically 50 to 200 kilobytes), on-chain verification is significantly more expensive, and the constraint overhead is 2.1 times Groth16. STARKs are used where eliminating trust assumptions outweighs proof size and verification cost concerns, most notably in StarkWare's production deployments.
How Circuit Constraints Translate to Hardware Memory Requirements
A circuit constraint is an arithmetic relationship — typically an addition or multiplication gate — that the prover must satisfy during proof generation. The prover works over a finite field, performing polynomial operations across all constraints simultaneously via Fast Fourier Transform. This is why memory requirements scale non-linearly with constraint count rather than linearly. The FFT step requires holding coefficient vectors of size equal to the next power of two above your constraint count, and doing multiple passes over that data. Empirically, Groth16 prover memory peaks at approximately 100 to 200 bytes per constraint for the FFT working set, with a 4 to 8 times multiplier for intermediate polynomial products. At 500,000 constraints this gives roughly 400 megabytes to 800 megabytes — well within the WebAssembly 4 gigabyte address space limit and feasible in most browsers. At 1,500,000 constraints the working set approaches 1.2 to 2.4 gigabytes, which is feasible on desktop but problematic on mobile or in memory-constrained CI environments. Above 2,000,000 constraints — the browser feasibility threshold this tool uses — peak memory reliably exceeds 4 gigabytes, requiring a native prover process or GPU-accelerated proving infrastructure such as RapidSNARK or Bellman running server-side. The STARK multiplier of 2.1 means a circuit with 500,000 logical operations translates to over 1,000,000 effective constraints, pushing hardware requirements into the server-side range earlier.
Worked Example: ZK Age Verification With Hashed Identity Attributes
Consider a ZK proof that a user is over 18 without revealing their exact birthdate or national ID. The circuit takes three private inputs — a birthdate integer, a hashed national ID, and a salt — and two public inputs — the minimum age threshold and the current date. Two Poseidon hash operations are performed inside the circuit to commit the private attributes. Using Groth16: constraints equal ((3 private inputs times 15) plus (2 public inputs times 30) plus (2 hash operations times 300)) times 1.0 system factor, totalling 705 constraints. This is well below the 2 million browser feasibility threshold. Peak RAM is negligible — under 10 megabytes. The Ethereum L1 verification gas cost for a Groth16 proof of this size is approximately 220,000 to 250,000 gas, which at 20 gwei and 3,000 USD ETH corresponds to roughly 13 to 15 USD per verification. For a production KYC gate processing thousands of users per day, this on-chain cost makes L1 verification prohibitive — the same circuit on a zkRollup verification layer reduces per-user cost by approximately 1,000 times by amortising the proof across many state transitions, making the approach economically viable at scale.
Frequently Asked Questions
Commonly Asked Questions
- What is a circuit constraint and why does the count matter?
- A constraint is a single arithmetic equation — typically R1CS form: a times b equals c over a prime field — that the prover must satisfy. Every logical operation in your ZK program compiles down to one or more constraints: a field multiplication is roughly one constraint, a comparison operation is 30 to 50 constraints depending on bit width, and a cryptographic hash over a ZK-friendly function like Poseidon is approximately 300 constraints. Constraint count determines prover RAM, proving time, and ultimately whether browser-based proving is feasible without dedicated hardware.
- Why does STARK have a 2.1 times constraint multiplier compared to Groth16?
- STARK arithmetisation uses AIR (Algebraic Intermediate Representation) rather than R1CS, which requires expressing computations over execution traces rather than individual gate equations. The trace encoding introduces additional auxiliary columns for boundary constraints, transition constraints, and FRI (Fast Reed-Solomon IOP) proximity checks. These structural overheads mean that a computation requiring 100,000 R1CS constraints in Groth16 requires approximately 210,000 effective trace cells in a STARK, before any FRI repetition parameter overhead. The 2.1 multiplier in this tool is a conservative mid-range figure — actual multipliers vary between 1.8 and 2.5 depending on the specific STARK implementation and circuit structure.
- What hash function should I use for ZK-friendly operations inside a circuit?
- Standard cryptographic hash functions like SHA-256 and Keccak are expensive inside ZK circuits because they use bitwise operations that map poorly to prime-field arithmetic. SHA-256 in a Groth16 circuit costs approximately 25,000 constraints per hash. ZK-native hash functions designed for algebraic structures — Poseidon, MiMC, and Rescue — reduce this to 200 to 400 constraints per hash by working natively in the same prime field the proving system uses. This tool uses 300 constraints per hash operation as a mid-range estimate. If your application requires Ethereum Keccak compatibility for on-chain verification, either accept the constraint cost or use a recursive proof to bridge between the native hash and Keccak.
- What does browser WASM feasibility mean in practice?
- Browser feasibility means the proof can be generated client-side using a WASM-compiled prover library such as snarkjs without exceeding the WebAssembly linear memory limit of 4 gigabytes. This is significant for user-privacy applications — a browser-based prover means the private inputs never leave the user's device, because the proof is generated locally before any network request is made. Server-side proving requires sending private inputs to the prover server, which reintroduces the trust assumption that ZK proofs are often used to eliminate. If your circuit exceeds the 2 million constraint browser threshold, you must either simplify the circuit, use a recursive composition approach to split proving across smaller sub-circuits, or accept that private inputs will transit to a proving server.
- How much does Groth16 verification cost on Ethereum mainnet in USD?
- On-chain Groth16 verification gas cost is largely independent of circuit size — it depends on the verification key size, which is proportional to the number of public inputs. A typical Groth16 verifier with 2 to 4 public inputs costs 200,000 to 300,000 gas. At 20 gwei gas price and ETH at 3,000 USD, that is approximately 12 to 18 USD per verification. At 100 gwei — common during high network load — the cost rises to 60 to 90 USD. This makes direct L1 verification economically viable only for high-value transactions. Layer 2 rollup verification amortises the cost across thousands of proofs by verifying one aggregated batch proof per settlement transaction, reducing effective per-user cost to fractions of a cent.
- When does the 2,000,000 constraint threshold become a practical problem?
- Most simple ZK applications — age gates, credential proofs, single-value range proofs — stay well below 100,000 constraints and are comfortably browser-feasible. The 2 million threshold becomes relevant when circuits include: multiple Keccak or SHA-256 hashes for Ethereum compatibility (25,000 constraints each), deep Merkle proof paths (roughly 5,000 constraints per 20-level tree), complex arithmetic over 256-bit integers rather than native field elements, or repeated verification of cryptographic signatures inside the circuit. zkEVM circuits — which must prove every Ethereum opcode execution — are the most constraint-intensive common application, typically requiring tens of millions of constraints per block and GPU cluster infrastructure to prove within block time.