4 posts tagged with "rollups"

The blob count limits on Ethereum have always been embedded in the consensus spec. Pre-Fulu, both the target and maximum blobs per block were hardcoded: currently 3 target / 6 max (post-Dencun). Changing them required a hard fork.

EIP-7742 changes that. From Fulu onward, the consensus layer sends the target and max as fields in the ExecutionPayloadHeader. The execution layer reads them and applies them dynamically. No recompile. No fork vote required for the limit itself — only for the mechanism that sets it.

This is a real change to how the blob fee market works.

Ethereum has two fee markets now. The execution fee market — EIP-1559, base fee, familiar — and the blob fee market introduced by EIP-4844. They're superficially similar: both have a target utilization, both use an exponential update rule, both burn the base fee. But they behave very differently in practice, and the reason is the parameter choices.

The blob fee market oscillates. It spends most of its time near the floor, spikes hard when demand exceeds the target, then crashes back. There's rarely a stable equilibrium. This post is about why.

In December 2025, Ethereum's Fulu upgrade raised the blob cap from 6 to 15, then to 21 in January. That's a 3.5× increase in the data availability space available to rollups per block — the single biggest capacity jump since EIP-4844 launched blobs in March 2024.

Three months later, not a single major rollup has used more than 6 blobs in a single transaction.

Each blob on Ethereum costs the same regardless of how much data you actually put inside it. The slot doesn't know if you packed all 131,072 bytes or left 99% empty. You pay either way.

That flat pricing creates a question that hasn't been answered cleanly: how efficiently are rollups actually using the space they're buying? The answer turns out to span an enormous range — from 100% fill all the way down to a rollup that's posting the same completely empty blob, over and over, every block.