← Back to blogs
// TECHNICAL WRITING

How ZK-Rollups Work After EIP-4844: From calldata to Blobs

How ZK-Rollups Work After EIP-4844: From calldata to Blobs — thumbnail

// · · 5 min read

blockchain zero knowledge evm

The Ethereum Dencun upgrade, powered by EIP-4844 (Proto-Danksharding), marks a fundamental shift in how Layer 2 rollups achieve scalability. This update introduces a new, cost-effective way to post data on-chain, moving away from the expensive calldata method to a new system: "blobs."

For ZK-Rollups, this isn't just a simple swap. It requires a new cryptographic architecture to prove that the data processed off-chain is the same data posted in these new blobs. This article breaks down the problem, the EIP-4844 solution, and the clever cryptographic trick ZK-rollups now use.

The Old Bottleneck: Data Availability via calldata

To maintain security and allow anyone to reconstruct the L2 state (a property called data availability or DA), rollups must post all their transaction data to the L1 (Ethereum).

  • Before EIP-4844: The only place to do this was in a transaction's calldata.
  • The Problem: This was extremely expensive. calldata is processed by all Ethereum nodes and competes for the same block space as L1 transactions. For many rollups, this DA cost accounted for over 80% of their total user transaction fees.

The EIP-4844 Solution: Blob-Carrying Transactions

EIP-4844 introduces blob-carrying transactions. A blob is a large (~128 KB) packet of data designed specifically for rollup DA.

Here's what makes blobs a game-changer:

  • Cheap: Blobs have a separate fee market (blob gas), so they don't compete with regular L1 transactions.
  • Temporary: Blob data is pruned from L1 nodes after a few weeks (e.g., ~18 days). This is long enough for DA, but it avoids permanently bloating the Ethereum state.
  • Opaque to the EVM: This is the most crucial part. The EVM cannot read the data inside a blob. Instead, the execution layer only has access to a cryptographic commitment to the blob.

This commitment is not a simple hash. EIP-4844 uses KZG (Kate-Zarankiewicz-Goldwasser) commitments. The L1 contract sees a versioned_hash (derived from the blob's KZG commitment) and can get this hash using the new blobhash opcode.

The New Challenge for ZK-Rollups: The "Consistency Check"

This "opaque" nature of blobs creates a new challenge for ZK-Rollups.

  • The Old Way (with calldata):
    1. A ZK-Rollup posted its transactions to calldata.
    2. The L1 verifier contract would hash this calldata (e.g., using keccak256).
    3. This hash was passed into the ZK-circuit as a public input.
    4. The circuit would prove: "I correctly processed a batch of transactions that also hash to this exact public input." This linked the off-chain proof to the on-chain data.
  • The New Problem (with blobs):
    1. The rollup posts a blob.
    2. The L1 contract only has the versioned_hash (a KZG commitment).
    3. The ZK-circuit has the raw blob data.

How can the circuit prove that its raw data is the exact same data represented by the versioned_hash on L1? This is the blob consistency check, also known as a proof of equivalence.

The Solution: Polynomials and Precompiles

The solution is a clever cryptographic protocol that uses the fact that KZG commitments are based on polynomials.

The data in a blob is interpreted as a polynomial, let's call it p(x). The KZG commitment is a commitment to this polynomial. To prove that the blob data used in the ZK-circuit is the same as the one committed to on L1, we use the Schwartz-Zippel Lemma. This lemma states that if two polynomials are different, they will only evaluate to the same value at a random point z with a very low probability.

So, the new process becomes a two-step verification:

Step 1: Verify the L1 Commitment (Point Evaluation Precompile)

EIP-4844 introduces a new precompile at address 0x0A called the point_evaluation_precompile.

This precompile's job is to verify a KZG proof. The ZK-Rollup's L1 contract calls this precompile and essentially asks it: "For the blob represented by this versioned_hash, does its polynomial p(x) equal y when evaluated at point z?"

precompile.verify(versioned_hash, z, y, kzg_proof)

If the precompile returns true, the L1 contract now trusts that (z, y) is a valid evaluation of the blob's polynomial.

Step 2: Verify the ZK-Circuit's Data (In-Circuit Evaluation)

Now, the ZK-circuit (off-chain) must prove it's working with the same data.

  1. The circuit takes the raw blob data as a private input (witness).
  2. It also takes z and y (from Step 1) as public inputs.
  3. Inside the circuit, it reconstructs the exact same polynomial p(x) from the raw blob data.
  4. It then evaluates this polynomial at the point z.
  5. Finally, it asserts that its result equals y.

If p_circuit(z) == y, and the L1 precompile has already confirmed that p_blob(z) == y, we have cryptographically proven that the circuit's polynomial and the blob's polynomial are identical. The consistency check is complete!

The Final Hurdle: Non-Native Field Arithmetic

There's one last, highly technical complication. Cryptography runs on specific elliptic curves, and these curves operate over different mathematical "fields."

  • EIP-4844 (Blobs/KZG) uses the BLS12-381 curve.
  • Most ZK-Rollups (and Ethereum's existing precompiles) use the BN254 curve.

This means the ZK-circuit (running on BN254) must perform polynomial math for the blob (which is defined over BLS12-381). This is called non-native field arithmetic, and it is computationally very expensive.

Rollup teams must implement complex circuits (e.g., using a barycentric formula) to perform this BLS12-381 math inside their BN254 ZK-proof. This is a significant engineering feat, but it's the final piece of the puzzle that makes the entire EIP-4844 system compatible with existing ZK-EVMs.

EIP-4844 is more than just "cheaper data." It fundamentally re-architects the data layer of Ethereum. For ZK-Rollups, this required moving away from simple hashing to a more complex system of polynomial equivalence.

By combining blob transactions, KZG commitments, the new point_evaluation_precompile, and advanced in-circuit non-native field arithmetic, ZK-Rollups can securely and verifiably use this new, ultra-cheap data source, paving the way for the next wave of L2 scalability.

← Back to blogs