EIP-4844: blobs, cheap data for rollups
Rollups must publish their data on L1 so anyone can verify them — but as permanent calldata it was ruinously expensive. Derive blobs one fix at a time: a separate data lane, a commitment to bind it, pruning after ~18 days, and its own fee market.
- rollups
- gas & EIP-1559
Ethereum scales by pushing execution onto rollups (L2s): they run thousands of transactions off-chain and post only the results to L1. But a rollup has to publish the data of those transactions somewhere public, or no one could check its work. For years it published that data as ordinary calldata — and that one choice made L2 fees painful and capped how cheap Ethereum could get. EIP-4844 (“proto-danksharding”) fixed it with a strange-looking new object called a blob. Strange until you build it: start from the calldata problem and fix exactly what’s wrong, one step at a time.
Why rollups must publish data — and why calldata hurt
A rollup compresses a batch of L2 transactions and posts it to L1. It must publish the underlying data so that anyone — a user, a challenger, a competing node — can reconstruct the L2 state and verify (or disprove) the rollup’s claimed result. That’s data availability The guarantee that the data behind a block or batch was actually published, so anyone can download it and independently check or challenge the state. Distinct from storing it forever. : not “store it forever,” but “make sure everyone can get it.” The obvious place to put it was a transaction’s calldata.
Three things hurt at once. Calldata costs 16 gas per byte — expensive. It is stored by every full node forever — you’re paying for permanent storage. And it shares the same gas market as execution, so a busy L1 directly spikes rollup costs, and rollup data competes with everyone’s transactions for the same space. Rollup fees were dominated by this single line item.
→ Step 2: give data its own lane.
A separate, EVM-invisible lane — bound by a commitment
Add a new place to put data, beside calldata, not inside it: a blob — a big (~128 KB) chunk attached to a new transaction type (0x03) in a “sidecar.” The crucial property: the EVM cannot read a blob’s contents. It isn’t state that contracts operate on; it’s just data the network agrees was published. So blobs carry rollup data without bloating the state the EVM has to touch.
But if the EVM can’t read the blob, and (next step) nodes are going to delete it, how does anyone later prove a block really included the right data and not garbage? Bind each blob with a KZG commitment A 48-byte cryptographic commitment to a blob (treated as a polynomial). It uniquely fixes the blob's contents, and lets anyone verify a specific piece against it with a tiny proof — without holding the whole blob. : a 48-byte value placed in the block. The EVM gets a BLOBHASH opcode (the versioned hash of that commitment) and a point-evaluation precompile, so a rollup contract can check a specific piece of a blob against its commitment — without ever holding the full blob.
- 1 a version byte — lets the commitment scheme change later
- 2 hash of the KZG commitment that binds the blob
- 3 drop its first byte; the version byte takes that slot
→ Step 3: throw the data away (on purpose).
Availability, not storage: prune after ~18 days
Here’s the leap that makes it cheap. Nodes keep the raw blob bytes for only a window — about 18 days (4096 epochs) — then delete them. That window is plenty: long enough for any rollup, challenger, or user to download the data and for any fraud or validity proof to settle. After it passes, the data has done its only job. The chain keeps the tiny commitment in history forever, but not the 128 KB behind it.
That’s the whole conceptual shift: rollups never needed permanent storage, they needed temporary availability. Decoupling the two is what turns “expensive forever” into “cheap and disposable.”
→ Step 4: price them separately.
A separate fee market: blob gas
Price blobs in their own unit — blob gas — with their own EIP-1559-style base fee, fully separate from execution. At Cancun each block targeted 3 blobs and allowed up to 6 (EIP-7691 raised this to 6/9 for Pectra, and Fusaka’s PeerDAS raises it further via BPO forks); the blob base fee moves up or down per block toward that target, and is burned just like the execution base fee. A flood of rollup data now raises the blob base fee without touching your swap’s gas price — and a busy execution layer doesn’t make blobs more expensive. Two independent congestion signals, two independent prices.