EIP-4844: Ancestor blob availability check

[terencechain]

The blob availability in 4844 should be a validity condition of a chain. This means a node should download and verify blobs up to MIN_EPOCHS_FOR_BLOBS_SIDECARS_REQUESTS duration. Given that the attestation availability must be the same as the validation condition and user's chain availability rule, within fork choice spec, we should explicitly mention one of the following

• A block can't be head until the ancestor blobs are downloaded and verified
• A block can't be imported until the ancestor blobs are downloaded and verified

I have to think more about the tradeoff between the two. Feedback is welcome

[tbenr]

What do you have in mind with the two options?
Seems to me like the difference is the "optimistic" behaviour: the first allows it, the latter closes the door to it.

To me there is a strong relation with what we will end to do with the "byRange" p2p methods.
If we end up coupling, we will have everything coupled, so the latter will be the most natural\simple way to go.
If we go for the decoupled way, we should choose the first.

Pls correct me if I'm on the wrong train of thought :)

[terencechain]

@tbenr + 1

Regarding implementation complexity, "can't import" is much cleaner and simpler to implement for Prysm. Would love to not have to mix in "optimistic" behavior if possible

[paulhauner]

My current state-of-mind for Lighthouse is to not implement optimistic import of blob-less blocks. Additionally I don't think the spec should allow for it. My reasoning is below.

The reason we perform an execution-optimistic import (i.e., importing a block without having verified the execution payload) is because there's value in doing so. The value is that it allows us to provide tip-of-chain blocks to the EL so it can sync to the head. Without that, we're stuck in the well-known "can't import bocks because the EL isn't synced, can't sync the EL because we're not importing blocks" deadlock.

When it comes to a blob-optimistic import (i.e., importing a block without having verified the blob), I don't see value in it. Importing the blobless block doesn't help us obtain any ancestor blobs/blocks like it does for execution-optimistic imports. We can't attest to a blobless block and we also can't build atop it.

Given the significant complexity and ugliness we faced with execution-optimistic imports, I'm with @terencechain in looking to avoid it in Lighthouse.

When it comes to the specification, I'd be tempted to go with option (2): "A block can't be imported...". If someone has a strong argument for implementing blob-optimistic imports then I'd be open to (1). But if we can't see a valid use case for blob-optimistic then I'd say we don't waste time and spec complexity on it. I believe this would be consistent with what we're doing currently, we only have an execution-optimistic spec today because that's the only thing we know that some clients will need. We don't, for example, have a spec for state-root-optimistic imports.

[tbenr]

I agree with Paul. The only reason I can see for supporting it is for performance reasons in case blocks are significantly faster to download compared to blobs (assuming decoupled p2p methods). But depends what is the bottleneck here. In any case it seems not worth the implementation complexity.

[timbeiko]

PR related to this issue: #3125