In the current spec for forkchoiceUpdatedV1 it is stated that a node must not allow a payload to be built atop any ancestor of the head:
Client software MAY skip an update of the forkchoice state and MUST NOT begin a payload build process if forkchoiceState.headBlockHash references an ancestor of the head of canonical chain. In the case of such an event, client software MUST return {payloadStatus: {status: VALID, latestValidHash: forkchoiceState.headBlockHash, validationError: null}, payloadId: null}.
(from: https://github.com/ethereum/execution-apis/blob/main/src/engine/specification.md#engine_forkchoiceupdatedv1)
However, there are cases where it is better for the health of the chain if payloads can be built upon ancestors. If a block arrives late across the entire network and has not been attested to, then it is beneficial to re-org it out to disincentivise that behaviour. Validators may be incentivised to publish blocks as late as possible to maximise MEV, and re-orging them out when they do this is IMO the most viable way to establish a healthy equilibrium.
I have a proposal for the consensus-specs that allows honest validators to perform re-orgs of late blocks, but it currently requires a hack to suppress the forkchoiceUpdated message for the block-to-be-reorged (see: ethereum/consensus-specs#3034). If execution clients were capable of building payloads on ancestors of the head then this hack wouldn't be necessary and the consensus client could just send payload attributes for whichever block it wants to build on.
Whether or not my proposal is adopted, I suspect that we will eventually move to (block, slot) fork choice which will allow attesters to vote for the emptiness of a slot. This would lead to a similar situation, where the canonical head can revert to an ancestor of the previous head, and a new block should be built atop that ancestor.
In the current spec for
forkchoiceUpdatedV1it is stated that a node must not allow a payload to be built atop any ancestor of the head:(from: https://github.com/ethereum/execution-apis/blob/main/src/engine/specification.md#engine_forkchoiceupdatedv1)
However, there are cases where it is better for the health of the chain if payloads can be built upon ancestors. If a block arrives late across the entire network and has not been attested to, then it is beneficial to re-org it out to disincentivise that behaviour. Validators may be incentivised to publish blocks as late as possible to maximise MEV, and re-orging them out when they do this is IMO the most viable way to establish a healthy equilibrium.
I have a proposal for the consensus-specs that allows honest validators to perform re-orgs of late blocks, but it currently requires a hack to suppress the
forkchoiceUpdatedmessage for the block-to-be-reorged (see: ethereum/consensus-specs#3034). If execution clients were capable of building payloads on ancestors of the head then this hack wouldn't be necessary and the consensus client could just send payload attributes for whichever block it wants to build on.Whether or not my proposal is adopted, I suspect that we will eventually move to
(block, slot)fork choice which will allow attesters to vote for the emptiness of a slot. This would lead to a similar situation, where the canonical head can revert to an ancestor of the previous head, and a new block should be built atop that ancestor.