Currently, Engine API has the following payload statuses:

• VALID - payload is valid, requires full validation
• INVALID - payload is invalid, doesn't require full validation (block header values might be invalid)
• INVALID_BLOCK_HASH - recently became equal to INVALID, see [RFC] Engine API: remove INVALID_BLOCK_HASH #270
• ACCEPTED - a side chain payload hasn't been validated, but ancestors of this payload are locally available
• SYNCING - parent block of a payload is unknown; or equals to ACCEPTED if EL doesn't support ACCEPTED

The problem of utilizing ACCEPTED is that it does not preclude EL from pulling pieces of state from the network in order to obtain a parent state of a payload in question.

Apart from EL's implementation complexity, I am curious if we had a clear status meaning "I can compute parent state locally" would CL make use of it? If a state can be locally computed it should take less time and preclude the possibility of DA issues.

If yes then we could have the following statuses (names are picked for clarity not for brevity, so we can leave the same names):

• VALID
• INVALID
• MISSING_DATA - parent block is unknown or parent state can't be locally computed, reorg to this block implies SYNCING
• HAS_REQUIRED_DATA (ACCEPTED) - parent state is unknown but is locally computable
• VALIDATING (SYNCING) - EL is either computing a parent state or pulling data from the network and will validate a payload once parent state is obtained

ELs are free to choose to not HAS_REQUIRED_DATA and always response MISSING_DATA instead. But if EL do support the former, CL may optimise for such a support.

This proposal changes a set of statuses for Engine API methods in the following way:

• newPayload: VALID | INVALID | MISSING_DATA | HAS_REQUIRED_DATA (ACCEPTED)
• forkchoiceUpdated: VALID | INVALID | VALIDATING (SYNCING)

UPD
These changes (if we decide to take them) aren't considered to be incorporated before the Merge

UPD 2
We might even want to split VALIDATING into two separate statuses: SYNCING and EXECUTING. The latter would mean that the execution is in progress but all required data are locally available. This would allow CL to avoid remembering whether the payload is either MISSING_DATA or HAS_REQUIRED_DATA, and solely rely on fcU status to understand what EL is doing.