#DappCon22 : Day 2 - MEV-Boost: What Block Building Has In Store For Ethereum, Stephane Gosselin

Transcript

hey everyone um can everyone hear me okay yes awesome um and yeah just feel free to go in and go sit down if you guys um all right I'm gonna do a complete rug pull and change the topic of the talk so I put these slides together this morning because I thought the topic was much more interesting than talking about that boost again I've given a lot of different podcasts over the course of the last month about who essentially what the implications for it so I want to try to address the topic that's like a little bit more Cutting Edge topical and sort of explore these with these ideas um I'm gonna present a few slides and then

um I think we can get some mics around and do a bit of q a and answer some questions um yeah these are sort of platform ideas okay so order flow has a solution um so one of the things that uh maybe these sort of brains to uh logginess this idea of an Med Supply Chain um and while probably actually it's going to show up hands on this how many of you are familiar with the concept of the mpb supply chain just put your hand up okay all right all right a good a good group then I'll I'll cover it quickly so before flashbots existed we sort of had a a mental model where users would interact with wallets wallets with send

transaction to a transaction pool and then the transaction pool would make its way to a minor as a minor as an equivalent transactions into a block when flashbots came around then we sort of introduced this additional rule which is of a Searcher right and so for the last couple years uh or so um users sent transaction to a wallet well it sends it to the transaction pool it's sort of picked up by a Searcher and then submitted to a builder validator that's integrated which is called a minor and now with the merge that's coming up this week we're sort of separating Alex field Builders validator role and that's the the sort of new change that energy boost has been appearing

however um one of the concerns that people have about uh not a goose about the introduction of this new Builder role is that it has the potential to become centralized right so it's a centralized sort of specialized entity that's aggregating a bunch of different transactions a bunch of different bundles and trying to produce a Blog and one of the vectors by which they can try to become centralized is through capturing exclusive order flow um so John chargono sort of created this this graphic and he has a nice post also a Twitter thread you guys so go check it out that explores the idea of why order flow can lead to centralization

um so what you do is as a block Builder you show up to in a mask or some other wallet and you say Hey you can give me your transaction flow I'm going to only do back running to it so I won't do any predatory Nev um and it's going to give you some money they can then monetize your order flow and you know all of a sudden you have a business model um so payment Florida flow um and exchange what I want as a block Builders I want exclusivity so I want to be the only person that has access to these transactions this gives me an edge right because I'm competing against all the other block Builders and getting the blocks included on chain and now I have all of a sudden all these transactions are valuable that no one else has so I'm

able to increase the total value of my block relative to the value of the block of the competition all right so high value build blocks um what does this allow you to do well it allows me to consistently pay more for the blog space I'm bidding as all these other block builders for the block space I'm bidding for um for the validators to accept my block over anyone else's blog and if I have a more valuable block I need a little bit more all right so now I'm consistently winning more of the block space what can I then do well then I can justify and say hey like I'm winning the majority of the block space you should continue sending more transactions to me because I'm able to give you better rates for it and so the loop continues so this is sort of the exclusive order flow problem

um that uh that is starting to be discussed here um all right so where do we go from here I'm going to posit that exclusive order flow is not actually a problem and I'm going to pause it that there's a sort of market dynamics and economic reasons why the problem will go away uh on itself and this is all through looking at what order flow systems look like um so I'm sort of defining this new term order flow systems out of nowhere so I'll provide a good context on what I identified the transaction pool is an order flow system it's a Curative here decentralized Order flow transparent system that like doesn't provide any

privacy guarantees but has good uh censorship resistance and uh and time protection here you sign a transaction that commits to pay a certain amount of gas if it gets included on a chain it gets propagated in this pure Network lands on the other side and then gets included object um right okay what is exclusive water flow well that's also an order flow system it's saying I just get my transaction over to a builder or Searcher and it's the most centralized sort of version of an organ as a single counterpartier but there's a whole design space of other order flow systems that you can use for routing these transaction to multiple different types of users and so

the design space here is like fairly novel and fairly of research but it's one that's likely to evolve a lot over the course in the next year um so how do we categorize and think about the design of a motor flow system and how do we think about comparing two different order flow systems with regards to each other which one is going to win I'm going to provide a few thoughts on this here um so the the starting point of designing an order flow system is the idea that order full has value you know that the order flow has value but you kind of don't know how much right you don't know how much it has so one of the first things that you need to try to figure out how to do is measure the value of the order flow and the system itself should be able to do this the

