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
implements ethereum/consensus-specs#5497