data availability & relay misbehavior

[obadiaa]

Context:
There are discussions, as mentioned by @thegostep in issue 109, of relays gossiping builder payloads among each other to improve data availability and combat exclusive orderflow. Intuitively, this feels like it shouldn't be done without getting explicit approval of the builders as it otherwise subjects them to unwanted exposure of information to a larger set of parties than they expected.

For each relay that a builder sends its payload to, a builder needs to trust that the relay won't use that information adversarially, for example frontrun them. This means a builder would rather send their payload to a single trusted relay instead of multiple ones. However, as pointed out by @fradamt also in 109, proposers would rather select headers they see from multiple relays to benefit from the 1/n assumption and lower the risks of a data availability issue (malicious or not) such as a block-body withdrawal from a relay after a header has already been signed by the proposer.

Questions:
Primary:

1. How difficult it is to monitor/detect relay misbehavior if multiple relays have the same payload?Understanding this problem better would allow us to think through the risks that builders subject themselves to by allowing relays to share payloads with one another.
2. Are there other ways to improve data availability? For example with a trusted data availability committee which collects payloads from all relays and aren't running relays themselves?

Secondary:

4. What kind of equilibrium (in number of relays trusted by builders for any given payload, and number of relays trusted by proposers for any given payload) will be reached given these two opposing forces?
5. How will it impact the market of builder's bids?