Survey of Privacy Solutions for Minimizing MEV - Mikerah

uh so hello everyone um i'm akira and um today i'll be going over um a few solutions um that are mainly like privacy focused or photography focus for minimizing mev um this is a current work in progress that we're doing as part of a flashbots grant so if you have any feedback any questions you can always just reach out to us um and also this kicks off the whole like privacy part of the talks today so we'll also have a panel afterwards so you can ask your questions during that time as well uh so i guess a quick recap of what we what was discussed over the day over the other talks um some mov is very mo is a very multifaceted problem uh manifests itself in different ways um that's actually have different ways to solve it um and keeping that in mind we know that and not all maybe is bad in fact some of it is just going to be as part of you know building financial applications um and the goal of this talk is mainly to discuss um how to use cryptography in order to solve mev and we'll look at ways in which people can try to use i mean sorry try to use these solutions today and they're in their applications or whether or not that might make sense just have this as like a layer one solution and then later on in the panel we'll dive more into um that aspect as well um in addition we'll like briefly go over some uh directions that we're pursuing as part of this research as well that's way more experimental i'm not sure if we'll have time for that but yeah so in the context of mev what exactly do we mean by privacy um so there's a few considerations that you might that you might want to think about when thinking about privacy in this context um so this is the concept of pre-trade privacy which is um if you're sorry which is the context of trade so you [Music] send the trade to be spent um but oh no freezing okay so field trade privacy is um if you're sending a bid then and it's a losing bid then you don't want your um you don't want the mempool to see that um the concept of free trade privacy which is slightly subtle is that um you don't want uh a failed transaction to be seen in the in the mempool um so the zone between these two uh the differences between these two are very subtle uh which is why it kind of goes up there and then the concept of complete privacy which is the most desirable one which is probably what most people think is um when like everything is hidden from the mempool until it's time to execute the transaction and the focus of today's talk is effectively on complete privacy solutions um i guess a very short overview of the design space for just solving mbp in general there is the um side of using more like math and economics for solving these problems and i think later on in the talk and earlier in the in the day people discussed those kinds of solutions um and then today will be focused mainly on the cryptography side of things so there's quite a few different uh solutions that people have come up with over you know the past years to solve front running and mev and ethereum we'll briefly go over each solution and i guess as as part of this being an ongoing work if you have any more suggestions or ways to combine these just just reach out um so first we'll go into commitments um cryptographic commandments are a really easy tool to use for trying to solve for running for your application um so briefly you can commit to a message um and then later on you reveal it whenever you want and so in a specific context what you do is you would commit to a transaction and then once it's added to a block you can reveal the transaction later and then have it execute the main issue with doing this is that you need like an extra block delay because now you need to execute your transaction which is not the best in terms of user experience for the users of the application implementing this but a good side of using this is that you can just typically libraries that allow you to just do this as a drop-in replacement however due to this like one one block delay it's really deployed in practice so from commitments uh you can use zkp's um and i guess most people here are familiar with tkps very briefly it allows you to prove statements without revealing um important details about that statement so in this case um you might want to prove something about a transaction such that it's within a specific the gas price is within a specific range um and that it's a valid transaction but you don't want to reveal the transaction on chain because we're trying to make it such that people can't you know arbitrage certain kinds of transactions and the nice thing about zkp's is that they're quite flexible so you can sort of ha aggregate many transactions together and prove them in a zkp um and typically we've seen this applied at both like the protocol layers um in the clear one blockchains and at application layers in the forms of different l2s um and they tend to not have a significant of a delay as the commitments that we just looked at and there's also a lot of tools for for using ckp's as well so the next one is timelock encryption which is also just an application of using commitment schemes so uh in the vanilla commitment schemes what you do is you commit to a message and then you refill it whenever you want um but with timelock encryption there's like a set date by which you have to reveal the message or set time specifically um and using timelock encryption you can like build these time capsules in such a way that you need it to solve a puzzle and the puzzle will reveal the commitments and this allows you to effectively uh uh prevent front running in your application um and this hasn't seen widespread deployments but it does work at both like layer one and at the protocol layers and it has like the similar similar issues as commitments in terms of uh the delay it provides to users um and the tooling for this isn't as uh ready compared to like ckp's uh yeah so then this threshold decryption um which i think was brought up earlier today in a separate talk um so in threshold decryption you have quorums of miners or validators that have each have a share of a private key for for decrypting messages that users encrypt and depending on whether you're in a full worker stake system um there's sort of delays on when when you can decrypt these transactions um most games i've seen usually have at least a one block delay on executing the transaction because you have to decrypt the transaction um and as such usually this is done at l1 but as we'll see later there's an attempt at doing this um at the application layer so that it's a drop-in replacement uh or a drop in addition to your that while you're you're building um so then there's sgx which is also another way that's been posed to solve mev and sgx is a technology by intel in which you can store data in these like secure enclaves and the data can't leave um these enclaves so um all the computation and accessing the data has to be done within these enclaves that's isolated from the rest of the os [Music] so pretty much what you need to do is find a way to sort of split up the encryption key for accessing the enclaves um and that's how you would do your uh your computation so practically how this is used for solving meb is that you can verify um all sorts of complex statements capability of transactions and blocks and stuff like that um so what you do is you would split up this private key that i would use to send messages to the enclave um and then the sgx can ascertain the validity of um the transactions and then depending on whether you're in a proof of work or stake system you either get the unencrypted transaction data or proof um that your transactions are valid and then you can use that as part of um consensus and depending on how it's instantiated you might get uh just as good as linty as like a the current like flashbots up one of the downsides though is that you do need to rely on intel for being an honest manufacturer although there are some attempts at making some open source versions of this kind of tech and lastly there's mpc which is um you can kind of consider as a software-only version of sjx which allows you to compute arbitrary functions without knowing the inputs in a sense threshold decryption is a instance of mpc um and more famously i guess mpc's is known for being inefficient but depending on the constraints of the system um it might not be as inefficient as one might think however it does introduce more trust assumptions on unknown behavior that might not be desirable depending on your use case so i guess we're nearing the end of the talk um some current work that we're looking into um in addition to those other uh solutions is the use of malleable cryptography um so very briefly mayable cryptography lets you do transformations on encrypted data so the idea here would be to use something like some homomorphic encryption that will allow you to morph encrypted transaction so that you can probably still do some uh execution on it if it's possible within uh like an efficient amount of time um and then the other perimeter we've been looking at is called order building encryption which is mainly has been applied in the database search domain for providing searching functions over encrypted databases and we think this uh might be a promising way for providing similar functionality for uh encrypted transactions it does um it does kind of reduce so far from our work it does kind of reduce to the threshold decryption case so we're not sure if it's particularly useful but we do have a write-up um that i can share more widely if you're interested um and something else that we're working on is we're trying to look at using npc for providing complete privacy and flashbots so in the same way that mev sgx provides complete privacy using sgx and flashpots we're looking at using some off-the-shelf fpc frameworks for towards that goal as well so i guess that's the end of the talk and so it's time for the panel