Blobs booby-trap

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

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.