Proto-Danksharding (EIP-4844) Explained: Ethereum Blobs

Proto-Danksharding, formally Ethereum Improvement Proposal 4844, is the upgrade that added temporary blob data to Ethereum. It is mainly useful to people building or operating rollups, but it also explains why Layer 2 transaction costs can fall without Ethereum processing every Layer 2 transaction itself. This guide follows a blob from a rollup sequencer to Ethereum, explains the separate fee market, and shows how to inspect blob-related fields with standard JSON-RPC.

What Is Proto-Danksharding?

Proto-Danksharding is a partial implementation of the data-availability design commonly called Danksharding. It gives Ethereum a new transaction type that can carry one or more large binary objects called blobs. A blob is not ordinary contract calldata: it is attached to a transaction, committed to cryptographically, propagated through the consensus network, and retained by nodes for a limited period rather than becoming permanent EVM state.

The Ethereum scaling documentation describes the broader goal: move high-volume execution to Layer 2 while using Ethereum as a settlement and data-availability layer. Proto-Danksharding supplies a cheaper, purpose-built place for rollups to publish the data needed to reconstruct and verify their state.

The prefix “proto” matters. Full Danksharding is intended to distribute blob handling across a larger data-availability-sampling system. EIP-4844 introduces the transaction format and fee-market foundation first; it does not implement the complete future architecture.

Why Does It Exist?

Rollups execute transactions away from Ethereum and periodically publish enough information for anyone to reconstruct the rollup state. Before blobs, that information was commonly placed in calldata. Calldata is secured by Ethereum and can be read by smart contracts, but it competes directly with normal execution data and remains part of the historical chain data. Paying the permanent calldata price for large batches makes rollup fees sensitive to Ethereum’s execution gas market.

That arrangement creates three related problems:

1. Cost coupling: A rollup’s data bill rises with the same gas market used by swaps, contract deployments, and other L1 operations.
2. Poor data fit: Rollup batch data generally needs to be available to nodes and provers, not read by an EVM contract one word at a time.
3. Long-term storage pressure: Data needed for a dispute or state reconstruction may not need to remain in every execution client forever.

Blobs separate these requirements. Ethereum still commits to and propagates the data, while the EVM receives only a compact commitment rather than the complete blob contents. Rollups can therefore publish more bytes per unit of cost while keeping their settlement and availability guarantees tied to Ethereum.

This does not make block space unlimited. Validators still process, propagate, and temporarily store blobs, so the protocol caps blob capacity and adjusts its price when demand changes.

How Proto-Danksharding Works

A rollup sequencer collects Layer 2 transactions, executes them, and encodes the batch data required to reproduce the resulting state. It then creates a blob transaction, signs it, and sends it to the execution network. The transaction includes commitments to its blobs and a maximum blob fee, while the blob payload is handled alongside the consensus-layer data path.

The high-level flow is:

1. The sequencer encodes compressed rollup data into one or more blobs.
2. A KZG commitment is created for each blob. The commitment is a short cryptographic representation of the blob polynomial.
3. The transaction includes versioned hashes derived from those commitments and a max_fee_per_blob_gas limit.
4. Execution clients validate the transaction’s normal fields. Consensus clients and blob-aware relays validate, propagate, and make the blob sidecars available.
5. Validators include the transaction and its blob commitments in a block.
6. Rollup nodes, provers, and watchers retrieve the blob data during the retention window and verify that it matches the commitments.

The EVM does not expose blob bytes through a normal SLOAD, CALLDATA, or contract storage read. A contract can access the versioned hash associated with a blob transaction, which lets a rollup contract bind a state update to the expected data without making every blob byte part of EVM execution.

Calldata Versus Blob Data

The important distinction is not simply “cheap bytes versus expensive bytes.” It is that blob data has a different access and retention contract. A rollup must preserve or re-fetch data it needs beyond the network’s normal blob retention period.

Components and Key Concepts

Type 3 Blob Transactions

EIP-4844 defines a new transaction envelope, commonly called type 3. In addition to ordinary fields such as to, value, and gas limits, it carries blob versioned hashes and a maximum blob fee. The transaction’s execution payload does not contain the full blob bytes; clients transmit the payload and blob sidecar together.

The recipient is normally a rollup contract or other protocol component that records the commitment. The transaction cannot use an arbitrary EVM contract as a permanent blob store, which is intentional: storing the full data in contract storage would defeat the design.

KZG Commitments

KZG, or Kate-Zaverucha-Goldberg, commitments let a verifier check that a blob and a short commitment describe the same polynomial. Ethereum uses a trusted setup and a point-evaluation verification mechanism so validators can check the relationship without executing the blob as contract input.

The commitment becomes a versioned hash before it is placed in the transaction. Versioning leaves room for future commitment schemes. A rollup contract can compare the expected versioned hash with the hash referenced by the transaction and reject a state update that points to different data.

Blob Gas

Blob gas is priced separately from execution gas. The protocol tracks blobGasUsed and excessBlobGas in block headers and derives a blob base fee from the excess. When blob demand stays above the target, excess blob gas increases and the blob base fee rises; when demand is below target, it falls gradually.

The EIP defines a target of three blobs per block and a maximum of six under its initial parameters. Each blob is 131,072 bytes, so the target is a capacity signal rather than a promise that every block will contain exactly three blobs. The separate market prevents ordinary contract execution demand from directly determining the price of rollup data, although both markets still compete for the validator’s bandwidth and overall block resources.

Blob Sidecars and Retention

