Classifying MEV - Sunny Aggarwal

wait now you guys can hear me um okay hey guys my name is sunny uh i am one of the co-founders of a project called osmosis uh it's a dex built on the cosmos ecosystem and one of our main things that we've been focused on is how to decrease front-running uh off on with in uh new l ones um and yeah so you know i've been thinking about mev for a long time i think i initially started thinking about it with the flash spots team like last summer um and so part of what i've been doing is like thinking about how to like classify mev and how to like approach you know different i feel like this mev terminology is very very broad and covers a whole swath of different kinds of things and so i wanted to kind of dive deep into figuring out how to like classify it and then with each sort of category of mev what kind of solutions are possible and then just come up with a model for how to think about solutions so um to start off uh i just want to get one thing out of the way you know mev stand for a minor extractable value but really it's proposer extractable value thank you phil for you know for end of time we're always gonna have to start every single presentation with this caveat um but yeah so you know as systems switch towards proof of stake uh you know we we don't have minors anymore but we have proposers but really the the it's the same sort of thing it's whoever is the block proposer has some ability and so how are we defining mev we i i like to think of it in terms of proposer powers so what unique powers does a block proposer have that they can single-handedly execute so you know obviously it depends a little bit on the uh protocol right like you know different protocols block producers have different powers but you know but we can talk a little bit just about some of the generalized ones that are pretty common throughout most protocols obviously some protocols will have more some will have less but you know some of the uh most common ones one of one of them that comes up often is the mess with the time stamps in their blog proposal so in many protocols so including bitcoin and ethereum and many protocols you know in a distributed system you often need some form of decentralized clock and we often use the block proposers as a sort of oracle into wall clock time and you know and there's very little and because they're being used as oracles there's very little that they could do here and so very a lot a lot of like flexibility that they have and very little ability to like slash them you know both bitcoin and ethereum have like models of you know constraining their ability bitcoin does the whole like you know has to be greater than the median of the last 12 and whatnot but you know with this you can pull off a lot of different sort of attacks you know this random manipulate randomness manipulation so if you remember back in ethereum a couple years ago when everyone tried to start using like time stamps as sources of randomness and that was just like a terrible idea but you know the fact that a minor could mess with the timestamp and you know win a lottery or something that is a form of mev because it is a type of power that the block proposer had single-handedly uh there's also attacks like time jacking where like you know if you mess with the time stamps you can like you know screw around with the consensus protocol a bit um and you know how you can solve this one way of doing it this is something that we do with tendermint uh is we use some you know this well this application layer solution which is like you know you stop just you know stop using time as a randomness source but then there's also protocol there solutions and this is what we do in tendermint it's called bfd time so the idea is basically you know you have every validator uh because 10 minutes is like bfd system where every router contributes votes you can have every validator give like hey this is what i think the time is and so even if you have the block proposer who you know has some weird time that's completely out of band with everyone else you know as long as you take the weighted median of all the votes you'll end up with a bft time that is more accurate than just depending on the block proposal themselves so what is something else uh block proposers can single-handedly do you can do consensus vote censorship right so i would consider selfish mining and all the like the things that come from it you know feather forking all these kind of things as types of mev because this is some this is still a power the ability to censor other validators votes and not build on top of them is a is still a power that a single uh block proposer can have um what else can block composers do they have the ability to read transactions from the mempool so you know normally everyone has the ability to read transactions from the uh mempool but you know thank you to flashpot only the block proposals now have the ability to read transactions from the mempool because now there's a system where flashbox provides a way for you know users to send uh transactions directly to the miners and so it's not visible in the public mempool so now this has become sort of a power of the proposer that is not like available uh widely which is good in a lot of ways because you know now instead of anyone being able to front run you only a select view confront run you um then you have the control they have the ability to control inclusion of transactions in their uh block proposal so they get to choose which transactions to include in in their block and they get to choose the order of transactions in their block proposal so i think you know what's interesting is you notice these la these ladder three all contain this like transactions as like a core piece of what they're trying to do and so you know i think we can put this into a category called transaction based manipulations um so you know within transaction-based manipulations i think there's a lot of you know there's further subcategories there's censorship manipulation and ordering manipulation um censorship could include you know you're just trying to censor people from the block maybe you're trying to maybe they have to close a payment channel or something and you're trying to censor them that that would be a and you know if you could do that successfully that would be a form of uh any because you there might be a way to profit off of that as well um but ordering manipulation you know i i think we there's a couple of different ways we think about it so we'll build it into this like sort of quadrant so well you know we'll start with things that are based on other transaction data so you have relative ordering so this is what normal front running is where you see like someone else's transaction and you do something with it so you know in traditional finance you know front running would be you know you see someone's trying to place an order and then for a large amount of shares and you put your order right in front of them and then you know sells right after them and you can profit off of this this is called a sandwich attack um in a blockchain it's very similar where you know there's a bunch of transactions in the mempool and then the block proposer can say hey i can't read alice's transaction and i want to do something with it so i'm gonna go ahead and add my transaction to the mempool and then make sure my transaction comes in front of alice's because i wanted to do something off of that um yeah and then there's also what i call uh absolute ordering where it's dark force attack style things uh this is basically you know it was written by dan and giorgio's couple almost a year ago i guess um and you know the way this forms is basically you know you can assume that there's a you can simplify it and say hey here's a reward for the first person that can so show a solution to a puzzle on chain and that puzzle could be you know it's vague it could be an exploit that's possible or it could be you know there's many different things that it could be but you know what would happen is alice figures out the solution she goes ahead and submits the solution to the mempool sikka can that which is a block proposer can now go ahead and you know see it read the transaction add their own solution and then make sure their solution comes first and so the difference between why i categorize these as two different things about relative ordering versus absolute ordering relative ordering has to do with positioning relative to another transaction so you know uh in that case the blockbuster their goal is to be right before alice's transaction or right after alice's transaction in absolute ordering they don't really care about where in the block that they they care about the position of the block they don't care where they are relative to alice's transaction so what why that's important is they could just go ahead and remove alice's transaction altogether and if they don't include alice's transaction but they still go ahead and put their transaction as the first one in the block they still have successfully put executed the dark force attack which is why i think it's worth separating these two um one requires inclusion analysis transaction while the other one does not um and so you'll notice that you know this is based off of reading other people's data and a lot both of these uh attacks come from the ability to read transactions from the mempool and so the solution to this or one solution to this is you have encrypted transaction in the mempool so you know at a high level what would happen is alice would go ahead and submit a encrypted transaction uh all the transactions in the mempool would be encrypted a block it the block proposal will create a block all the validators will commit and finalize on a block and then some sort of private uh magic will happen and the transactions will get decrypted and executed and at this point it is too late to do anything about it because they've already been committed and they must be executed in that order there's many ways of doing this encryption which is not sort of you know i actually gave a talk at a previous mev roast about like sort of comparing the trade-offs of all of these but i'd say the three main ones that i'm aware of right now are trusted hardware time lock encryption and threshold encryption uh this is sort of the end result of that talk i gave last time which is here's the trade-off summaries um i'm i'm a little bit biased because our our project we're focused on threshold encryption because we think it fits the bet it makes the least uh trade-offs um but so yes you know assuming if you if you use any of these solutions if you're able to remove the ability to read transactions from the mempool you've solved you know sort of both of these sort of attacks but there is like another type of um ordering manipulation where it's not really based on anyone else's transaction data and so what i mean by that is what if like the puzzle was so simple that you know sikka didn't need to copy anyone else they could we just knew the solution ourselves so it's like five dollars to the first person that can answer two plus two um and you know there could be all these solutions in the mempool that are all encrypted and you know the block proposer doesn't need to be able to read the solutions because you know we're not that dumb we know the answers for um and we can always guarantee because of our ability to choose ordering in a block we can always guarantee that we will be the first one in the block and so you know this it doesn't have to always be like you know the two plus two equals four it could be for example a liquidation right that's something that you know i don't need to copy someone else's transactions to know how to do it it's a very simple thing everyone can do it pretty easily um and so i i don't have a good term for this right now i'm calling it blind front running but i don't really like the term so if people can come up with a better one that would be great um but yeah this is like not you know a relative ordering for something not based on another transaction doesn't make any sense because how can you be relative to nothing but absolute but not based on something else we'll call that blind front running um you know how do you prevent this you can try to block off the power these powers that enable it so you know the fact that the block proposer can choose the order of transactions well one solution you could do is some sort of order randomization right you could say okay once you decrypt the transactions there's a second step where you use some sort of decentralized randomness in order to you know mix up the transactions and just tornado them around and so they get into some random ordering this you know does that solve the uh this like blind front running though it doesn't because even if we go ahead and uh you know randomize the order of the transactions you still have a situation where sikka can no because the blockbuster doesn't only have the control of the ordering of transactions they also control the inclusion of transactions and so if they create a block where they are the only um transaction in the block you can randomize it as much as you want it will still be the one that will win right and so you still have to solve this other one which is the control inclusion of transactions in a block proposal and this is you know i think this is sort of what spent uh a lot of these like fair ordering protocols like equitas and things are trying to aim to do where you want to make sure that it's not just one person involved with making a block choosing which transaction to go in a proposal and i i'm kind of dubbing all of these in this idea called joint proposals where you say hey instead of just the propose just the proposer including the transactions everyone has a little bit of a say of which transactions get included and you know they can have overlaps which is fine but once you have you know the once you have the votes from the previous block the next proposer has all they by you know having the votes which need to commit they by definition have to have the information of at least a bunch of transactions even if they choose to do a little bit of censorship you know they'll still have other people's you know other votes that they have to include and their block proposal will only be valid if they include all of those transactions and so this basically makes it so the proposer is not single-handedly choosing inclusion all validators have some input into the uh inclusion process and you know obviously this has you know yeah so this helps you solve this like sort of blind front running problem so you know to zoom out from like you know what have we what is this sort of taxonomy that we have designed so far so we have this large category of mev manipulations i i want to avoid the word attacks because i feel that that provides like a certain connotation which might not always be correct because you know you want someone to be doing liquidations that's a good thing right so i'll call them manipulations um you know we have things that are like oracle-based because oftentimes uh block proposals are used in oracle's in many protocols so you know time stamp manipulation would be categorized as a type of oracle-based manipulation uh there could be other ones right because many many um many uh protocols rely on block proposals for other sorts of things so as an example gas pricing right or in erp 1559 you know the block proposal has some amount of say in the uh minimum fee and if there's the ways to exploit that for gain no that that would also fall under oracle-based manipulations next would be consensus space where you're you know block proposer are obviously a very important piece of the consensus protocol and so this is what you know where like the uh vote censorship and the uh you know selfish mining kind of stuff would fall under that category and then we have the transaction based manipulations uh in which you know we have the censorship category which we talked about uh and then we have the ordering based and you know there's probably other types of transaction based censorship that i'm i'm not sure of right now but i'm sure people can come up with more um within ordering base you have the type that is based on other transactions so this is you know requires the ability to read other people's transactions and then you have the type that's not based on other people's transactions and then finally within the um based on other transactions you have we split it up into uh absolute ordering versus relative ordering so the relative boarding would be what we term front running absolute ordering would be what we term dark forest and then it when you're not trying to be based on someone else's thing it's called blind front running and within the blind front running i'm sure there's a whole swath of like you know things to talk about what are we talking about liquidations are we talking about you know there's all these different things that fall into blindfolding so i think that's like gonna you know if you zoom into there there's an entire sub tree of categorizations that can be done uh that would probably be interesting to for someone else to uh dive into it further you know so my project we're focused mostly on preventing the adding mempool privacy so we're trying to really focus on solving everything that's under that base on other transactions tree but you know i think a lot of the stuff that has to do with like auctions and like mev auctions and things like that are really trying to solve a lot of the problems that happen in that blind front running category um and then you know i i just want to provide a little bit of categoricization to like some of the different solutions that people have come up with for mev mitigations uh i'm just going to put them into three main buckets but you know there's probably more uh one is cryptographic the second is uh threshold base which makes a little bit of sense because blockchains are crypto distributed systems so obviously it makes sense that your solutions will usually be cryptographic or uh distributed in some based and then there's also like application specific uh one so you know from the examples that we went over in today's presentation some examples of cryptographic mitigations would include things like randomness right so you need so that for the order randomization you know you have some sort of randomness whether it's from a vdf or uh some sort of uh uh threshold significant uh key which you know i guess if it's from a threshold it's somewhere in between cryptographic and threshold based uh but yeah that would be a cryptographic solution time lock encryption is a type of uh cryptographic solution to the uh mempool privacy uh and then i'm sure you know if you want to get really into it you can design like various like brand new types of state machines that are like you snarks and npc that like mitigate mev in a way that's like very different than like you know then you know the state machines that we're currently used to anyways um then you have the threshold base and you know with within that we have examples like the bft time where you're taking you're saying hey the proposer doesn't get to choose all validators gotta choose uh your threshold encryption where you say hey all the validators have to contribute to decrypting these transactions uh you have the joint proposals right uh which is like uh the way of like allowing for inclusion and this is really interesting because i think you know like i said if i if you know it's kind of my own definition i posited at the beginning where mev is refers to the types of manipulations that a block proposer can single-handedly do and if you take that as the definition the idea of these threshold-based solutions are you say try to take these powers that only the block producer has and try to decentralize them across your entire validator set and so this you're basically trying to move it your these um powers from to have the same security model as your consensus system as itself so within with threshold encryption you know you require only two-thirds of your validators have to come together to decrypt or propose to decrypt the transactions and so you make that follow the same security model of your proof of state chain itself uh and obviously you know what you need to do is now figure out how to add slashing solutions slashing conditions for each of these uh you know for threshold encryption we've come up with a lot of different slashing conditions that you know seem to work well uh the tendermint core team has come up with a lot of like slashing conditions for bfd time to make it work pretty well um i'm sure a lot of people who are working on like fair ordering systems have come up with things for joint proposals but you know i think that's one of my main issues with a lot of the fair ordering uh protocols is i don't understand how the slashing conditions work and so i think that's something that's important to be figured out and then finally we have this last category of application specific solutions so this is where like you know if you know the application you have in mind you can design very specific solutions which is why you know uh so an example would be things like slippage tolerance right the fact that like uh amms and many dexes have slippage tolerance is sort of in and of itself mev mitigation if you didn't have the slippage tolerance someone could front run you and just cause you to buy things at an incorrect price so the idea is that that is a type of application specific mitigation that's already very widely adopted uh you have batch execution right batch execution is you know a form of how you how do you do dexes and you provide more fair pricing for everyone so um yeah and then you know uh that should that shouldn't say liquid that should say liquidy stability pool so the liquidity protocol one of the cool things that they did in their thing was they said hey the uh in maker dow the uh auctions the liquidation auctions are way too uh weird and too subject to mev and so what they did was they said hey we're going to build a into our protocol a stability pool that provides like fair access to liquidation revenues for everyone who helps deposit into it and so that's also an another example of um a application specific mitigation and then you know just like tips and tricks like don't use bad randomness like time stamp maybe like time stamp as a randomness source right that would also be a type of application specific mitigation where you're telling the application developers hey like you know avoid this thing um so yeah that's uh that's the end of my talk i hope you know it was pretty fast and lightning round but uh i hope that helps give some clarification of like okay these are different ways to start thinking about mav and then once you unders once you really start to understand mev in terms of the powers of proposers then you can start to work on solutions just start like striking away at the different powers that proposers single-handedly have right thank you all right thanks thanks sonny um you're up next