Try   HackMD

Update 2

This is my update for week 1-2. During those two weeks, I studied partial block auctions in greater detail and looked at concepts like reducing trust in the relay or even removing the relay completely. Additional resources that I looked into are listed at the end. My first update outlines the issues that partial block auctions are attempting to address. Currently, relays serve as the link between the builders and mev-boost, while the proposer operates mev-boost.


Source.
Builders can submit offers to the relay to have their block included in the proposers slot. The relay selects the highest bid and forwards the block header to mev-boost. Mev-boost 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, it's released to the network together with the block body. This strategy has some drawbacks, such as relying on the relay to release the block on time and to not capture the builder's mev opportunities. One solution for this was proposed by the EigenLayer team. Which has a few drawbacks: they still require a central relay, and they also require that the proposer is not stateless.

Reducing required trust in the relay

This section will provide a proposal that, although being similar to the EigenLayer team's strategy, does not necessitate a central relay and allows for stateless proposers. However, I'll also discuss several shortcomings of this strategy. For now, I'll ignore the discovery mechanism and the process of choosing the highest bid from builders. (This is covered in the "Discovery mechanism" section)

  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.

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.

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)

Integrating PBA

This idea was inspired by this commment. It is also not perfect and contains some of the problems listed in Vitaliks article "How much can we constrain builders without bringing back heavy burdens to proposers?".

  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.

Conclusion

In summary, I believe that both the approach described above, and the one proposed by the EigenLayer team, have the potential to be more effective than the current status quo. A trade-off must be made between the 32 ETH barrier to entry for builders and the requirement for a centralized relay and the proposer not being stateless. These are just two possible techniques; there may be one that works better.

Next steps

  • Write a project proposal

Resources

Last changed by 
 
ogechno
0
338

Read more

Final EPF update

This is the final update for the "Reducing trust in the PBS relay" project by echno. 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 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.

Feb 27, 2023
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

Feb 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.

Feb 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.

Feb 6, 2023
Read more from ogechno
Published on HackMD