What Are Blobs? EIP-4844 and L2 Data Availability Explained
If you've watched Base, Arbitrum, or Optimism fees drop from cents to fractions of a cent since 2024, you've already felt the effect of blobs — even if you've never touched one. Blobs are the single biggest reason L2 transactions got cheap, and they quietly changed what "the chain's data" even means. Here's what they actually are and what changes for you when you're reading an L2 or Ethereum with an RPC endpoint.
The problem blobs solve
An L2 (rollup) executes transactions off-chain, then posts data back to Ethereum L1 so anyone can verify or reconstruct the L2's state. That posting is the whole security model — it's what makes a rollup a rollup rather than a sidechain. The catch: before 2024, rollups posted that data as calldata in regular L1 transactions, and calldata is expensive. For most L2 transactions, the dominant cost wasn't execution — it was paying L1 to store the data forever.
"Forever" is the key word. Calldata lives in every Ethereum block for all time, replicated by every full node. But rollups don't actually need their data to live forever. They need it available long enough for anyone to download it, run fraud/validity proofs, and reconstruct state. After that, the data has done its job.
That mismatch — paying for permanent storage when you only need temporary availability — is exactly what EIP-4844 fixed.
What a blob actually is
EIP-4844 (also called proto-danksharding) shipped in the Dencun upgrade in March 2024. It introduced a new kind of data attachment called a blob (binary large object) and a new transaction type to carry it.
A blob is a fixed ~128 KB chunk of data (4,096 field elements of 32 bytes each) with three defining properties:
- It's ephemeral. Blobs are pruned after ~18 days (4,096 epochs). The network keeps them just long enough to guarantee availability, then drops them. This is the core trick — temporary storage is dramatically cheaper than permanent.
- The EVM can't read it. Smart contracts can't access blob contents directly. The execution layer only sees a KZG commitment — a cryptographic hash (a "versioned hash") that proves what the blob contained. This keeps blobs cheap to handle while still letting contracts verify a blob existed.
- It has its own fee market. Blobs are priced in blob gas, a separate EIP-1559-style market with its own base fee. Blob demand doesn't compete with regular transaction gas, so a busy day for swaps doesn't spike blob costs and vice versa.
Dencun set a target of 3 blobs per block and a max of 6; later upgrades raised that (Pectra moved the target/max up to roughly 6/9) as demand grew. More blob capacity, all of it cheap and temporary.
Calldata vs blobs at a glance
| Calldata | Blobs (EIP-4844) | |
|---|---|---|
| Persistence | Permanent (every node, forever) | ~18 days, then pruned |
| EVM-accessible | Yes | No — only the KZG commitment |
| Fee market | Shares regular gas | Separate blob-gas market |
| Cost for L2 data | High | Much lower |
| Lives in | Execution layer | Consensus (beacon) layer |
That last row trips up a lot of developers, so it's worth its own section.
Where blobs actually live (and why your RPC can't always get them)
Blob contents don't live in the execution layer where your eth_* calls go — they live in the consensus (beacon) layer as "blob sidecars." Your execution RPC sees the transaction's blob references (the versioned hashes), the blob-gas accounting, and the commitments, but not the raw blob bytes.
What you can read from a normal execution endpoint:
eth_blobBaseFee— the current blob base fee.- Type-3 (blob) transactions carry
blobVersionedHashesandmaxFeePerBlobGasfields. - Block headers include
blobGasUsedandexcessBlobGas; receipts include the blob gas price paid. - In the EVM, the
BLOBHASHopcode and a blob-base-fee opcode expose blob info to contracts.
What you cannot reliably get from execution RPC: the actual blob data, especially after the ~18-day window. To fetch raw blob contents you go to a beacon node with blob history (/eth/v1/beacon/blob_sidecars/{block_id}) or a blob archive/indexer like Blobscan. If you're building something that needs historical blob data, design for that up front — assuming eth_getTransactionByHash will hand you the blob bytes is a common and painful mistake.
Checking the blob base fee on Ethereum is a one-liner:
curl -s -X POST https://rpc.swiftnodes.io/rpc/eth?key=YOUR_API_KEY \
-H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","method":"eth_blobBaseFee","params":[],"id":1}'
Why this matters for L2 developers
If you build on Base, Arbitrum, Optimism, or any Ethereum rollup, blobs are why your users' fees fell — the rollup now posts its data as blobs instead of calldata, and passes the savings on. It also means an L2's cost profile is now tied to the blob market: when blobs are in heavy demand across many rollups, blob base fee rises and L2 fees tick up with it. Watching eth_blobBaseFee is a legitimate input if you're modeling L2 transaction costs.
It also reshapes the data-availability landscape. Some L2s post DA to Ethereum blobs; others use external DA layers like Celestia or EigenDA (see our Mantle deep-dive on the EigenDA approach) to push costs even lower, trading some of Ethereum's DA guarantees for cheaper data. That's a real security/cost tradeoff worth understanding per chain — and it's downstream of the same question EIP-4844 answered: how long does this data need to be available, and who guarantees it?
The bigger picture
Proto-danksharding is the "proto" because it's a stepping stone. The endgame, full danksharding, adds data availability sampling — nodes verify blob availability by checking small random samples instead of downloading everything, which lets the network scale blob capacity far higher without every node storing it all. EIP-4844 shipped the transaction format and fee market first; the sampling machinery comes later. Either way, the principle is set: rollups get cheap, temporary, verifiable data availability, and Ethereum L1 becomes a settlement-and-DA layer for a fleet of L2s.
For most of this, you don't manage blobs yourself — your rollup does. But understanding them explains your fee bills, tells you where historical data does and doesn't live, and clears up why finality and data availability are separate concerns (more on the first in Soft vs Hard Finality on L2s).
Want a fast, flat-rate Ethereum RPC endpoint — plus every major L2 under one key — to read blob fees, type-3 transactions, and L1/L2 state without metering? Grab a free key and point your app at https://rpc.swiftnodes.io/rpc/eth?key=YOUR_API_KEY.
Related posts
- Subscribing to Contract Events with eth_subscribe (logs)
Polling eth_getLogs in a loop is the slow, brittle way to watch contract events. eth_subscribe pushes logs to you over WebSocket the instant they're mined. Here's how to build a subscription that filters correctly, survives reconnects, and never silently misses an event.
- Full Node vs Archive Node: What's the Difference (and Which Do You Need)?
Most developers either overpay for an archive node they don't need or hit a wall on a full node that can't answer their query. The difference comes down to one thing — historical state — and here's the simple test for which one your app actually requires.
- The Real Cost of `debug_traceTransaction` (and When to Use It)
Tracing a transaction costs 20-30× more than reading its receipt. Sometimes that's worth it; usually it isn't. Here's what trace actually tells you, the four tracer modes, and when a cheaper RPC method gets the same answer.