**A** (00:00):
Wait, now you guys can hear me? Okay. Hey guys, my name is Sunny. I am one of the co founders of a project called Osmosis. 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 in new L1s. And yeah, so I've been thinking about MEV for a long time. I think initially started thinking about it with the Flashbots team last summer. 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 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 start off, I just want to get one thing out of the way. You know, MEV stands 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 going to have to start every single presentation with this caveat. But yeah, so you know, as systems switch towards proof of stake, you know, we don't have miners anymore, but we have proposers. But really it's the same sort of thing. It's who whoever is the block proposer has some ability. How are we defining mev? I like to think of it in terms of proposer powers. What unique powers does a block proposer have that they can single handedly execute? Obviously it depends a little bit on the protocol. Different protocols, block producers have different powers. But we can talk a little bit just about some of the general generalized ones that are pretty common throughout most protocols. Obviously some protocols will have more, some will have less, but some of the most common ones, one of them that comes up often is the mess with the timestamps in their block proposal. So in many protocols, so including Bitcoin and Ethereum and many protocols 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 there's very little. And because they're being used as oracles, there's very little that they can do here. And so a lot of flexibility that they have and very little ability to slash them. Both Bitcoin and Ethereum have models of constraining their ability. Bitcoin does the whole 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 started using like timestamps as sources of randomness and that was just like a terrible idea. But you know, the fact that a miner 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. There's also attacks like time jacking where if you mess with the timestamps you could screw around with the consensus protocol a bit. How you can solve this? One way of doing it, this is something that we do with Tendermint is we use some. Well there's an application layer solution which is you stop using time as a randomness source. But then there's also protocol layer solutions and this is what we do in Tendermint, it's called BFT time. So the idea is basically you have every validator because TenderMinutes is like BFD system where every validator 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 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 proposer themselves. So what is something else block proposals can single handedly do? You could 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 and 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 block proposer can have. What else can block proposers do? They have the ability to read transactions from the mempool. So you know, normally everyone has the ability to read transaction from the mempool. But you know, thank you to Flashbot. Only the block proposers 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 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 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 can front run you. Then you have the control, they have the ability to control inclusion of transactions in their block proposal. So they get to choose which transactions to include in their block and they get to choose the order of transactions in their block proposal. So I think what's interesting is you notice these latter three all contain this transactions as a core piece of what they're trying to do. And so I think we can put this into a category called transaction based manipulations. So within transaction based manipulations, I think there's a lot of, there's further subcategories. There's censorship manipulation and ordering manipulation. Censorship could include you're just trying to censor people from a block. Maybe you're trying to, maybe they have to close a payment channel or something and you're trying to censor them. That would be, if you could do that successfully, that would be a form of mev because there might be a way to profit off of that as well. But ordering manipulation, I think there's a couple of different ways. We need to think about it. We'll build it into this quadrant. We'll start with things that are based on other transaction data. You have relative ordering. So this is what normal front running is, where you see someone else's transaction and you do something with it. So in traditional finance, front running would be you see someone's trying to place an order for a large amount of shares and you put your order right in front of them and then sells right after them. And you can profit off of this. This is called a sandwich attack. In a blockchain it's very similar where there's a bunch of transactions in the mempool and. And then the block proposer can say, hey, I can read Alice's transaction and I want to do something with it. So I'm going to 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. Yeah. And then there's also what I'd call absolute ordering, where it's dark forest attack style things. This is basically, it was written by Dan and Georgios couple almost a year ago, I guess. And the way this forms is basically you can assume that you can simplify it and say, hey, here's a reward for the first person that can show a solution to a puzzle on chain. And that puzzle could be, it's vague. It could be an exploit that's possible, or it could be. There's many different things that it could be. But what would happen is Alice figures out the solution. She goes ahead and submits the solution to the mempool. Sika can now, which is a block proposer, can now go ahead and read the transaction, add their own solution, and then make sure their solution comes first. 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. In that case, the Buckholes or their goals would 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 care about the position of the block. They don't care where they are relative to Alice's transaction. So 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 forest attack. Which is why I think it's worth separating these two. One requires inclusion of Alice's transaction while the other one does not. And so you'll notice that this is based off of reading other people's data. And both of these 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 at a high level, what would happen is Alice would go ahead and submit a encrypted transaction. All the transactions in the mempool will be encrypted. The block proposal will create a block, all the validators will commit and finalize on a block, and then some sort of private magic will happen and the transaction 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. 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. This is sort of the end result of that talk I gave last time, which is here's the trade off summaries. I'm, I'm a little bit biased because our project, we're focused on threshold encryption because we think it fits the best, it makes the least trade offs. But so yes, assuming if you use any of these solutions, if you're able to remove the ability to read transactions from the mempool, you've solved both of these attacks. But there is another type of ordering manipulation where it's not really based on anyone else's transaction data. And so what I mean by that is what if the puzzle was so simple that, you know, Sikkei didn't need to copy anyone else. We just knew the solution ourselves. So it's like $5 to the first person that can answer two plus two. And there could be all these solutions in the mempool that are all encrypted. And the block proposer doesn't need to be able to read the solutions because we're not that dumb. We know the answer is four. 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 it doesn't have to always be like the two plus two equals four. It could be, for example, a liquidation. That's something that 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. And so 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. 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 blindfront running. 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 mix up the transactions and just tornado them around and so they get into some random ordering. Does that solve this blind front running though? It doesn't. Because even if we go ahead and randomize the order of the transactions, you still have a situation where sika because the block processor 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 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, I think this is sort of what's been a lot of these fair ordering protocols like Equitas and things try 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'm kind of dubbing all of these in this idea called joint proposals where you say hey, instead of just the proposer including the transactions, everyone has a little bit of a say on of which transactions get included. And they can have overlaps, which is fine, but once you have the votes from the previous block, the next proposer has all of by having the votes which needed to commit, they by definition have to have the information of at least a bunch of other transactions. Even if they choose to do a little bit of censorship, they'll still have other votes that they have to include and their block proposal 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 inclusion process. Obviously this has, this helps you solve this blind front running problem. To zoom out from what is this taxonomy that we have designed so far we have this large category of MEV manipulations. 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 want someone to be doing liquidations, that's a good thing, right? So I'll call them manipulations. We have things that are like Oracle based because oftentimes block proposers are used as oracles in many protocols. So timescamp manipulation would be categorized as a type of Oracle based manipulation. There could be other ones, right? Because many block many, many protocols rely on block proposals for other sorts of things. So as an example, gas pricing, right? Or in EIP 1559 the block proposer has some amount of say in the minimum fee and if there's a ways to exploit that for gain, that would also fall under Oracle based manipulations. Next would be consensus based where block proposal are obviously a very important piece of the consensus protocol. And so this is where the vote censorship and the selfish mining kind of stuff would fall under that category. And then we have the transaction based manipulations in which we have the censorship category which we talked about. And then we have the ordering based. And there's probably other types of transaction based censorship that I'm not sure of right now, but I'm sure people can come up with more. Within ordering based, you have the type that is based on other transactions. So this is 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 base on other transactions you have, we split it up into absolute ordering versus relative ordering. So the relative ordering would be what we term front running. Absolute ordering would be what we term dark forest. And then when you're not trying to be based on someone else's thing, it's called blindfront running. And within the blind front running, I'm sure there's a whole swath of like, you know, things to talk about. Well, 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 going to, you know, if you zoom into there, there's an entire subtree of categorizations that can be done that will probably be interesting to someone else to dive into 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 based on other transactions tree. But you know, I think a lot of the stuff that has to do with auctions and MEV auctions and things like that are really trying to solve a lot of the problems that happen in that blind front running category. Then I just want to provide a little bit of categorization to some of the different solutions that people have come up with. For MEV mitigations, I'm just going to put them into three main buckets, but there's probably more. One is cryptographic, the second is threshold based, 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 distributed in some base. And then there's also application specific ones. So 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 for the order randomization you have some sort of randomness, whether it's from A VDF or some sort of threshold threshold key which you know, I guess if it's from a threshold it's somewhere in between cryptographic and threshold based. But yeah, that would be a cryptographic solution. Time lock encryption is a type of cryptographic solution to the mempool privacy. 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 use snarks and MPC that like mitigate MEV in a way that's like very different than like you know, than you know, the state machines that we're currently used to. Anyways, then you have the threshold base and you know, within that we have examples like the BFT time where you're take, you're saying hey, the proposer doesn't get to choose, all validators get to choose. You have threshold encryption where you say hey, all the validators have to contribute to decrypting these transactions. You have the joint proposals, which is like the way of allowing for inclusion. And this is really interesting because I think like I said my own definition, I posited at the beginning where MEV 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. You're basically trying to move these powers to have the same security model as your consensus system itself. With threshold encryption, only 2/3 of your validators have to come together to decrypt a proposal to decrypt the transactions you make that follow the same security model of your proof of stake chain itself. Obviously what you need to do is now figure out how to add slashing conditions for each of these. For threshold encryption we've come up with a lot of different slashing conditions that seem to work well. The Tendermint core team has come up with a lot of slashing conditions for BFD time to make it work pretty well. I'm sure a lot of the 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 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. So an example would be things like slippage tolerance, right? The fact that like amms and many DEXs have slippage tolerance is sort of in and of itself an 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. You have batch execution. Batch execution is a form of how do you do DEXs and you provide more fair pricing for everyone. That should say liquite stability pool. So the Liquite protocol, one of the cool things that they did in their thing was they said, hey, in MakerDAO, the auctions, the liquidation auctions are way too weird and too subject to mev. And so what they did was they said, hey, we're going to build into our protocol a stability pool that provides fair access to liquidation revenues for everyone who helps deposit into it. And so that's also another example of a application specific mitigation. And then just like tips and tricks like don't use bad randomness like timestamp, like timestamp as a randomness source. Right? That would also be a type of application, application specific mitigation where you're telling the application developers, hey, like you know, avoid this thing. So yeah, that's, that's the end of my talk. I hope you know it was pretty fast and lightning round, but I hope that helps give some clarification of like, okay, these are different ways to start thinking about mev. And then once you understand, 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. Thank you. All right, thanks Sunny Hasu, you're up next.