Handle unavailable data outside of prune window#3169
Conversation
terencechain
left a comment
terencechain
left a comment
There was a problem hiding this comment.
Lgtm. I think there's some value in updating /phase0/weak-subjectivity.md to include eip-4844 considerations. It can be another PR
|
From interop event discussions there is still some confusion regarding the practical implications of this PR.
Since that has significant UX implications from status-quo, it might be explicitly stated somewhere in the spec. |
I think it has always been pretty clearly stated that syncing from genesis is not safe because of weak subjectivity? So how is this new? The safe way to sync is to get a checkpoint within the weak subjectivity window. If you sync from genesis, you make the assumption that no exited key attack has happened. This would warrant at least a warning by the client -- probably better it should be an override flag in order to force the client into this sync mode. I think the same is true for syncing from genesis without checking data availability, but since in practice they cover the same blocks, the override flag for the two can be combined. |
6 participants
I believe this captures the intention of the discussion from #3141. This does not actually change the spec, it just clarifies what to do in a few scenarios. namely:
retrieve_blobs_sidecarmight fail on the p2p network outside of the prune window. Thusis_data_availablewould fail in this scenario due to the exception thrownBlobsSidecarhas subsequently been pruned." This is to avoid interactions with pruning and re-orgs past the depth. If a client has validated that a block's sidecar is available, and then re-orgs to this sidecar at a depth past the prune window, the client does not need to re-assert the availability.