# Update 6 - Rollup-Relay
As mentioned in the previous dev update, I have been leaning towards using a rollup as a solution for the off-chain commitment. In the past two weeks, I have explored this idea further. While the "rollup-relay" may not be the ultimate solution for solving PBS, I still belive it accomplishes the goal of my project, which is to reduce the trust assumptions in the relay. Additionally, I believe it has better trade-offs than the current solution and could serve as a temporary replacement.

## The Rollup-Relay
The Rollup-Relay approach involves using a rollup to facilitate the exchange of minimal information needed for the builder and proposer to accomplish the auction. In the following section, I will provide a more detailed explanation of how this process takes place.

First, before the proposer's slot, the builder and proposer register on-chain via a smart contract. The builder must also deposit some amount of stake, which can later be used to penalize the builder if they behave improperly.

Next, all the builder post their block headers and bids onto a contract deployed on a zk-Rollup. The proposer collects all the offers and selects the best bid. The proposer then signs the block header.

The proposer sends the signed header, encrypted with the builder's public key, to the rollup. The builder whose bid was selected by the proposer can now retrieve the signed header and release the block to the network.

Lastly, the rollup submits the batch of transactions to Ethereum, which is important for providing proof that the proposer has submitted the signed header and completed the auction. Now, if the builder misbehaves, for example by failing to release the block on time, the proposer can slash the builder on-chain.

## Slashable offences
These are the offenses for which a builder could be slashed.
- withholding the block
- submitting an invalid block
- (not paying the auction bid)

## Trust assumptions comparison
As previously mentioned, the goal of my project is to reduce the trust assumptions required in the PBS relay. To understand how this can be achieved, I will compare the trust assumptions of the current approach to those of the rollup-relay. By examining the trust assumptions of each approach, we can see how the rollup-relay aims to minimize the need for trust from both the builder and the proposer, helping to create a more secure and reliable system overall.
### Current approach:
- the relay is not tempering with the blocks content (e.g., mev stealing)
- the relay releases the block on time to the network
- the relay is not censoring blocks based on their transactions they contain
- the relay always chooses the highest bid (not biased which block builder to choose from)

### Rollup-relay
- the sequencer does not collude with the proposer
- the sequencer does not censor transactions (censor txs in the context of the auction)

The assumptions that the relay may tamper with the blocks content, censor certain blocks based on their content, or be biased in choosing which blocks to choose are no longer necessary in the rollup-relay system. This is because the builder in the rollup-relay approach does not need to provide the blocks content to any third-party before releasing the block to the network. Additionally, the builder is self-responsible for releasing the block on time and the proposer chooses their own bids. However, it is possible for the proposer to collude with the sequencer and unfairly slash the builder without the builder engaging in any slashable behavior. Additionally, the sequencer may censor transactions necessary for the auction, such as bids from builders, leading to potential censorship of the auction process. While both of these scenarios are highly unlikely due to the significant social and financial incentives for maintaining honesty in the rollup system, it is important to consider and plan for the worst case scenario in the design process. However, these assumptions can be further reduced if rollups decentralize their sequencer (and prover). This is a planned feature for all major rollups. Overall, the trust assumptions are considerably reduced in the rollup-relay system.

## Further Pros and Cons
It is important to note that in addition to the trust assumptions above, there are also other trade-offs listed here that should be considered.
### Pro:
- lower complexity then other solutions
- built-in spam protection, as builders must pay L2 gas fees to send offers
- EVM-compatible rollups are easily exchangeable
- proposer can theoretically chose on which rollup to auction of the block production
- neither the rollup nor the proposer can access the content of blocks, preventing the theft of the builder’s MEV.
- incentives for operating a rollup
- rollups are already an established part of the ecosystem, so there is no need to introduce a new entity such as a relay or specialized sidechain.
- inclusion lists could be easily implemented
- builders have an incentive to use this system because they do not need to trust the relay to not steal their mev
- the proposer also has an incentive to use this system because they do not need to trust the relay to release their block on time and risk missing out on the reward
- proposer can be stateless

### Cons:
- latency (not super high, but still)
- the builder has to stake X amount of ETH
- gas costs for the proposer and builder during registration and during the auction itself
- only zkRollups work for now (could be wrong about this)

## Next steps
- Further evaluate if this approach is feasable
- Further specify how the slashing mechanism works
- Design the mechanisms for the smart contracts