Potential Risk from Missing Relay Blacklisting Mechanism

[0xWeakSheep]

Potential Risk from Missing Relay Blacklisting Mechanism

Problem Context

Currently, during getHeader mev-boost only keeps the highest-value builder bid and records the set of relays that supplied it. During getPayload it fans out payload requests to all relays with a default timeout of --request-timeout-getpayload=4000ms. If none of the relays deliver the payload, mev-boost responds to the beacon node with HTTP 502 (core handling in server/service.go:419-429), forcing the validator to fall back to the local execution client. The fan-out logic is in server/get_payload.go:152-334.

Risk Description

• No blacklisting: Even if a relay repeatedly advertises high-value bids but refuses to deliver during getPayload, mev-boost never disables it automatically and will continue to select its bids in later slots.
• Slot time waste: When the winning relay withholds until timeout, the validator burns ~4 seconds waiting and still has to fall back to the local execution client, making that slot’s builder flow useless and reducing rewards.
• DoS vector: An attacker can run a relay that always posts top bids yet never hands over payloads, causing many validators to waste several slots, especially when operators share similar relay lists.

Suggested Directions

1. Introduce penalties or blacklisting, e.g., disable or deprioritize a relay after it withholds/times out a given number of times.
2. Persist failure counters on top of existing health checks/metrics so external monitoring or CLI tools can warn operators automatically.
3. Consider keeping a secondary bid (second-highest) from getHeader to fall back to when all winning relays fail, reducing slot waste.

These improvements would mitigate the impact of malicious or unstable relays on validator rewards and shrink the 4-second delay + MEV loss caused by a single faulty relay.

[0xWeakSheep]

I add demo in this pr #883

[stlpruitt314]

Show me