Understanding MEV - with Georgios Konstantopoulos, Dan Robinson, and Hasu

Transcript

welcome to uncommon core where we explore the big ideas in crypto from first principles today i brought on dan robinson and georges constanticulos who are both research partners at paradigm together we explore the topic of mev or minor extractable value blockchains like ethereum have this dirty little secret that while in most regards they are very decentralized the ordering of transactions within a single block is actually completely in the hands of a single miner they can insert their own transactions rearrange those of users or even censor them completely mev describes how much value miner can extract from users

and other miners by using these powers to their advantage and if you've never looked into mev before i think you'll be both shocked and fascinated by the complexity and sophistication of the war that is raging inside ethereum's memory pool enjoy dan and georges thanks so much for coming on the show thanks for having us on thanks for having us dan could you start by introducing yourself to our audience i'm dan robinson i'm a research partner at paradigm um and in past lives i was a lawyer and then a crypto protocol engineer hi i'm georgios consandopoulos i used to be

a consultant in encrypto and now i'm also a research partner in paradigm i brought you to here to talk about one of my favorite topics which is mempool games and mev and front running in ethereum so to start this conversation of most people have used wallet like metamask before to send a transaction on ethereum and they roughly understand how the user experience works from their perspective right so you create a transaction you set a free rate and then you publish it to the network and if you selected a high enough fee then most of the time you should hear familiar bing a few

seconds later and your transaction has been confirmed but i feel like this is one of the cases where behind a simple user experience there's actually a lot of complexity hidden that most of the time the user doesn't need to be aware of but in some cases they do so so what actually happens between the user broadcasting a transaction and the moment it confirms on the blockchain so after you have broadcast your signed transaction it gets sent to the node which your client was connected to and after validating that transaction that node

sends it over its peer-to-peer network to its rest of its peers and then these peers proceed to send it over to the next nodes and so on and so forth and this transaction then gets stored in an in-memory database which we call the memory pool and the memory pool can be thought of as a as a bucket of transactions which still have not been confirmed but will be chosen by the miners for confirmation in one of the next blocks and typically miners choose these transactions in order to maximize their profits so they would usually take the top let's

say 100 transactions sorted by the product of the gas that the transaction will pay and the gas price of the transaction and afterwards the transaction will get mined and so on so this memory pool or mempool in short is actually transparent for anyone to see so is there anything that other people can do with the information yeah so i think there's there's a few ways that people who are watching the uh the mempool can uh exploit this knowledge of other transactions um and or the ability to get transactions in before others to to profit so one sort of typical such example is when somebody

participates in a an arbitrage on unit swap basically when the price changes the first person to do a trade on the uniswap pair right after the price of that asset changes gets arbitrage profits and that's what i would call something like benign mev because it's something that somebody's going to get that profit and it doesn't depend on knowing anything about any other uh transactions in the mempool it just depends on being the first one to take advantage of it of a change in the world's state uh but then obviously strategies get a lot more um complex and also a lot more uh potentially you you could call them malicious so one would be another uni-swap example is if somebody front runs a transaction and so that would be if you see a

transaction in the mempool that has a a very generous slippage limit um you can cause that transaction to execute at a worse price by trading ahead of it on uniswap and then after the transaction you can trade in the opposite direction and you swap to lock in your profit um and so that it works somewhat similarly to how front running works um in uh traditional finance and uh it does depend on knowing not only being able to get a transaction and quickly but knowing the content of other people's transactions to do this and that profit ultimately um gets taken from the user in in the form of worse execution on their trade so how how common would you say is this kind of front running between the swap transactions um i think with uniswap transactions

the um the slippage limit setting a relatively low slippage limit means that on a low um on a not particularly big trade typically it won't be profitable to do this so it doesn't happen that often you see it happen when there's really huge trades on unit swap that push the price really far which could make it possible um to uh uh to properly front run it um and when trades have have uh two generous slippage limits or when the when you know the when the price has changed has been there's been positive slippage in which case the uh the front runner can uh can basically take that yeah so i guess intuitively you would expect when the fees go up as as they are right now and feeds on

ethereum are very high right now that the amount of arbitrage opportunities for minus actually goes down for minus but for for frontrunners actually goes down yeah like the quantity of them for sure um and of course a lot of the high gas prices are also driven by these front runners so let's say you you are one of those front runners so you actually operate a front running bot so if you try if you try to front run a a trade on unit swap and you just you see the the regular traders transaction in the mempool and you just swoop in with a slightly higher gas fee to to basically skip the queue and get your transaction

mind ahead of them so it's not that's not really how it works right because if a frontrunner can front run a regular user then the front runner themselves can be front run right so um you know i think there's there's ordinary users getting picked off by by this but then there's also this war going on at a higher plane between all these front runners trying to front run each other um and that takes the form of i mean i mean you can you can try to minimize that by having your transaction have exactly the same or exact just just under that gas price or even exactly the same gas price and just putting a lot of them in in order to hope that it gets included at the same place but ultimately yeah like if you confront around something someone can

someone can get in and and get ahead of you um potentially blocking your transaction um and so what happened what we see there are these priority gas auctions where once when there's a front-running opportunity different bots compete to get it and this is a it's a costly auction because you have to pay the gas or at least some gas regardless of whether whether you win or lose because your transaction could still be included and fail and this has been empirically seen to be a driver behind the increase of gas prices in the ecosystem so i believe the academic term for that is actually an oil pay option because every like even the failed bids pay some amount of gas and that's a very like very unusual type of option it hasn't been studied all that much

right but the detail here is that when this auction plays out let's say there's 10 bids for 1.5 million gas at some gas price then the people that see that they would that the ones that would lose the bid the auction they can replace their transactions their 1.5 billion gas transactions with a very small gas transaction in order to kind of cut their losses from participating in this auction do you know maybe off the top of your head what is the minimum that you have to pay as a front runner for failed bid the minimum would be a 21 000 gas transaction a normal pay if transaction

