Add execution_payload and execution_payload_gossip event#588
Conversation
|
we should probably add versions to this too... |
| event: data_column_sidecar | ||
| data: {"block_root": "0xcf8e0d4e9587369b2301d0790347320302cc0943d5a1884560367e8208d920f2", "index": "1", "slot": "1"} | ||
| execution_payload: | ||
| description: The node has received a `SignedExecutionPayloadEnvelope` (from P2P or API) that is successfully imported on the fork-choice `on_execution_payload` handler |
There was a problem hiding this comment.
May I know the difference between this and execution_payload_available?
This one emits when the payload is fully imported, execution_payload_available emits when payload is available for PTC vote.
Is there a gap/delay between the occurrence of these two events?
There was a problem hiding this comment.
I guess you are right, there shouldn't be much of a difference in the timing and would at most be minimal based on how the client specific import pipeline works.
We can probably remove it and only stick to execution_payload_gossip and execution_payload_available
execution_payload_available is emitted when the execution payload + all data (based on custody) is available, it does not require the execution payload to be valid, while execution_payload does since it is emitted after successful import into fork choice via on_execution_payload handler, so it includes the time it takes for the EL to execute and verify the execution payload
was thinking about that, I am not that convinced that versioning here makes sense as the schema is not based on a spec container |
nflaig
changed the title
execution_payload and execution_payload_gossip eventexecution_payload_gossip event
still, we might be better off being consistent? |
but that means not having the version/data container here? eg. I am open to adding a version here too if that's really what we want |
|
@michaelsproul thoughts? |
nflaig
changed the title
execution_payload_gossip eventexecution_payload and execution_payload_gossip event
|
I'm not Michael, but implementing this in Lighthouse. I agree with @nflaig, let's version only the directly embedded consensus objects. Versioning the others by fork name as well would be inconsistent as noted above, and would be strange to use in cases where we e.g. want to add some field to an event outside of the fork lifecycle. |
|
haven't started implementing this yet but looks good to me |
Adds execution payload events from ethereum/beacon-APIs#588 --------- Co-authored-by: Matthew Keil <github@mail.matthewkeil.com>
Implement boilerplate for new SSE events as specified in - ethereum/beacon-APIs#588 While that one is not merged yet, I believe the SSE events might be utilized in Dora already. Implement the boilerplate, i.e. subscription tracking and publish queues. A PR to implement to fully implement already implementable events will follow. Co-Authored-By: Daniel Knopik <daniel@dknopik.de>
Implement boilerplate for new SSE events as specified in - ethereum/beacon-APIs#588 While that one is not merged yet, I believe the SSE events might be utilized in Dora already. Implement the boilerplate, i.e. subscription tracking and publish queues. A PR to implement to fully implement already implementable events will follow. Co-Authored-By: Daniel Knopik <daniel@dknopik.de>
|
applied changes due to ethereum/consensus-specs#5094, the events no longer emit the |
5 participants
This adds
execution_payloadandexecution_payload_gossipto the eventstream.The events mirror the existing
blockandblock_gossipevents.execution_payload_gossipis emitted when an execution payload passes gossip validationexecution_payloadis emitted when an execution payload is successfully importedexecution_payload_availableis emitted when an execution payload and all data are available for payload attestation without verifying the execution payload itselfThese events enable measuring execution payload timings via sidecar software such as contributoor.