The blob payload is carried in a sidecar associated with the block rather than being included in the execution payload consumed by the EVM. Consensus clients can verify and serve it to peers, while rollup operators and archival services decide how to retain it for longer-lived reconstruction and auditing.

Temporary availability is not the same as deletion at the protocol boundary. A rollup that needs historical data must operate an archive or use a service that stores blobs beyond the normal retention period. This operational responsibility is part of the rollup’s data-availability design.

Real-World Uses

Rollup Batch Publication

The primary use is publishing compressed transaction batches from optimistic and zero-knowledge rollups. A rollup still executes transactions on its own nodes and posts state commitments to Ethereum, but its data publication path can use blobs instead of calldata. The savings are greatest when a batch contains a large amount of data relative to the small commitment and proof metadata.

For optimistic rollups, the data supports independent reconstruction and fraud-proof workflows. For ZK rollups, it helps provers and other participants retrieve the inputs needed to verify or reproduce a proven state transition. Blob support therefore improves the data layer without deciding whether a rollup uses fraud proofs or validity proofs.

High-Volume Periodic Data

Any Ethereum protocol that needs temporary, integrity-protected publication can consider blobs, provided it can tolerate the access and retention model. Examples include availability commitments for specialized execution environments and batch-oriented applications. Blobs are not a general file-storage system: applications should not use them for user-facing permanent media, secrets, or data that a contract must read synchronously.

Rollup Fee Design

Rollup operators can use the blob fee market as an input to batch timing and fee estimation. A sequencer might publish more aggressively when the blob base fee is low, or wait briefly to aggregate a larger batch when application latency permits. It must also enforce a maximum fee and retain a fallback path, because blob capacity and fee levels remain dynamic.

For a focused treatment of the pricing and operational trade-offs, see Blobspace Economics: How Ethereum Prices Rollup Data.

Getting Started: Inspect Blob Activity

You do not need to submit a transaction to understand the mechanism. Any Ethereum JSON-RPC endpoint that exposes EIP-4844 fields can return the latest block header:

curl -sS https://YOUR_RPC_ENDPOINT \
  -H "Content-Type: application/json" \
  --data '{"jsonrpc":"2.0","method":"eth_getBlockByNumber","params":["latest",false],"id":1}'

Inspect the response for blobGasUsed, excessBlobGas, and, when supported by the endpoint, the block’s blob-related transaction references. A missing field can mean that the endpoint is connected to a pre-EIP-4844 network, an execution-only service, or a provider that filters newer fields.

The following Node.js script makes the same check without a package dependency. Node.js must have built-in fetch support:

const rpcUrl = process.env.ETH_RPC_URL;

if (!rpcUrl) {
  throw new Error('Set ETH_RPC_URL to an Ethereum JSON-RPC endpoint');
}

const response = await fetch(rpcUrl, {
  method: 'POST',
  headers: { 'content-type': 'application/json' },
  body: JSON.stringify({
    jsonrpc: '2.0',
    method: 'eth_getBlockByNumber',
    params: ['latest', false],
    id: 1,
  }),
});

if (!response.ok) {
  throw new Error(`RPC HTTP error: ${response.status}`);
}

const payload = await response.json();
if (payload.error) {
  throw new Error(payload.error.message);
}

const block = payload.result;
console.log({
  number: block.number,
  blobGasUsed: block.blobGasUsed ?? 'not reported',
  excessBlobGas: block.excessBlobGas ?? 'not reported',
});

For an operator, verification should go beyond checking that a block header contains blob fields. Monitor publication success, the number of blobs attached to each batch, blob base-fee changes, sidecar retrieval latency, and whether the rollup can reconstruct a batch from an independent endpoint. Keep an archive policy for data that must remain available after the protocol retention window.

Common Misconceptions

“Proto-Danksharding makes Ethereum a permanent data store.”

No. Blob data is designed for temporary availability, not permanent contract storage. Rollups and infrastructure providers must archive data they need for historical proofs, audits, or state reconstruction.

“Blobs are just larger calldata.”

They solve a related publication problem with different rules. Contracts can read calldata directly, while contracts cannot read blob bytes directly. Blobs also have their own fee market, commitment scheme, propagation path, and retention obligations.

“EIP-4844 is full Danksharding.”

It is the prototype and foundation for that direction, not the complete design. EIP-4844 adds blob transactions and the initial fee and verification machinery while leaving broader data-availability sampling and larger-scale distribution for later protocol work. The Ethereum Danksharding roadmap explains how this fits into Ethereum’s longer-term scaling architecture.

“Blob fees replace all Layer 2 costs.”

They reduce the cost of publishing batch data, but users still pay for Layer 2 execution, sequencing, proof generation or dispute infrastructure, withdrawals, and sometimes L1 contract calls. The actual fee depends on batch compression, operator policy, and current demand in both execution and blob markets.

Related Articles

• Optimistic vs Zero-Knowledge Rollups: Architecture Guide explains how rollup security models differ after data is published.
• Data Availability: What It Means, Options, and How to Implement covers availability guarantees, sampling, retention, and operational checks.
• Modular Blockchains: Architecture, Layers, and Trade-offs places execution, settlement, consensus, and data availability in one systems model.
• EIP-1559 Fee Market Mechanism explains Ethereum’s execution-gas base fee, which is separate from blob gas.
• Ethereum Gas Optimization Systems covers the execution-side techniques that reduce smart-contract gas consumption.

Changelog

• Initial publication: explains the EIP-4844 transaction format, blob fee market, KZG commitments, sidecars, and operator checks.