-
-
Notifications
You must be signed in to change notification settings - Fork 283
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
Only call regen.getBlockSlotState() if necessary #5401
Conversation
Performance Report✔️ no performance regression detected Full benchmark results
|
de5dd3b
to
7b1c83f
Compare
Tested in the last 5h on test mainnet node (feat2 - this branch vs unstable)
|
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
🎉 This PR is included in v1.8.0 🎉 |
// using getHeadState() means we'll use checkpointStateCache if it's available | ||
const headState = this.getHeadState(); | ||
// head state is in the same epoch, or we pulled up head state already from past epoch | ||
if (epoch <= computeEpochAtSlot(headState.slot)) { |
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.
@tuyennhv shouldn't this be a strict equals check? I noticed this method always returns the same state if a previous epoch is passed in
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.
@nflaig no this should be "<=", the function means to get head state dialing to an epoch. If provided epoch < head state epoch just return head state
also if we let it pass through the below regen.getBlockSlotState
call, if provided slot < head state slot it'll throw error
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.
That makes sense, I was trying to figure out what would be required to get proposer duties of a finalized epoch. The right method to use in that case would be getStateBySlot
I'd assume.
async getStateBySlot( |
You also noted in #5846 is that Lodestar does not persists finalized states very frequently which would be an issue in that case. We could solve this issue if we add
--chain.archiveStateEpochFrequency 1
flag but this significantly increases storage requirements (but that might be fine for someone that really needs that data).
Motivation
validator_exit
messages at the same timeDescription
regen.getBlockSlotState()
always use queue implementation so we use it with care, only call it if necessarygetHeadStateAtCurrentEpoch()
andgetHeadStateAtEpoch()
apis in chain so it only callsregen
if necessary, using thecheckpointStateCache
(used insidegetHeadState()
) it'll reach the queue 1 time at most per epochclose #5400