Try   HackMD

Update 4

In week 5-6, the focus was on understanding the off-chain commitment process between the proposer and the builder. This commitment is necessary for allowing the proposer to provide proof of its occurrence and potentially slash the builder for withholding the block or submitting an invalid block. To prove the off-chain commitment between the proposer and builder, the builder needs to provide evidence of the agreement to the proposer. In turn, the proposer needs to provide the signed header to the builder. However, if the builder sends the proof first, the proposer could withhold the signed header and punish the builder later on. On the other hand, if the proposer sends the signed header first, the builder could engage in slashable behavior without being punished, as the proposer doesn't yet have proof of the agreement. As a result, it is necessary to find a way to securely and atomically exchange the signed header and proof of the off-chain commitment. This needs to be done inside the 12s slot window. The plan for all the approaches is that validators register on-chain beforehand, so builders know which validators participate and how to discover them.

Off-chain commitment

  1. Escrow Relay:
    This approach involves using a centralized relay that acts as an escrow service. It waits for the proof and signed header to be provided by the builder and proposer, respectively, and then exchanges them. This is similar to the current approach, although in the status quo, the relay has additional tasks beyond serving as an escrow. This approach is also used by the mechanism proposed by the EigenLayer team. This might not be desirable due to the lack of decentralization.

  2. Rollup:
    One potential approach to consider is the use of a rollup, a layer 2 scaling solution, to perform the atomic exchange. A smart contract could be employed on the rollup to atomically exchange the relevant information. However, most rollups currently rely on a centralized entity called the sequencer, which could potentially lead to collusion between the sequencer and the builder/proposer. Several rollups have plans to decentralize the sequencer, but this has not been implemented yet. As there are multiple rollups available, builders and proposers can choose which one they want to use. Using a rollup is the easiest solution, but at the moment but it simply shifts trust from one centralized entity to another. However, we could build this ahead of time with the assumption that a rollup is decentralizing their sequencer in the near future.

  3. Sidechain:
    Another approach we could consider is using a sidechain with its own nodes and consensus algorithm. This would be a complex solution for this project, but it could be useful if we later want to fully decentralize the builder and perform cross-domain mev. However, the need for fast confirmation times (due to the 12-second time constraint) could compromise the security or decentralization of the sidechain.

  4. Data availability committee
    One potential approach is to utilize a trusted data availability committee to collect the block from the builder and verify its authenticity. The proposer would then send the signed block header, and the full block would be released. The committee could also attest to this commitment on-chain at a later time. However, this approach would not be fully decentralized, as it relies on a collection of trusted entities. It could be extended to incorporate threshold encryption for greater decentralization.

  5. Threshold Encryption Committee:
    Similar to the approach outlined in this video, the threshold encryption committee would generate an encryption key and send it to the proposer and builder. Both parties would encrypt their data using identity-based encryption and send it to one another. Once both parties have received the encrypted data, they would send a confirmation message to the committee. Upon receipt of both confirmation messages, the committee would send the identity-based decryption key to both the proposer and builder. This approach offers the potential for full decentralization and but suffers from high complexity.

Overall, finding a way to prove the off-chain commitment between the proposer and builder in a decentralized manner is a complex challenge that requires further exploration.

Last changed by 
 
ogechno
0
138

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