# 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](https://hackmd.io/@echno/update-6-rollup-relay), there are 3 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. 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. ### How do you prove such a slashable offense happened: 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 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. Optionally, 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. ### Some extra slashing condition, for later 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". ## Availability committee for the off-chain commitment 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 if they misbehave. Next, all the builders send their block headers and bids either to the proposer directly or they get sent to the availability committee. 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 availability committee. The availability committee attests to this message. The builder whose bid was selected by the proposer can now retrieve the signed header and release the block to the network. If something slashable happened, the proposer sends the message with the attestation, which needs to be at least m out of n to the slashing contract as proof, the rest of the slashing is the same as in the rollup-relay. 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 I 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.
Last changed by  
 
ogechno
247

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.

2/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

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
Read more from ogechno
Published on HackMD