Skip to content
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

Closed
mkalinin opened this issue Nov 23, 2021 · 4 comments
Closed

CL reaction to SYNCING response status post-Merge #2735

mkalinin opened this issue Nov 23, 2021 · 4 comments

Comments

@mkalinin
Copy link
Collaborator

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 with SYNCING 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:

  1. Import optimistically, stop attesting and proposing until the sync is finished
  2. Import optimistically, attest to and propose on top of fully verified head
@djrtwo
Copy link
Contributor

djrtwo commented Nov 23, 2021

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.

@mkalinin
Copy link
Collaborator Author

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 SYNCING will end up with INVALID + latestValidHash set to a block that is several blocks behind the head. Attesting to the head in this case might result in attesting to invalid block.

@djrtwo
Copy link
Contributor

djrtwo commented Nov 23, 2021

Ah, I see that... good point

@mkalinin
Copy link
Collaborator Author

Addressed in #2770:

Let only a node which returns is_optimistic(head) == True be an optimistic node. Let only a validator on an optimistic node be an optimistic validator.
An optimistic validator MUST NOT produce a block
An optimistic validator MUST NOT participate in attestation

In other words, if the payload of the head of the chain turned EL into SYNCING a validator must stop attesting and proposing until the sync is finished.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants