KZG Commitments

Polynomial commitments for EIP-4844 blob transactions, Proto-Danksharding, and data availability

Future Plans: This page is planned and under active development. Examples are placeholders and will be replaced with accurate, tested content.

KZG Commitments

KZG (Kate-Zaverucha-Goldberg) is a polynomial commitment scheme using pairings over the BLS12-381 elliptic curve, enabling succinct proofs of polynomial evaluations.

Mainnet-critical algorithm (post-Dencun) - Core primitive for EIP-4844 blob transactions, enabling proto-danksharding and L2 data availability scaling.

Overview

KZG commitments allow rollups to post large data blobs (~126 KB) as tiny commitments (48 bytes) on-chain. Validators can verify data availability without storing full blobs, enabling Proto-Danksharding and reducing L2 costs by 100-200x.

Why KZG for Ethereum?

Data Availability Crisis: L2s need cheap data posting Solution: Blob transactions with KZG commitments Impact: Rollup costs reduced from ~$1-5 to ~$0.01-0.10 per transaction

Key Properties:

• Succinct: 48-byte commitment for ~126 KB blob (4096 field elements)
• Binding: Cannot change blob after commitment
• Verifiable: Prove p(z) = y at any point
• Batch-friendly: Verify multiple proofs efficiently

Mathematical Foundation

Polynomial Commitments

Represent blob as polynomial:

p(x) = a₀ + a₁x + a₂x² + ... + a₄₀₉₅x⁴⁰⁹⁵

Commitment: C = [p(τ)]₁ (G1 point on BLS12-381)

Evaluation Proof for p(z) = y:

π = [(p(τ) - y)/(τ - z)]₁  (quotient polynomial in G1)

Verification (pairing check):

e(C - [y]₁, [1]₂) = e(π, [τ]₂ - [z]₂)

Trusted Setup

Ethereum KZG Ceremony: Multi-party computation generating trusted setup parameters

τ (tau): Secret value from MPC ceremony

• 140,000+ participants (Ethereum KZG ceremony 2023)
• Safe if ANY participant destroyed their secret
• Powers of τ precomputed in G1 and G2

Security Assumption: Soundness relies on at least one honest participant who destroyed their secret contribution. If all participants colluded, they could create false proofs. However, with 140,000+ participants, this scenario is cryptographically impractical.

Setup Size: ~1 MB (4096 G1 points + 65 G2 points)

Implementation Details

Native C Only: KZG operations via c-kzg-4844 library (trusted setup required)

WASM Not Supported: WASM target returns error.NotSupported due to C library dependencies. KZG is only available in native environments.

Import:

import { KZG } from '@tevm/voltaire/KZG';

Quick Start

Standard API

import { Kzg, Blob } from '@tevm/voltaire';

// Load trusted setup (once, required before operations)
Kzg.loadTrustedSetup();

// Create blob (131,072 bytes = 4096 field elements × 32 bytes)
const blob = Blob(131072);
// ... fill with rollup data

// Kzg.Commitment(blob) → 48-byte commitment
const commitment = Kzg.Commitment(blob);

// Kzg.Proof(blob, z) → proof at evaluation point
const z = randomFieldElement();
const { proof, y } = Kzg.Proof(blob, z);

// Kzg.verify(commitment, z, y, proof) → boolean
const valid = Kzg.verify(commitment, z, y, proof);

// Kzg.verifyBatch(blobs[], commitments[], proofs[]) → boolean
const batchValid = Kzg.verifyBatch(
  blobs, commitments, proofs
);

Factory API

import { Kzg, Blob } from '@tevm/voltaire';
import * as ckzg from 'c-kzg';

// Load trusted setup (once)
Kzg.loadTrustedSetup();

// Create factories with c-kzg dependency injection
const Commitment = Kzg.CommitmentFactory({
  blobToKzgCommitment: ckzg.blobToKzgCommitment
});
const Proof = Kzg.ProofFactory({
  computeKzgProof: ckzg.computeKzgProof
});
const verify = Kzg.VerifyFactory({
  verifyKzgProof: ckzg.verifyKzgProof
});
const verifyBatch = Kzg.VerifyBatchFactory({
  verifyBlobKzgProofBatch: ckzg.verifyBlobKzgProofBatch
});

// Use factories
const blob = Blob(131072);
const commitment = Commitment(blob);
const z = randomFieldElement();
const { proof, y } = Proof(blob, z);
const valid = verify(commitment, z, y, proof);
const batchValid = verifyBatch(blobs, commitments, proofs);

Benefits: Tree-shakeable, testable, custom c-kzg implementations

Documentation

Core Operations

• Commitments - Creating KZG commitments from blobs
• Proofs - Opening proofs and evaluation verification
• Point Evaluation - EIP-4844 precompile 0x0a
• Trusted Setup - Ceremony, verification, security

Integration

• EIP-4844 - Blob transactions, gas pricing, lifecycle
• Usage Patterns - L2 integration, data availability sampling
• Test Vectors - Official EIP-4844 test cases
• Performance - Benchmarks, gas costs, optimizations

EIP-4844 Blob Transactions

Blob Format

Size: 131,072 bytes (~126 KB) Structure: 4,096 field elements × 32 bytes Constraint: Each element < BLS12-381 scalar field modulus

Note: While often described as “128 KB”, the actual size is 131,072 bytes (128 × 1024), approximately 126 KB in decimal.

interface Blob {
  length: 131072;  // Fixed size
  elements: FieldElement[4096];  // BLS12-381 Fr elements
}

Transaction Type

Type 3 (Blob Transaction):

interface BlobTransaction {
  chainId: bigint;
  nonce: bigint;
  maxPriorityFeePerGas: bigint;
  maxFeePerGas: bigint;
  gasLimit: bigint;
  to: Address;
  value: bigint;
  data: Uint8Array;
  accessList: AccessList;
  
  maxFeePerBlobGas: bigint;  // New: blob gas pricing
  blobVersionedHashes: Hash[];  // New: KZG commitment hashes
  
  blobs: Blob[];  // Sidecar (not in tx hash)
  commitments: KZGCommitment[];  // Sidecar
  proofs: KZGProof[];  // Sidecar
}

Blob Lifecycle

1. Submission: Rollup creates blob transaction with KZG commitments
2. Inclusion: Block proposer includes in block
3. Verification: Nodes verify KZG proofs ensure commitment correctness
4. Availability: Blobs available for 18 days (commitments enable verification without full blob download)
5. Pruning: After 18 days, blobs deleted (commitments remain on-chain permanently)

Mainnet Deployment: Dencun hard fork (March 2024)

Point Evaluation Precompile

Address: 0x0a (precompile 0x0a)

Function: Verify KZG proof for blob evaluation

// Precompile input (192 bytes)
interface PointEvaluationInput {
  versionedHash: Bytes32;  // 32 bytes
  z: Bytes32;              // 32 bytes (evaluation point)
  y: Bytes32;              // 32 bytes (claimed value)
  commitment: Bytes48;     // 48 bytes (KZG commitment)
  proof: Bytes48;          // 48 bytes (KZG proof)
}

// Returns: 64 bytes (success)
// Reverts if proof invalid

Gas Cost: 50,000 gas (fixed)

Use Case: On-chain verification of blob data samples

Implementation

C-KZG-4844: Official Ethereum implementation

• Location: lib/c-kzg-4844/
• Language: C (portable)
• Audits: Sigma Prime (2023), zkSecurity (2025)

Zig Wrapper: src/crypto/c_kzg.zig

• Safe FFI bindings
• Error handling
• Memory management

Platform Support:

• Native: Full support via c-kzg-4844 C library
• WASM: NOT SUPPORTED - Returns error.NotSupported due to C library dependencies

Trusted Setup: Must call loadTrustedSetup() before any KZG operations. Setup loads Ethereum KZG Ceremony parameters (~1 MB).

Gas Economics

Blob Gas: Separate gas market from execution gas

Target: 3 blobs per block (~393 KB) Max: 6 blobs per block (~786 KB)

Pricing: EIP-1559 style (exponential)

baseFeePerBlobGas adjusts based on blob usage

Cost Comparison:

• Calldata: ~16 gas/byte × 131KB = 2.1M gas ($100-500)
• Blob: 50K gas per blob ($1-5)

Savings: 100-200x reduction for L2 transaction data costs

Security

Trusted Setup Security:

• Assumption: Safe if ≥1 participant destroyed their secret contribution
• Participants: 140,000+ in Ethereum KZG Ceremony (2023)
• Verification: Publicly verifiable transcript ensures ceremony correctness
• Risk: If all participants colluded, they could create false proofs. With 140,000+ participants, this is cryptographically impractical.

Commitment Binding:

• Computationally infeasible to find collision
• Based on discrete log hardness in G1 (BLS12-381)

Proof Soundness:

• Cannot forge proof for wrong evaluation value
• Pairing check guarantees correctness via bilinear map properties

Use Cases

Optimistic Rollups:

• Post transaction data as blobs
• Fraud proofs reference blob data

ZK Rollups:

• Post full transaction data
• Validity proofs verify state transition

Data Availability Sampling:

• Light clients sample random points
• Verify via KZG proofs
• Ensure data availability without full download

Performance

Native (c-kzg-4844):

• Blob to commitment: ~50 ms
• Compute proof: ~50 ms
• Verify proof: ~2 ms
• Verify blob proof batch: ~2 ms per blob

Limits:

• Max 6 blobs per block
• Verification time: ~12 ms per block (6 blobs)

Related

• BLS12-381 - Underlying elliptic curve
• Precompiles: Point Evaluation - 0x0a implementation
• KZG (Effect) - Effect.ts integration with Schema validation

References

• EIP-4844: Shard Blob Transactions
• KZG Ceremony
• c-kzg-4844 Library
• Proto-Danksharding FAQ