ogechno

@echno

Joined on Oct 29, 2022

  • 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.
     Like  Bookmark
  • 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
     Like  Bookmark
  • 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.
     Like 1 Bookmark
  • 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.
     Like  Bookmark
  • 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.
     Like  Bookmark
  • As mentioned in the previous dev update, I have been leaning towards using a rollup as a solution for the off-chain commitment. In the past two weeks, I have explored this idea further. While the "rollup-relay" may not be the ultimate solution for solving PBS, I still belive it accomplishes the goal of my project, which is to reduce the trust assumptions in the relay. Additionally, I believe it has better trade-offs than the current solution and could serve as a temporary replacement. The Rollup-Relay 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, I will provide a more detailed explanation of how this process takes place. 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 penalize the builder if they behave improperly. Next, all the builder post their block headers and bids onto a contract deployed on a zk-Rollup. 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 rollup. The builder whose bid was selected by the proposer can now retrieve the signed header and release the block to the network.
     Like  Bookmark
  • 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: 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. Builders send bids and a proof of commitment to the relay. The relay selects the highest bid and forwards the corresponding block header to the proposer.
     Like  Bookmark
  • 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 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. 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.
     Like  Bookmark
  • This is my update for week 3-4. During those two weeks, I iterated on the feedback I received for my last update about the proposal to remove some trust from the relay. Furthermore, I worked on my project proposal. Feedback The main feedback I received was that the builder does not need to be a validator. This is because the builder could just stake X amount of ETH in a smart contract and we could still have these slashing mechanisms. Benefits include a barrier to entry of potentially less than 32 ETH and the elimination of the obligations associated with taking part in the consensus protocol. Furthermore, the EigenLayer hasn't been released, and if we had used it, we would have run into the principal agent problem. Consequently, the consensus protocol's security would be weakened. We do not have this issue while utilizing an own staking contract. However, this also makes it simpler for builders to create new identities, which is problematic for anti-spam systems that are meant to safeguard the proposers. The second feedback was that builders could grief proposers by submitting invalid blocks. This can be prevented if we assume that 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 his block which signals that it is not an invalid block. Because if it was, he wouldn't be able to call this function. The third feedback was that by signing the block through the proposer but failing to deliver it to the builder in time, proposers could grief builders. Barnabe suggested, setting up a committee to determine if a proposer's header was received on time by the builder. Next steps
     Like  Bookmark
  • This project attemts to identify and specify a mechanism to reduce the required trust in the PBS relay. Motivation Currently, relays serve as an intermediary between the builders and mev-boost, while the proposer operates mev-boost. However, the relay serves as more than just a proxy for the proposer and builder; it also chooses the highest offer from among all builders, verifies the builders' blocks, and releases the block to the network once the auction is complete. Because of this, the relay must be trusted by both the builder and the proposer. The proposer must trust the relay to release the block to the network on time, and the builder is trusting the relay not to steal their mev opportunities. Since Ethereum is designed to be a decentralized, trustless system, this creates a bottleneck for these properties. Project description To decrease the necessary trust in the PBS relay, a mechanism must be identified and specified. In order to produce a specification, we focus on finding such a mechanism or adopt an approach currently proposed by other entities. If there is still time after the approach has been specified, we will attempt to prototype the specification. Specification The current approach, which will be refined regularly, is explained here.
     Like  Bookmark
  • This document outlines an approach that aims to remove some of the trust in relays that is required from builders and proposers. This note contains additional background details. Regular updates will be made to this page. Discovery mechanism There are several ways the discovery mechanism can function. These approaches might coexist since there are various validators with various incentives. 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
     Like  Bookmark
  • 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) The builder with the highest bid sends the block header to the proposer. The proposer signs the block header. 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.
     Like  Bookmark
  • This is my first update for the Ethereum Protocol Fellowship - cohort three. In the first week I was exploring possible project ideas. My previous experience with Ethereum is mainly related to the EVM and Ethereums security. But since this is a learning opportunity I wanted to do something out of my comfort zone. Since one of the biggest concerns I have with Ethereum right now is base layer censorship and builder centralization due to economies of scaling. Therefore I wanted to explore ideas in those directions. I discussed some ideas with Alex Stokes. Those ideas include: Partial Block Auctions to constrain the power the builder currently has, trust-less searcher to builder connection and a protocol for a decentralized builder. Partial Block Auctions: Partial Block Auctions wouldn't directly solve the problem of builder centralization but would mitigate some of the concerns with a centralized builder censoring blocks This would result in builders only partially deciding what goes into a block and where One example would be an inclusion list which is a list of transaction that the proposer demands from the block builder to be included in the block How much can we constrain builders without bringing back heavy burdens to proposers? The project idea would be to create a specification of a fitting approach and prototype it in e.g. mev-boost
     Like  Bookmark