# Blobs booby-trap :bomb:

Given the conditions:

1. To ensure an upper-bounded disk size, consensus clients must only store blobs within the `MIN_EPOCHS_FOR_BLOBS_SIDECARS_REQUESTS` time range
2. Blobs from finalized blocks are considered available

If the latest finalized checkpoint is before `MIN_EPOCHS_FOR_BLOBS_SIDECARS_REQUESTS`, there exist a range of blocks which cannot be checked for `is_data_available`. More context on [ethereum/consensus-specs/pull/3141](https://github.com/ethereum/consensus-specs/pull/3141)

## Range sync

When performing a range sync the client cannot know the latest finalized checkpoint until it syncs to the head. There are two possible scenarios:

_Finalized checkpoint >= MIN_EPOCHS_FOR_BLOBS_SIDECARS_REQUESTS_


_Finalized checkpoint < MIN_EPOCHS_FOR_BLOBS_SIDECARS_REQUESTS_


Given current mainnet values:

- Weak subjectivity window: 3532 epochs ~ 15,7 days
- `MIN_EPOCHS_FOR_BLOBS_SIDECARS_REQUESTS`: 4096 epochs: 4096 epochs ~ 18 days

So starting from a checkpoint older than MIN_EPOCHS_FOR_BLOBS_SIDECARS_REQUESTS is already unsafe, as it's outside the weak subjectivity window. Clients may choose to shutdown or warn about it.

## Deep re-org

On a reorg of depth > MIN_EPOCHS_FOR_BLOBS_SIDECARS_REQUESTS, the node is not able to assert is data available for the range of blocks older than MIN_EPOCHS_FOR_BLOBS_SIDECARS_REQUESTS.


1. If the node's fork-choice already contains such branch in the fork-choice, that branch has been checked for is_data_available thus it can be re-orged to
2. If the node's fork-choice does not contain that branch it will have to perform a sync, so the first scenario applies.