Fix blob download from checkpointz servers #7495
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Issue Addressed
Closes:
GET /eth/v1/beacon/blobs
#7489Proposed Changes
Use
ForkName::latest_stable
, i.e. Electra when decoding blobs from a server that does not provideversion
. This is only a temporary workaround that should be reverted oncecheckpointz
is fixed. Having a default fork is potentially incorrect, and glossing over bugs in servers in general is not ideal.However, even in the case where we update
ForkName::latest_stable
toFulu
, this should continue to work, as the blob limit is likely to increase and theRuntimeVariableList
will just have a slightly higher limit than necessary (which is OK so long as the server isn't buggy enough to violate the correct lower bound: e.g. if the block is an Electra one and the server sends 10 blobs, which exceeds the Electra max (9) but not the Fulu max).Additional Info
I've opened an issue to revert this PR before we proceed with Fulu on mainnet, but after v7.1.0:
/eth/v1/beacon/blob_sidecars/{block_id}
#7496