Add Blob sidecar information to event stream
parithosh opened this issue · 6 comments
We use Xatu extensively for monitoring block/attestation arrival metrics on the beaconchain/testnets. This was extremely useful for us in the big block tests that help decide the values used for the size of blobs. Xatu gathers this data by subscribing to the event stream, parsing the data, annotating it and forwarding it to a server for storage in a database. Extending the beaconAPI eventstream to include events for blobs would greatly help in adding support downstream in Xatu.
The events that would be nice to have are:
- blob arrival
Topics up for debate:
- would an event stream emit a block as valid before it gets blobs associated ?
- when would we say a blob is available? when all its parts are received or when 2/3rd or whatever we need for reconstruction are received?
cc @dapplion (since he had some suggestions for a PR based on this issue)
cc @Savid for Xatu (can't tag sam for some reason)
I agree we should have a blob event that provides us with information on a blob. At a first stab, I'd go for the following information in the event:
- block_root
- index
- slot
- versioned hash of blob
- KZG commitment
between them this should provide enough info for explorers and the like to index and reference them.
As to when the event stream emits information:
- blob should be emitted as soon as the blob is accepted from the P2P layer
- block should be emitted as soon as the block is accepted from the P2P layer
- head should be emitted once the head is updated in state
These would allow monitors to understand when the individual components of the block arrive, along with the time taken to update state.
Is it necessary to include the KZG commitment even if that data can be recovered from the block latter?
The thinking behind the KZG commitment is that you can use this information to see if the same blob is in multiple beacon blocks. Not absolutely critical per se, but if the block to which the blob is attached is reorged it would be good to be able to track which block it turned up in again at the consensus layer.
The thinking behind the KZG commitment is that you can use this information to see if the same blob is in multiple beacon blocks. Not absolutely critical per se, but if the block to which the blob is attached is reorged it would be good to be able to track which block it turned up in again at the consensus layer.
Would the versioned hash of blob by sufficient for this purpose?
when would we say a blob is available? when all its parts are received or when 2/3rd or whatever we need for reconstruction are received?
talking internally it seems that we should keep it simple and just when one is available