Skip to content
Blockchain LabTHE VENTURE STUDIO

LibraryPrivacy2016Design paperCorpus record

On the Size of Pairing-based Non-interactive Arguments

Groth16. Jens Groth.

A pairing-based argument in three group elements. The proofs are tiny and cheap to verify. Each circuit needs its own setup, and a leaked setup can forge proofs.

Groth16 proves an arithmetic circuit in three group elements. Verification is a handful of pairings. The structured reference string is specific to that circuit, and anyone who kept the trapdoor can forge.

The five-minute read

Size is the result

The paper is about how small a pairing argument can be. Three group elements became the reference that later systems either beat for other reasons or deliberately gave up.

The string is the circuit

The setup bakes in the program. Change a constraint and the old ceremony does not apply. A team that says we upgraded the circuit and kept the setup has left the proof system.

Toxic waste is literal

The trapdoor can satisfy the verifier for a false statement. Multi-party ceremonies exist to make one honest deletion enough. A ceremony that nobody can audit is a trusted party with extra steps.

Zero knowledge is optional to the use

The same argument can prove a public computation. Privacy appears only if the witness stays secret and the circuit does not leak it. A public input can undo the slogan.

One action, walked through

  1. Someone writes the statement as an arithmetic circuit.
  2. A setup produces a proving key and a verification key, and is supposed to destroy the trapdoor.
  3. The prover, who knows the witness, produces three group elements.
  4. Anyone with the verification key checks a pairing equation.
  5. A new circuit requires a new setup before those steps mean anything.

The argument, unpacked

Tiny proofs moved the trust into the ceremony

The chain is easy to verify and hard to trust if the setup is opaque. PLONK later made the setup universal so one ceremony could serve many circuits. It did not make the ceremony optional. STARKs are the line that refuses the string.

A proof of the wrong circuit is a correct proof

Groth16 will happily prove that a weaker program accepted a bad state. Auditing the circuit is not the cryptography's job, and it is most of the actual risk.

What has to be true

  • Knowledge-of-exponent type assumptions hold in the pairing groups.
  • The trapdoor was destroyed. One party who kept it can forge.
  • The verifier uses the verification key that matches the circuit the users think is running.
  • Public inputs really are the statement. Moving a secret into the public input destroys the privacy claim without breaking the proof.

What happened after the paper

Zcash's Sapling era and many early rollup proofs used Groth16 because the proofs are small. Newer systems moved to PLONK-family or transparent proofs to escape per-circuit setups. A project still on Groth16 in 2026 has to name its ceremony and its circuit. The paper will not do that for them.

What to check before you use the idea

  • Which circuit is bound to the reference string?
  • Who participated in the setup, and how is the transcript checked?
  • What is a public input, and does it leak the witness?
  • Is a circuit change paired with a new setup?

Terms

Common reference string
The setup output both prover and verifier need. In Groth16 it is specific to one circuit.
Trapdoor
The secret from the setup that can forge proofs if it is kept.

The problem the paper names

Earlier SNARKs were still large or costly. Groth16 is about the minimum size of a pairing argument for an arithmetic circuit, under a structured reference string.

What the design proposes

  • A circuit-specific common reference string.
  • A proof of three group elements.
  • Verification with a small number of pairings.

How the mechanism is specified

  • The setup encodes the circuit. A different program needs a different setup.
  • Soundness fails if the trapdoor is known. The ceremony is the security assumption you can actually botch.
  • Zero knowledge is a property of the proof, not a property of the system that feeds it secret data.

What this page does not treat as proven

  • Do not call a Groth16 deployment trustless. The setup is a trust assumption.
  • Universal setups are PLONK and its relatives, not this paper.
  • A small proof is not a small prover. Proving cost still tracks the circuit.

Why a venture studio still reads it

Ask who ran the setup, who was supposed to delete the trapdoor, and what program the string is bound to. If those answers are missing, the three group elements are a costume.

This is Blockchain Lab's reading of a public design paper. It is not the paper, not a copy of it, and not an offer of tokens, equity, custody or a partnership. Later network behaviour can diverge from the text. Nothing here is investment, legal or technical advice.

Research status: Design paper. Last reviewed: 1 October 2026. This is a reading of a public paper, not investment, legal or security advice.