Try   HackMD

Update 5

During the past two weeks, I have been carefully evaluating the various options that were previously identified for implementing an off-chain commitment process in our system. This process, which involves the exchange of the signed headers and proof of commitment between a proposer and a builder, is essential for ensuring the timely and accurate addition of valid blocks to the chain. To facilitate the atomic exchange of information required for this process, several potential solutions have been identified in the last dev update, including the escrow relay, rollups, sidechains, data availability committees, and threshold encryption committees. Each of these approaches carries its own set of trade-offs with respect to decentralization, incentives, complexity, and latency. We're currently looking at the pros and cons of each option to decide on the best course of action. As of yet, I have not made a final decision on which approach to take, as the trade-offs involved are complex. In my assessment, a sidechain solution is currently suboptimal due to the rapid confirmation times it would entail, which could potentially compromise security guarantees. Additionally, it is not necessary to maintain a complete history of transactions, as only the history within the 12-slot window from Ethereum is required for the auction. Furthermore, implementing a sidechain from scratch is a highly complex task.

Escrow Relay

We will now examine the escrow relay approach in greater detail:

  1. Prior to the proposer's slot, both proposers and builders must register on-chain in order to participate in the process.
    • As part of this process, builders must deposit a specified amount of stake.
  2. Builders send bids and a proof of commitment to the relay.
  3. The relay selects the highest bid and forwards the corresponding block header to the proposer.
  4. The proposer signs the header and returns it to the relay.
  5. The relay responds to the proposer with the proof of commitment provided by the builder.
  6. The relay then forwards the signed header to the builder.

With the completion of the off-chain commitment, the builder is obligated to release the block or face being slashed on-chain by the proposer using the proof of commitment provided. However, the escrow relay approach is far from ideal due to its reliance on a centralized relay, which lacks incentives to perform its duties. The escrow relay approach does offer the advantage of requiring less trust in the relay, as it does not have access to the content of the blocks it handles. In contrast, under the current system, the relay has the ability to inspect the full contents of blocks, which could potentially be exploited for economic gain. By removing the relay's access to block content, the risk of such exploitation is reduced.

Disadvantages:

  • Centralized relay is still present :(
  • Potential for collusion between the relay and proposer to slash the builder
  • No monetary incentives for operating a relay

Advantages:

  • Lower complexity compared to other solutions
  • Low latency
  • Neither the relay nor the proposer can access the content of blocks, preventing the theft of the builder's MEV.

Availability Committee

As previously mentioned, the escrow relay approach represents a good initial step towards a more secure and efficient process. A potential next step could be the implementation of an availability committee (AC). The following changes would be made relative to the escrow relay approach:

  1. Prior to the proposer's slot, both proposers and builders must register on-chain in order to participate in the process.
    • As part of this process, builders must deposit a specified amount of stake.
  2. Builders send bids and a proof of commitment to the proposer.
  3. The proposer selects the highest bid.
  4. The proposer signs the header and sends it to the availability committee (AC).
  5. The AC responds to the proposer with the proof of commitment provided by the builder.
  6. The AC then forwards the signed header to the builder.

In the availability committee (AC) model, only trusted members may initially be included. This approach has the potential to be upgraded to incorporate threshold encryption to improve decentralization, and participation in the AC could be incentivized through fees that the builder pays.

Disadvantages:

  • No permissionless participation (lacks decentralization)
  • High latency

Advantages:

  • Neither the rollup nor the proposer can access the content of blocks, preventing the theft of the builder's MEV.
  • Less centralized than the escrow relay approach
  • Potential to be extended to a decentralized model.

Rollup

We will now discuss rollups:

  1. Prior to the proposer's slot, both proposers and builders must register on-chain in order to participate in the process.
    • As part of this process, builders must deposit a specified amount of stake.
  2. Builders send bids and a proof of commitment to the L2 smart contract.
  3. The proposer selects the highest bid.
  4. The proposer signs the header and sends it to the L2 smart contract.
  5. Upon receipt of the signed header, the L2 smart contract releases the proof provided by the builder.

Disadvantages:

  • Possibility of sequencer collusion
    • However, there is an incentive not to collude **
  • In order to facilitate transactions on the rollup, both builders and proposers must ensure that the required currency is available for use. This may involve bridging the necessary funds.

Advantages:

  • Lower complexity compared to other solutions
  • Low latency
  • EVM-compatible rollups are readily exchangeable for this scenario
  • Neither the rollup nor the proposer can access the content of blocks, preventing the theft of the builder's MEV.
  • Built-in spam protection, as builders must pay L2 gas fees to send offers
  • 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.

It is possible that the sequencer for major rollups may become decentralized in the future, introducing a new dynamic to the process.

** The entity responsible for running the sequencer is typically the rollup maintainer themselves, who have a vested interest in ensuring the authenticity of their transactions. If they were to act fraudulently, the integrity of their rollup would be compromised, potentially leading to the transfer of the auction to another L2.

Threshold Encryption Committee

We will now discuss the threshold encryption committee approach:

  1. Prior to the proposer's slot, both proposers and builders must register on-chain in order to participate in the process.
    • As part of this process, builders must deposit a specified amount of stake.
  2. The threshold encryption committee generates an encryption key and sends it to both the proposer and builder.
  3. Both parties use identity-based encryption to encrypt their data and send it to each other.
  4. Upon receipt of both confirmation messages, the committee sends the identity-based decryption key to the proposer and builder.

Disadvanteges:

  • High latency
  • High complexity

Advantages:

  • Decentralized
  • Neither the committee nor the proposer can access the content of blocks, preventing the theft of the builder's MEV.

Currently, I am leaning towards rollups as the most viable solution for the off-chain commitment process. Given Ethereum's rollup-centric roadmap, there is no need to introduce a new entity for this purpose. Additionally, the built-in spam protection and low likelihood of sequencer collusion due to the incentives for maintaining the integrity of the rollup make it an attractive option.

Last changed by 
 
ogechno
0
174

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