-
Notifications
You must be signed in to change notification settings - Fork 933
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
Handle top-ups to exiting/exited validators #3776
Conversation
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.
Makes sense to me
It seems this change is necessary for security, but I just wanted to note that it probably has a detrimental impact on the performance of Lighthouse's single-pass epoch processing. Previously,
Now we are forced to add random-access in step 1 to load validators and check their |
@michaelsproul thanks for raising this performance point, I am currently working on the set of changes to the eip6110 that was agreed during Nyota (#3689 (comment)). Those changes leverage on and extend |
Thanks for the update @mkalinin, I had not been following! A short queue of deposits that we can process with random access sounds fine |
* EIP-7251: Implement changes from ethereum/consensus-specs#3776 * Unskip epoch processing spectest * EIP-7251: unit tests for logic in ethereum/consensus-specs#3776 * Radek feedback
This PR does the same thing as #3650, which was based on the EIP-7251 spec. Meanwhile, the rationale for it has evolved somewhat, with the realization that it is actually more security-critical than previously realized understood. An attacker can do the following:
This can lead to churn limit invariants being violated, even though top-ups go through the deposit churn. The reason for this is subtle: the top-ups can go through the deposit churn slowly, over a long period of time, but the same balance can then exit much faster. For example, say the exit queue is one week long, while the activation queue is completely empty, and an attacker executes the strategy above, exiting validators with minimum balance and topping them up to max balance. Because of the exit queue being full, the large top-ups have one whole week to go through the deposit churn and be processed. Moreover, all exits happen very fast once the week is over, because the validators had minimum balance when the exits were initiated, and so the exits are scheduled very close to each other. The end result is that a bunch of very large exits all happen in a short period of time.
More details in this section of the WIP annotated spec