core/txpoo/blobpool: clarify conversion in GetBlobs

[cskiraly]

It is better to make it clear that here we do conversion on-the-fly.

[lightclient]

Should we be computing the proofs on the fly for GetBlobs? Seems like it will get pretty blocked up around the fork.

[rjl493456442]

https://github.com/ethereum/execution-apis/blob/main/src/engine/osaka.md#engine_getblobsv2

Specification

Refer to the specification for engine_getBlobsV1 with changes of the following:

Given an array of blob versioned hashes client software MUST respond with an array of BlobAndProofV2 objects with matching versioned hashes, respecting the order of versioned hashes in the input array.

Client software MUST return null in case of any missing or older version blobs. For instance,

• if the request is [A_versioned_hash, B_versioned_hash, C_versioned_hash] and client software has data for blobs A and C, but doesn't have data for B, the response MUST be null.
• if the request is [A_versioned_hash_for_blob_with_blob_proof], the response MUST be null as well.

Client software MUST support request sizes of at least 128 blob versioned hashes. The client MUST return -38004: Too large request error if the number of requested blobs is too large.

Client software MUST return null if syncing or otherwise unable to serve blob pool data.

Callers MUST consider that execution layer clients may prune old blobs from their pool, and will respond with null if a blob has been pruned.

[rjl493456442]

Spec says we can just return null if any blob with legacy sidecar is requested. Maybe we can get rid of the conversion here?

[fjl]

We discussed this and the conversion should be removed in GetBlobs