IPTF
concept hybrid I2I + I2U

ZK Proof Systems

Give designers a decision framework for choosing a zero-knowledge proof system on Ethereum. A zero-knowledge proof lets one party prove a statement is true without revealing the inputs. The system's commitment scheme (elliptic-curve pairings, discrete log over curves, collision-resistant hashes, or lattices) drives its post-quantum posture; the setup model drives its trust assumption; proof size and prover and verifier cost drive deployment economics.

CR
Medium
Censorship Resistance
O
Yes
Open Source
P
Full
Privacy
S
Medium
Security
CROPS context
Censorship Resistance
Proof systems themselves do not resist censorship; the surrounding verifier, sequencer, and DA choices do. Transparent systems eliminate the ceremony-operator trust point.
Open Source
Pairing-based and hash-based proof systems have open-source reference implementations. Domain-specific zkVMs and production proving services vary in licensing.
Privacy
All listed systems provide computational zero-knowledge. Metadata at the prover (proof requests, witness sizes) and at the verifier (on-chain calls, proof sizes) remains visible.
Security
Rides on the soundness of each system plus the integrity of any trusted ceremony. Hash-based and lattice-based systems remain sound against a CRQC; pairing-based and elliptic-curve-based systems do not.
I2I
Between institutions the dominant constraint is typically on-chain verification gas and ecosystem maturity; trusted-setup ceremonies can be run bilaterally or within a consortium. PQ migration planning is bounded by the parties' own retention windows.
I2U
For user-facing deployments the dominant constraint is client-side proving cost on mobile and browser targets. Transparent systems avoid toxic-waste risk and delegation-friendly backends reduce the device burden; HNDL risk for long-lived user data raises the priority of PQ-safe backends.
Works best when
Selecting a proof system for a new privacy design on Ethereum.
Evaluating post-quantum readiness of an existing zero-knowledge stack.
Comparing trust assumptions, proof size, and prover and verifier cost across backends.
Avoid when
The application does not use zero-knowledge proofs.
A specific proof system is mandated by an existing verifier contract and no migration is planned.
Intent

Give designers a decision framework for choosing a zero-knowledge proof system on Ethereum. A zero-knowledge proof lets one party prove a statement is true without revealing the inputs. The system's commitment scheme (elliptic-curve pairings, discrete log over curves, collision-resistant hashes, or lattices) drives its post-quantum posture; the setup model drives its trust assumption; proof size and prover and verifier cost drive deployment economics.

Components
  • Pairing-based SNARKs rely on elliptic-curve pairings over curves such as BLS12-381 or BN254 and produce small constant-size proofs with low verifier cost. Groth16 requires a trusted setup per circuit; PLONK over KZG uses a universal setup.
  • Elliptic-curve-based SNARKs rely on discrete log over an elliptic curve without pairings. Transparent setup, moderate proof size, medium verifier cost. PLONK over IPA and the Halo2 family sit here.
  • Hash-based proof systems rely on collision-resistant hashes. STARKs over FRI and hash-based SNARKs (Plonky family, Binius) have transparent setup and remain sound against a CRQC, at the cost of larger proofs.
  • Lattice-based SNARKs rely on Module-SIS or LWE hardness. Emerging, transparent, and PQ-safe; no production deployment yet.
  • Hybrid systems compose a hash-based STARK with a pairing-based SNARK wrapper to achieve small on-chain proofs; the wrapper reintroduces pairing assumptions and the matching PQ exposure.
Protocol
1
[designer] Define the statement to be proved (preimage knowledge, state-transition validity, credential verification).
2
[designer] Express the computation as an arithmetic circuit or constraint system (R1CS, PLONKish, AIR) in a chosen DSL.
3
[operator] Run the required setup: trusted per-circuit ceremony for Groth16, trusted universal ceremony for PLONK over KZG, or transparent setup for STARK, IPA, and hash-based systems.
4
[prover] Generate a proof from the private witness and the public inputs.
5
[verifier] Check the proof on-chain or off-chain against the public statement; verifier cost is driven by proof size and the verification algorithm.
6
[designer] Re-evaluate the backend choice on roadmap checkpoints, driven by PQ migration deadlines and proof-size or gas improvements.
Guarantees & threat model

Guarantees:

  • Completeness: an honest prover with a valid witness always convinces the verifier.
  • Soundness: all listed systems offer computational soundness; a cheating prover cannot convince the verifier except with negligible probability under the stated cryptographic assumption.
  • Zero-knowledge: each system hides the prover's private inputs from the verifier.
  • Transparency (STARK, IPA, hash-based SNARK): no trusted party or ceremony is required.
  • PQ safety: hash-based and lattice-based systems remain sound against quantum adversaries; pairing-based and elliptic-curve-based systems do not.

Threat model:

  • Soundness holds only under the stated assumption: hardness of discrete log for EC-based systems, pairing-related assumptions for pairing-based systems, collision resistance for hash-based systems, Module-SIS or LWE for lattice-based systems.
  • Trusted setups require that at least one ceremony participant was honest and that toxic waste was destroyed; a compromised ceremony allows proofs for false statements.
  • Side-channel attacks on the prover or the signer for recursion are out of scope.
  • Verifier contract bugs or mis-wired public inputs can accept proofs that the proof system itself rejects.
Trade-offs
  • PQ migration cost: existing pairing-based circuits must be re-implemented for hash-based or lattice-based backends; constraint systems differ (R1CS vs AIR) and field arithmetic differs.
  • Proof size on-chain: hash-based proofs are roughly 100 to 1000 times larger than pairing-based proofs. EIP-4844 blobs help but on-chain verification remains more expensive.
  • Hybrid complexity: wrapping a STARK in a pairing-based SNARK yields small on-chain proofs but reintroduces pairing assumptions and the matching PQ exposure.
  • Ecosystem maturity: pairing-based tooling (Circom, Noir, Halo2) is more mature than STARK tooling, though the gap is closing.
Post-quantum
high risk
Vector: Pairing-based systems (Groth16, PLONK over KZG) and elliptic-curve-based systems (PLONK over IPA, Halo2) are broken by a CRQC. HNDL risk applies to any proof whose soundness must hold against a future quantum adversary, for example proofs anchoring long-lived state.
Mitigation: Migrate to hash-based systems (STARK, hash-based SNARK) or lattice-based systems for long-horizon designs. See Post-Quantum Threats.
Example

A privacy L2 uses pairing-based PLONK for transaction proofs today. To prepare for post-quantum migration, the team evaluates moving to a FRI-based STARK backend. Proof size grows from about 400 bytes to about 100 kilobytes, but proofs become PQ-safe and require no trusted setup. Recursive composition keeps on-chain verification cost manageable, and EIP-4844 blobs carry proof Data Availability at lower cost than calldata.

Open-source implementations
arkworks ecosystem, reference Rust libraries for Groth16, PLONK, IPA
Rust
Plonky3 hash-based SNARK toolkit
Rust
Stone STARK prover (transparent, hash-based)
C++, Rust