-
Notifications
You must be signed in to change notification settings - Fork 957
Prevent unnecessary state advances pre-Fulu #8388
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
Prevent unnecessary state advances pre-Fulu #8388
Conversation
|
I'm seeing the "State advance too slow", after every attestation since I updated my mainnet node: Here is the most recent If you'd like I can test when you're ready |
|
The funny thing about this patch is that it's only relevant before the fork. Once Fulu happens this change is irrelevant It will take us a bit of time to cut the v8.0.1 release, but I can ping you once this PR is reviewed and merged and you could run it prior to v8.0.1 if you would be comfortable with that |
I'll test it |
jimmygchen
left a comment
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, the fix looks good!
|
@winksaville if you'd like to test, you can compile the |
I assume if something goes wrong I can just revert to v8.0.0? |
|
Yeah it's completely backwards compat, very minimal difference from v8.0.0. |
|
I'm running v8.0.0-47b984e with the fix on my mainnet node: And there are no "WARN State advance too slow" So issue resolved from my perspective, TXS! |
|
Great to hear! |
This hot fix release includes the following fixes: * #8388 * #8406 * #8391 * #8413 Co-Authored-By: Jimmy Chen <[email protected]>
Issue Addressed
State advances were observed as especially slow on pre-Fulu networks (mainnet).
The reason being: we were doing an extra epoch of state advance because of code that should only have been running after Fulu, when proposer shufflings are determined with lookahead.
Proposed Changes
Only attempt to cache the next epoch shuffling if the state's slot determines it (this will only be true post-Fulu). Reusing the logic for
proposer_shuffling_decision_slotavoids having to repeat the fiddly logic about the Fulu fork epoch itself.