KZG Commitment (Kate-Zaverucha-Goldberg)

What Is a KZG Commitment?

A KZG commitment (named after its creators Aniket Kate, Gregory Zaverucha, and Ian Goldberg, who introduced the scheme in 2010) is a cryptographic commitment scheme for polynomials. It allows a prover to commit to a polynomial using a single elliptic curve point and later prove properties of that polynomial (such as its value at a specific input) without revealing the entire polynomial.

Think of it like a fingerprint for data. Just as a fingerprint uniquely identifies a person without revealing everything about them, a KZG commitment uniquely identifies a dataset (encoded as a polynomial) in just 48 bytes. Anyone can verify claims about the data by checking a compact proof against the commitment, without downloading the original data.

KZG commitments are foundational to modern blockchain scaling. They underpin Ethereum's blob transaction system (EIP-4844), the PLONK proving system used in many ZK-rollups, and various other zero-knowledge proof constructions. Their ability to produce constant-size proofs makes them especially attractive for on-chain verification where every byte of calldata costs gas.

How It Works

KZG commitments operate in three phases: setup, commitment, and proof verification. Each phase builds on elliptic curve mathematics, specifically bilinear pairings on curves like BLS12-381.

Trusted Setup

Before anyone can use KZG, a one-time trusted setup generates a structured reference string (SRS). This string contains powers of a secret value τ (tau) encoded as elliptic curve points:

SRS = [G, τG, τ²G, τ³G, ..., τⁿG]

where:
  G   = generator point of the elliptic curve
  τ   = secret value (must be destroyed after setup)
  n   = maximum polynomial degree supported

The critical security requirement: τ must never be known to anyone after the ceremony concludes. If any party ever learns τ, they could forge commitments and fake proofs. The ceremony uses multi-party computation so that τ is assembled from contributions by many independent participants, and the setup remains secure as long as at least one participant honestly destroyed their secret share.

Committing to Data

To commit, the prover first encodes their data as a polynomial. For example, a dataset of values [v₀, v₁, v₂, ...] becomes a polynomial p(x) that passes through those points. The commitment is then computed by evaluating the polynomial "inside" the elliptic curve using the SRS:

C = p(τ)·G = a₀·G + a₁·(τG) + a₂·(τ²G) + ... + aₙ·(τⁿG)

where:
  C        = the commitment (a single curve point, 48 bytes)
  a₀..aₙ  = polynomial coefficients
  τⁱG      = values from the SRS (tau is never known directly)

