EIP-4844, called proto-danksharding, went live on Ethereum mainnet in March 2024 as part of the Dencun upgrade. If you've read about Danksharding — Ethereum's full data availability sharding design — EIP-4844 is the deployed version of step one of that roadmap. It introduces the blob transaction format and a new fee market, but doesn't implement the data availability sampling that full Danksharding requires.
The distinction matters because EIP-4844 is actually in production and has already materially changed how rollups operate. It's worth understanding on its own terms, not just as a placeholder for something that might ship in the future.
What a Blob Transaction Actually Is
Before EIP-4844, rollups posted their compressed batch data to Ethereum using calldata — the field in a transaction that holds arbitrary bytes. Calldata has two problems. It's stored permanently in Ethereum's history (every node that wants to sync from genesis must download it forever). And it competes with regular execution transactions for the same block space, so its price reflects whatever the main gas market is doing.
EIP-4844 introduced a new transaction type: the blob-carrying transaction. A blob is a fixed-size chunk of binary data, 128 KB each. The transaction can carry up to six blobs, with a target of three per block. Blobs are attached to the transaction at the protocol level, but the EVM doesn't read or execute blob data — it's completely invisible to smart contracts. The only thing the EVM sees is a commitment to the blob: a 48-byte KZG polynomial commitment that gets embedded in the transaction and is verifiable on-chain.
This is the core design. The actual blob contents never touch the execution layer. They propagate separately through the consensus layer's peer-to-peer network, where consensus clients gossip them between nodes during the availability window.
That window is roughly 18 days (specifically 4,096 epochs). After that, blob data is pruned. It doesn't go into Ethereum's permanent state, which means nodes don't have to store it forever. For rollups, this works out fine: a fraud proof window for an optimistic rollup is typically around seven days, and ZK rollups don't need the data on-chain at all after proof submission. The blob outlasts the window where anyone needs to challenge or reconstruct the rollup's claims.
The Separate Fee Market
Blob data gets its own fee market, completely separate from regular gas. There's a blob base fee that adjusts up or down based on blob consumption, with the protocol targeting three blobs per block. When consumption is below three, the blob base fee decreases. Above three, it increases. This mirrors EIP-1559's base fee mechanism but runs independently.
Before Dencun, rollups competed with Uniswap swaps and NFT mints for calldata space. Blob transactions now have dedicated capacity that doesn't interfere with execution throughput, and their pricing reflects rollup demand rather than the full Ethereum transaction market. The effect on rollup costs was immediate. In the weeks after Dencun activated, L2 transaction fees on Optimism, Arbitrum, and Base dropped by 80-99% as rollups switched from calldata to blobs. The fee floor shifted entirely.
What "Proto" Means — and What's Missing
The "proto" prefix signals an incomplete implementation. Full Danksharding's key innovation is data availability sampling (DAS): nodes would verify blob availability by downloading random small chunks and checking them, rather than downloading full blobs. This allows blob capacity to scale enormously without proportionally increasing per-node bandwidth requirements.
EIP-4844 doesn't have DAS. Consensus nodes download full blobs from peers during the 18-day availability window. That means the 3/6 blob limit isn't arbitrary — it's roughly calibrated to what the existing consensus layer peer network can handle without degradation. You can't simply increase the limit without either implementing DAS or significantly increasing node hardware requirements.
That said, "doesn't have DAS yet" isn't a flaw. It's the correct staged approach. Deploying the blob transaction format and the KZG commitment infrastructure first lets rollups migrate, lets the ecosystem develop tooling, and gives researchers time to finalize DAS specifications before deploying them at scale.
The named intermediate step is PeerDAS — a simplified form of DAS using column-based sampling over existing p2p subnets — which is on the roadmap for Osaka and would allow the blob target to increase beyond 3/6 without a proportional bandwidth burden on all nodes.
What Would Confirm the Direction
Blobs are already live. The directional signal for this track is blob utilization: if the major rollups sustain near-maximum blob consumption and blob fees remain meaningfully below calldata prices, that validates the separate data market design. PeerDAS moving from specification to testnet to mainnet deployment without degrading consensus client performance would confirm the next leg of the roadmap.
What Would Break It
The main technical risk is blob propagation failures under high load — if consensus clients can't reliably gossip blobs to enough peers within the slot window, fraud proof windows could theoretically be put at risk. So far this hasn't materialized, but it's the right thing to watch. A second risk: if blob capacity fills before PeerDAS ships, rollups face a bottleneck similar to the calldata problem they just escaped, just with a different ceiling.
The economic assumption — that separate blob pricing remains substantially cheaper than calldata — holds as long as blob demand doesn't permanently fill the 6-blob max. If it does, blob fees could approach calldata prices and the cost advantage disappears until capacity increases.
Timing
Now: EIP-4844 is live, blobs are in production, all major L2s are using them, and rollup transaction costs are a fraction of what they were pre-Dencun. The infrastructure is real.
Next: PeerDAS is the active research target, intended to increase blob capacity without proportional bandwidth growth. No confirmed mainnet date as of mid-2026.
Later: Full Danksharding — 2D erasure coding, full DAS at validator level, 64+ blobs per block — remains a multi-year roadmap item. It requires ePBS (enshrined proposer-builder separation) to handle the proof generation load.
Boundary
This covers what EIP-4844 is and how the blob mechanism works. It doesn't address the KZG trusted setup ceremony in detail, blob fee estimation for rollup operators, or the technical specification of PeerDAS. It's also worth noting that blob data being pruned doesn't mean it's lost — archive nodes and specialized data availability providers retain it, and Ethereum's EIP-4444 (history expiry) is a separate proposal about a different layer of data. The blob pruning mechanism here is its own design choice, not the same thing.
