# Rollup-relay
The goal of the project was to reduce the trust assumption in the PBS relay. While the Rollup-Relay may not be the ultimate solution for solving PBS, we still believe it accomplishes this goal. Additionally, this solution could be implemented relatively quickly today compared to other solutions, since the infrastructure is already in place. It also serves as a solid foundation for more sophisticated solutions.

# The Problem
Currently, relays serve as the link between the builders and proposers. Builders can submit bids to the relay to have their block included in the proposers slot. The relay selects the highest valid bid and forwards the block header the proposer. The proposer picks the best block from all the relays and returns the signed header back to the chosen relay. After the signed block header is received, the whole block is released to the network.
This strategy has some fundamental trust assumptions, e.g. relying on the relay to release the block on time, unbiased in selecting the blocks for the proposer (e.g. the relay operators do not prefer their own blocks over others), does not censor blocks based on their content and do not steal the builder’s mev opportunities. To reduce these trust assumptions, we propose the rollup-relay.

# The Approach
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, we 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 slash the builder.

Next, all the builders post their block headers and bids onto a contract deployed on a 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.

## Slashing conditions
1. The builder did not release the block on time - this is necessary because in our approach, the builder is responsible for releasing the block to the network on time. If they fail to do so, the proposer is missing out on the reward for proposing the current block. The slashing amount could be the block reward + promised bid in the auction + some \mu for punishment.
2. The builder submitted an invalid block - this condition is needed so the builder does not grief the proposer by submitting an invalid block. The proposer would also lose out on the reward for proposing the block. Because of that, the builder needs to be slashed. Again, the amount could be the block reward + promised bid of the auction + \mu.
3. The builder did not pay the promised fees - this slashing condition is needed so the builder actually pays the proposer the promised bid. The slashing amount could be the promised bid + \mu for punishment.

## Fault proving
1. We can assume the builder will always send an invalid block and by default remove some stake unless the builder includes a transaction with a function call to the staking contract in their block, which signals that it is not an invalid block. Because if it was, they wouldn't be able to call this function. This can be used for slashing condition 2. as explained, but also for 1. because if the block isn't released on time, the block is not included, therefore the function is not called, and they get slashed.
2. The bid needs to be sent to a smart contract and not the proposer directly. The bid is released after a certain challenge period where when the bid is not there, the proposer could slash the builder.

# Analysis
The concrete mechanism on how the proposer will prove the commitment between the builder and themselves is left open. This is due to the upcoming changes by EIP-4844. Currently, rollups post their compressed data in the blocks which are part of the execution layer, this would allow the proposer to prove that the signed header transaction is included in that data. With EIP-4844, rollup data will no longer be stored in the execution layer, but on the consensus layer, making it inaccessible from smart contracts. But the proposer can resubmit the relevant parts for the proof via calldata and verify using the POINT_EVALUATION_PRECOMPILE that the data corresponds to the submitted blob by the rollup. From there, the proposer can prove whether the signed header transaction was included in the rollup's batch or not. Since the spec for EIP-4844 isn't frozen yet we will wait until then to finalize this mechanism, in case something changes with 4844.

Currently, we need to verify that the batch containing the signed header transaction from the proposer was submitted by the rollup's sequencer. This is because a malicious proposer could submit a batch with the signed header transaction included on their own, without sending it to the rollup or the builder, therefore the builder is unable to submit the block, resulting in the proposer falsely being able to slash the builder. Therefore we need this check to make sure the transaction was submitted to the rollup for the builder to retrive this transaction. Additionally, we need to verify that the signed header transaction was submitted on the rollup before the proposer's slot ended. For example, an availability committee could ensure this.

All slashing conditional inherent a problem - if the bid is greater than the staked ETH of the builder, the proposer losses out on some reward. In addition the builder has an incentive to just take the "slash" instead of paying the promised bid amount in case of slashing condition 3. if bid > stake.

## Trust assumptions
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, we 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.
## Trade-offs
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)
- Although in the current relay approach, the relay needs to execute the block to verify its legitimacy, in the rollup-relay, neither the relay nor the proposer need to execute blocks, resulting in savings in speed and computational resources.
- the builder has to stake X amount of ETH which is a hurdle to entry
- gas costs for the proposer and builder during registration and during the auction itself
- only zkRollups work for now (could be wrong about this)

