KZG Commitments

How a structured reference string turns "prove you know a polynomial" into a single group element, and how a pairing equation lets a verifier check an opening in constant time.

The problem a commitment solves

Say I have a polynomial and want to convince you of two things later: that I fixed it in advance and haven't changed it since, and that it evaluates to some specific value at some specific point — all without ever sending you the whole polynomial. A polynomial commitment scheme is exactly this: a short, binding commitment now, and a small proof for each evaluation claim later.

KZG — named for Kate, Zaverucha, and Goldberg — is one of the most widely used schemes for doing this. It's the commitment scheme behind Groth16, PLONK-style SNARKs, and Ethereum's proto-danksharding blob commitments.

The structured reference string

KZG needs a shared setup before anyone commits to anything: a structured reference string (SRS) — a sequence of powers of some secret value, each one multiplied into a group generator. Conceptually, that's g, g^s, g^s², g^s³, … up to whatever the maximum polynomial degree requires.

The secret value s — sometimes called toxic waste — must never be known to anyone once the setup finishes. If it leaks, someone can forge false commitments and openings. That's why KZG setups are usually run as multi-party ceremonies: many participants each contribute randomness, and the setup stays secure as long as even one of them destroyed their share honestly. No single party ever needs to be fully trusted on their own.

Committing and opening

Committing to a polynomial means evaluating it "in the exponent" using the SRS — combining the SRS elements with the polynomial's coefficients to produce a single group element. That one element is binding: given the SRS, it's computationally infeasible to find a different polynomial that produces the same commitment.

To later prove the polynomial evaluates to some value at some point, the prover leans on a basic fact about polynomials: if a polynomial takes a given value at a given point, subtracting that value leaves a polynomial with a root there — which means it divides evenly by a simple linear factor. The prover computes that quotient polynomial and commits to it. That commitment to the quotient is the opening proof — again, a single group element.

Why a pairing makes this checkable

The verifier can't just divide two group elements the way you'd divide numbers, so KZG relies on a bilinear pairing — a function that takes two group elements and maps them into a third group while respecting exponents, in a way that lets multiplicative relationships be checked "in the exponent."

Using a pairing, the verifier checks a single equation involving the commitment, the opening proof, the claimed evaluation point, and the claimed value. If that equation holds, the verifier is convinced the committed polynomial really does evaluate to the claimed value at the claimed point — without ever seeing the polynomial itself. This is what makes KZG openings succinct: constant-size proofs and constant-time verification, regardless of the polynomial's degree.

BLS12-381, briefly

KZG needs a pairing-friendly elliptic curve to work over, and BLS12-381 is the one most commonly paired with it in practice — used across Ethereum's consensus layer and blob commitments, and in most PLONK-style proving systems. Its main properties are an efficient pairing operation and roughly 128 bits of security, which together make constant-size, fast-to-verify proofs practical.

The trade-off, stated plainly