aprioriSearching For The Holy Grail: Order Flow Auctions & The Enshrined Builder
IntroductionUpon reflection, my favorite presentations from the MEV workshop at SBC were Vitalik’s distributed builder, which I reference several times in this article, and @0xQuintus warning about the rise of exclusive order flow. The former put forth several new possible iterations that enhance PBS, while the later articulated the negative externalities of exclusive order flow. Both presentations served as an inspiration for this article. In addition this should also be considered a follow ...
aprioriRandom half-baked thoughts on MEV redistribution
Bootstrapping an EcosystemAs time progresses rollups will look more like public goods than they do today. The question of long-term economic sustainability is contingent on the demand for blockspace. Rollups can contribute to this by funding public goods and using governance as a tool to distribute ecosystem funding. Users and developers will want to go where the action and attention is. We have seen this play out in the last economic cycle with the persistence of the bridge, farm & dump rout...
aprioriEndgame: Polygon POS
BackgroundPolygon POS as constructed today and in the context of our current understanding of what an L2 is, is not an L2 or a Stage 0 rollup. While there have been hints at a future transition, there is no public roadmap or known endgame. As a result, here we will speculate about what a Polygon POS to rollup transition could look like. Polygon is uniquely positioned because its core product, Polygon POS can eventually become a Stage 2 rollup while maintaining medium-term flexibility, a notor...
I write about protocol design, intents & MEV related stuff.
aprioriSearching For The Holy Grail: Order Flow Auctions & The Enshrined Builder
IntroductionUpon reflection, my favorite presentations from the MEV workshop at SBC were Vitalik’s distributed builder, which I reference several times in this article, and @0xQuintus warning about the rise of exclusive order flow. The former put forth several new possible iterations that enhance PBS, while the later articulated the negative externalities of exclusive order flow. Both presentations served as an inspiration for this article. In addition this should also be considered a follow ...
aprioriRandom half-baked thoughts on MEV redistribution
Bootstrapping an EcosystemAs time progresses rollups will look more like public goods than they do today. The question of long-term economic sustainability is contingent on the demand for blockspace. Rollups can contribute to this by funding public goods and using governance as a tool to distribute ecosystem funding. Users and developers will want to go where the action and attention is. We have seen this play out in the last economic cycle with the persistence of the bridge, farm & dump rout...
aprioriEndgame: Polygon POS
BackgroundPolygon POS as constructed today and in the context of our current understanding of what an L2 is, is not an L2 or a Stage 0 rollup. While there have been hints at a future transition, there is no public roadmap or known endgame. As a result, here we will speculate about what a Polygon POS to rollup transition could look like. Polygon is uniquely positioned because its core product, Polygon POS can eventually become a Stage 2 rollup while maintaining medium-term flexibility, a notor...
I write about protocol design, intents & MEV related stuff.
Subscribe to apriori
Subscribe to apriori
Share Dialog
Share Dialog
<100 subscribers
<100 subscribers
Agency is the freedom to act (Voltaire’s definition of liberty).
“ How do we bring back the status quo of proof of work style CR where the validators have agency on choosing only builders that are not censoring while maintaining the revenue they can see from MEV optimization. We don’t want validators to choose MEV optimization or censoring. We want them to be at w/e point on that tradeoff point they want to be at. And we want to incubate as many points on this graph as we can…”
~ Phil Daian, Eth Bogota
In this article we will examine the problem statement by reviewing the recent MEV-Boost min-bid upgrade, MEV-Boost + & MEV-Boost ++. Thereafter we will review open questions and draw a few conclusions.
‘The core aspect of Mev-Boost is to ensure that proposers stay decentralized while being able to extract MEV at the best market rate.’
~ Sreeram Kannan, SBC MEV day
Whilst this design helps maintain decentralization of the validator set as any proposer can participate in this open block space market, it does not allow proposers to exercise agency.
Today a proposer can build their own vanilla block using the standard algorithm of their preferred execution client or they can connect to trusted relays that give them access to an off-chain builder market. Builders only construct full blocks. As a result, proposers cannot specify any set of transactions to be included.
Proposers can:
Participate in the MEV-Boost marketplace by accepting the highest bid for their blockspace from any builder (via trusted relays)
Accept bids only from specific builders
Contribute to censorship resistance at the cost of forgoing the MEV they would have captured from a builder’s bid
Another thing to keep in mind is that in the medium term (realistically, 2-8 years? Not sure), MEV-Boost will be replaced by in-protocol PBS, so the structure does not need to last forever, but we can’t assume PBS will come quickly.
~Vitalik on MEV-Boost
IP-PBS (in protocol proposer builder separation) is years away. With Flashbots’ commitment to decentralization they have begun the process of transferring stewardship of MEV-Boost to the broader MEV community. The time is nigh to build out a roadmap with features that get as close to ideal versions of IP-PBS as possible, allowing for valuable analysis, testing, and iteration. This is important because changes like single slot finality and/or a replacement of LMD Ghost in addition to SSLE or full Danksharding are not yet in a solid state.
Therefore, in order to provide maximum flexibility for future protocol changes and not lock into one solution now, delegating the development of PBS in the near-term to Mev-Boost or other out of protocol middleware is arguably the best path forward. Rollups provide salient examples where this delegation is showing fruits and freeing up core developers to press ahead with the broader roadmap.
MEV-Boost is building on top of a core feature of Ethereum: Slashing. If a given block proposer signs two block headers for the same slot, the proposer will be slashed (equivocation). The Mev-Boost architecture was built to leverage this slashing condition, the root of trust. This prevents MEV stealing and explains why Mev-Boost is not more flexible with block building.
A first step is to return agency to the block proposer with MEV-Boost. The new flag min-bid allows for just this. Now, block proposer’s can express a minimum builder bid they are willing to consider from the blockspace market. If the MEV opportunity < min-bid, the Proposer will build their block locally using their Execution Client. Previously this had not been possible.
./mev-boost
-min-bid <x> /
-relay $YOUR_RELAY_CHOICE_A /
-relay $YOUR_RELAY_CHOICE_B /
-relay $YOUR_RELAY_CHOICE_C
The min-bid flag allows you to create a minimum bid value. <x> is the minimum bid value the block proposer is willing to accept for their blockspace. All connected relays will only deliver builder bids if the minimum bid is met.
As you can see from the above chart provided by Flashbots, this is a significant step in the right direction that allows proposers to have more granularity in the choice between economic incentives vs. values maxing. By sacrificing a minimal amount of ETH per block, ideally 0.10 ETH, the network can ensure non-OFAC tx inclusion rate after 1 block is >90%.
The article the chart is taken from argues that a min-bid of 0.05 ETH is a reasonable starting point. For example the 1 block inclusion probability for non-OFAC compatible transactions would increase from the current 28% to ~ 53%. Thus, censorship resistance is increased by each proposer making a small sacrifice.
Though, min-bid still requires the block proposer to trust a relay to participate in MEV-Boost.
MEV-Boost+ is an iteration on MEV-Boost which uses the Eigen Layer, a meta-slashing protocol on Ethereum, to return agency back to block proposers allowing them to partition an execution block into a builder_part and proposer_part. The proposal was initially put forth by Sreeram Kannan in writing here & via presentation at MEV workshop at SBC.
In MEV-Boost + there is the notion of a prefix & suffix; in a block there is a portion of the block created by the builder and another portion which the proposer creates. The Proposer receives a bid from a builder, then signs off on the builder_part; a special message that can be enforced by slashing on the Eigen Layer. The Message enforces a commitment by the proposer to include the builder portion of the block. The proposer now has freedom to include any transaction they want in the suffix.
The block proposer can also commit to a back up block. If they don’t propose the builder’s header there is a backup block they will pre-commit to and then propose. The proposer then sends the signed message back to the Relay with a merkle_root and a commitment to B_alt,a back-up block. The relay then returns the builder_part to the proposer who from there can exercise their agency by creating the suffix. The proposer then proposes the block and broadcasts it out over the p2p network.
How much of the block should the builder_part take and how much should the proposer_part take? The Builder can build any size they want. The proposer can add on any arbitrary part with the remaining available space. The builder will not fill the block every-time due to EIP-1559.
Hence, proposers can exercise agency to include their own transactions not included by the Builder. This ensures any valid transaction can be included and boosts the censorship resistant properties of the Ethereum Protocol.
With Both MEV-Boost+ & the new min-bid preference, there is still a trusted relay. Is there anything that can be done within this framework of MEV-Boost + to make the relay trust minimized? Yes, enter MEV-Boost++.
The builder takes their builder_part of the block and creates a secret shared version of the block then splits it into many chunks and encodes it. No one chunk exposes information about this block. The builder then sends the chunks to a decentralized escrow which is comprised of EigenDA nodes. The Builder sends one chunk to each of these nodes.
Each node sends back a signature saying they received a share corresponding to this commitment. The signatures flow back to the builder who signs off on commitment attesting to a certificate from EigenDA that certifies the builder’s action of dispersing data to EigenDA. The Builder then takes an aggregate signature (BLS?) and sends it to Block Proposer.
The Proposer chooses the highest possible bid which also has certificate from EigenDA. The Proposer then sends a signed message back to EigenDA. Once EigenDA sees the signed message for a specific block header the nodes release the chunks and the block’s secret share. After all the chunks are released the proposer can reconstruct the prefix of the block then add a suffix (as outlined above in MEV-Boost +) and propose it.
The relay is now fragmented into many entities who have to work together to break these cryptographic guarantees underlying the root of trust.
MEV-Boost++ is compatible with expanded user preference. As an example you could have a block with different portions, users could have the choice to send transactions to an off-chain block space market place like today (SUAVE in the future), a threshold encrypted mempool (Shutter), or use the general memory pool for Inclusion List transactions.
The more choices that Alice has, the more agency she can exercise as she now has more ways to express her preferences.
SUAVE as a validium secured by EigenDA? The primary benefit would be leveraging Ethereum’s decentralized network of trust. SUAVE builders could also be comprised of ETH re-stakers allowing for an internally distributed builder. Therefore behavior such as breaking searcher bundles could be attributable and punishable by slashing. Sending blocks full of spam to proposers or attempting to bribe the trust minimized relay could also be punishable. Out of band bribes would still exist, but more accountability enhances the incentive to cooperate.
The subset of SUAVE chain validators (ETH re-stakers) can double up and opt into providing a trust minimized relay for MEV-Boost++. SUAVE chain could also become a rollup with 4844 which will reduce data costs for rollups with a new fee market priced in data_gas making this possibility economically viable. Rollup or not, additional slashing conditions would still be necessary to make SUAVE chain’s interaction with Ethereum block proposers trust minimized.
Returning agency back to the proposer lessens the explicit trade-off between economic incentives vs. values maxing. The min-bid solution is not perfect but it is a solid building block for further iterations.
MEV-Boost++ brings censorship resistance back to the MEV supply chain by making it as trust-minimized as possible without in protocol slashing conditions or FIL. MEV-Boost ++ eliminates the need for a trusted relay. MEV-Boost ++ is forward compatible with SUAVE and/or other block building schemes. Importantly, MEV-Boost++ does not require altering Ethereum’s consensus.
Hence, MEV-Boost ++ provides a medium-term solution for censorship resistance and a logical bridge to IP-PBS.
Are there better choices worth pursuing which solve this issue of proposer agency, eg. Inclusion Lists?
In order for MEV-Boost++ to be effective, a large amount of Ether would need to be re-staked opting into slashing conditions
MEV-Boost ++ entails a threshold committee; what is the cost of corruption?
As postulated by the Eigen Layer proposal, latency does not appear to be an issue
Slashing oracle for Beacon Chain?
Thank you to the authors of all the cited slides, articles, docs, research, tweets & videos. Thank you to @vote_escrow for reviewing the draft and providing feedback.
Agency is the freedom to act (Voltaire’s definition of liberty).
“ How do we bring back the status quo of proof of work style CR where the validators have agency on choosing only builders that are not censoring while maintaining the revenue they can see from MEV optimization. We don’t want validators to choose MEV optimization or censoring. We want them to be at w/e point on that tradeoff point they want to be at. And we want to incubate as many points on this graph as we can…”
~ Phil Daian, Eth Bogota
In this article we will examine the problem statement by reviewing the recent MEV-Boost min-bid upgrade, MEV-Boost + & MEV-Boost ++. Thereafter we will review open questions and draw a few conclusions.
‘The core aspect of Mev-Boost is to ensure that proposers stay decentralized while being able to extract MEV at the best market rate.’
~ Sreeram Kannan, SBC MEV day
Whilst this design helps maintain decentralization of the validator set as any proposer can participate in this open block space market, it does not allow proposers to exercise agency.
Today a proposer can build their own vanilla block using the standard algorithm of their preferred execution client or they can connect to trusted relays that give them access to an off-chain builder market. Builders only construct full blocks. As a result, proposers cannot specify any set of transactions to be included.
Proposers can:
Participate in the MEV-Boost marketplace by accepting the highest bid for their blockspace from any builder (via trusted relays)
Accept bids only from specific builders
Contribute to censorship resistance at the cost of forgoing the MEV they would have captured from a builder’s bid
Another thing to keep in mind is that in the medium term (realistically, 2-8 years? Not sure), MEV-Boost will be replaced by in-protocol PBS, so the structure does not need to last forever, but we can’t assume PBS will come quickly.
~Vitalik on MEV-Boost
IP-PBS (in protocol proposer builder separation) is years away. With Flashbots’ commitment to decentralization they have begun the process of transferring stewardship of MEV-Boost to the broader MEV community. The time is nigh to build out a roadmap with features that get as close to ideal versions of IP-PBS as possible, allowing for valuable analysis, testing, and iteration. This is important because changes like single slot finality and/or a replacement of LMD Ghost in addition to SSLE or full Danksharding are not yet in a solid state.
Therefore, in order to provide maximum flexibility for future protocol changes and not lock into one solution now, delegating the development of PBS in the near-term to Mev-Boost or other out of protocol middleware is arguably the best path forward. Rollups provide salient examples where this delegation is showing fruits and freeing up core developers to press ahead with the broader roadmap.
MEV-Boost is building on top of a core feature of Ethereum: Slashing. If a given block proposer signs two block headers for the same slot, the proposer will be slashed (equivocation). The Mev-Boost architecture was built to leverage this slashing condition, the root of trust. This prevents MEV stealing and explains why Mev-Boost is not more flexible with block building.
A first step is to return agency to the block proposer with MEV-Boost. The new flag min-bid allows for just this. Now, block proposer’s can express a minimum builder bid they are willing to consider from the blockspace market. If the MEV opportunity < min-bid, the Proposer will build their block locally using their Execution Client. Previously this had not been possible.
./mev-boost
-min-bid <x> /
-relay $YOUR_RELAY_CHOICE_A /
-relay $YOUR_RELAY_CHOICE_B /
-relay $YOUR_RELAY_CHOICE_C
The min-bid flag allows you to create a minimum bid value. <x> is the minimum bid value the block proposer is willing to accept for their blockspace. All connected relays will only deliver builder bids if the minimum bid is met.
As you can see from the above chart provided by Flashbots, this is a significant step in the right direction that allows proposers to have more granularity in the choice between economic incentives vs. values maxing. By sacrificing a minimal amount of ETH per block, ideally 0.10 ETH, the network can ensure non-OFAC tx inclusion rate after 1 block is >90%.
The article the chart is taken from argues that a min-bid of 0.05 ETH is a reasonable starting point. For example the 1 block inclusion probability for non-OFAC compatible transactions would increase from the current 28% to ~ 53%. Thus, censorship resistance is increased by each proposer making a small sacrifice.
Though, min-bid still requires the block proposer to trust a relay to participate in MEV-Boost.
MEV-Boost+ is an iteration on MEV-Boost which uses the Eigen Layer, a meta-slashing protocol on Ethereum, to return agency back to block proposers allowing them to partition an execution block into a builder_part and proposer_part. The proposal was initially put forth by Sreeram Kannan in writing here & via presentation at MEV workshop at SBC.
In MEV-Boost + there is the notion of a prefix & suffix; in a block there is a portion of the block created by the builder and another portion which the proposer creates. The Proposer receives a bid from a builder, then signs off on the builder_part; a special message that can be enforced by slashing on the Eigen Layer. The Message enforces a commitment by the proposer to include the builder portion of the block. The proposer now has freedom to include any transaction they want in the suffix.
The block proposer can also commit to a back up block. If they don’t propose the builder’s header there is a backup block they will pre-commit to and then propose. The proposer then sends the signed message back to the Relay with a merkle_root and a commitment to B_alt,a back-up block. The relay then returns the builder_part to the proposer who from there can exercise their agency by creating the suffix. The proposer then proposes the block and broadcasts it out over the p2p network.
How much of the block should the builder_part take and how much should the proposer_part take? The Builder can build any size they want. The proposer can add on any arbitrary part with the remaining available space. The builder will not fill the block every-time due to EIP-1559.
Hence, proposers can exercise agency to include their own transactions not included by the Builder. This ensures any valid transaction can be included and boosts the censorship resistant properties of the Ethereum Protocol.
With Both MEV-Boost+ & the new min-bid preference, there is still a trusted relay. Is there anything that can be done within this framework of MEV-Boost + to make the relay trust minimized? Yes, enter MEV-Boost++.
The builder takes their builder_part of the block and creates a secret shared version of the block then splits it into many chunks and encodes it. No one chunk exposes information about this block. The builder then sends the chunks to a decentralized escrow which is comprised of EigenDA nodes. The Builder sends one chunk to each of these nodes.
Each node sends back a signature saying they received a share corresponding to this commitment. The signatures flow back to the builder who signs off on commitment attesting to a certificate from EigenDA that certifies the builder’s action of dispersing data to EigenDA. The Builder then takes an aggregate signature (BLS?) and sends it to Block Proposer.
The Proposer chooses the highest possible bid which also has certificate from EigenDA. The Proposer then sends a signed message back to EigenDA. Once EigenDA sees the signed message for a specific block header the nodes release the chunks and the block’s secret share. After all the chunks are released the proposer can reconstruct the prefix of the block then add a suffix (as outlined above in MEV-Boost +) and propose it.
The relay is now fragmented into many entities who have to work together to break these cryptographic guarantees underlying the root of trust.
MEV-Boost++ is compatible with expanded user preference. As an example you could have a block with different portions, users could have the choice to send transactions to an off-chain block space market place like today (SUAVE in the future), a threshold encrypted mempool (Shutter), or use the general memory pool for Inclusion List transactions.
The more choices that Alice has, the more agency she can exercise as she now has more ways to express her preferences.
SUAVE as a validium secured by EigenDA? The primary benefit would be leveraging Ethereum’s decentralized network of trust. SUAVE builders could also be comprised of ETH re-stakers allowing for an internally distributed builder. Therefore behavior such as breaking searcher bundles could be attributable and punishable by slashing. Sending blocks full of spam to proposers or attempting to bribe the trust minimized relay could also be punishable. Out of band bribes would still exist, but more accountability enhances the incentive to cooperate.
The subset of SUAVE chain validators (ETH re-stakers) can double up and opt into providing a trust minimized relay for MEV-Boost++. SUAVE chain could also become a rollup with 4844 which will reduce data costs for rollups with a new fee market priced in data_gas making this possibility economically viable. Rollup or not, additional slashing conditions would still be necessary to make SUAVE chain’s interaction with Ethereum block proposers trust minimized.
Returning agency back to the proposer lessens the explicit trade-off between economic incentives vs. values maxing. The min-bid solution is not perfect but it is a solid building block for further iterations.
MEV-Boost++ brings censorship resistance back to the MEV supply chain by making it as trust-minimized as possible without in protocol slashing conditions or FIL. MEV-Boost ++ eliminates the need for a trusted relay. MEV-Boost ++ is forward compatible with SUAVE and/or other block building schemes. Importantly, MEV-Boost++ does not require altering Ethereum’s consensus.
Hence, MEV-Boost ++ provides a medium-term solution for censorship resistance and a logical bridge to IP-PBS.
Are there better choices worth pursuing which solve this issue of proposer agency, eg. Inclusion Lists?
In order for MEV-Boost++ to be effective, a large amount of Ether would need to be re-staked opting into slashing conditions
MEV-Boost ++ entails a threshold committee; what is the cost of corruption?
As postulated by the Eigen Layer proposal, latency does not appear to be an issue
Slashing oracle for Beacon Chain?
Thank you to the authors of all the cited slides, articles, docs, research, tweets & videos. Thank you to @vote_escrow for reviewing the draft and providing feedback.
No activity yet