Amazing, I support this 100%. As the original author of should_override_forkchoice_update I always wished the ELs would be a bit more flexible in which blocks they allowed us to build on (ethereum/execution-apis#313).

Hey @ensi321, there are some helper functions which only exist because of this deleted function. We should delete them too. Eg get_proposer_head, is_head_late, is_head_weak, is_parent_strong, and maybe more.

cc @mkalinin & @jihoonsong.

Hey @ensi321, there are some helper functions which only exist because of this deleted function. We should delete them too. Eg get_proposer_head, is_head_late, is_head_weak, is_parent_strong, and maybe more.

cc @mkalinin & @jihoonsong.

I think should_override_forkchoice_update existed because of get_proposer_head. After this clean up the existence of latter will still be the case at least for some implementations. @potuz said it is fine to remove it from the spec though, I am doubtful and want to hear from others as well. cc @michaelsproul

I replied above 😅

I never wanted to have to write should_override_forkchoice_update, it was a necessity because of the (now relaxed) limitations of EL fcU handling.

LH will have to keep our implementation of should_override around for a while to maintain backwards compatibility, but we will relish the opportunity to delete it as soon as we can guarantee all the ELs have updated (probably our first post-Gloas release).

EDIT: misread, see below

Ohh my bad, I misread your comment. You wanted my take on deleting get_proposer_head?

It's not clear to me why it isn't necessary post-Gloas. If a beacon block is revealed late and gets 0 attestations don't we still want to be able to reorg it? And its payload?

It's not clear to me why it isn't necessary post-Gloas. If a beacon block is revealed late and gets 0 attestations don't we still want to be able to reorg it? And its payload?

I don't see why that would change with gloas, you can still earn more money by delaying the beacon block and give you more time before committing to a payload, timing games still exist

also you wanna punish the proposer for publishing late and not the honest attesters that missed the head vote?

imo we should keep get_proposer_head (and thus all other small helper functions like is_head_late) post-gloas because we still want to re-org out the late blocks. Proposers can pick a higher value bid by delaying publishing their blocks.

This PR is just to simplify the proposer boost re-org by no longer needing to override fcu.

Okay, sounds good. Will let @jihoonsong review/merge this one, if and when he thinks it's ready.

Will take a good look next week.