Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposer boost reorg #5125

Closed
twoeths opened this issue Feb 10, 2023 · 4 comments · Fixed by #6652
Closed

Proposer boost reorg #5125

twoeths opened this issue Feb 10, 2023 · 4 comments · Fixed by #6652
Assignees
Labels
meta-feature-request Issues to track feature requests. prio-medium Resolve this some time soon (tm).

Comments

@twoeths
Copy link
Contributor

twoeths commented Feb 10, 2023

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 [vc] Investigate late attestations published on mainnet #4881

Describe the solution you'd like

@philknows philknows added prio-high Resolve issues as soon as possible. meta-feature-request Issues to track feature requests. labels Feb 10, 2023
@twoeths twoeths self-assigned this Mar 6, 2023
@dapplion dapplion added prio-medium Resolve this some time soon (tm). and removed prio-high Resolve issues as soon as possible. labels Jun 1, 2023
@philknows
Copy link
Member

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

@twoeths
Copy link
Contributor Author

twoeths commented Dec 5, 2023

@naviechan is looking into this

@ensi321
Copy link
Contributor

ensi321 commented Dec 15, 2023

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
Copy link
Member

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.

  1. 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.

  1. 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: sigp/lighthouse#2860

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
meta-feature-request Issues to track feature requests. prio-medium Resolve this some time soon (tm).
Projects
None yet
4 participants