-
Notifications
You must be signed in to change notification settings - Fork 169
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
Update submitPoolAttestationsV2 endpoint #472
base: master
Are you sure you want to change the base?
Changes from 7 commits
7203294
c581a51
508487a
085e16a
f2f7969
997ddb7
1df7423
6520c2f
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -56,7 +56,7 @@ post: | |
operationId: submitPoolAttestationsV2 | ||
summary: Submit Attestation objects to node | ||
description: | | ||
Submits Attestation objects to the node. Each attestation in the request body is processed individually. | ||
Submits SingleAttestation objects to the node. Each attestation in the request body is processed individually. | ||
|
||
If an attestation is validated successfully, the node MUST publish that attestation on the appropriate subnet. | ||
|
||
|
@@ -82,7 +82,7 @@ post: | |
$ref: '../../../beacon-node-oapi.yaml#/components/schemas/Attestation' | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. so the idea is to always submit SingleAttestation even pre-Electra? in this case should remove the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. removed The idea here is that this endpoint should only be used post electra. Since the v2 endpoint is fairly new I thought it'd be ok to repurpose it for post electra usage. Lighthouse is only using the v2 endpoint post electra, but maybe other clients would prefer a v3 endpoint? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't think we need a v3, this endpoint is effectively only used in devnets right now and would be updated for the next devnet and I don't think anyone is running mixed client setups yet. In Lodestar we also start using the attestation v2 apis post-electra but what I meant is that after electra is live on mainnet we can be sure that all nodes implement the v2 apis and the v1 apis become unusable since those only support phase0 attestations, this means we could completely remove them from the codebase. We still wanna support earlier forks though, e.g. our sim tests do fork transitions from phase0 to latest fork, but for that the v2 apis need to be backward compatible. We should clarify what type of attestation should be submitted pre- and post-electra, submitting There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Since ethereum/consensus-specs#3900 now also updates the honest validator spec, wouldn't it make the most sense to submit whatever attestation format the validator works with, i.e. |
||
- type: array | ||
items: | ||
$ref: '../../../beacon-node-oapi.yaml#/components/schemas/Electra.Attestation' | ||
$ref: '../../../beacon-node-oapi.yaml#/components/schemas/Electra.SingleAttestation' | ||
responses: | ||
"200": | ||
description: Attestations are stored in pool and broadcast on the appropriate subnet | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -26,6 +26,7 @@ get: | |
- block | ||
- block_gossip | ||
- attestation | ||
- single_attestation | ||
- voluntary_exit | ||
- bls_to_execution_change | ||
- proposer_slashing | ||
|
@@ -66,6 +67,11 @@ get: | |
value: | | ||
event: attestation | ||
data: {"aggregation_bits":"0x01", "signature":"0x1b66ac1fb663c9bc59509846d6ec05345bd908eda73e670af888da41af171505cc411d61252fb6cb3fa0017b679f8bb2305b26a285fa2737f175668d0dff91cc1b66ac1fb663c9bc59509846d6ec05345bd908eda73e670af888da41af171505", "data":{"slot":"1", "index":"1", "beacon_block_root":"0xcf8e0d4e9587369b2301d0790347320302cc0943d5a1884560367e8208d920f2", "source":{"epoch":"1", "root":"0xcf8e0d4e9587369b2301d0790347320302cc0943d5a1884560367e8208d920f2"}, "target":{"epoch":"1", "root":"0xcf8e0d4e9587369b2301d0790347320302cc0943d5a1884560367e8208d920f2"}}} | ||
single_attestation: | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I wonder if it's not better to simply add the validator index as a stand-alone field here, so that both index and committee list are available to consumers - ideally, this would be introduced in a way that doesn't require downstream tooling to change. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
No matter if we go with ethereum/consensus-specs#3900 or not, there will be an impact on downstream consumers since the For Overall, it seems like the cleanest solution would be to also go with ethereum/consensus-specs#3787 and This seems cleaner from a consumer point of view as well, you can always subscribe to multiple topics if you want to track all kind of attestations but as it is right now, the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. As far as I understand it, we need access to the state in order to convert between There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
you only need access to shuffling but this is already required to validate |
||
description: The node has received a SingleAttestation (from P2P or API) that passes validation rules of the `beacon_attestation_{subnet_id}` topic | ||
value: | | ||
event: single_attestation | ||
data: {"committee_index":"1", "attester_index": "1", "data":{"slot":"1", "index":"1", "beacon_block_root":"0xcf8e0d4e9587369b2301d0790347320302cc0943d5a1884560367e8208d920f2", "source":{"epoch":"1", "root":"0xcf8e0d4e9587369b2301d0790347320302cc0943d5a1884560367e8208d920f2"}, "target":{"epoch":"1", "root":"0xcf8e0d4e9587369b2301d0790347320302cc0943d5a1884560367e8208d920f2"}}, "signature":"0x1b66ac1fb663c9bc59509846d6ec05345bd908eda73e670af888da41af171505cc411d61252fb6cb3fa0017b679f8bb2305b26a285fa2737f175668d0dff91cc1b66ac1fb663c9bc59509846d6ec05345bd908eda73e670af888da41af171505"} | ||
voluntary_exit: | ||
description: The node has received a SignedVoluntaryExit (from P2P or API) that passes validation rules of `voluntary_exit` topic | ||
value: | | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we might wanna just say "attestations" here as pre-electra we pass
phase0.Attestation