Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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?
Update submitPoolAttestationsV2 endpoint #472
Changes from 3 commits
7203294
c581a51
508487a
085e16a
f2f7969
997ddb7
1df7423
6520c2f
e2a461b
cee75f9
45a8f2c
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
so the idea is to always submit SingleAttestation even pre-Electra? in this case should remove the
anyOf
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.
removed
anyOf
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 comment
The 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
SingleAttestation
should also work for earlier forks, so I don't think this is an issue.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.
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.
Attestation
(phase0) for pre-electra andSingleAttestation
post-electra. This means we don't need to do any transformation before gossiping the attestations.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.
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 comment
The 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
Attestation
is modified in electra.For
single_attestation
it would be best to start emitting it even pre-electra (by convertingphase0.Attestation
toSingleAttestation
) so that consumers can switch to the new topic earlier.Overall, it seems like the cleanest solution would be to also go with ethereum/consensus-specs#3787 and
AggregatedAttestation
(as noted in ethereum/consensus-specs#3900 (comment)). We could then add two new topicsonchain_attestation
andaggregate_attestation
and completely deprecateattestation
post-electra.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
attestation
topic always emits all 3 different types of attestations which is not great imo.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.
As far as I understand it, we need access to the state in order to convert between
SingleAttestation
toAttestation
. So emitting anAttestation
event for this new endpoint seems to add complexityThere 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.
you only need access to shuffling but this is already required to validate
Attestation
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.
the spec reference results in a 404, need to wait for upstream PR to be part of a pre-release, or update it later on