-
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
Add liveness endpoint for doppleganger protection #131
Conversation
I'm not sure why CI is failing, I had a look but it's not clear to me. Perhaps someone with more CI skills could nudge me in the right direction? 🙏 |
apis/validator/liveness.yaml
Outdated
type: object | ||
properties: | ||
epoch: | ||
$ref: "../../../beacon-node-oapi.yaml#/components/schemas/Uint64" |
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 think you'll find references in this file are only ../../beacon-node-oapi.yaml
and that's probably the main build issue...
apis/validator/liveness.yaml
Outdated
content: | ||
application/json: | ||
schema: | ||
title: GetAttesterDutiesBody |
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.
you should probably change this title. If somebody generates client code from this spec, this title will affect generated type/class name.
apis/validator/liveness.yaml
Outdated
content: | ||
application/json: | ||
schema: | ||
title: GetAttesterDutiesBody |
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.
same here
Quick question on how is this intended to be used? It only queries for a single epoch, so I assume a validator client would have to poll a few (2-5) epochs to be certain? Maybe it's worth adding a short sentence about this intended use. |
Co-authored-by: realbigsean <[email protected]>
@paulhauner Shouldn't this be part of the eth/v1/beacon. Ultimately you are asking the question "Who are the validators being observed to be live at this (end of) epoch?" no? |
I'm trying to determine if the validator has been seen to sign any message during the given epoch to try and make a guess about whether or not there's some other VC running the same pubkey. This is different to asking if it exists in the state, has an attestation included in a block or if it is included in the attestation pool. |
Got it. I looked at the other requests and saw their folder structure. I was confused as to where this get belongs. Thanks |
…#2607) ## Issue Addressed N/A ## Proposed Changes Add a note to the Doppelganger Protection docs about how it is not interoperable until an endpoint facilitating it is standardized (ethereum/beacon-APIs#131). ## Additional Info N/A Co-authored-by: realbigsean <[email protected]>
There's no information in here on how far back the "epoch" parameter can/should go. Is it expected that this could be called for any epoch, or for only the most recent epochs? And if the latter, what would a reasonable number of epochs be? Perhaps back to the last finalized epoch? |
@paulhauner could you check "Allow edits from maintainers" or update yourself? :) |
Thanks for raising this PR - we're in the process of adding doppelganger support to our VC, so getting this settled would be nice.
Indeed -an easy solution here is to simply remove it - in Nimbus, we only keep track of a single "last-seen" data point, which is sufficient for doppelganger, or "liveness" in general.
This flag seems redundant - I think we can capture the essence of this API by simply returning the last epoch (or indeed
Possibly, we could increase granularity here to |
I'll throw my support behind this one. Post-merge, Rocket Pool has seen several people shuttling nodes around to migrate to different clients with better performance, and in some situations exporting & importing the slashing DB isn't easy to do. Doppelganger detection is a common way to miss attesting on purpose in cases like this, but we had one instance where someone tried to attach a Lighthouse VC to a Nimbus BN and it failed because the routes aren't standardized. Having a standardized liveness route so any VC with doppelganger could work with any BN would be very well received by our node operators. |
Alrighty, I have updated this PR. My apologies for letting it linger. Thanks for @rolfyone for prodding me (several times) 🙏
@mcdee, good point. I've added that the BN MUST support the current and previous epoch and MAY support previous epochs. Based on our implementation in Lighthouse, this seems to be the minimally useful set of information.
@arnetheduck, removing
The reason that I have specified |
I think without epoch, the query poses a different question: "when was the validator last active" vs "was the validator active in epoch X" - answering the latter requires book-keeping of historical "activeness" which complicates the implementation
as specified, it's somewhat ambiguous what the
under what circumstances do we need to know two epochs for doppelganger, and why two specifically? it seems sufficient to know when the validator last published something - this allows configuring different paranoia policies (number of inactive epochs) for liveness without having to do multiple (potentially racy) queries. limiting it to "previous" and "current" constrains the implementation to that number of "inactive" epochs (one-and-a-few-slots) |
@arnetheduck, I can see two points in your previous post:
1. Why track liveness per epochFirstly, we already need to track per-epoch liveness to follow the P2P spec. For instance, if you've seen an attestation in epoch Secondly, we should note that the P2P spec only requires the node to track the current + previous epochs (potentially the next epoch too, if you consider clock disparity). Given those two points, let's assume that all nodes have at least this abstract data structure in order to meet the P2P propagation conditions:
If we accept that the above struct is the minimum required struct to meet the P2P propagation conditions, then I think it's clear that the best way to query it is by epoch. I argue that querying this struct for "highest seen epoch" is strictly worse for the following reasons:
So, I argue that "highest live epoch" is:
The upside of "highest live epoch" is that it can smoosh together information about the current and previous epoch to reduce the number of calls to the BN. You made a point about "racy" queries, I reject that claim because the liveness of epoch 2. Why is the
|
I'm in line with your logic @paulhauner , thanks for the detailed description and your hackmd - I find it all really logical... To me, there's been no discussion for a long time, so I think that we were happy previously with the logic also. Will flag this to make sure ppl read it on discord, but I'm inclined to approve and merge unless theres strong objections raised... |
|
I had a look around the other endpoints and it seems that not including the epoch in the response would be most consistent with the rest of the repo. I also think your argument makes sense. I've removed the epoch in 4bbefdb. |
Nitpick:
It should say |
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.
LGTM
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.
LGTM. last call for any strong objections...
ethereum#131 introduced a new liveness endpoint - the request is similar to attester duties in that we query a list of attesters for data pertaining to a particular epoch - as such, it seems reasonable to keep the two requests similar in terms of their URL/postdata structure.
#131 introduced a new liveness endpoint - the request is similar to attester duties in that we query a list of attesters for data pertaining to a particular epoch - as such, it seems reasonable to keep the two requests similar in terms of their URL/postdata structure. Co-authored-by: Paul Harris <[email protected]>
ethereum/beacon-APIs#131 introduced a new liveness endpoint - the request is similar to attester duties in that we query a list of attesters for data pertaining to a particular epoch - as such, it seems reasonable to keep the two requests similar in terms of their URL/postdata structure. Co-authored-by: Paul Harris <[email protected]>
What
Following from #64, this PR adds a
/eth/v1/validator/liveness
endpoint which indicates if a validator has been observed to be "live" in some epoch. The idea is that doppleganger protection should only start if some validator hasis_live: false
for some number of epochs.This PR differs from @dankrad's proposal in that it doesn't ask "give me the latest attestation", instead it asks the broader question "has the validator been observed to be live?". This has the following advantages:
Why
This provides doppleganger protection as a first-class citizen. Given that clients already need to answer the "has this validator been observed" question for gossip message verification, this seems cheap to implement. If we add this endpoint then things like Infura can also support doppleganger protection.
I understand that Nimbus has already implemented doppleganger protection (cc @arnetheduck) and Lighthouse is in the later stages of implementing it (see #2230).
Example
Request
POST /eth/v1/validator/liveness
Response