# 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_ ![](https://i.imgur.com/3J1YkFv.png) _Finalized checkpoint < MIN_EPOCHS_FOR_BLOBS_SIDECARS_REQUESTS_ ![](https://i.imgur.com/ASKDZLO.png) 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. ![](https://i.imgur.com/zqH6mXq.png) 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.