# Related Work
- [EigenLayers PBA](https://hackmd.io/@layr/SkBRqvdC5)
- [Threshold Decryption](https://www.youtube.com/watch?v=acMfCjjX7O4)
- [IP-PBS](https://ethresear.ch/t/unbundling-pbs-towards-protocol-enforced-proposer-commitments-pepc/13879)

# Future Work
This is a collection of half-backed ideas about potential future directions for this approach.

## Searcher-Builder market
The rollup could also be used for a searcher-builder market. Searchers can submit their bundles to the rollup, and builders could include them in their block for a fee. Bundles could be encrypted on the rollup, and builders would commit to including them in their block. If the builder steals the searchers' MEV opportunities or does not include the bundle even though they committed to it, they get slashed. Because the builder does not know what is inside the bundle before committing to it, they would have to choose only disjoint bundles. This could make the searcher-builder market more accessible to new builders, since these bundles received through bundle endpoints from big builders are often not shared, and therefore exclude small builders.

## Multi-Rollup approach
The proposer can specify the preferred rollups for conducting the auction. This enhances diversity and provides further incentives for the sequencer to be honest. The trust assumption, "the sequencer does not censor transactions," is reduced as builders can submit bids on all rollups specified by the proposer. This decreases the chance of a bid being censored, since all sequencer would have to censor this builder's bid.

## Specialized Rollup
A specialized rollup could be a rollup specifically created for the purpose of PBS. In general, this approach can be applied to any rollup for reasons such as diversity and ease of adaptation. However, having a dedicated rollup, rather than a generalized rollup, would have some advantages. For instance, it could have limited transaction types, such as a bid transaction or a sendSignedHeader transaction. It would also allow for specifying the cost of each transaction. For example, bid transactions could cost the most to prevent spam and pay for rollup operations, while sendSignedHeader transactions could cost nothing to incentivize the proposer to use the rollup.

## EigenLayer
Instead of requiring the builder to stake X ETH, they could become a re-staked proposer, lowering the barrier to entry. However, EigenLayer still has some issues from the protocols perspective, as explained [here](https://ethresear.ch/t/unbundling-pbs-towards-protocol-enforced-proposer-commitments-pepc/13879#in-protocol-eigenlayer-ip-eigenlayer-1).

## Merkle Proofs
There could be a Merkle proof that is sent when the builder sends the bids, so the proposer could check if the needed transactions are included. But this should only be used as a quick sortout method, not as proof that these transactions are actually in the block. That's due to the fact that the builder could include those transactions, for example, the bid sent to the proposer and forge a proof, but they could include another transaction with the same nonce as the first one and therefore make the first one revert. Maybe there could be a proof to prove that such a second transaction does not exist in that block, but that might be too complex.

## Dynamic staking amount
Due to the issue with bid > stake as discussed in the analysis section, staking could be dynamic, requiring the builder to stake at least X amount of ETH, but allowing for the option to stake more. As a result, the proposer could specify that only bids with a stake higher than the bid are accepted. Although, this favors builders with more capital, which could lead to further centralization.

## Extra slashing condition
1. Inclusion lists - the proposer defines a list of transactions that need to be included, and if they are not included, the builder gets slashed.
2. Front-running protection - builders are not allowed to include trivial front-running transactions like sandwiching, if they do, they get slashed, and for example, these slashing fees could be redistributed to the user who got sandwiched.
- Only trivial sandwich attacks because they can be proven easily and don't really leave any room for speculation if this was just a "coincidence".
- On the other hand, this could open the door for unwanted censoring of transaction patterns

## Availability committee for the off-chain commitment

This approach replaces the rollup in the rollup-relay with an availability committee. The signed header is sent to the availability committee and attested by them. In the event of something slashable happening, the proposer submits the signed header message along with a required number of attestations (m out of n) to the on-chain slashing contract. The rest of the slashing process remains the same as in the Rollup-Relay approach.

The only thing that is still open is how to incentivize honest participation in this availability committee. EigenLayer could be a solution, and the builder also needs to pay some fee to the committee, but this is not 100% clear yet. As a benefit of this approach, assuming incentives are there, that now large trust assumptions like with the current approach or the rollup-relay, like the proposer and the sequencer do not collude with one another, don't exist anymore. As a downside, it has no spamming protection by default, but we believe this is implementable.

Overall, the approach with the availability committee might be the better solution in the long term, but it is more complex and there are still some open questions like the incentive layer and spam-protection.

## Availability committee - Rollup hybrid
The "Availability committee - Rollup hybrid" approach involves an availability committee that ensures the data was accessible on the rollup by requesting the transactions that are relevant for the auction. The builder can for example request the signed header transaction from the committee as a backup, in case the sequencer and proposer collude against him. The committee confirms the accessibility of the header, meaning the proposer would need to provide evidence of availability from the committee to penalize the builder. This removes the trust assumption that the sequencer does not collude with the proposer.