Blob retrieval by versioned hash

[terencechain]

Currently, in the construction of retrieving a blob, the request is based on the block ID, which can be either a block root or specific keywords like "finalized" or "justified." However, it would be beneficial for L2 in general to have the ability to retrieve blobs using versioned hashes. This would address a pain point for L2 mapping, as L2s primarily focus on versioned hashes and it would be more sensible to use them as the request parameter rather than beacon block roots

[mcdee]

At current each potential block ID is easily identifiable. Both block roots and versioned hashes have the same structure (32-byte array) so this would cause issues with servers in working out which should be used for retrieval.

It would be possible to send this as a query parameter, but then that breaks the existing format of the URL. Perhaps we could add another endpoint (and do so in a different namespace) that is more focused on providing support to L2s?

[terencechain]

Perhaps we could add another endpoint (and do so in a different namespace) that is more focused on providing support to L2s?

Makes sense to me

[tbenr]

Having a separated endpoint seems to make sense also from a perspective of making this optional. Since maybe not all are interested in consuming this api, we could avoid to have the versionedHash->blobSidecar index always populated in DB.

[terencechain]

Having a separated endpoint seems to make sense also from a perspective of making this optional.

+1 on optional

[kasey]

For the existing endpoint, in the case where an L2 is able to compute the required slot from on-chain data, L2 server and CL client would both benefit from the ability to limit retrieval and transmission to only the necessary set of indices, which L2 knows by their versioned hashes. We could add another optional parameter versioned_hashes which would filter the response to a subset of blobs, just like the existing indices param: https://github.com/ethereum/beacon-APIs/blob/master/apis/beacon/blob_sidecars/blob_sidecars.yaml#L17-L25

[jpnovais]

+1 to implement a method to fetch blobs by versioned hashes. L2 would benefit a lot from this, especially to rebuild/verify L2 state from L1 blobs.

[tbenr]

@terencechain @dapplion @kasey did you endup implementing it? Did you followed this approach?
Looking at it versioned_hashes could be the only input for that api, avoiding the block_id, or do you think that L2 wants to fix a block anyway?