Proposer boost reorg

[twoeths]

Is your feature request related to a problem? Please describe.

• Allow a proposer to reorg late block (blocks come after 4s): block N + 2 may build on block N if block N + 1 arrived late leveraging proposer boost

There are some benefits with this:

• Proposer is likely to make more proposer reward due to more transactions
• Connected attesters may get more reward since there votes on block N + 1 are not considered late
• It's better for the network, especially for Lodestar if a block comes after 4s then our attestations are potentially missed due to I/O lag issue https://github.com/ChainSafe/lodestar/issues/4881

Describe the solution you'd like

• Spec: https://github.com/ethereum/consensus-specs/pull/3034
• Lighthouse's implementation: https://github.com/sigp/lighthouse/pull/2860

[philknows]

Spec has now been merged. Great thread on feature here for implementation by Lighthouse: https://x.com/sproulm_/status/1720604070207950883

[twoeths]

@naviechan is looking into this

[ensi321]

I guess there are couple questions that we want to answer before implementing it:

1. Should we give users the option (via a flag) to enable/disable proposer boost reorg feature?
2. If so, should it be enabled or disabled by default? imo, it should be enabled by default to contribute to the overall health of the protocol.
3. Since the spec doesn’t enforce the implementation of should_override_forkchoice_update() which is a collection of conditions that need to be satisfied in order to skip the late block, how closely should we follow the suggested implementation? Furthermore, any condition that should be added or removed on top of the suggested impl?

[philknows]

I guess there are couple questions that we want to answer before implementing it:

1. Should we give users the option (via a flag) to enable/disable proposer boost reorg feature?

According to their PR, it looks like it's on by default but there is a --disable-proposer-reorgs to turn it off. I think we should do something similar.

2. If so, should it be enabled or disabled by default? imo, it should be enabled by default to contribute to the overall health of the protocol.

Yes, on by default is my preference here to help with network health.

3. Since the spec doesn’t enforce the implementation of should_override_forkchoice_update() which is a collection of conditions that need to be satisfied in order to skip the late block, how closely should we follow the suggested implementation? Furthermore, any condition that should be added or removed on top of the suggested impl?

I would say we should try to match at least what Lighthouse is doing and the options they give, which is explained very well in their PR here: https://github.com/sigp/lighthouse/pull/2860

Will let the team also chime in to see if there's anything else we can add to it.