mev-boost with unconditional payments

TLDR: We'd like to consider whether it would make sense for builders to bid unconditionally for their header to be selected by the proposer. This would imply the proposer gets paid regardless of whether the body gets revealed. We care about this because it maps onto the current spec of in-protocol PBS more closely (further helping test PBS with MEV-Boost), because it is more favorable to proposers, and because it places less trust on _relays_.

**Context**
In the current version of MEV-Boost:
- *searchers* submit bundles to *builders*
- *builders* build blocks with these bundles and public mempool transactions
- *builders* send their blocks and bids `(body, header, bid)` to *relays*
- *relays* check the validity of and store builder blocks, get pinged by the *proposer* and share **only** the headers of all the valid blocks they have alongside their respective bids `(header,bid)`
- the *proposer* selects the header with the highest bid and signs on it within the beacon block they propose
- once the *relay* knows the *proposer* has signed on this header, the block body of the associated header is revealed by the *relay*. The payment is contained within the body.

> Note:
> This commit-reveal scheme was chosen in order to ensure there is no trust assumption placed on validators, making accessing MEV revenue via MEV-Boost completely permissionless. This is the 'trusted relay' model in this document: https://hackmd.io/8cUfu-HKQuyYjWk-f9DVuw. This Github issue doesn't discuss in detail why this solution was chosen. Please refer to a presentation given at EthStaker for more detail for why ensuring all validators have access to MEV revenue is especially important in PoS Ethereum: https://youtu.be/GJwS7VF40wk?t=23292.

**Unconditional payments**
In the current model, the proposer only gets paid if the block body whose header they've signed on is revealed by the relay. This means the proposer is at the mercy of the relay. If the relay doesn't reveal the body, then the proposer ~~gets slashed from proposing an empty execution block~~ loses protocol rewards they would've gotten from proposing a block as well as the MEV rewards (incl. transaction tips) that are in the block body. (edit: correcting previous statement that proposer gets slashed from proposing an empty block).

The relay is therefore trusted by 1) the builders who submit their blocks to it, 2) the validators who sign on one of the headers they receive from the relays.

We would like to consider an alternative system where builders pay unconditionally for their bid. In this system:
- *searchers* submit bundles to *builders*
- *builders* build blocks with these bundles and public mempool transactions
- *builders* send their `(header,bid)` pairs to *relays*
- *relays* store builder's `(header,bid)` pairs as well the money needed to fullfill the bid
- *relays* get pinged by the *proposer* and release each `(header,bids)` pairs it has for the current slot.
- the *proposer* selects the header with the highest bid and signs on it within the beacon block they propose
- as soon as the *relay* sees the header, it releases the payment to the proposer, unconditionally of the body being revealed.
- the block body of the associated header is revealed by the *builder* who is now incentivized to do so since they've already paid for it.

How does this differ from the current system?
- The relay now essentially acts as a payment escrow.
- The relay cannot see the block bodies and does not check for the validity of the bodies. This reduces the trust builders and proposers need to have in the relay.
- The proposer now gets paid regardless of whether the body gets revealed.
- The builders are now responsible to reveal their header's body, and they are incentivized to do so since they've already paid for it. Similarly, they are incentivized to make sure their body is valid.
- This shifts the attack vector to builders, who can now be griefed by proposers who can pick a header late enough such that a builder doesn't have time to reveal the body before the appropriate time window but a relay has enough time to see it and release the payment.

A document outlining this alternative was written by @thegostep here: https://hackmd.io/@flashbots/Skc0vuyCt

**Outstanding questions**
1) How does unconditional payment work with multiple relays? In other words, who does the builder send money to if it sends its `header,bid` pair to two relays? (h/t @lightclient for asking this question)
2) Does this system put a prohibitively higher capital requirements on builders who now need to put up money upfront?
3) Is a griefing vector from proposers acceptable?
4) Which solution is better between the current design and unconditional payments? Do we fully understand the trade-off space?

We open this up for discussion and look forward to your questions and comments 🤗