feat: proposer boost reorg #6298
Conversation
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## unstable #6298 +/- ##
============================================
- Coverage 61.69% 61.53% -0.16%
============================================
Files 555 556 +1
Lines 58255 59090 +835
Branches 1844 1874 +30
============================================
+ Hits 35939 36363 +424
- Misses 22277 22686 +409
- Partials 39 41 +2 |
| @@ -352,7 +352,7 @@ export function getValidatorApi({ | |||
| // forkChoice.updateTime() might have already been called by the onSlot clock | |||
| // handler, in which case this should just return. | |||
| chain.forkChoice.updateTime(slot); | |||
| chain.recomputeForkChoiceHead(); | |||
| chain.recomputeForkChoiceHead(UpdateHeadOpt.GetProposerHead, slot); | |||
There was a problem hiding this comment.
need to get the result (proposer head) from this function, put it in chain.produceBlindedBlock() in order to build block with expected parent_root
same to the other 2 chain.recomputeForkChoiceHead () calls below
| @@ -646,12 +647,12 @@ export class BeaconChain implements IBeaconChain { | |||
| }; | |||
| } | |||
|
|
|||
| recomputeForkChoiceHead(): ProtoBlock { | |||
| recomputeForkChoiceHead(mode: UpdateHeadOpt = UpdateHeadOpt.GetCanonicialHead, slot?: Slot): ProtoBlock { | |||
There was a problem hiding this comment.
it takes me a while to figure out the use of different params here. I prefer to keep this function as is and add:
predictProposerHead: to be used inprepareNextSlot.tsgetProposerHeadwhen we produce a block
that'd be cleaner to me, each function has its own purpose. Would like to know opinions from @wemeetagain @g11tech too
| @@ -476,7 +484,7 @@ export class BeaconChain implements IBeaconChain { | |||
|
|
|||
| async produceCommonBlockBody(blockAttributes: BlockAttributes): Promise<CommonBlockBody> { | |||
| const {slot} = blockAttributes; | |||
| const head = this.forkChoice.getHead(); | |||
| const head = blockAttributes.proposerHead ?? this.forkChoice.getHead(); | |||
There was a problem hiding this comment.
need to make change in chain.produceBlockWrapper() to use use proposerHead inside BlockAttributes to build block
|
this is too big to review and get merged imo. @ensi321 I suggest breaking this into at least 2 PRs:
once we have e2e test, I'm comfortable merging this work with disable flag, test it for a while on different networks and fix bugs if any, then finally turn in on by default in the future |
|
Splitting this PR into smaller chunks for better reviewability. |
Motivation
There is an optional piece of the consensus spec that allows a CL client to re-org out a late head block by proposing new block on the parent of the canonical head. This discourages other block proposers on the network to maximize MEV by intentionally publishing a block late and thus, improving the overall health of the network.
Description
get_proposer_head()andshould_override_forkchoice_update()computeProposerBoostScoretocomputeCommitteeFractionto align with the naming in the specproposerBoostReorgEnabledcli flag to enable/disable the proposer boost reorg featuretimelinessfield toProtoBlockCloses #5125