You're on day six of a seven-day challenge window, you have the proof half-built, and the data you need has already been pruned.
Not hacked. Not censored. Just gone, on schedule, because Ethereum full nodes delete blob data on a rolling timer, currently set around 18 days (4096 epochs, give or take network conditions). For most users that's a footnote buried in a spec doc. For anyone running a fraud-proof challenge against an optimistic rollup, it's the one clock in the room that the sequencer doesn't have to watch nearly as carefully as you do.
This is the asymmetry. It's worth understanding precisely.
Why blobs exist, and why they disappear
EIP-4844, deployed in the Dencun upgrade, gave rollups a cheaper lane for posting transaction data to Ethereum. Instead of cramming data into calldata, which lives in full nodes more or less forever, rollups write to a separate blob-carrying transaction type. Blobs run roughly 128 KB each, and Ethereum's consensus layer stores them only temporarily. After the pruning window closes, nodes drop them.
The commitment to the blob, a KZG cryptographic hash, stays on-chain permanently. You can always prove a blob existed and matched some hash. What you cannot do, once pruning hits, is re-derive the actual transaction data from on-chain state alone.
For data availability, that's fine by design. Rollup operators, DA layers, and archival services are supposed to keep copies. The problem surfaces specifically in the fraud-proof game, where "supposed to" is doing a lot of load-bearing work.
The clock the challenger has to beat
Optimistic rollups work on a simple premise: post a state root, wait, and let anyone who disagrees submit a fraud proof within the challenge window. Arbitrum's canonical challenge window is seven days. Optimism's is also seven days. Both sit comfortably inside the 18-day blob pruning horizon, in theory.
Here's the scenario that breaks that comfort.
A sequencer posts a dishonest batch at time zero. A challenger, call her Priya, spots the discrepancy on day two. To construct a valid fraud proof she needs to re-execute the disputed transaction, which means she needs the original blob data. If she's running a full archival node with blob retention, she has it. But Priya's node had a disk failure on day one. She restored from a snapshot that predated the blob. Now she has to source that blob data externally: from the rollup's own DA layer, from a third-party archival service, or from another node that kept it.
None of those are guaranteed. The rollup operator, who is also the sequencer, has obvious incentives to make that data hard to find. They're not deleting it from Ethereum. Ethereum already did that on its own schedule. They just don't have to serve it.
Priya submits her challenge on day six, one day before the window closes. The on-chain verifier needs the blob data to adjudicate. It checks the KZG commitment. The commitment matches. The actual data? Pruned. The verifier cannot complete the proof. The dishonest state root finalizes.
That is not a theoretical edge case. It is a direct consequence of combining a time-bounded challenge window with a time-bounded data availability layer, and the two timers are not as well-separated as they look on paper.
What makes the asymmetry structural, not accidental
Think of it like a pressure-relief valve wired to a countdown fuse. The valve only works if the pressure builds within the window. Miss the window and the fuse wins, by design.
The sequencer posts data once, at a moment of their choosing, with full access to the blob contents. Their advantage is baked in at time zero. The challenger must reconstruct a proof reactively, under time pressure, from data that has a countdown on it.
Eighteen days sounds generous against a seven-day challenge window. Eleven days of buffer. But fraud detection isn't instant. Automated watchtowers miss things, and some fraud only becomes apparent when downstream effects surface. Add in the time to assemble a multi-round interactive proof (Arbitrum's dispute protocol can run several rounds of bisection), factor in Ethereum congestion that delays on-chain moves, and that eleven-day buffer compresses faster than the numbers suggest.
The deeper issue: blob pruning was calibrated for storage costs, not adversarial game theory. Those are genuinely different optimization targets, and conflating them was a mistake worth naming.
What the honest answer looks like
Some projects are building around this. Celestia and EigenDA offer longer or configurable retention windows, and rollups can post to those instead. Ethereum's own roadmap includes PeerDAS, which distributes blob data across more nodes and makes retrieval more robust, though it does not extend the pruning window itself. Archival blob services exist, but relying on them introduces a trust assumption that was never in the original threat model, which should make any serious security reviewer uncomfortable.
The KZG commitment does give you one solid guarantee: if you have the data, you can prove it's authentic. The commitment doesn't lie. The gap is purely in whether the data remains physically retrievable when you need it most.
So: have you actually checked your rollup's DA setup? If it's posting to Ethereum blobs and running a standard seven-day window, the math works, but only if your watchtower is archiving blobs locally from day one. That's not a configuration detail sitting somewhere in a README.
That's the entire security assumption. It just doesn't announce itself.