that's the cheapest transaction you can make on free and that applies only to your last transaction right so in a typical priority gas option two front runners who compete for the same transaction might replace that transaction 100 times every time bidding a little bit higher but you don't have to replace all of these transactions right only the last one each time you're replacing only the previous transaction so indeed you only you do not need to care about all your previous transactions that are unconfirmed because they're all they're all basically the same transaction you're broadcasting the same transaction with the same nonce just with a bigger gas price so the moment that you replace once all the other previous transactions are gone right okay okay okay that's

that's interesting so the way i find this topic so interesting is because it's it's a game with so many layers at the bottom layer you have basically users competing with bots for trading opportunities to get their transactions included and even this layers is invisible to like 99 of users but on top of that layer you have this game of bots versus bots that we just discussed but on top of that layer you also have another layer which is the bots versus the miners because if we if we consider like a very naive strategy in which the the bots compete for front running opportunities against each other

a very naive strategy would be they they each basically whenever they get outbid they raise a bid on their transaction by 10 000 gas right that that and that why they basically the the price of the transaction gets bid up very fast until it captures the entire arbitrage opportunity and what happens there is basically the rb charges get nothing and the miners get everything so that shows us that there's this big incentive even though the bots compete with each other and they are actually at war with each other to also unite against this even bigger enemy which is the miners

so i would be curious to learn what if any strategies do the the arbitrage spots employ to basically enforce cooperation among each other and like improve their their global outcome against the miners so yes there are ways that you can kind of improve this result by basically finding a way to reduce the number of players in the system such that the auction price doesn't get you know you don't get all these thousands of failed transactions trying to capture the value so what you do is that you have to figure out the ways for all these bots to collaborate

so recently a project called the keypad down and we didn't say that earlier in the podcast but nothing we say in the sport podcast constitutes of any approval or anything of any of the projects that we mentioned so keep it now this idea where they say if anybody tries to front run us we will instantly um overbid so that the profit opportunity instantly disappears so they just say we'll go nuclear we don't care about you outbid us and we will just make it nonprofitable for you and for us but they they don't care basically and this creates an interesting um situation where you're never incentivized

to try to beat them and if they have good enough infrastructure which allows them to always exercise this quote-unquote grim trigger um the result is that everybody should cooperate with them and act as a unified entity and this means that from you went from a situation where you had many multiple front runners who try to front run each other to have a situation where all the bots collaborate with each other which is which is a net improvement on the previous situation you're kind of holding the mvv hostage you're saying if you try to go for our mev we will kill the mvv and there's no more

there's nothing else to take so you're not that's literally what it is yeah and not just we kill the mev but we also like we we we hit you but just a little bit right so so you as well take a small loss because of your transaction that your failed transaction sure sure but but because you're the keeper though you're a big player and you can keep playing the green trigger until all the people that are willing to defect uh are gone and basically you've scared away everyone and then everybody plays by your rules yeah yeah right yeah my point is you need to make it not just zero ev for someone to challenge you but you need to make it actually

minus a v because otherwise they would be griefing you correctly sorry where the minus v what the minus v is the opportunity cost from all the gas that you keep paying and the mov opportunities that you are losing exactly yeah okay so the event that brought mev back on my radar recently is your an article that you two wrote together which showcased um what i thought was an amazing case study for what we've just discussed which is this um actually the earlier stage of this conflict of users versus front runners and i think i think your article was the most

accessible and dramatized also like which made it so accessible to so many people but article on on on on front running and the memphis that i've ever seen and i think it pulled a lot of people into into this topic why don't you basically recap what happened sure so um to set up the story somebody had accidentally so somebody was a liquidity provider on uniswap on a uniswap pair um and they had accidentally sent the uniswap liquidity tokens to the uniswap pair itself um and normally when you send a tokens a token to the token contract itself or any token contract it's usually not recoverable unless there's a special case for it

um and my initial reaction when i heard about this from the united support discord was that this these tokens were lost and then i basically like jolted awake in the middle of the night realizing that actually the tokens were not only not lost but that anybody could could grab them simply by calling baron on the uniswap pair and that's because of a detail of how uniswap works and the key thing here the reason that this um became such a such a strange nightmare is because anybody any address could do this call and they would get the money um basically and so uh i could do this and i went and checked and the uh pool still had these uh these tokens

and they worth about twelve thousand dollars but the uh but anybody else could as well so i had to do a pretty if i wanted to white hat rescue these funds i'd have to do it pretty quickly um but then i had heard about something a story from a few years ago from um from phil dion who's a researcher who studies uh mev and ethereum transaction shenanigans and as a result i was i knew i couldn't actually do this and so that was the puzzle that we found ourselves in and that i that i recruited georgios to help with so to understand why i couldn't just just make this call the analogy that that we use in the post is to a science fiction book called the dark forest which

i don't want to spoil on this call but if you've read if you haven't read it it's great it's a really great book it's in the three body problem uh trilogy and it has this this concept in it um of this kind of game theoretic environment of a dark forest and this is an environment where the there are such advanced predators around that anybody who is detected will almost certainly be destroyed instantly and so a strategy in order to destroy somebody is basically just to reveal their location um in the forest and this was the metaphor that came to mind when i heard about a particular kind of front running bot a really scary one called it a generalized front runner and we were talking before about the uniswap front runners that do this very

particular strategy by sandwiching unit swap trades but there's a lot of mev and in fact computing all possible mev um would be an impossible is an impossible problem but there's there's the strategy that you can do to to grab a lot of it especially when you're in these circumstances that we were in where anybody can make this particular contract call so what you do is you watch every transaction in the pool you look at you run the transaction trace for it you look at every step of that transaction every internal call made and you test what if i made that call what if i made that call but changed the parameters to be my address um you basically you sort of brute force on every single transaction that you see in the mempool

if i did this would i make a profit and if so then you generate that transaction and you front run you front run it and this is a this is a common problem for security researchers who are doing something like a white hat hack i imagine it's also a problem for black hat hackers because i it's in the nature of a hack often or of many kinds of hacks that that anybody can do them it's not it's not some specially privileged address so you know some i think some require multiple steps and therefore are um are less vulnerable to this but this was a case where there was literally an internal call that we would have to make in order to recover this money and if anybody saw this call they'd know exactly how to get the money and so that was the environment in which

we were dealing and you know i felt a little bit paranoid freaking out about this but i'd heard some horror stories from phil before about it and i didn't want to risk this money by doing that so i called in georgia to try to obfuscate it and one one high-level point i want to make about this is that this is you know like like on-chain smart contract security is a is a really uh difficult and harsh environment where you know often if there's money that can be that can be uh exploited from a smart contract someone will do it but this money had been sitting there anybody could have grabbed it by calling a documented function on the uh on the contract and nobody had for at least eight hours but as soon as we actually tried to we would get sniped so that the mempool is

an even harsher environment than the ethereum state itself how did you even go about like approaching this problem so the main thing i did because um as i mentioned in the post i'm i'm a d5 thought leader who has never actually deployed a contract to ethereum before it was i called in some help so this included a couple security researchers like sam sun and also georgios who was who uh handled handle a lot of the of the actual implementation so i'll leave it to georgia to kind of describe what uh what we tried to do and what we would end up happening yeah so the situation is that this is basically a cat and mouse game where you try to make the time until the attacher finds the trace which generates the jackpot you try to make that time as long as

possible so that basically your transaction can get included and get mined so basically if you have let's say that you put a big enough gas price and your transaction would get included let's say in the next 15 or 30 seconds you need to be lucky enough that the attacker doesn't find it so what we did after giving some advice from the people that dan mentioned is that we split the process in two so instead of just saying make a transaction you know that calls the uniswap function which was required we said we would have two transactions that are required to make the step to make the se the rescue and the two transactions they would be sent

from two different accounts in two seemingly unlinked contracts but the moment that one of the transactions got included it would be sort of like a precondition for the other transaction to be also executed so for an attacker to be able to kind of extract the winning transaction they would need to both play the first transaction then what then play whatever other transaction that would be in the mempool and then also play the second transaction so you can see that we're kind of trying to do some sort of um obfuscation uh in this procedure so what we did is that we sent the first transaction with gas price let's say

a hundred in reality that was more like three or four hundred due to all the yield farming mania but that's another story and um and then so we send the first one with a hundred and the second one with 80 let's say and what happened was that instead of using my own local node which had fallen behind for a few days we used infura as our node and uh what happened is that when i i send the first transaction and i also send the second one in the same block so you don't wait for the first one to get confirmed you just instantly broadcast the second one and then what happens is that i got a client side there or from the server then from insurer basically that you know your transaction got

rejected and uh what possibly happened was that because when you send it to infuria or any other you know hosted service typically they have load balancers and what that means is that maybe my first transaction got load balanced to one mempool um so when i say load balanced it means that they have let's say 10 computers behind some common unified endpoint and when you talk to the one end point in practice what this does is that it sends your transaction to one of the other computers so what possibly happened is that my transaction went to the first transaction went to let's say computer one and then uh the other transaction went to computer two

and because the second transaction required the first transaction to succeed typically geth would have both the transactions in the mempool so it would throw no error but because in this case i suspect that the transactions were in different mempos it was not able to know that there would be no error so it simply rejected the transaction which was you know it was a kind of a bespoke uh situation for us at that moment and we were under time pressure because as dan said it was already i think eight hours or something it was 2 a.m for them it was 8 a.m for me you know i still haven't had didn't have my coffee yet so we we were under we had to get this done quickly before

somebody wakes up and uh sweeps the money so let's just do it in two transactions what can go wrong i i explicitly told dan you know there's no chance anybody's watching like come on yeah i mean put yourself in our position there we've been spending hours trying to engineer around this kind of monster that we'd actually never seen and only knew about um uh sort of second hand through effects effects that we've we know that it has had um and in the meantime there was this time pressure because anybody could just remove their own liquidity from the pool um and and accidentally trigger this this call so um as a result we thought the bigger risk was was someone doing this and so we got we got sloppy and thought

you know look we can we can we're still making a call you know this is this is deep in the call stack it's making a call to an authorized contract that nobody else can call reading an address from storage which it is passing to um to the unisrop pool we thought that would be enough um to prevent the front runners from getting us but it wasn't no it wasn't because so literally the only change was you know firstly in the script that you're writing you say send this transaction then send the other transaction and the only change that we did was wait for the so it was send the first transaction wait for it to get confirmed and then send the second one and so we check which check it we see the first one get confirmed we see the second one get broadcasted so

we didn't get the previous error and i'm like okay it worked we won and then i click the transaction house i go to etherscan and i get revert unisop in sufficiently liquidity and then at that point it's like okay we got wrecked and and then we we go and dan finds the other than the transaction which frontrunners and it was it is this kind of monster of a transaction which has um 20 self-destructs in it and it somehow transfers 12.5 or whatever the amount was to the attacher and it was a pro the etherscan account had hundreds of thousands of dollars it had multiple transactions um in the past days it was

it was literally something completely automated and not by some random person and those those self-destructs as i understand them are from are from gas tokens so that's another thing correct a tool that front runners use um in order to reduce their gas costs for which incidentally phil diane who is the author of all these mev papers uh is also one of the co-creators of if the second transaction would have been picked up by the infuria would it have worked your idea or is it speculative we don't we don't know that it would have worked it probably would have had a better chance um but uh but if the attacker was able to just

basically construct a a representative block every second and run the transactions in it and do this process on it um and they could do this potentially and uh massively in parallel then it wouldn't have stopped them um though the hope was just to slow them down for a few seconds because the idea is that the attacker just applies the memphis state on their local state all the time and they try to see is there a profitable opportunity here and then they just they literally take all the internal calls in the that the function created that the call made and they just say okay this makes me money i can change this parameter and i will execute it as a standalone transaction imagine that our transaction did a bunch of things but he took the one

like the one little piece that they needed to to extract the profit ah so your strategy was basically so you have a generalized functioner who does a complete simulation of every transaction to see if they can make money by taking your transaction or transactions mutating them and replacing them all with their own address or a subset of our transaction because because a smart contract call can do 10 things so they don't need the whole transaction they need the one little piece which will make them the money oh yeah so so your strength is basically to make that simulation more costly for them and take longer and then you hope that

basically so the block discovery process in ethereum there's also something unusual for an auction right because you never know when the next block is going to be found it could be it could be in a second from now but it could be in 30 30 seconds from now and both are sort of equally likely actually so so you you hope that you make the simulation of the front runner take a little bit longer and then also for a block to come in before they finish their simulation yeah that's that's that's right um ultimately i think we could have done better on this obfuscation um but this kind of obfuscation is is an arms race that the white hats are destined to lose um and the reason is

it's just sort of a fundamental law here that um uh for your transaction to be included before the front runner is able to get it some miner has to produce this block and be able to run this block and and validate it um and then and mine on top of it and and broadcast to the world before um the attacker can and so that's i think you know sometimes you'll get lucky but like winning those races i think in general is probably gonna be a losing battle and this is something where where in this particular case uh the fact that it was an internal call that anyone could make um there's basically nothing we could have done to actually make it impossible um or really hard to compute um

there's nothing we can do to make it harder really to compute for the um for the attacker than for than for an honest minor or at least not much harder so um that's that's kind of the fundamental limitation here um of the of the obfuscation strategy so if we'd known um if we'd known a minor or if we were able to mine a block um that probably would have been the better strategy and that would be to directly submit the transaction to somebody who could include it in a block without it ever being propagated through the mempool and so in that case it would still be possible for someone to not just knowing a miner but also guaranteeing that the miner does not broadcast the transaction to other miners or users mempools right yeah so i don't think that would be a smart

broadcasting policy by a miner to broadcast their transactions and that would put them at a competitive disadvantage well most miners do when you submit a transaction to a minor they typically they do yeah so one reason they do is is in in order to make the execution of their blocks faster um because if people have already seen the transactions potentially although i gotta i gotta take that i gotta take that back because that's not true in ethereum because you have to run the whole block that's true on bitcoin it's not not your own yeah this only happens on bitcoin because they apply that you did like you expose as they arrive right so cancel cancel what i said but um this actually is the policy that most miners do so like sparkful is an api that you can submit to but it will broadcast it um to other

ones i don't know why they do this actually do you know do you think there are any like white gloves servers for basically broadcasting a transaction exclusively to a bunch of mining pools so nobody um we haven't found one i haven't seen one um and nobody in the security community that i've asked about this problem um has seen one it's mostly done i think bespoke by um by individual miners with people that they have relationships with um i think it would be a great service but it's kind of a very niche service uh it would really be primarily for like white hat hackers i think i mean i see a ton of opportunities for a service like that so i think someone should definitely do it if they hit this podcast i hope they do

i hope they do yeah and i mean this brings us kind of brings us like back to what you said earlier right so so this is a race that the good guys are destined to lose um because like one of the reasons is that if there's like a ten thousand dollar arbitrage opportunity then the bad guys are willing to spend up to ten thousand dollars to get this but i mean the owner of the ten thousand dollars also should be in theory but in practice they are not and the white attackers they never are right so they don't have any funds to spend on securing someone else's money typically um not unless there's like some insanely reliable bug bounty or whatever it's some way for them to recoup the

losses so i that's like one reason i think why and we've seen this like with bzx the last days they had a bug exploited and a white like whitehead actually found the bug and they didn't pay out the bounty and i just think it's like it's shocking and extremely like poor foresight to yeah basically make it so that people are not willing to recover funds for you in the future right so anyway so we we already touched on briefly um that there's another layer of the game on top of the the ones where the bots play against the users and the boards play against the bots and then the bots play against the miners

but there's actually one that is the reason why some people are very worried about mev as a concept and to highlight this i i picked out a tweet that you sent out a few weeks ago georges and it says good day to everyone except those that do not think mev is a serious threat to the stability of ethereum and other chains so what do you mean by that firstly let's uh just say that all of these attacks that come around inserting reordering transactions by front running and so on miners can do them for free miners are the ultimate you know they hold all the cards in this uh in

this game and the mvv is the minor extractable value it's how much each miner can account um you know given a set of transactions some state and some contracts and they can just get it by inserting transactions censoring transactions on the reordering transactions right so today it's the users or the bots you know doing their reorders but eventually miners will wake up and they will either do this themselves or they would outsource this to some service that does it for themselves and you will periodically i think that eventually we will start hearing more

publicly about such such services popping up and basically the issue uh the big danger of mv towards the stability of ethereum is the following so what they can do is that they can kind of start reorging like doing multiple forks of the chain as blocks arrive um in order to get mev which was already extracted in a previous block so let's say that we're at block let's say 10 and there's some there's 100 bucks of mvv at block 11.

um and then block 12 gets mined by some miner i as a miner i'm incentivized to reorg out block 12 and block 11 and remind the transactions of block 11 with some reordering or some censorship or some of my own new transactions um in a way such that i profit and so this results in me canceling out two very legit blocks in order to improve my profit it's a kind of um it is the the sort of attack that you will hear that miners won't do because you know because it is against their interest

because it undermines the chain's stability kind of like how selfish mining works but this kind of time bandit attack when you reorg past blocks in order to extract already extracted mv is a particularly uh dangerous one let me actually uh say say something very briefly about time bennett attacks so because i've actually had a big change of mind about this topic so um so something about the difference between bitcoin and ethereum so in bitcoin when a miner reorganizes the blockchain and let's say they go back 10 blocks and they they remove one transaction and

replace it with another right for example a double a classic double spin attack what happens there is that all of the other transactions go back into the mempool and then they just reconfirm again in the same order so basically in bitcoin nobody except with like very in very rare circumstances is is even affected by a double spend that would target an exchange and that's generally true for utxo based chains but can you describe how that is different in um a state food chain such as ethereum right so this happens because ethereum's transactions are much more you know interlinked

in a way so in the utxo model you add some inputs to your transaction you destroy these inputs and you create some new outputs while in the account model so this means that you know the transaction is solely limited to the data that you passed to it while in the account model your transaction is very much dependent on everything else that happened in that block because for example maybe i don't know maybe you had a price let's say that you made the trade on uniswap and because there was some other transaction that happened before your transaction on unisop uh it it gets outside of your slippage limits

which ends up diverting your transaction while this kind of thing would never happen uh in bitcoin or a utxo kind of chain so i understand that this is what you meant yes exactly so in ethereum in bitcoin all the transaction was replayed just fine and users would be unaffected but in ethereum people who have nothing to do with the attack could see their transactions reverted like without any fault of their own so we can see why any kind of reorg in a chain like ethereum would have a much more destabilizing and harmful effect on users than it would have in bitcoin so that is that is my first point and second the second thing that i've changed my mind on recently so

so we've seen like uh attacks described that are like field sniping for example this is very similar to the time bandit attackers where basically uh instead of building on the block of another miner a miner would go back and fight again for the same reward of that block and there's a pretty easy solution to that to prevent that kind of thing from happening which is um you basically the original miner doesn't keep all the feed to himself if he thinks that other miners are not incentivized to build on that block what he does instead is he he takes the reward but then he pays some of it forward in the form of uh and anyone can spend

transaction or we'll just acquire any kind of coinbase rewards and anyone can spend transactions so so any other miner especially incentivized to build on their block that has the big reward by getting like an some of that reward in the future and i i always thought that like you can solve basically time-banded attacks in that way as well so if there's a block that has a lot of mvv that miner was worried about their block being reorg they would just pay some of the reward forward for let's say the next 20 blocks in order to ensure that their block is very 20 blocks deep but there's actually a special case and i think that's actually like the reason that like they invented

the new name for this the time-banded attack is when you don't actually know like how big the reward in in these more stateful chains is going to be 10 blocks from now 20 blocks from now because you have all these dex trades going on and um liquidations and and so on and so many different assets moving against each other so if you imagine that for example um there is a front run opportunity for let's say a thousand eve now and it's not worth it's not worth reorgan for the other miners but then 10 blocks later suddenly the price of eth doubles

what happens then the the reward of going back in time and actually taking that arbitrage opportunity now has doubled and that's that's the the kind of risk that you you have in ethereum but you may not have bitcoin yeah i mean i think this this is one reason why actually we haven't seen yet very much apparent mev extraction by miners is that it's an extremely specialized activity um that right now is effectively outsourced to um uh to the to these front-running bots and ultimately goes to the benefit of miners i mean uh minor fees are way up in part uh likely due to due to mvv extraction um but we think in the future that

miners are either gonna get savvy on this or they're gonna find other ways to outsource it um that resulted more value capture for the miners yeah i mean it's to anyone who's listening to this episode now i think it's it's important to acknowledge how early we still are in the game because you look at this game that is rigged incredibly hard in the favor of miners so basically nobody should almost none of this meb all of these front running opportunities and so on should go to anyone else but miners but in practice only a small amount of it does and that shows you how inefficient and unoptimized miners are in ethereum today

and how much there's the um to gain from for them so do we have any idea how big mev is um are you aware of any like ways to or heuristics to measure it so i think one estimate for it would just be transaction fees um which is of course literally minor extracted value um so total transaction fees on ethereum uh way up i think it's been it's been around 3.5 million uh dollars a day for the past week which is which is far higher than bitcoin's fees yeah i think that's that's that's sort of that's that's sort of the clearest and you know in some sense every transaction um every fee paid by any transaction is minor extracted value right from the estimates i've seen some estimates and i don't know how accurate

they are that the actual uh amount of muv that's potentially extractable is orders of magnitude higher than that and some of that some of that may require doing things that bots can't do um and that would be for example uh censoring transactions entirely across a period of multiple blocks um or reordering transactions uh not according to their gas price um and so these these kinds of uh these others if you sort of extend mev or obviously double spending and even reorgan a chain um these are things that really sort of only miners can do um and that potentially could be could be massively profitable or of course could could destabilize and destroy the chain just from a high level where does anyb come from like when you look at a chain

what are the attributes of that chain that you look for to predict that like this chain is going to have a lot of mev this chain doesn't smart contract i think specifically like the property of bitcoin that means that there's that there's much less mev other than other than explicit uh rollbacks and double spends is the primary property for that is that there's there's very little contention there are very few cases in which um i send a transaction and whether it gets included or not whether it's valid or not um depends on whether someone else sends a transaction uh at the same time um or sooner and beats mine uh if i'm spending my own funds if i'm

just spending on my own utxo there's literally nothing that anyone can do to prevent it from being included um other than other than obviously censoring the sensory in the base layer because there's no way to make a transaction that conflicts with it um some bitcoin transactions like multi-sigs or transactions that spend from different utxos controlled by different parties potentially could be invalidated by um by other parties and in something like a like a summa auction which is um a protocol designed by james prestwich for um for cross-chain uh dutch auctions between uh ethereum and bitcoin um there are there's sort of a protocol there that could potentially create a little more contention but like so it's it's not technically impossible in bitcoin but it's so limited

uh bitcoin is a limited record you do that most transactions don't have contention what so judges do you know what how layer twos interact with this so what would the network for example create more any view on bitcoin yeah exactly so something i wanted to touch on is that any protocol that involves uh dispute transactions which must be included within some time in the chain which means anything involving lightning there isn't coin swap proposal for bitcoin for privacy all of this they involve timeout windows everything layer 2 in ethereum including roll up state channels plasma whatever has been designed in the recent times

aragon has been having some ideas around how to do some optimistic mechanisms which introduce disputes all of these mechanisms they directly increase the amount of mv in the system so today uh to answer the question yes uh the existence of lightning increases the available mev in the system by the by the exact amount that you can dispute for inside the inside the bitcoin transaction so if there's a channel with let's say 10 000 bitcoin or 10 or whatever um [Music] the moment the transaction uh the moment the dispute transaction about this uh rather not the dispute a stale channel

close uh transaction goes to chain there must be either a justice transaction included within some time or there must be you know some cooperative closed transaction if none of this happen the money gets lost and so the big danger in this is that the miner can just say i won't i i never saw these transactions or will censor these transactions which in the end means that this is a chance for a miner to get bribed either out of band or via some uh some some output and uh and yeah this creates incentives for i mean in this case it's increasing the opportunities in bitcoin

yeah so then you you already mentioned that there can be malicious forms of mev and the way i understand it so these are the ones that would actually uh incentivize miners to destabilize consent consensus for users and then you have benign forms of mev so let me ask you can mev be good for blockchain security as well or is it purely negative right so so benign mev happens uh regardless you know is going to be there regardless of whether anybody's doing any of these strategies so the first trade on uniswap um it's got nothing to do with with monitoring the mempool um or with censoring transactions

um and this is something that somebody's gonna get um and uh and the only question is is who um there's there's more so uh if miners um were able to effectively extract this benign muv um if mine was or someone else like keeper dao um or like uh uh optimism's sequencer which um full disclosure where investors and and optimism um paradigm is but um if one of these parties were able to extract this kind of benign mev um then potentially it could be used to either secure the chain or fund uh sort of other other public goods that

are beneficial ultimately to the chain keeping the chain safe yeah so i i already gave two things earlier where i recently changed my mind by thinking more about mev so i actually until like a few weeks ago i had this like a pretty extreme position on mvv which is that most mvv is benign mev which is something that i still think um and the 9mmv directly contributes to the minor reward in a basically non uh destabilizing way and thereby secures the blockchain and if you combine this with like this previous

guess that we had that that like in in practice like well sorry in theory the mev that can be captured by miners is like magnitude's higher than it is today then shouldn't this mean that we can secure a blockchain purely by any v so if you if you think this like all the way through then could you in theory have a blockchain that does not have a block reward that not only not has a block reward but maybe even has like some kind of deflation or something right you know so it's it's it's isn't that like the the perfect kind of blockchain so yeah my answer would be yes but it probably requires changing how

ethereum works because if tr if all transaction fees go to the minor of the current block um then there's this very destabilizing um influence where uh miners are basically basically could reorg each other in order to fight for those transactions unless they pay it forward right and if but if you well if you can mandate that they do if you can take some of these transaction fees and spread them out over subsequent blocks um then potentially that could be a more consistent more more uh positive effect on stability and so i think georgios can talk a little about eip1559 which is a proposal for upgrade ethereum that does something like this and potentially could have this effect how does it help with mav in this case though because it means some transaction fees

will be spread out over multiple blocks it it you burn them right yeah so they and there's a block reward that gets distributed yeah so in effect it's it's it's it's securing the chain but making the popuoid more valuable let's let's repeat that on the one end you're burning the rewards and on the other you are distributing them but over a longer period of time and in an extremely consistent way how is it in a longer period of time because well i guess i guess just it's still wrong in the sense that um only the base fee is burned in eip159 whereas mev is not really in the base fee it is um correct correct

i think i think there's a flat tax on andre i think i think it would i think it would it would uh matter i have no doubt in my mind that erp 15f9 is very beneficial for blockchain stability because it creates this consistent incentive for the blockchain to move forward yeah and and it removes some of this like destabilizing effect that transaction fees have that we also uh discussed here so totally right one one other thought so if we think that all that oil uh benign mvv makes the blockchain more secure and could be used on the other end to lower the block like the block subsidy

which means there's less inflation for holders and so on and at the at earlier in the podcast we discussed that there's a game going on between front runners and miners and right now the miners capture only a very small amount of like the possible benign mev that they could capture because the front runners are way more like i don't want to say intelligent but they are way more developed and sophisticated and way better at cooperating with each other so far so shouldn't we as users or like not as users maybe but like as people who like uh think about ethereum and develop products on it and so on shouldn't we

want miners to get all the benign mvv shouldn't we try to make that a reality like how in like in what sense do we benefit if a frontrunner extracts value from users i mean if miners get it there's like a very strong case that this is positive for users because it secures the chain and it can be it can be used to reduce inflation on the other side but the front runners get it so this in my opinion is actually way worse so i would agree with the general thinking but i think that it is based on a flawed assumption that firstly there is only benign mev and secondly even if there is no benign mvv

that you're able to separate programmatically between um b9 and non-b9 mv so the the issue that i see is that the kinds of malicious mev like that kind of there's a very gray line between the two at least on a programmatic level because for example imagine that you sensor a cdp liquidation transaction so you don't let the cdp get liquidated or for example um you sensor an oracle update in order for a defi for a cdp saving transaction to get included is that benign mvv or is that malicious mmv i think i that's funny i think i do have i

my definition i'm a categorization and i'm i'm i'm not 100 sure on this um but between basically benign mvv and what i would just call non-benign mev would be that benign mev uh does not depend on knowing anything about transactions that would be included after the transaction that you are including um and so on being the first trade on unit swap in a block um is has this form where it's a strategy that does not depend on knowing anything about the transactions that come after um oh and sorry and then and also don't depend on um on blocking transactions sensoring transactions from being included um uh within one block and so that uh if you if you limit your strategies to only ones

that don't have not for knowledge of subsequent transactions um and then then i think uh that that filters for only benign i mean if you've only the kind of mev that's like yeah that's like being the first straight on you just dropping a block where someone's gonna get it um and you're just winning a race for it so i would actually go back to what georgia said so i don't see why we actually need like for this forward aesthetic for this idea if we should distribute more mev from front on us to minor so i don't see why we need to distinguish at all between benign and non-benign mbv because the front on us can only capture the

nine uvb right so by definition so they can only they can only of the three things that mev that it generates mvp they can only insert transactions whereas miners can insert they can censor and they can rearrange right so those three things so the frontlines by definition have only benign mvp so whatever whatever uh mev we shift from front on us to minus is thereby by definition hundred percent benign and so and the the non-benign we can can be captured by miners anyway right so um that would be my thinking but this brings us just in general this uh this this topic of distinguishing

benign and non-benign mvp brings us to the final part of this this podcast actually which is if we could would we want to mitigate mvv i think i think i agree with you that um mev going to miners is very probably better than um mev going to to front runners um i think certainly for especially some kinds of mvp uh it's bad for the users ultimately um that's i think arbitrage by the way is not is not this like a user typically trading on uniswap um an end user uh wants there to be an accurate price and so it's it's uh if it's just sort of a random retail trader uh noise trader then uh arbitrage is at least as likely

to help them as it is to hurt them in terms of their execution price um so arbitrage yeah arbitrage on unison plays plays a very valuable role and so that's going to be there no matter what um i think the uh or to give like sorry to interrupt but to give an even more clear example if you have a cdp and maker and you're about to get liquidated like you want uh the keepers on chain which are by definition front on us right so you want them to be as efficient as possible to liquidate your collateral as soon as possible so you get a better price a lot of ethereum depends on there being these these uh incentivized actors um out there that are that are watching

the chain and doing all this work um and that's why a lot of these systems can be as simple as they are um i think as far as as far as the other kinds of mev um uh i think some some of it would be better to reduce or have them redistributed basically to the to the users um some i think uh potentially it could be worth it to have to have the miners still extract them i think some certain kinds like like particularly censoring transactions um is the sort of thing that we really just hope a system like this does not have um and ultimately would ethereum i think would basically have failed if um even even if it's even in my line i'm sorry i think ethereum would have failed if even a

even a benign entity has the has the power and makes the decision to include transactions at all on the chain or not i guess that's that's sacrificing some fundamental principles that you know regardless of the value being extracted or where it's going um potentially damages the entire experiment in my opinion and from past discussions i believe there are three types of high level techniques that you can use to mitigate mvv firstly obfuscation so firstly our dark forest for example uh case is a situation where you try to separate your transactions in some way um so that they don't look like they have an mv opportunity behind them

um another way another thing that you can do is some form of commit and reveal scheme so first you would commit your transaction on chain uh so that it doesn't look like there's some mov to be extracted and then the moment that you reveal it that the ordering is already committed to and this is uh related to the second um type of uh mitigation which is the separation where you want to separate execution from ordering and there's more or less um kind of like three techniques which you can use for separating execution from ordering and they're all based in the fact that the miner or the block producer in a proof of stake or whatever

they don't know um the clear text transaction before they have committed to its ordering so basically what they all do is that in one case you can say that i will have a verifiable delay function the miner receives a transaction encrypted and they can only learn the clear text transaction let's say 15 seconds later but they must commit to the ordering of the transactions in that block like now so basically you just enforce that they commit to the order now but they only learn the content later and uh you can also assume that any transaction that gets submitted encrypted and ends up being an invalid transaction gets interpreted

as a no wall so nothing happens um and anytime that you do this kind of encryption with verifiable delay functions there's also its counterpart uh that you can also do it with threshold encryption similarly to how you can say that you can do secure randomness either with verifiable delay functions or with threshold and fiction they're more or less counterparts of the same solution and the third way that you can do this is by just saying that the block proposer before they before they include your transaction they promise you by putting up a security bond they're saying here's 10 ether that i will include your transaction at the index number 5 in the block and then the block gets mined

and if your transaction was not at the index that they promised you to um they will get slashed um yeah and then there's another way which i'm not a huge supporter hold on a second so before we move on to the the final um the final method i would have a few questions about separation so um are these generally techniques that you can use on any layer including layer one assuming that your layer one is built with this uh in mind so doing this on ethereum or bitcoin they would require um a fundamental change or okay uh i believe that what you could do

in ethereum is that you could have a smart contract which does the following um the miner puts up a bond on a smart contract and says that this transaction hash will be at this transaction index and i'm just making up the protocols i go and then after the block is mined um the user would then take uh the merkle patricia proof of inclusion of their transaction and they would post it on chain if the index did not match and this is doable because you can you can access the block hash via smart contract and you can also provide a medical proof which shows that your transaction was included in that specific block

so i believe this is doable so the proposal is offering receipts and bonds for transactions at a specific index i believe is dublin ethereum not doable on bitcoin the time lock and threshold encryption ideas they both require um consensus level changes so does the mev auctions that are being uh pioneered by the optimism uh optimistic roll-up uh also fall into this category of separation not exactly i think they fall morning the bundling and batching kind of uh situation although dan is more familiar with that so you can chime in here yeah so i mean it's these yeah the sequencer component of optimism system

um it's saying that could be done on on layer one um as well i think the fact that is that it's combined with the optimistic roll up um gives some benefits but the the basic idea yeah is that is that it if you have someone who's responsible for for secrecy transactions who basically has to sign every transaction um for it to be included before a particular uh other on the fast track on the fast path um for transactions um then you can provide uh a lot more assurances soft assurances but assurances to users um uh about about the ordering of those transactions um and that could prevent you know these kinds of mvv but that requires the users essentially opting in um and or actually the contracts themselves have to opt-in because if

there's another way to call this contract um that doesn't go through the sequencer or doesn't go through something like um like a pdf uh yeah so like yeah so yeah another another way to do this would be if like um like so stockwear has a full exposure where is another company we're invested in um has a project called vidu which um which is basically vdfs as a service and so if you if you just had somebody um instead of having a sequencer you just said every transaction has to have a vdf on it um and go through this go through this uh smart contract um that could potentially prevent prevent the same kind of thing but only if the contract opts in so this wouldn't have helped us

uh with unit swap with the uniform situation that we had because that contract um doesn't have this kind of uh constraint on it anyone can call it i see but you could in theory build like unisof version three in a way or unison version four or whatever in a way that requests a specific contract but it has to go through a sequencer in order to call it yeah i think that's that's that's certainly any any contract could be built in a way um where the rules for accessing it are gated by either something like a vdf or something like a sequencer so the way that i understand the concept of an mev auction is that you auction off the right to other the transactions

separately this is also basically the first time that you can measure how high anyb even is in like a market-based way because like you have a free market for bidding on that mev and if you assume that there's not like another cartel that suppresses like price discovery then you you would actually discover the true price the the true price of of mev would you agree with that right so yeah the the mev auction uh concept which was proposed by by the optimism team um does uh if you did this if you did sort of like a pure auction on a per block basis um where anyone could or

per per minute basically anyone can be the sequencer for the next minute um you're paying for it you get um you potentially could yeah gotta get a much more accurate price for mev i think the the solution that uh and this is this is a sort of a future potential part of uh of something that up that could be done with optimism um it's not it's not it's not part of the unit of the initial system i mean the details aren't aren't really all worked out um but the uh i think is more likely to be gated um in some ways and rather than just being a free-for-all auction precisely in order to avoid like the really most malicious forms of mav um yeah so like having something like a white list of participants um who can who can be removed by

governance so that that's the sort of thing um where yeah but i think you still potentially learn a lot about how much mvv there actually is potentially on a chain so another question that i would have about optimism so i don't know if that's still on the on the roadmap but um in the original idea the proceeds from auctioning of the sequencing rights um would be used uh to fund basically public goods on ethereum and i'm skeptical why anyone would use this chain when you could also just fork uh [ __ ] the chain and and pay the med back to users for like for example this concept is like very established right so for

example traditional finance you have exchanges where um basically like the worst kind of uh of users get get paid back from uh so let's say front running efforts of like of the stronger traders and i believe this is even something that uh is implemented today in synthetics um for for example so why wouldn't such a such a version of like the optimism be vastly superior to the one that just like gives away the money it's tough to discuss because i think it's it's all very uncertain um exactly what these things will look like so it's hard to discuss with that more

more detail um i think in general the answer to why won't someone just fork away something that does something good um into something that's that's that's more neutral or doesn't or doesn't do the positive thing um but it's slightly more profitable i think is spontaneous order like ultimately um things like roll-ups have pretty strong network effects um and you want if you basically only want to be on a roll-up if there's if there's other um users on it and so um even just like a like a relatively small uh fuzzy factor um like having like um not just not extracting malicious mev but also but redistributing the benign mv to positive um goods i think could potentially be enough to to make that the shelling

point for everyone to use um as their as uh that roll up and i think it might be tough to fork that interesting yeah yeah i think um that's a very good explanation so in terms of mitigation so we discussed you can obviously obfuscate um basically your transactions in ethereum or you can try to separate execution from the transaction ordering so what is the third field that you can do both what rollup does and what uh you can imagine that you have a service which aggregates transactions and puts them on chain is that the ground group creates a bundle which means that either all transactions

in that bundle would get included confirmed or none of them so basically what you do is that you batch you would batch together a bunch of transactions and you try to enforce this condition so what you do is that you enforce that the ordering happens off chain and then any kind of attempt at interfering with the ordering um fails and that's it so you make a bundle and you say anybody that tries to touch this bundle and reorder it uh invalidates the bundle let's assume there's uh there's that you have a like sequencing service that is off chain

and users submit their the transactions to it and maybe there's also a commit reveal scheme or whatever to to make sure that you know that the actual operator can't change the order of transactions and then that that service bundles the transactions and publishes them to ethereum so why can't at that point a miner look at the bundle and just unbundle it and rearrange it in any order they want right so i think that's a case where you need um uh the individual users and then potentially uh the contracts um in some cases uh to opt into this so you could do it if the users opt in to opt undo it then

at least their signature won't be valid it won't be an independently valid transaction from them it'll only be valid when best with these other um transactions so that's that's the kind yeah so basically if the user opts into this uh then yeah and so uh but then in in other cases where it's like front running like yes there's no reason someone couldn't front run the whole batch um and there i think the uh as its own transaction and there the hope is that basically the transactions within the batch cancel out and all happen atomically and and in sequence guaranteed um so that that sort of that that mitigates it to some extent ah okay so that is very similar to what you said earlier about human swap and optimism

yep but but it's not gonna i mean this this isn't going you know that sort of system is not gonna save um uh you from the generalized front runners because they can still read through the entire internal call stack of that of that batch uh okay yeah so you something that you can't prevent is when there's an opportunity that anyone can take they will still take it yeah these are all funny implications of the blockchain's main feature that is the transparency you know that because all the data is out there that means that anybody can just go and pick them apart and reconstruct them in any format that they want and use them to their advantage and you know like from a first principles

perspective that's why the the solution with the encryption of the transaction feels like it's the most proper one because it exactly tries to basically force the ordering to happen at a time when nobody knows what's inside what is inside the transaction so maybe for like the last question to to like zoom way out so neither bitcoin nor ethereum have been designed with the goal of like fair transaction ordering in mind in the sense that there's zero guarantee that transactions are ordered in in the actual sequence that they came in to to miners and that is basically the whole reason why we

have to talk about this so do you think that there's going to be a new generation of like blockchain and i am very careful like even to entertain these ideas because bitcoin and ethereum have like such strong network effect and it's so hard to make something that's like 10x better but if i had to like pick one thing that that could be like 10x better it would like one other one or two things that would be that would be like fair transaction ordering so do you think that's even possible and like how likely is that and we see something like that i think it's possible i think it's also possible that this happens on layer two on ethereum and i sorry i described ways

that this could work um with optimism or starkware um i think the uh i think i think ultimately any solution this is something that bitcoiners used to say um was oh if anybody just creates a better future we'll just we'll just add it to bitcoin and they don't say that anymore because nobody nobody adds anything to bitcoin anymore uh but i do think uh i think on ethereum you know it's very hard to change ethereum but it's not it's not that hard it's very easy to build something on top of it and so hopefully if if some other blockchain um finds a way to uh solves this problem then potentially that will help users on ethereum as well um because someone can someone can build that kind of system on top of ethereum

okay guys so i thought it was just an amazing discussion and i'm i'm so glad that uh that we did this thanks guys thanks for having us on thank you thank you