Skip to content
Blockchain LabTHE VENTURE STUDIO

LibraryPrivacy2019Design paperCorpus record

PLONK: Permutations over Lagrange-bases for Oecumenical Noninteractive arguments of Knowledge

PLONK. Ariel Gabizon, Zachary J. Williamson and Oana Ciobotaru.

A SNARK with a universal and updatable structured reference string. One setup can serve many circuits. The proofs are larger than Groth16, and there is still a setup.

PLONK moves the circuit out of the trusted setup. One structured string can serve many programs. Proofs are larger than Groth16, and a setup still exists.

The five-minute read

Universal means reusable, not optional

The reference string does not encode one circuit. You can prove a new program without a new ceremony. You cannot skip the ceremony entirely. That is the difference from a STARK.

Permutations wire the gates

The paper checks that a value leaving one gate is the value entering another by a permutation argument. Custom gates then express the actual program. The wiring is part of what an auditor has to read.

Updates need an honest participant

An updatable string lets a later party randomise the trapdoor. Soundness returns if at least one updater was honest and destroyed their contribution. An update theatre with no honest party is still a trapdoor.

Variants are not the same paper

TurboPLONK and UltraPLONK add gates and lookups. A rollup that says PLONK may mean a variant with a different verifier. Ask for the circuit and the variant.

One action, walked through

  1. A one-time setup produces a universal string. Later parties may update it.
  2. The team encodes their program as gates and a wiring permutation.
  3. The prover commits to the witness polynomials and produces an evaluation proof against the universal string.
  4. The verifier checks the permutation and the gate constraints.
  5. A changed program changes the prover's circuit description. It does not, by itself, require a new string.

The argument, unpacked

The ceremony stopped blocking iteration

Groth16 made every circuit edit a social event. PLONK's adoption in rollups is largely about being able to patch a virtual machine without reassembling the planet. The trust did not leave. It concentrated in one string.

Updatability is a process claim

The math says an honest update suffices. A real system has to show that an honest update happened and that the verifier key everyone uses is the one that update produced.

What has to be true

  • The polynomial commitment's setup assumption holds, and at least one setup contributor was honest if the string is updatable.
  • The Fiat-Shamir transcript binds the proof to this circuit and this public input.
  • The verifier checks the wiring, not only a proof blob handed to a contract.
  • Custom gates used by a variant are specified. Unspecified gates are a different language.

What happened after the paper

PLONK-family proofs became the default for many zk-rollups and zkEVMs because one setup could survive circuit changes. STARKs competed by refusing the setup and paying in proof size. A 2026 system that says PLONK should be pinned to a variant, a circuit hash, and a setup transcript. The 2019 paper is the permutation argument, not that transcript.

What to check before you use the idea

  • Is the reference string universal, and which variant is implemented?
  • Who updated the string, and is the verifier key the updated one?
  • What is the circuit hash users are supposed to be proving?
  • How big is the proof relative to a Groth16 proof of the same program?

Terms

Universal setup
A structured string that is not tied to one circuit, so later programs can reuse it.
Permutation argument
The check that wires carry the same value between gates, which is how the circuit is held together.

The problem the paper names

Groth16's ceremony is per circuit. Teams were running a new trusted setup every time the program changed. PLONK moves the circuit description into the proof so the setup can be reused.

What the design proposes

  • A permutation argument checks that wires are the same value in different gates.
  • Custom gates encode the program.
  • The reference string can be updated by later participants, so one honest participant restores soundness if the update is real.

How the mechanism is specified

  • Universality means the toxic setup is not tied to one circuit. It does not mean there is no toxic setup.
  • Updatability helps only if an honest party actually contributed and the transcript is checked.
  • Verifier time and proof size sit between Groth16 and a STARK. That is the trade the paper is for.

What this page does not treat as proven

  • PLONK is not a STARK. Transparency is a different property.
  • A universal string does not audit the circuit. A wrong circuit is honestly proved.
  • Later variants, TurboPLONK and UltraPLONK, change the gates. Cite the variant.

Why a venture studio still reads it

When a rollup says PLONK, ask whether the setup is universal, who can update it, and which circuit is actually being proved. The brand is not the circuit.

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.