second thing that the Overflow system should be able to do is capture the value of the Overflow I mean what's the point of an order flow system that just delivers all the value to to the block Builders and the Searchers right like really what you want from an order flow system is something that's able to capture some of that value and return it to either the order flow originator or the user that generated that value um and so the third problem is to attribute the value of the order flow how much of that value should go back to the user how much of it is attributable to the activity that the individual user took versus a sort of emergent out of the fact that like there's this aggregate order flow that exists um so I would posit that a good order flow system needs to be the best at all

three of these things if it wants to win um and we can sort of look at okay well how does the public transaction pool do on this well it kind of like fails the first one uh it kind of fails the second one and it kind of fills the third one as well so you know the the public transaction pool is not great order flow system from the perspective of the economics of it um but uh we're not stuck with the transaction pull forever there are alternatives um so I'll deliver a few insights I think that are useful when we start to think about uh order flow systems what are good overflow systems and where it's likely to be to be going um the first one is that optimal price

Discovery is determined by open markets so if I posit that the optimal overflow system is going to be the one that's the best at measuring the value of the order flow and that the optimal price Discovery mechanism is an Open Marketplace then the conclusion is that any system in order to win will need to be decentralized and permissionless otherwise it just won't be able to price the the order flow accurately and and most efficiently an exclusive order flow Market cannot compete with a purely a completely decentralized and permissionless one I think this is like the most important key takeaway here in the next year we're going to see so

many different order flow systems be developed some of them that are more closed more permission using white list some of them that are going to be more open more permissionless with lower barriers to entry and the permissionless one are always going to out-compete the the permission ones all right Insight number two Mev is equivalent to gas price okay this is kind of obvious when you think about it a lot but on the surface maybe it is not obvious um because the corollary is that Mev minimization is actually equivalent to gas price minimization um so what do I mean by this Mev can sort of be thought of as an implicit cost that the user is is sort of incurring when submitting a

transaction right when a user puts a trade on uniswap and and puts a high slippage it could put a really high slippage and pay zero gas price and still get the transaction included right because it's paying someone else to do the conversion from slippage into gas price for the miner to then include it in the chain so my claim is that that means that these two are completely equivalent right I can set a trade with zero slippage or even positive slippage and be completely out of the market right like I could set a trade that um that is is way uh overpriced for for what any Market maker would be willing to pay but if my gas price is high enough someone will do the conversion of getting the transaction included on

chain receiving the gas price then buying and fulfilling the trade at whatever price it was so Mev and gas price are isomorphic they are equivalent um and the problem of protecting users of minimizing the Mev is also one of minimizing gas price I'm getting the the hand up what does that mean okay okay okay I'm gonna get to the questions after I'm gonna deliver the insights first and then we can do a rounded question go back to them [Music] um okay Insight number three users have a Time preference uh time price preference curve so a user will sort of think about okay I'm exposing some amount of price with my uh some I have to incur some

amount of cost to get my transaction included right and I think users have sort of been put into this mindset that if they increase the gas price that they're paying they're going to get prioritized in execution and they're going to be included faster um so there's this trade-off here between the price and the time of execution that can actually be thought of also in the context of Mev if I expose more Mev in my transaction I'm able to get included faster right if my transaction has more slippage I'm going to be able to get included faster but this also is sort of a very rough metric for how to define um uh this preference curve right like when a user defines just a single gas price for a transaction they're not defining their curve they're defining a single point in the curve instead of a

dynamic preference that changes depending on the state of the market so what you would rather want is to have some kind of system that allows for the user to define a more granular curve of okay well if I get it included in the next block I want to pay this price the block after that I'll pay a little bit less or maybe a little bit more you want the user to be able to Define this this curve um and yeah in particular users are willing to compromise on price optimality in order to get reliable execution and really the reliable execution part of it I think is one that a lot of the non-transaction pool and somewhat permissioned order flow systems are missing on it's very difficult to give reliable execution if you don't factor in this time preference time time price

preference curve all right Insight number four uh gas prices can be negative um this is kind of like uh okay well how does it work right like we need to compensate the miners for for including the transaction but once you factor in Mev right really what miners are getting they're getting an Mev a hidden me V Value Plus gas price so if the Mev value is high enough the gas price can be negative and you can actually pay your user to get the transactions included you don't need like complicated systems that like have outside bidding you just need to have these these new transaction type that are allowed to be negative so what's the solution um well I kind of hinted at it at the beginning with the the escalator so there's this concept of the fee

escalator was talked a lot about a little bit over a year ago around the London hard Fork um and it's the idea that like users don't really know how to estimate the amount that they're willing to pay for um for the blog space that they're consuming um and there's a benefit to introducing new transaction types to allow users to start with a very negative gas price they don't know how much Mev they're exposing they don't know what's the value of their transaction to The Miner so you start very negative and then over time you escalate the fee so that's the the users willing to expose a little bit more Mev or spend a little bit more on gas fees and gradually at some point some block Builders some Searcher will

be willing to take the other side of that will be willing to take the transaction include it in a block the important part here is that it essentially transform paying for gas price from a user perspective into a Dutch auction right like you start at a very unattractive price and you increase it until the price becomes attractive for the counterparty to take it you can do this at the transaction level for every single user transaction it protects the user from Mev it makes sure that they expose the least amount of Mev possible by tweaking this gas price value and it also allows it to be completely permissionless because all of a sudden now you can introduce these transaction types to the public transaction pool and have a sort of permissionless bidding on top of of those transactions

um okay that's it questions [Applause] so uh you're at you you're Insight number two about how Mev is equivalent to gas price this equivalent sounds like the old sort of auction modeling for gas prices since EIP 1559 I feel like this doesn't work this statement it still does um so something that's interesting about 1559 and base fees is they sort of don't factor into any Mev uh calculation they're

um they're like a sunk cost they're like a tax that's exposed imposed by token holders and of a network on using their currency for the network so when you make when you say this you don't refer to the Basie but the the tip correct yeah so so the base speed is just like attacks that gets like added to all this so like the Mev plus gas price that's paid needs to be at least as high as the base fee plus some tip for the block space inclusion the um the base fee is like just like it's a tax for using the system that that needs to get paid for somewhere um and it gets paid from yeah the sum of these two thanks for clarifying yeah any other questions so you made the statement that uh you

believe that basically like we won't have private order flow and my understanding is that most LPS in traditional markets the reason that they uh bid order flows because they want to basically avoid toxic flow which is saying that basically if I have a better view of the price then I can you know exploit that and make this spread so do you think that by making this Ducks Dutch auction change that then uh whatever price that is that's basically going to have to be like all LPS will basically uh they have to be profitable right so that they won't include in a block um until you know your your Dutch auction has basically like reached that

same equilibrium if that makes sense um so is it actually better for the user or are you just uh reaching the same point of stasis where um everyone is you know happy but they're still compromising what's up I'll reset your question because it's a great question I think you're on the right inside um so so the question is kind of if I can reframe it as okay well this is all nice and well that you have this fee escalator but is this really the optimal price Discovery given that market makers are willing to bid for non-toxic flow right um and if all the flow is sort of homogeneous and going through this public transaction pool you're losing that information value and so isn't like therefore are they like not going to be

willing to pay as much um and I think that is probably the case so I don't think that the fee escalator is the full solution I think that it requires still some mechanism to capture that value and I would put this into the um uh the measuring the value of the order flow so as soon as you publish transaction publicly right you're exposing information value that actually the information value is very difficult to attribute right so when you think about toxic floor versus non-toxic flow it's not really at the transaction level right like I can auction off a single transaction and it'll be like okay well this kind of seems like a regular trade but then if I add the metadata that says like the source of origin then I'll say oh well this is definitely a bad trade

it's like coming from wintermute or whatever right so um so so there's this like problem around uh having these like public markets for this that uh that cause uh that caused the issue though you I think the fallacy that people will fall into is that uh Public Market is going to be equivalated with um with uh with permissionless markets so I think you can have permissionless markets that are decentralized but maintain the Privacy um and that's probably going to be you know the optimal solution to to these three points um here um I've heard this before but what do

you think uh kind of like the switch to proof of stake will do like even like in the early days to I mean because I like I heard the main worrying and like the merge breaking is actually in like crazy Meb and like a very high inefficiencies happening like next few weeks like what's your take on it like like also playing out like over years or months how it's changing yeah so the main the main change uh with the Mev landscape after the merges is this one right is a separation of these two um I think over the next few weeks yeah it'll be crazy and like validators will come to grips with what it means to be running nodes in a network that's live and I don't think anyone's ready for the Mev that's going to take place um probably the faster that validators

adopt might have Boost that like the better better the network will be but we'll sort of have you know the merge also allows us to see something that we haven't seen which is like what does ethereum with a lot of usage look like when you don't have an Outsourcing market for uh for blog space um and so uh if the majority of validators don't adopt this like Outsourcing Marketplace we'll see what you know what games end up playing thankfully there's like you know a Marketplace that allows into Outsource said and eventually it'll stabilize and things will be fine the problems I'm talking about you know with this are are much longer term sort of you know six months to a year plus uh problems um and and the solutions that will happen I'm

not really worried in the in the short to medium term hey I have a question thanks for the the the idea I think it's a very nice Innovative uh solution or approach to to um redistributing and attributing Mev um I was just wondering on your take on how this differs from actually implementing Dutch auction mechanisms into the trading venues themselves like let's say uni swap or whatever amm you're using had this system where you're placing an order that's outside the market the outside the market price and over time it your your slippage tolerance grows and grows and grows until it's eventually fillable and would be filled at this point how is um addressing it and like the EAP or level one layer better than addressing this on the dab

layer um so my theory on this is that this is generic enough to be useful for any type of transaction and you can Implement like a DEX use case or swap use case on top of it while still using the same account abstraction layer um but it does probably require some level of account extraction or some like some tooling to be able to like do it more effectively like yeah the goal the goal is to have some standard new transaction type that's generic enough to support like as broad as possible set of use cases and then Implement like specific use cases swaps and not pivot um obviously yeah swaps is like the biggest use case for this yeah hi thank you for your talk I really

enjoyed it and uh so I want to come back to uh what you said about defining uh the user defining uh the gas price they're willing to pay depending on the market conditions so the defining a curve uh how would you go to about doing that and also how would that fit with uh the Dutch auction Solutions because now you want to define a curve and the attraction just Define just one price so how would that work um I don't know if Dutch auction is the right term but the way I'm thinking about the attraction it is this curve it is this like price curve that's incrementing with time um yeah this is a ux problem I'm not a ux guy uh this is like up to the wallets

and the applications to figure out like how do you define curves where the different curves that are possible how do you like get the user who doesn't know what the hell they're doing to like pick one curve um yeah I don't know this is like yeah this is the the application layer the wallets that are going to have to figure this out I mean I can give some ideas right like you can have like a fast medium slow mode right like we've seen with gas prices in the past uh High protection medium protection low protection or like you know it's kind of like the same thing as defining slippage there there isn't like a a perfect way to do it at the end of the day you need some system that's able to estimate the value of um of the trade right so um one of the actually one of the the

tools I think doesn't exist yet that will likely exist in the future is some simulation service where you can just send a transaction um without having like a signature in it and it just tries to estimate to you what's the me V value of that transaction and that helps you like Define what is the starting point for this this price curve it doesn't I mean it's kind of similar to like an aggregator right like a DEX aggregator where you like submit a trade request and it gives you like the best price um you kind of want the same thing but just for any sort of Mev and then you can use that in your UI in your wallets to start to display like okay this is a starting point for this price curve um and that'll be helpful I think that might be one yeah we've got

time for one more cool thanks um basically the question would be so the model seems to assume that there's a figure stand up I can't see hi yeah all right hey sorry uh the basically the model I think seems to assume that there's a fixed or well-defined value of Mev of each transaction but I think in some cases it might depend on the state and also in other transactions in the in the mempool at the same time does that change anything or is that a problem or not it affects the optimality um so so yeah what we're getting into is like discrete time let's see um yeah it's probably this one still so so what you're what your um what you're

alluding to I think is like yeah what are the discrete time steps in this preference curve relative to like the state of the blockchain relative to like the state of other blockchains of centralized exchanges Etc and what if the prices or like the Mev the state on these other chains uh these other domains changes within a single price step on this curve right like then obviously the user is not able to capture that um but if this price curve the time steps are like granular enough and small enough um then it should uh it should mitigate for any sort of crazy movement on some other domains and like capture like the minimum amount of it um so you know one of the the assumptions that this makes is once a user makes it past a certain point in

the curve right like it's slowly incrementing it can never go back down right it can only be included or like try to cancel or whatever but it doesn't have the ability of like then adapting and then like resetting lower point and then going back up um it's a it's a single price curve all right one more round of applause [Applause]