You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Opening this issue to test if there's interest in supporting BlobSidecar retrieval indexed by versioned hash.
Current route to retrieve blobs supports retrieval by block hash + blob index. However the EVM only has access to the version hash, and is not aware of the blob index. One can imagine an application emitting an event to signal a consumer of data location. However, without awareness of the blob index it provide all data required to query the current API indexed by block root.
Adding such a new route would require clients to mantain an index of versioned hash -> (block_id, blob_index). The data minimum data requirements per month are 606024*30/12 * 3 * (32+32+8) / 1e6 (slots_per_year * blobs_per_block * entry_size) ~ 46MB
The text was updated successfully, but these errors were encountered:
Opening this issue to test if there's interest in supporting BlobSidecar retrieval indexed by versioned hash.
Current route to retrieve blobs supports retrieval by block hash + blob index. However the EVM only has access to the version hash, and is not aware of the blob index. One can imagine an application emitting an event to signal a consumer of data location. However, without awareness of the blob index it provide all data required to query the current API indexed by block root.
Adding such a new route would require clients to mantain an index of versioned hash -> (block_id, blob_index). The data minimum data requirements per month are 606024*30/12 * 3 * (32+32+8) / 1e6 (slots_per_year * blobs_per_block * entry_size) ~ 46MB
The text was updated successfully, but these errors were encountered: