Potential Risk from Missing Relay Blacklisting Mechanism

# 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.