The prover never learns τ directly. They combine the public SRS points with their polynomial coefficients using elliptic curve arithmetic. The result is a single 48-byte curve point that uniquely represents the polynomial. This commitment is binding (the prover cannot change the polynomial after committing) and hiding (the commitment reveals nothing about the polynomial's coefficients).

Opening and Verification

To prove that the polynomial evaluates to a specific value y at a point z (that is, p(z) = y), the prover computes a quotient polynomial:

q(x) = (p(x) - y) / (x - z)

// This division is exact (no remainder) if and only if p(z) = y
// The proof π is the KZG commitment to q(x):
π = q(τ)·G

The verifier checks the proof using an elliptic curve pairing equation. This check confirms that the committed polynomial actually evaluates to y at point z, without the verifier ever seeing the polynomial itself. The verification requires only two pairing operations and runs in constant time regardless of the polynomial's degree.

// Verification pairing check:
e(π, τG - zG) = e(C - yG, G)

// If this equation holds, the proof is valid
// e() denotes the bilinear pairing function

Use Cases

EIP-4844 Blob Transactions

The most prominent deployment of KZG commitments is in Ethereum's proto-danksharding upgrade (EIP-4844), activated in March 2024 with the Dencun hard fork. Each blob transaction carries up to six blobs of approximately 128 KB each, and every blob is accompanied by a KZG commitment.

The commitment serves as a compact fingerprint of the blob data. Consensus-layer nodes store and propagate the full blob data for roughly 18 days, but execution-layer nodes only need the 48-byte commitment. Smart contracts access blob commitments through versioned hashes (the commitment hash prefixed with a 0x01 version byte) via the BLOBHASH opcode.

A point evaluation precompile allows on-chain verification of claims about blob contents. This means a rollup's on-chain contract can verify that specific data was included in a blob without reading the full blob, enabling data availability guarantees at a fraction of the cost of calldata. Rollups using blob transactions have seen data costs drop by approximately 90% compared to posting data as calldata.

For a deeper analysis of how blobs changed Ethereum's fee dynamics, see EIP-4844 and the blob fee market.

Data Availability Sampling

KZG commitments are essential to Ethereum's roadmap for full danksharding. In this future upgrade, data availability sampling (DAS) will allow validators to verify that blob data is available by downloading only a few random samples rather than the entire dataset. KZG makes this possible because the polynomial structure allows any individual evaluation to be verified against the commitment.

With DAS, each validator samples a small number of points, and if enough validators independently confirm their samples, the network gains high statistical confidence that the full data is available. This approach scales blob throughput dramatically without requiring each node to download all data.

Zero-Knowledge Proof Systems

KZG commitments are a core building block in many zk-SNARK systems. PLONK, one of the most widely deployed proving systems, uses KZG as its polynomial commitment backend. The constant-size proofs (approximately 0.5 KB for PLONK) and fast verification make KZG-based SNARKs practical for on-chain proof verification.

Other systems that use or have used KZG commitments include Sonic, Marlin, and the original Plonky1. Research has shown that nearly all known zk-SNARKs with constant-size arguments rely on KZG or a closely related polynomial commitment. For a broader look at how zero-knowledge proofs apply across blockchains, see zero-knowledge proofs and Bitcoin applications.

Rollup Validity Proofs

ZK-rollups such as zkSync, Scroll, and Polygon zkEVM use KZG-based proving systems to generate validity proofs for batches of transactions. The rollup operator commits to the state transition using polynomials, and the on-chain verifier checks a constant-size proof to confirm that thousands of transactions were executed correctly. This is what makes ZK-rollups scalable: verification cost stays constant regardless of batch size.

The Ethereum KZG Ceremony

Because KZG requires a trusted setup, Ethereum organized the largest such ceremony ever conducted. The ceremony ran from January to August 2023 and collected 141,416 contributions from participants around the world. Contributors used browser-based tools, custom scripts, and even hardware in space (Cryptosat contributed from a satellite) to add entropy.

The security guarantee: as long as at least one of those 141,416 contributors honestly generated randomness and destroyed their secret, the resulting SRS is secure and no one can forge KZG proofs. The scale of participation makes it practically impossible that every single contributor was compromised or dishonest.

The ceremony generated the structured reference string now used by all EIP-4844 blob transactions on Ethereum mainnet. The SRS supports polynomials up to degree 4,096, matching the number of field elements in a single blob.

Risks and Considerations

Trusted Setup Dependency

KZG's reliance on a trusted setup is its most debated property. If the secret τ were somehow reconstructed (requiring collusion among all ceremony participants), an attacker could forge valid-looking proofs for arbitrary data. While the 141,000+ participant ceremony makes this practically impossible, it remains a theoretical concern and a philosophical departure from trustless systems.

Alternative commitment schemes like FRI (used in STARKs) avoid trusted setups entirely but produce larger proofs. The tradeoff between setup trust and proof size is a fundamental design decision in cryptographic protocol engineering.

Post-Quantum Vulnerability

KZG commitments rely on the hardness of the discrete logarithm problem on elliptic curves with bilinear pairings. A sufficiently powerful quantum computer running Shor's algorithm could break this assumption, allowing an attacker to extract τ from the SRS or forge proofs directly. Ethereum's own documentation flags KZG as vulnerable to quantum attacks and identifies STARK-based commitments (which rely on hash functions rather than pairings) and lattice-based schemes as potential replacements.

No practical quantum computer capable of this attack exists today, but the concern shapes long-term protocol planning. For more on quantum threats to cryptographic systems, see post-quantum cryptography and the Bitcoin threat model.

Curve-Specific Assumptions

KZG commitments used in Ethereum operate on the BLS12-381 curve, which supports efficient bilinear pairings. This curve choice ties KZG's security to specific mathematical assumptions about the elliptic curve group. Unlike hash-based schemes that can swap underlying primitives relatively easily, migrating KZG to a different curve would require a new trusted setup ceremony.

Proof Size vs. Setup Tradeoff

KZG proofs are constant-size (48 bytes for a single opening), making them ideal for on-chain verification where gas costs scale with data size. However, this compactness comes at the cost of the trusted setup. Systems that prioritize eliminating trust assumptions (like STARKs) accept larger proof sizes (tens to hundreds of kilobytes) in exchange for transparent, setup-free security. Choosing between KZG and alternatives depends on whether proof compactness or trust minimization matters more for a given application.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.