# Removing trust from the relay
This document outlines an approach that aims to remove some of the trust in relays that is required from builders and proposers. This [note](https://hackmd.io/e12Q8UYBSqOySdrbU7LdwA?view) contains additional background details. Regular updates will be made to this page.

## Discovery mechanism
There are several ways the discovery mechanism can function. These approaches might coexist since there are various validators with various incentives.
1. A centralized relay which only forwards requests
- \+ Proxy for proposer privacy
- \+ Lower latency for builder to have more time to build more profitable block
- \- Trusting the relay to be honest
2. A peer-to-peer protocol with a validator dht, in which builders could transmit their bid and block header to the proposer. Afterwards, the highest bid is chosen by the proposer. Designing an anti-spam mechanisms with the use of EigenLayer is another possibility. (But I haven't thought it through, yet)
- \+ Trust less
- \- No dos protection
- \- No privacy protections (You could argue that, that this is already the case for validators with the normal consensus mechanism)

## Reducing required trust in the relay
1. The builder with the highest bid sends the block header to the proposer.
2. The proposer signs the block header.
3. The builder makes an off-chain commitment that he will either release the block or get slashed if he receives the signed block (via the EigenLayer technique or similar). This can only work if the builder is also a proposer.
4. If he agrees, he receives the blinded block and releases the entire block.

## Integrating PBA
1. Proposer broadcast/publish an inclusion list
2. Builder creates the block and sends the proposer the block header and a merkle proof or a kzg commitment that proves the inclusion of the proposer's inclusion list is in the block.
3. The highest builder offer is chosen by the proposer, who then verifies the proof and, if the builder completed the EigenLayer off-chain commitment, returns the signed block header.

## Analysis
Since the proposer is unaware of the block's contents prior to the builder releasing it, he is unable to steal the mev from the builder. There is a chance that, if the profit of this block is greater than 32 ETH, the proposer will choose to release a block with the same height for his slot, which is a slashable offense. However, if the profits are high enough, the risk can be financially worthwhile for the proposer. Given that this is a more fundamental issue, there is a lot of discussion surrounding it. Additionally, the builder is incentivized to release the block because doing otherwise will result in him being slashed on the EigenLayer. Another issue with this is that in order to restake their share for the off-chain commitment, the builder also needs to be a proposer. For new builders, this is a barrier to entry. The proposer can be stateless since it only needs to sign the block header and communicate with the builder.

## Comparing to other approaches