-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Push proposer settings every slot: builder #14155
Conversation
validator/client/runner.go
Outdated
} | ||
}() | ||
// account has changed in the middle of an epoch | ||
if err := v.PushProposerSettings(ctx, km, slot, time.Now().Add(1*time.Minute)); err != nil { |
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.
why 1 minute instead of 1 slot ?
return errors.Wrap(ErrBuilderValidatorRegistration, err.Error()) | ||
if len(signedRegReqs) > 0 { | ||
go func() { | ||
if err := SubmitValidatorRegistrations(ctx, v.validatorClient, signedRegReqs, v.validatorsRegBatchSize); err != nil { |
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.
this will cancel at the end of the slot, for some groups like dvts should we provide much longer deadlines?
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.
Our code should assume that it is a single logical validator underneath. Also this simply sends it out to multiple relays which is unrelated to dvts.
What type of PR is this?
Other
What does this PR do? Why is it needed?
This is a temporary fix/improvement to how often push proposer settings get called until a rework of health tracking and account changes is implemented.
currently, the push proposer settings API is called at the start of every epoch and updates the proposer cache on the beacon node. This may not be ideal as sometimes validators get added in the middle of the epoch and wouldn't correctly account for proposals afterward within the same epoch. Other cases include beacon node upgrades or migrations requiring load balancing, the proposer cache and such may not be updated at the start of the switchover.
Below are some benchmarks for several hundred keys. The majority of the processing time is collecting the current status of keys, and not the API calls themselves.
currently, I believe lighthouse at the very least does something similar.
testing on holesky with about 5k keys yielded the following results-- results have been updated --
with an updated call things changed to 52ms on holesky, 5k keys signed
Which issues(s) does this PR fix?
Fixes #14179
Other notes for review