You're sixteen days into a dispute. Your fraud prover goes to fetch the original blob data it needs to finish the job. The data isn't there. Not corrupted, not withheld. Just gone, on schedule, exactly as the protocol intended.
That's the tension baked into EIP-4844, and it's worth understanding precisely.
What blobs actually are, and why they disappear
EIP-4844 introduced a new transaction type carrying a cryptographic commitment (a KZG commitment) alongside the blob itself: a chunk of binary data, capped at 128 KB per blob, up to six blobs per block in the initial configuration. Rollups use this space to post their transaction batches cheaply, because blob data lives in a separate fee market from ordinary calldata and is priced to be dramatically cheaper under normal load.
The design choice that creates our problem: blob data is kept by consensus nodes for roughly 4,096 epochs, which works out to approximately 18 days. After that, nodes are free to prune it. The KZG commitment stays on-chain permanently, which lets anyone verify that a given piece of data matches what was committed, but only if they still have the data to check against.
The commitment without the data is a receipt for a package that was already incinerated.
This isn't an oversight. The Ethereum researchers who designed EIP-4844 were explicit about it: blobs are temporary, and the long-term assumption is that a distributed network of blob archivers will store this data beyond the pruning window. The protocol itself makes no such guarantee.
The fraud prover's race against the clock
Optimistic rollups work by posting state roots and giving anyone a window to challenge an incorrect one by submitting a fraud proof. The canonical challenge window across most deployed optimistic systems is seven days. That sounds like it fits comfortably inside the 18-day blob expiry window, with eleven days to spare.
Except the windows don't align the way that arithmetic suggests.
Consider a concrete scenario. A rollup sequencer posts a batch in blob transactions at a given block. An observer notices something suspicious but spends three days gathering evidence and reconstructing the relevant state transitions. They submit a challenge on day four. The on-chain dispute game now begins, and multiple rounds of bisection may be required before the final instruction-level proof is submitted. Some multi-round fraud proof protocols (Arbitrum's BoLD is designed with exactly this in mind) require iterative back-and-forth that can itself stretch across days.
Now suppose the original blob was posted close to the beginning of a busy period, and the prover's node had a connectivity gap, or relied on a third-party archiver that lagged. If that blob was posted 16 days ago and the prover needs to re-fetch it to construct the final step of their proof, they may find it pruned from every node they can reach. The KZG commitment sitting on-chain confirms the data existed. It does not help them reconstruct it.
The gap isn't theoretical. It's a straight addition problem: sequencer delay before posting, observer detection time, challenge initiation time, multi-round dispute duration. Stack those together and you're brushing uncomfortably close to day 18.
The archiver assumption and who actually holds the bag
The ecosystem's answer to this is the blob archiver network: services and nodes that voluntarily retain blob data beyond the protocol's pruning window. EthStorage, various RPC providers, and Ethereum client teams have all discussed or implemented archival solutions.
But "voluntarily" is doing heavy lifting in that sentence.
Archival is not incentivized at the protocol layer. A node operator has no consensus reward for storing blobs past day 18. They do it because it serves their users, or because their business depends on it. That's a reasonable assumption for large, professional infrastructure providers. It is a much shakier assumption for a permissionless fraud prover who spun up a node six months ago and relies on a public endpoint, and the ecosystem has been slow to reckon with that honestly.
Consider two validators who both ran full nodes when EIP-4844 launched. Call them Priya and Marcus. Priya runs her own archival infrastructure and syncs blob data to cold storage as a matter of habit. Marcus relies on a well-known public RPC that quietly dropped blob archival after a cost-cutting round. In a dispute that runs long, Priya can prove fraud. Marcus can't, not because he was wrong, but because the data his argument depends on was pruned from every endpoint he has access to.
Same protocol, same facts, different outcomes. The difference is entirely infrastructure choices that have nothing to do with whether the fraud actually occurred.
That asymmetry matters when the system is adjudicating nine-figure rollup state.
What the ecosystem is doing about it, and what it isn't
The blob expiry problem has prompted real design work. The successor roadmap including full Danksharding envisions data availability sampling as the long-term answer: rather than any single node storing all blob data, the network samples small pieces distributed across many nodes, making data withholding statistically detectable and full reconstruction feasible from the aggregate. Meaningful improvement. Future state, not a current guarantee.
In the shorter term, some rollup teams have responded by building their own blob archival into their node software, treating the 18-day window as a floor and adding their own retention layer on top. Others have gone belt-and-suspenders: posting blob data and also storing a compressed version in calldata or on a separate data availability layer as a fallback. Both approaches work. Neither is free.
The more surgical fix would be adjusting challenge window parameters so the full dispute lifecycle, including worst-case multi-round bisection, completes well before day 14 as a conservative buffer. Some rollup governance discussions have touched on this. None have made it a hard protocol constraint yet, which means the gap remains a matter of operational discipline rather than cryptographic enforcement.
EIP-4844 solved a real cost problem for rollups, and it solved it well. The blob fee market has done exactly what it was designed to do. But the 18-day expiry transferred a data availability responsibility from the protocol to the ecosystem, and the ecosystem's response has been uneven. That transfer deserves to be named plainly, not buried in a threat model appendix.
A fraud prover who treats blob data as reliably available indefinitely is making an assumption the protocol explicitly refuses to make. Build your archival layer before the dispute, not during it.