-
Notifications
You must be signed in to change notification settings - Fork 997
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
CL reaction to SYNCING response status post-Merge #2735
Comments
When not at the Merge transition boundary, I would argue that (1) is generally okay, as it looks like some sort of EL sync failure. It's probably still valuable (and okay) to attest (as in suggin such a case at least for some depth of SYNCING (e.g. within 32 slots). Essentially, if my EL goes out of sync for a few slots, I can still say what I see as the head (a few slots back) at slot N and help with finality. Once the depth exceeds ~32 slots, shufflings would no longer map to mainnet and there is little to no value to attesting. |
I am thinking about one crazy edge case scenario. User hot swapping EL software with the new client version that has a bug fix and partially invalidates the chain that has been canonical to the previous view of CL. In this case |
Ah, I see that... good point |
Addressed in #2770:
In other words, if the payload of the head of the chain turned EL into |
This RFC is originated by discussion in #2732
Assuming the network post-Merge, suppose a node has caught up with the head and stays online. Then suddenly a subsequent call to
executePayload
is responded withSYNCING
status meaning that EL is missing data required to verify the payload. If this happens with a side chain then CL obviously may keep importing, attesting and proposing on the canonical one.The things become tricky when this happens on the canonical chain, CL has the following options:
The text was updated successfully, but these errors were encountered: