Allow builders to bid on multiple branches

[nflaig]

Currently a builder can only submit a single bid per slot over gossip because the first-bid rule is keyed per builder and slot, while the highest-value rule already tracks bids per branch since #5001. This means a single builder entity can't bid for both an empty and full parent when it's contested whether the next proposer will build on full or empty (eg. a late payload reveal or split PTC vote), and can't serve a proposer that re-orgs a weak head. The workaround would be to register multiple builders and submit one bid with each, which just bloats the builder registry and is less capital efficient for honest builders, this is something we want to avoid.

This PR updates the first-bid rule to use the same tuple as the highest-value rule and adds MAX_BIDS_PER_BUILDER = 3 to keep the number of bids per builder per slot bounded. The value of 3 allows a builder to (1) bid for both an empty and full parent and (2) serve an honest proposer boost re-org, ie. 2 payload states for the parent plus the re-org parent whose payload status is already resolved by fork choice. Only one of those bids can ever be included and charged since they are mutually exclusive. There is still only one bid per tuple, so builders can't escalate their bids.

DoS wise, the worst case per builder only goes from 1 bid (~1.3 KB) to 3 bids (~4 KB) per slot. Note that the per builder limit was never the main protection here, anyone can trivially register many builders and submit bids with each of them, with or without this change. This is covered by the highest-value rule and the DoS prevention measures note, eg. nodes should only forward bids that exceed the current highest bid by a minimum threshold.

[jihoonsong]

Do we want to specify that a builder can bid up to 3 in builder.md?

[nflaig]

Do we want to specify that a builder can bid up to 3 in builder.md?

sure, that might be helpful, you wanna do that or should I push a change for it?

[jihoonsong]

Could you add it when you have some time? @nflaig

[potuz]

Do we want to specify that a builder can bid up to 3 in builder.md?

This is incorrect, the builder can (and probably should) submit as many bids as it deems necessary (for example if there are multiple possible heads) peers will ignore most and only the relevant ones should reach the proposer. This PR is about control on at the peer level, not at the builder nor proposer level.

[nflaig]

the builder can (and probably should) submit as many bids as it deems necessary (for example if there are multiple possible heads) peers will ignore most and only the relevant ones should reach the proposer

isn't that statement only true if we go with something like #5491, because otherwise a peer will see the first broadcast bid, it will pass gossip validation even if it's not head compatible, the peer will add it to the seen cache, and then any follow-up bid would be ignored due to [IGNORE] this is the first signed bid seen with a valid signature from the given builder for this slot., so in a sense your PR improves bid propagation by making it stricter if I understand correctly

[jihoonsong]

Relaying relevant discussion for visibility.

[nflaig]

closing in favor of #5497, it allows multiple bids per slot too while limiting propagation based on the node’s local head view, so we don't need a separate per-builder counter, I think that is a cleaner approach and less invasive as it doesn't add a new config