-
Notifications
You must be signed in to change notification settings - Fork 175
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
Comments
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? |
Makes sense to me |
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. |
+1 on optional |
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 |
+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. |
@terencechain @dapplion @kasey did you endup implementing it? Did you followed this approach? |
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
The text was updated successfully, but these errors were encountered: