Is multi-block MEV a thing? Insights from 2 years of MEV Boost Data by Pascal Stichler | Devcon SEA

[Music] see that already Friday morning quite a few people make it to the me stage seems like there are quite some M Ultras um looking forward to it um I'll be doing quick intro on multiblock M just quick lightning talk um to Dive Right In quick um recap what is multiblock M actually multiblock m means uh one block Builder has multiple slots in a row and can extract more M um by having the slots in the sequence than by yeah having individual slots this arises due to the fact that me accurs um exponentially um if we look at the data we can see that over time it slightly exponentially grows um for example one strategy could be to manipulate prices a block Builder can for example buy a certain token in slot one then only include buy transactions on the one side and not include the sell transactions and then in his last slot captur me of selling the token first um this is one potential strategy of manip manipulating the price there other ways to do it uh we can do liquidation attacks of also um forcing the price to go below a certain threshold and thereby liquidating assets and capturing the liquidation gains um so I won't go too deep into it but there um yeah a whole set of strategies um what did we do we looked at data since the merge um 4.3 million data points of MEF Boost payments um and did on the other side a mon Carlo simulation of daily market shares of Builders to see what would be like statistically um yeah no distribution of multi slots um to have a Baseline and yeah based on this what we saw is interestingly we have less multi-lot sequences than expected um we see especially on the chart on the right we see the blue blue bars being the expected distribution of multi slots um we see less of them um also yeah interestingly what we saw however longest sequence was 25 slots in a row by the same Builder beer build and for the same validator and same Builder it was 11 slots in a row March of this year so what we see just by yeah statistic there are long sequences which would allow for multislot M strategies um so in the next step what we looked at was the payments the MEF Boost payments for longer sequences so this is basically for sequence of length five for example what was the average payment uh what we see interestingly it increases for longer sequences so it seems to be there is a value in longer sequences um however why this is the case so far we can only speculate one hypothesis could be that MEF boost it's a continuous first price auction so it basically from an economics perspective works like a second price auction from the value where we end and so it could be actually driven not by the highest bidder but by the second highest bidder who has an increasing value for the blocks based on private autoflow M captured in private order flow um so it could be the case that actually the intrinsic value of the second um highest bid increases and that drives uh yeah this increasing values um so what we also did is looked for the payments per slot so in longer sequences what was the bid for um yeah the slot at the specific uh Point um there we saw so far there is an increase but only a very very slight increase so this uh yeah led us to the conclusion that so far we don't see dedicated multi-lot strategies um we also looked at the top 10 Builders to see if there's a certain pattern for the top 10 Builders if there's there are builders that are deviating from the mean uh we didn't see any yeah very um yeah outstanding data okay Cas a few builders that have more slots more multi-lot sequences or that are particularly strongly correlating with um the same validators um however from our perspective that's probably based on things like latency and collocation and not based on other types of uh yeah strategies that are run um last thing that we looked at was autocorrelation of MEF Boost payments to see if we can use historical MEF Boost payments to predict future ones um there what we see is based on different correlation metrics um that it strongly goes down after the second or third slot so it means there's a very very low yeah autocorrelation so a low predictability um so we don't have times of high or low me but there's a fast reversion to the mean of all um yes there was the quick run through um if the Topic in general is interesting there's a post on E research I'm going into the details also a link to the to the Jupiter notebook with all the data and I'm also doing a workshop today in the afternoon on execution tickets agent-based simulation of execution tickets so whoever is interested feel free to join otherwise happy to take on questions I think I have around one and a half minutes or one minute left for questions feel free to scan the QR code or ask them directly [Applause] so we already have two questions we want more you can just scan the QR code and put it and uh one quick question Pascal like where is your talk so that the audience is aware of the room that the talk is in uh the talk is in classroom B so just down a yeah so I'll read out the question for those who are joining virtually um have you studied arbitri time boost do you think Dow should be capturing meev Revenue um to be honest I haven't looked deeply into arbitrum time boost I think there people in the audience that have much more knowledge of this so um I can't really give there an in depth take um unlike proposer Builder is not guaranteed to win PBS auction multiple times in a row would you advocate for a random proposer allocation which does not allow the same proposer in a row in general I think it makes sense um however I think there is um so I mean that's a bit of a Outlook already on the simulation what we saw is that the secondary Market um usually reduces decentralization um which means there should be some component of just in time auction um however I think with the current MEF boost setup what we have is the problem of inflight variation um so I think a combination of both could be interesting um but I think some component of randomization does make sense to prevent multislot M strategies thank you so much that was a great talk and a good start to the day uh to me D I like the name that you gave this is me room you know yeah thank you [Music] for [Music] um so we have our next talk coming up really quick with Felix lold um the talk is on do we really even need PBS and how we can solve uh me at the app versus infrastructure layer uh this is going to be a full day of uh hardcore research so really glad to see all of you here and engaging and asking questions uh make sure to scan the QR code if you have any questions for our speaker and with no further Ado let's welcome Felix on stage [Music] hi I will have to speedrun this talk so if you want a more relaxed version of it you can scan the QR code or go to Tiny url.com Decon uh where I gave this talk in a 25 minute version let's start with the problem that I have with proposer Builder separation why I think it's not a good idea there are three main arguments in my point of view first the trust and centralization um problems that it brings onto the ethereum base layer for all types of transactions not even the ones that actually contain me ethereum today is proud to have more than one million validators um proposing and validating the chain and you know we are one of the most decentralized chains or the most decentralized chains in the world but at the end of the day if you look at it there's only two very well-known entities beaver and Titan that propose more than 90% of the Block's contents and how valuable is it really to have a vast validator Network when the most important part the content of the block is decided by two entities moreover PBS adds this trusted component to the supply chain the Mev relay that Builders have to put their faith in and even if we trust the research that's ongoing that's trying to propose ways to enshrine the Mev relay into the base layer and get rid of that trusted component I think there is a couple of issues with that first it adds complexity to the core protocol one thing that we're trying to avoid and second of all it's not even clear that if implemented it will find a adoption because meev is a very latency intense game and any decentralized peer-to-peer gossip based solution is always going to have latency disadvantages and also feature disparity um Builders today want to have bid cancellation as an example they want to make a bid and then cancel it if they if they change their mind and such a feature is simply not possible in an enshrined PBS version because once you gossip the message you cannot take it back and let's not forget that PBS actually maximizes the harm that is inflicted on users in order to win the PBS s auction you have to create the block that is extracting the most values value via sandwiching or other types of M attack and thus we've created a system that really favors the worst possible outcome for the user okay enough of a rant what do we do about it first let's maybe St take a step back and try to find out why does me exist in the first place and here really the fundamental reason is that in today's system every token trades at many different prices within the same block here I brought brought you an example block from a couple of days ago in which ethusd trades at least seven different times with seven different prices and so you'll see sexex arbitragers that are able to access for instance the Unis pool at the previous Block's outdated price and then the rest of the block will trade at the new kind of fair equilibrium price you will see Liquidators that are able to get um bad collateral at a fixed liquidation penalty 15 20% below fair market Price and the rest of the block trading at a different price and last but not least you have S s wiers that front runner user to buy a token at Price a the user then priz it at Price B and the sandwichery have one thing in common the same asset trades in the same block at different prices and the reason for this is that we basically took our well very well best known standard first come first served mechanisms that work in traditional continuous time markets and deployed them on blockchain and this was the key mistake ethereum doesn't have Contin time there's only new information being released every 12 seconds and then it's released in one go and The Ordering of the information within the block is up to a unilateral party the proposer to decide how to order things there and so it's unsafe to deploy any kind of mechanism that works on continuous time on a discrete time blockchain so what what's next what what how can we do to fix this well as you might guess we need to come to a point where trading the same asset in the same block should lead to the same execution regardless of trade ordering or put differently we need to get to one price per token per block this design requires to be able to batch trades together so it doesn't work on Raw ethereum transactions instead we need trade Intense or just signed limit orders and batch those together in a multi-dimensional auction which can later be cleared at a single price for details on how this looks I encourage you to look at cow protocol the trading mechanism that powers cow swap which pioneered and implements this mechanism it's processing many billions of dollars in transaction volume every month and is basically proof that this mechanism can work on chain cow protocol provides me protection for all the cases that I mentioned on two slides ago um we protect swappers by having buyers and sellers um that trade the same asset receive the same price regardless of their ordering and we can even match them together in what is known as Coincidence of Once by making amm part of the batch and treating them like swappers LPS no longer trade at outdated prices but instead get the fair new equilibrium clearing price and liquidations are just stop loss orders which you can also add to the total um liquidity pool and make sure that collateral recovery happens at the most efficient and fair price I want to leave you with this number which is a dune query that you can check for yourself that shows that more than 97% of meev today is trading related and that is sandwiches sex sex Arbitrage back running liquidations and those can be vastly reduced if not completely eliminated at the application layer by not using pseudo continuous time mechanisms so I'd like you to join me on my mission to convince this space that we should fix the mechanism rather than making the chain more complex and with that thank you very [Applause] much thanks for that great talk um if any of you have questions you need to scan the QR code and uh ask the questions remotely uh I'm going to read out the question for those joining virtually do you have an estimation of reduction in me if only Dex used is cow yeah so right now cow swap focuses on Swap meev protection um I didn't break the number 97% into swap amm resistance and liquidations um so right now it would probably be you less than 97% but the mechanism itself not the product as it exists today but the mechanism itself would be able to reduce meev by that number that I that I showed um the second the other question is do you think PBS causes centralization or is it correlation I think PBS uh causes centralization um mainly because it's a winner takes all latency game um I wouldn't say it's correlation there's also a reason I couldn't get to that slide because I didn't have enough time for why I think cow protocol or an application specific um auction is not going to cause the same centralization or even if it would not affect kind of all types of transactions so if I want to make a transfer I'm not kind of subject to the censoring that happens today in the in the Builder Market um but yeah for this I would refer to the longer talk yeah um how would you compare C with what sella is doing to fix meev on the application layer while uni swap hooks yeah I would I mean cow is working and out there and live um I think the mechanism is relatively similar um and uh yeah I think that's the the just you can deal with the last question how does cow deal with multiblock me um it it doesn't uh because basically the batch itself has its own um has its own kind of heartbeat its own time and so if you were to try to do multi batch me I think you're running the risk that the whoever solver will win the batch is going to um execute the trade before you so so there's no real incentive for you to to