Skip to content

SSE for payload attributes #305

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.

Sign up for GitHub

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

Merged
michaelsproul merged 3 commits into from
Feb 28, 2023
Merged

SSE for payload attributes #305

Changes from 2 commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
b86bbf7
SSE for payload attributes
michaelsproul Feb 24, 2023
57f46b4
Tweak encoding wording
michaelsproul Feb 25, 2023
cb15cac
Add comment about beacon node config
michaelsproul Feb 27, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
27 changes: 27 additions & 0 deletions apis/eventstream/index.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -32,6 +32,7 @@ get:
- contribution_and_proof
- light_client_finality_update
- light_client_optimistic_update
- payload_attributes
responses:
"200":
description: Opened SSE stream.
Expand Down Expand Up @@ -91,6 +92,32 @@ get:
value: |
event: light_client_optimistic_update
data: {"version":"phase0", "data": {"attested_header": {"beacon": {"slot":"1", "proposer_index":"1", "parent_root":"0xcf8e0d4e9587369b2301d0790347320302cc0943d5a1884560367e8208d920f2", "state_root":"0xcf8e0d4e9587369b2301d0790347320302cc0943d5a1884560367e8208d920f2", "body_root":"0xcf8e0d4e9587369b2301d0790347320302cc0943d5a1884560367e8208d920f2"}}, "sync_aggregate": {"sync_committee_bits":"0x01", "sync_committee_signature":"0x1b66ac1fb663c9bc59509846d6ec05345bd908eda73e670af888da41af171505cc411d61252fb6cb3fa0017b679f8bb2305b26a285fa2737f175668d0dff91cc1b66ac1fb663c9bc59509846d6ec05345bd908eda73e670af888da41af171505"}, "signature_slot":"1"}}
payload_attributes:
description: |
The node has computed new payload attributes for execution payload building.

This event gives block builders and relays sufficient information to construct or
verify a block at `proposal_slot`. The meanings of the fields are:

- `version`: the identifier of the beacon hard fork at `proposal_slot`, e.g.
`"bellatrix"`, `"capella"`.
- `proposal_slot`: the slot at which a block using these payload attributes may be
built.
- `parent_block_root`: the beacon block root of the parent block to be built upon.
- `parent_block_number`: the execution block number of the parent block.
- `parent_block_hash`: the execution block hash of the parent block.
- `proposer_index`: the validator index of the proposer at `proposal_slot` on
the chain identified by `parent_block_root`.
Comment on lines +104 to +110
Copy link
Member

@ralexstokes ralexstokes Feb 25, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is there a reason we have all of this data, instead of just the minimum required data?

following the lead of the builder APIs, we can uniquely identify a proposal with the tuple (proposal_slot, proposer_index, parent_block_hash)

which suggests we can drop parent_block_root and parent_block_number

Copy link
Contributor Author

@michaelsproul michaelsproul Feb 26, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ralexstokes I figured the block number is useful for stateless dummy builders that just return empty payloads. We use such a builder to run blockprint. It wouldn't be hard to track the block number but it would require separately looking up data from a CL/EL.

The parent block root is potentially interesting to differentiate the case where an identical payload ends up in two competing beacon blocks. Although arguably this case shouldn't be differentiated because the EL state is identical. Another reason to keep it is that it grounds the data in something CL-related, so if the receiver wants to look up more info from the beacon API they have a concrete reference point (a slot is ambiguous, and a payload hash isn't natively understood).

Copy link
Member

@ralexstokes ralexstokes Feb 26, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

makes sense, if everyone else thinks they pull their own weight then lets leave them in

- `payload_attributes`: beacon API encoding of `PayloadAttributesV<N>` as
defined by the `execution-apis` specification. The version `N` must match the
payload attributes for the hard fork matching `version`.
The beacon API encoded object must have equivalent fields to its counterpart in
`execution-apis` with two differences: 1) `snake_case` identifiers must be used
rather than `camelCase`; 2) integers must be encoded as quoted decimals rather
than big-endian hex.
value: |
event: payload_attributes
data: {"version": "capella", "data": {"proposer_index": "123", "proposal_slot": "10", "proposal_block_number": "9", "parent_block_root": "0xcf8e0d4e9587369b2301d0790347320302cc0943d5a1884560367e8208d920f2", "parent_block_hash": "0x9a2fefd2fdb57f74993c7780ea5b9030d2897b615b89f808011ca5aebed54eaf", "payload_attributes": {"timestamp": "123456", "prev_randao": "0xcf8e0d4e9587369b2301d0790347320302cc0943d5a1884560367e8208d920f2", "suggested_fee_recipient": "0x0000000000000000000000000000000000000000", "withdrawals": [{"index": "5", "validator_index": "10", "address": "0x0000000000000000000000000000000000000000", "amount": "15640"}]}}},
"400":
description: "The topics supplied could not be parsed"
content:
Expand Down