ethereum/consensus-specs#5174 proposes removing should_override_forkchoice_update.
That function was a pre-emptive FCU suppression mechanism: if the node expected to propose the next slot and the current head looked reorgable, it could avoid sending notify_forkchoice_updated for the current head so the EL would still allow building on the parent.
With the Engine API behavior now allowing reorg targets within the unfinalized chain, this prediction step appears less necessary as a safety measure. There is still a block-production concern though: even if the EL can technically recover, Teku should avoid asking it to prepare a payload on top of a block we already expect to reorg.
The shape is different before and after Gloas:
Pre-Gloas: the execution payload arrives with the beacon block, so the relevant moment is block arrival. This is roughly where Teku currently evaluates should_override_forkchoice_update. After #5174, the same concern should be expressed as a build-target decision based on get_proposer_head: if the current proposer-head choice is the parent, avoid starting EL payload preparation on the just-arrived head.
Gloas: payload information can change after the beacon block has arrived, so Teku should be able to call get_proposer_head again when it sees a payload and let that result drive whether the active build target changes:
- if
get_proposer_head still matches the current head, and the payload is timely, switch/continue the build on top of that payload;
- if
get_proposer_head still matches the current head, but the payload is not timely, keep the current build choice;
- if
get_proposer_head selects the parent and the parent already has a full payload, keep the current build choice;
- if
get_proposer_head does not match the current head and the parent block is empty, switch the build process to the parent payload.
In other words, the final proposer-head decision should be made from the latest fork-choice and payload information, not from an earlier should_override_forkchoice_update prediction.
ethereum/consensus-specs#5174 proposes removing
should_override_forkchoice_update.That function was a pre-emptive FCU suppression mechanism: if the node expected to propose the next slot and the current head looked reorgable, it could avoid sending
notify_forkchoice_updatedfor the current head so the EL would still allow building on the parent.With the Engine API behavior now allowing reorg targets within the unfinalized chain, this prediction step appears less necessary as a safety measure. There is still a block-production concern though: even if the EL can technically recover, Teku should avoid asking it to prepare a payload on top of a block we already expect to reorg.
The shape is different before and after Gloas:
Pre-Gloas: the execution payload arrives with the beacon block, so the relevant moment is block arrival. This is roughly where Teku currently evaluates
should_override_forkchoice_update. After #5174, the same concern should be expressed as a build-target decision based onget_proposer_head: if the current proposer-head choice is the parent, avoid starting EL payload preparation on the just-arrived head.Gloas: payload information can change after the beacon block has arrived, so Teku should be able to call
get_proposer_headagain when it sees a payload and let that result drive whether the active build target changes:get_proposer_headstill matches the current head, and the payload is timely, switch/continue the build on top of that payload;get_proposer_headstill matches the current head, but the payload is not timely, keep the current build choice;get_proposer_headselects the parent and the parent already has a full payload, keep the current build choice;get_proposer_headdoes not match the current head and the parent block is empty, switch the build process to the parent payload.In other words, the final proposer-head decision should be made from the latest fork-choice and payload information, not from an earlier
should_override_forkchoice_updateprediction.