# Final EPF update This is the final update for the ["Reducing trust in the PBS relay"](https://github.com/eth-protocol-fellows/cohort-three) project by [echno](https://github.com/ogechno). The project aimed to reduce the required trust assumptions in the PBS relay either by proposing a new approach or adopting an existing one ## Status report The goal of the project was [defined](https://hackmd.io/@echno/epf-proposal#Goal-of-the-project) as follows: > The goal is to have developed a solution and specification, with the fewest possible drawbacks, that to some degree reduces the trust of the relay. Additionally, it would be nice to have a prototype implementation of this specification. The approach we created is called the Rollup-Relay, which is a PBS solution that utilizes a rollup as the intermediary between the builder and the proposer. Additionally, we described how this approach could be further abstracted to utilize other intermediaries, such as a modified MEV-Boost-Relay or a Data Availability Layer (DA). We also extended the approach with an additional Data Availability Layer to reduce trust assumptions even further. The approach is mostly completed, but unfortunately we didn't have time to write a formal specification and implementation. Below is a comparison of trust assumptions between the current PBS relay, MEV-Boost-Relay, the Rollup-Relay, and an extension of the Rollup-Relay that adds a Data Availability Layer. ### Trust assumption in the mev-boost-relay - 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 trust assumption - the sequencer does not collude with the proposer - the sequencer does not censor transactions (censor txs in the context of the auction) ### Rollup-Relay DA hybrid - the sequencer does not censor transactions (censor txs in the context of the auction) As you can see we have fullfilled our goal to reduce the trust assumptions in the relay. However, in the process of achieving this task, we had to make other tradeoffs. For example the approach proposed by us requires the builder to stake X amount of ETH, which is a hurdle to entry. On the other hand there are also advantages aside from the reduction of trust assumptions, for example spam-protection for the relay but also it being relativly easy to implement and at least for the rollup as the intermediary, it does not require any additional infrastructure. ### Links Project proposal: https://hackmd.io/@echno/epf-proposal Description Rollup-Relay: https://hackmd.io/@echno/rollup-relay Abstraction and further reducing trust assumption: https://hackmd.io/@echno/update-9 ## Future of the project PBS is still a very active area of research, where it isn't even clear if it will be out-of-protocol or in-protocol. Even though trust assumptions are reduced, there might be an incentive to not use this approach because builders need to provide upfront capital as well as pay fees for submitting bids. But I think it is still worth exploring, and I can see a world where multiple different approaches coexist, and the market decides which one they prefer. In the near future, I would like to further specify this approach and possibly also implement a proof-of-concept. An example of an open question is how much ETH should be staked by the builder. The problem here is that the bid amount should be at least the amount staked in case the builder does not provide the promised bid to the proposer. On the other hand, this leads to more centralization since only builders with enough upfront capital are able to participate. ## Self-evaluation Although it was very theoretical and sometimes unclear if I could even find a reasonable approach, I personally haven't had this much fun in a while working on a project. So I'm very sad it comes to an end and our ways are diverging. One important lession I took away from the fellowship programm is the importance of your communication skills, particularly in written form. Presenting your ideas in a clear and understandable way will result in receiving more constructive feedback and spark interesting discussions. Thanks to all the mentors, especially to Barnabe and Alex Stokes for helping out. Special thanks to the legends, Mario and Josh for being such great organizers and taking their time to help and inspire the next set of potential core developers.
Last changed by  
 
ogechno
280

Read more

Update 9

Over the past two weeks, I have mainly been exploring the 'Further Work' section of the Rollup-Relay approach, with a focus on further reducing the trust assumptions through a data availability layer, as well as further abstracting the approach. Abstraction Since I didn't emphasize this enough in my earlier posts, the off-chain commitment between the builder and the proposer does not need to have a rollup as the intermediary. It can also be done via a mev-boost-relay or a data availability layer, as shown in the illustration below. Trust assumptions are reduced with this approach regardless of which intermediary is used. However, there are different trade-offs to consider beyond the trust assumptions, which is why I initially chose to use a rollup as the intermediary. However, I can also see a world where all these different intermediaries can co-exist, and proposers and builders can choose which one to use based on their trade-offs. This leaves room for experimentation and lets the market decide what intermediary works best. Here is the full approach with the abstracted intermediary: Reducing trust assumption further with a data availability layer

2/19/2023
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.

2/19/2023
Update 8

The last two weeks, I have been mainly focused on cleaning up the approach and writing a comprehensive doc that explains the entire mechanism. I'm also in the process of collecting feedback from various people about the it. Additionally, I looked further into data availability layers with their own consensus algorithms, such as Celestia. The doc with the entire approach can be found at: https://hackmd.io/@echno/rollup-relay If you want to leave some feedback, dms are open on twitter or leave some feedback here: https://collective.flashbots.net/t/rollup-relay-reducing-trust-assumptions-in-the-relay/1212 I have also started a Github repo a while back: https://github.com/ogechno/rollup-relay There isn't much in the repo, except for some boilerplate code, but I will probably try to hack on it during the builder week at ETHDenver 2023.

2/6/2023
Update 7

The last two weeks, I focused on the slashing mechanism for the rollup-relay, as well as reconsidering an availability committee for the off-chain commitment. Slashing mechanism As mentioned in my last post, there are 3 slashing conditions: 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. 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. 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. Although, for all of them, there is 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 3. if bid > stake.

1/19/2023
Read more from ogechno
Published on HackMD