feat: allow multiple bids compatible with the head view - #9739
Conversation
Performance Report鉁旓笍 no performance regression detected Full benchmark results
|
| case GossipType.execution_payload_bid: { | ||
| // instead of searching for the message root, this searches for the parent root | ||
| // Search for the parent independently of current head compatibility. A bid may arrive | ||
| // before its parent block, so compatibility is checked later during gossip validation. | ||
| const parentBlockRoot = getParentBlockRootFromSignedExecutionPayloadBidSerialized(message.msg.data); | ||
| const parentBlockHash = getParentBlockHashFromSignedExecutionPayloadBidSerialized(message.msg.data); |
There was a problem hiding this comment.
@twoeths @wemeetagain curious what are your thoughts about queuing bids in the network processor, I think this could be a potential dos vector
There was a problem hiding this comment.
the root cause is epoch transition when validating gossip bid
I guess it's not an issue once we have #9739
that would prevent the epoch transition when validating the bid
so we can still run epoch transition when validating bid with this PR
we can avoid that by also front-running epoch transition for parent as well
but that means 2 epoch transition per epoch which affects us heavily
There was a problem hiding this comment.
but that means 2 epoch transition per epoch which affects us heavily
we should disallow this to happen at the epoch boundary somehow, currently the proposer boost reorg spec also prevents this behavior via is_not_at_epoch_boundary, so if we are proposer or others following the spec as is will not use bids for the parent of our head
| forkChoice: IForkChoice, | ||
| head: ProtoBlock, | ||
| bidSlot: Slot, | ||
| parentBlockRoot: RootHex, |
There was a problem hiding this comment.
maybe bidParentBlockRoot and bidParentBlockHash would makes it easier to understand
There was a problem hiding this comment.
applied that naming more broadly. I think it make sense to avoid confusing
|
review comments have been addressed, gonna merge this to prepare for |
implements ethereum/consensus-specs#5497 - Restricts propagation to bids compatible with the local head view - Tracks seen bids per builder and parent tuple - Preserves recovery for bids received before their parent block - Prevents duplicate validation before regeneration and after signature verification
Follow-up to #9739 Ignore bids building on the head parent at epoch boundaries, since proposer-boost reorgs are disabled and validating them would regenerate an unusable parent state through the epoch transition.
|
馃帀 This PR is included in v1.46.0 馃帀 |
implements ethereum/consensus-specs#5497