Skip to content
Blockchain LabTHE VENTURE STUDIO

LibraryScaling2022Design paperCorpus record

Shard Blob Transactions

EIP-4844. Vitalik Buterin, Dankrad Feist, Diederik Loerakker, George Kadianakis, Matt Garnett, Mofi Taiwo and Ansgar Dietrichs.

A new transaction type carries a blob: a large chunk of data that consensus nodes hold briefly and that the execution layer cannot read byte by byte. Rollups are the intended user. The blob is not cheap forever, and it is not the rollup's proof.

EIP-4844 adds blob-carrying transactions. Consensus nodes must hold the blob bytes for a retention window. The execution layer only sees a KZG commitment. A separate fee market targets how many blobs a block carries. Blobs are data availability for a while, not storage, and not a proof that a rollup's transition was valid.

The five-minute read

Two resources

Execution gas and blob gas are different. A cheap blob market does not make execution cheap, and a full blob market does not mean the EVM is congested.

Commitment, not body

Contracts cannot read blob bytes. They can see that a commitment was published. A design that needs the bytes on-chain forever has not got what the EIP provides.

A window, then gone

The protocol's job is to make the blobs available long enough for interested parties to fetch them. After that, Ethereum does not promise a copy.

KZG is the check

The commitment scheme lets a node test that the blob matches. It is the same polynomial commitment discussed in the KZG paper, used here as plumbing.

One action, walked through

  1. A rollup posts a blob-carrying transaction with a KZG commitment.
  2. Consensus clients propagate and temporarily store the blob.
  3. The execution payload records the commitment and burns the blob base fee.
  4. Anyone who needs the bytes fetches them during the window.
  5. A validity proof or a fraud proof is a separate object. The blob does not replace it.

The argument, unpacked

Availability is not validity

A rollup can publish a blob of nonsense and still pay the fee. Whether that blob is a valid state transition is the rollup's proof system, not this EIP.

Expiry is a choice

Keeping data for a window is how the EIP stays cheaper than calldata. A product that needs historical blobs is relying on some other archive. That archive is not Ethereum consensus.

What has to be true

  • Enough nodes actually propagate blobs during the window. The EIP specifies the rule. It does not conjure bandwidth.
  • The blob fee market is independent. Quoting an execution fee as the blob price is a mistake.
  • KZG setup assumptions apply. The EIP does not switch Ethereum to a transparent proof system.
  • A later fork can change the target and the window. Cite the fork if you cite the number.

What happened after the paper

Proto-danksharding is this EIP. Full danksharding was the longer roadmap and is not what shipped with 4844. The honest sentence is: blobs added a priced, expiring data lane. It did not add permanent storage or a proof system.

What to check before you use the idea

  • Does the contract read the blob, or only a commitment?
  • How long is the retention window in the citation?
  • What proves the rollup transition, separately from the blob?
  • Who stores the bytes after expiry?

Terms

Blob
A large data payload carried by a transaction, stored temporarily by consensus nodes, and not readable as EVM state.
Blob base fee
The separate inclusion price for blob gas, adjusted toward a target number of blobs.

The problem the paper names

Posting rollup data as ordinary calldata prices that data as if it were executable forever. The EIP wants a lane for data that must be available now and need not live in the execution state.

What the design proposes

  • A blob-carrying transaction commits to blobs with a KZG commitment.
  • The execution layer sees the commitment, not the blob body.
  • A separate blob fee market targets how many blobs a block should carry.

How the mechanism is specified

  • Availability is 'the consensus nodes saw the blobs for the retention window'. It is not permanent storage.
  • The KZG proof lets a node check that a blob matches the commitment without treating the blob as EVM memory.
  • The fee market is its own EIP-1559-style controller. Demand for blobs and demand for execution are different queues.

What this page does not treat as proven

  • A blob is not a validity proof. An optimistic rollup still has a challenge. A zk rollup still needs a proof.
  • Data that expires cannot later be fetched from Ethereum itself. Someone else must have kept a copy if it is still needed.
  • The EIP does not promise a price for blob gas.

Why a venture studio still reads it

A rollup that says 'we use blobs' has said where the bytes go for a while. Ask who keeps them after the window, and what proves the transition, which is a different object from the blob.

This is Blockchain Lab's reading of a public design paper. It is not the paper, not a copy of it, and not an offer of tokens, equity, custody or a partnership. Later network behaviour can diverge from the text. Nothing here is investment, legal or technical advice.

Research status: Design paper. Last reviewed: 1 October 2026. This is a reading of a public paper, not investment, legal or security advice.