Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Blob retrieval by versioned hash #332

Open
Tracked by #364
terencechain opened this issue Jun 27, 2023 · 7 comments
Open
Tracked by #364

Blob retrieval by versioned hash #332

terencechain opened this issue Jun 27, 2023 · 7 comments

Comments

@terencechain
Copy link

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
Copy link
Contributor

mcdee commented Jun 27, 2023

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
Copy link
Author

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
Copy link
Contributor

tbenr commented Jun 27, 2023

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
Copy link
Author

terencechain commented Jun 27, 2023

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

+1 on optional

@kasey
Copy link

kasey commented Jul 10, 2023

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
Copy link

+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
Copy link
Contributor

tbenr commented Sep 11, 2024

@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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants