Privacy All the Way Down: Tackling MEV at Different Layers via. Cryptography Jannik Luhn et al.

well i supposed to get started in alphabetical order uh we are working on a system for distributed key generation threshold description uh called fairview which is a collaboration with sikka so dave can probably speak as to any parts that i miss or perhaps parts that i don't even know about yet one it sounds like you've already covered as you've referenced in the slide special description i'll just note that the way we integrate closely into the consensus algorithm in this case tendermint although the approach to generalize to any sort of like multi-phase vft consensus allows us to more or less avoid the one block delay i mean there's still latency in so far as the validator set which is the same as this set which has to provide threshold decryption shares in our case has to like compute the shares and combine them but because we can just put the threshold decryption shares for each transaction in the pre-commits entenderman so in this in the last phase of the bfd consensus round uh we can execute the transactions in the same block decrypt and execute the transactions in the same block even though the proposer who has to propose before the pre-vote round uh which happens before the pre-committee round has to commit to an ordering of encrypted transactions by the time we get to pre-commits if a block is finalized because we have the same set for uh two-thirds of the quorum requirement to finalize block and two-thirds of the share requirements transactions those two coincide and so we can decrypt and execute the transactions in the same block in which they were committed okay maybe i can fix the next one uh hi everyone this is early uh i'm the co-founder of automated network uh so for those of you who heard about us for the first time we are building privacy middlewares for the apps across multiple chains using sjk and oram so our team has several researchers who has been doing svx research since 2014 and some of us were previously working at a security research lab in ius national university of singapore and just to let you know uh before uh tom the network this research lab already had a few such successful spring of uh crypto projects such as cyber network and zelika so under this context of mev we are actually developing a decentralized privacy middleware called conveyor to help dexes to minimize mvd and also if you happen to know that uh we actually also released a small free tool called mev.tags for people to inspect if they have been sandwiched attacked previously so our approach is uh we are using uh trusted hardware pe or uh intel stx whatever you you think the term is to try to just hype the transaction temporarily and determines the transaction ordering before it is published and to and to preserve the maximum compatibility with existing blockchains uh it will review the transaction only after the ordering is locked decided and locked so that means uh layer one block producer and also uh layer two sequentials uh cannot i can can can we we just process it as normal transactions but they do have they don't have the ability to uh to change the order anymore so this would allow us to directly work with dexes on managing and to protect existing users with uh with a non-intrusive integration with them so uh so and and maybe a little more details about it so the ordering we are we are providing here is actually particular to uh uh it's very application specific so we can even just provide a lot order only for the uh a particular trading pair and we will have multiple uh trading pairs running in power live so we would it's kind of just a scalable way to for us to support uh dexes and the other technique we are using is uh is called oblivious ram uh which uh kind of directly enhances the privacy of trusted hardware and it also radiates the bar of uh breaking dee uh through side channel attacks so we know uh uh trusted hardware can provide these safe rooms or enclaves but it actually doesn't solve all the issues for example the traces left by this uh enclave when interacting with the outside world could look it could leak information even your data is encrypted before leaving this enclave the access pattern that it reviews uh could be uh collected and learned by malicious node operators and then used to infer the computation inside your enclave so uh so there have been papers that uh successfully apply these sidechain attacks and and also extracted uh private keys from dee so it's it's pretty uh dangerous in some sense so um so and this this kind of attack involves many runs of profiling probing and analyzing and the sensitive information is actually reconstructed sometimes bit by bit based on the access pattern that that were exposed uh so um so maybe i can give an example of this so if if something looks like a duck and swims like a dog and clocks like a dog then it probably is a dog so if some of the observations of the excess pattern could be associated with a certain computation with very high probability then the observer would know what you are doing even you are using traffic hardware so oram is trying to change the access pattern so that even the traces are observed it will be uh useless because the uh the access pattern will not make sense anymore to those observers and this line of research as this actually has been there uh for several decades and the idea is just to providing uh just to uh kind of shuffle the access pattern uh just doing more uh useless work but uh the end of it ended up just uh uh just uh doesn't allow the uh observer to get an useful information from that so yeah so that's uh the uh the pet of the uh technologies we are using to to try to safeguard the privacy of the transaction otherwise okay cool uh who's next i think i can go next um this is john um from secret network uh secret network is a cosmos sdk based uh layer one chain um where where every validator runs uh nsgx and um as a result the the privacy so um as everybody that wants to know checks uh what happens is we can ensure that all contracts on the network are privacy-preserving contracts and um the way this works is um valid there's one chain that's uh one one uh private key that's uh shared across all the validators that's generated uh within the sjx or trusted execution environment and when a user is interacting with the network they create a symmetric key by using their private key and the network key and encrypted inputs are stored in the memphis that's why like no one can really see what's going on uh as to what the inputs are and then um validators take those encrypted inputs they can decrypt them inside their enclaves uh because they have the network key the computation takes place inside each validator's enclave and then validators share hashes of the computation results on chain and form consensus based on those on those hashes and um you know assuming there's consensus the state updates the states also always encrypted uh and stored on change that's uh how secret network uh deals with front-running attacks and now we've had um secret contracts live on our mainnet since september of 2020 and we have a functioning functioning amm that is front running resistance since uh february of 2021. okay well i guess throughout the panel you have you'll probably have the time to go into delta talk about how you default from automotive number so let's see who's next uh dave yeah hey hello i'm dave um so we're going to project called osmosis and one of the things we're doing to front front running as chris mentioned it's like working very closely with them is to use threshold description so again chris uh kind of summarized this earlier so i think what i'll i'll talk about instead some people is how i want to handle fair ordering which i think's also an important question so with threshold decryption on its own you know the proposer can still try to get their transaction as the first transaction or the last one so on top of that we kind of imagine um arctic unfair ordering is not the same as like kind of the wendy or equilibrium it's instead which is like this kind of time this take on when something arrives in imagined global memple across all nodes and instead we're trying to take that everything in a block should ideally like be treated as though it came at the same time so you what the way you can imagine this for something like trades is then you can imagine you had a random permutation of the trades and you take the average across the random permutation for how your trade would have been executed in like sort of a batch environment and then for things where you can't really white box like that where it's not clear like transaction sends for instance then you take a random permutation so uh the idea is then summarize for orderings and take for things you can white box like analyze do some light box analysis as though everything was came at the same exact time or you have random permutation of them all which you can which applies for trades on unison for instance and then for things you can't take a random permutation based off of decrypted contents and then do some other techniques to ensure that there's some decrypted content there's some transaction content in there that the validator who's proposing the block doesn't control uh yeah that's like what we do for uh fair ordering on top of like special description things interesting uh yeah i guess i'll have more time to go into details um let's see who's next uh barry can you hear me yeah hey everybody um yeah so i might take on um mev prevention is that there's two kind of approaches the first approach is where you limit the amount of the the group who are able to take advantage of of minor expectable value and that's where you see solutions like encryption and threshold decryption and the second group is where the second approach is where you you make it kind of impossible for you you kind of randomly order transactions based upon you you just randomly order them so that even if someone is kind of front running you're not able to get as much value out of it but there is like a certain class of mav that we're not really able to prevent with either mechanism like for example if someone is getting their collateral slashed there's gonna be mev there and even if you order the transactions randomly someone is going to get that and like this will actually produce this kind of weird incentive game where people are creating thousands and thousands of transactions because they just want to be the first one ordered by the block so there's these weird kind of incentives that appear and i'm yeah so that's my take and maybe there's some interesting things to discuss about that okay cool so christopher when okay so yannick yeah i guess i'm the last one can you hear me yeah cool so yeah i'm from um shutter and we're one of these projects that use threshold encryption to prevent front running um yeah it's very similar to um for example with zika does i think the main or the general principle is very similar the main difference is that we not don't see us as a new layer one blockchain but we try to interpret this as a more general technique that can use and apply different layers and the first layer that we applied it on is very close to the application layer so we implemented this as a kind of a smart contract system on top of ethereum um so that users can send encrypted transactions to ethereum wrapped of course in a normal ethereum transaction and then those would be um at some point decrypted and passed on to to another smart contract which would then be frontrunning protected basically as long as they only accept transactions through this mechanism yeah that's the main idea of shutter at the moment okay so yeah i think that is everyone um so i guess yeah from the introductions um everybody's working on different solutions and they're meant to be deployed in different ways so some are working on uh layer one solutions um and then others are working on drop-in solutions for developers um a sort of a plug-in and so the main point of this question is sort of what are the pros and cons of using your respective technique at um you know these different layers layer one or layer two uh an application layer however you'd like to to answer that question yeah i'll leave support to you guys to choose your order okay uh maybe can i start first um so yeah our solution is actually uh so the pros about the solution is is fully compatible with uh any kinds of lager one and layer two uh because we are really just trying to provide uh this solution as a plugin to the existing system so that we can help the users and also the daxes and and most important thing is we are not modifying any uh layer one layer two protocols and also at the application layer we are able to offer uh kind of different uh variants of implementations that balances between uh easier integration uh better gas efficiency or even higher fault tolerance so for example if you just need a very quick patch to get rid of mev uh so you could just build off a single uh trusted relayer that does a very simple uh fifo ordering uh that will just uh kind of solve that but for sure that's uh that introduces a single point of failure so maybe a more uh decentralized relayer network that runs a little bit uh consensus algorithm to ensure ordering is better and in terms of the integration actually since we are just directly working with uh taxes at the application layer so they could just adopt this approach very easily as it only needs to kind of acknowledge the ordering coming out from the trustee layers and also this this kind of meta transaction approach also uh brings another quite interesting design point uh where we can actually make the transaction guess less and user won't need to pay uh in the native tokens for the cash fields and also uh since we have this great flexibility uh our design also uh make it possible to to work with other mev solutions as well for example we can with work with flashboard in order to just ensure the uh the other transactions are delivered without being kind of censorship by the miners um and if you and talking about the uh the cons i think uh it's really about uh when you build this kind of really network it really takes time to uh to fully decentralize your entire system but actually since we are using trusted hardware each individual node in the system has a slightly different trust model than the uh just just the random node that are hosted by anyone so uh we we we sort of have by a slightly better confidence on this de node uh so uh in that sense uh even we're starting with a smaller number of nodes the system overall is uh is actually by uh it's also secure yeah i guess uh that's uh that's the uh my uh my take on this i guess i can go next um for us um when you have smart contract privacy on layer one the things that you can address uh with that is like much more than uh anyb um like you could have uh like nfts where the content is encrypted and you could get into like more subscription and and content access or content monetization like use cases uh in in the world too which to me is very very exciting um and also like building things are are are easier um but then the problem is then you know you have to build a new ecosystem and have new people build applications on this new layer one rather than plugging into another network i to me that's like the that's the big trade-off um and i think one thing that we are doing uh more and more is to explore um some sort of like uh like an operator model whereas you know in order to target someone who's on ethereum and like you know just like a simple use case say want to do a mix like one thing that uh we are working towards is how to allow the user to do that just with the metamask transaction rather than getting into the whole cosmos ecosystem of wallets and then tooling and um and and and i believe like that will be something that will allow us to target more people um and where like you know we can have the user get a key from the secret network to the help of an operator and then when they're making their ethereum deposit transaction they can also like you know create a um an address that where they want to get their funds back that address can be decrypted in secret network uh i guess that's similar to what you have been mentioning daily and then you know sent back to uh sent back to ethereum to just like you know make a new transaction um yeah but that means that like you know may not be as as exciting in the in the med index cases because it does add some latency we're also building onoma's also building a layer one and i would agree with the primary disadvantage of simply adoption from zero or building a ecosystem up from scratch although i think some of that can be mitigated with good interoperability protocols the other point i would note uh specifically with relation to med is that it seems to me like for some of the protocols involved which use randomization or which use threshold decryption in ways which are uh you know where there are like a bunch of transactions being grouped together and somehow combined as dave was mentioning or being randomly reordered there's a little bit of a sort of network effect or like the larger the set is the better the uh like guarantees or the better the kind of unpredictability individual transactions have and it seems to me that's easier to achieve in practice when you can make it the default in a system as we can much more easily do in a layer one than perhaps in kind of an add-on solution just because the whole system can be architected to integrate it as like the default pipeline for submitting transactions and we can change generate consensus strands like i mentioned so it's very easy to achieve a kind of holistic integration uh such that end users can really use threshold decryption without knowing it and such that it's so easy that even transactions which don't need it and probably aren't going to want to pay additional costs either in gas fees or in user experience to get it uh can get it for free and thus contribute to the public good of more transactions being randomly reordered or whatever uh i can go next i think chris sunrise is pretty well i guess i don't want to say on the point of like mev resistance tactics and i don't think there's actually a meaningful difference in pros and cons between l1 and l2 really what you're doing is you control your own like chain your own consensus and l2 or really roll ups really just means that you have some data that needs to be posted to eth or you know whatever base chain and and some priority for like how getting transactions from each onto your chain that's not really like an mev because that's like a fun transfer thing which didn't really have too much immunity that really had like latency and sensor resistance concerns so i think the key questions to ask is just your own chain l1 l2 as one category versus the app layer and then for something like threshold decryption the guarantees actually differ a lot here actually really for all the mempool privacy techniques except svx so i guess menthol of encryption and threshold encryption sorry timelock encryption and threshold encryption the guarantees differ a decent amount um like because you're doing in the app layer to get these strong guarantees you kind of have to make your own subset of the chain that's only taking in transactions from this encrypted layer here otherwise you get these like issues where since you know the decrypters can never guarantee their transactions going to get like when it's gonna get included they could broadcast the decryption and then if there was a path for someone who's not using decryptions to get their transaction uh in first they do is they'd see the decryption being broadcasted over the ppp layer here and then they front run that before the description get gets posted on chain then defeating the point so it's actually you have to so when you're in that player it's actually pretty hard to like you have to kind of make your own inter uh subsystem which is not going to be interoperable with the uh rest of the ecosystem so i think that's like a key difficulty you have with a really these mental private techniques when you're at an apple layer versus your own chain yeah sorry to interrupt you dev i yeah i completely agree with what you're saying that was the point that i was i was trying to make and maybe to drive the point home just to drag it out a little bit more um so the example here is that okay if you take unit swap and you say we want to make a private version we want to make a mav resistant version of uniswap there's always going to be a place where the mev resistant version goes to the smart contract to tell it these are the orders to place and at that point you're able to front run and this is this is the concern that you end up just building everything in a silo where you have like front-runner resistant unit swap and then you have unit swap and then you have front-runner resistant compound and a new compound they can't really be interoperable between each other and this is this is a big concern i guess i i definitely agree with these concerns that's also the main issue that we see that this application layer front-running protection breaks composability in in some sense um the reason why we still started there is that it's just much easier to implement and you can just focus on on this particular problem of front running protection and you don't have to worry about all um the other stuff i mean building a new blockchain is very hard building a new layer too it's very hard it takes a long time and so this is um one reason why i think it makes sense to start there um and the other reason is yeah i think it has already been mentioned that it's um the problem exists at the moment um on on layer one for uh for many applications and it doesn't really help them if there's a uh mev or front ring resistant uh layer one or layer two somewhere else if the application is on that layer that is not protected against this so that's the two reasons i see for um in pro of application layer and just i guess to like build upon this is like depending on the application um you you might be willing to like take some amount of i guess latency um so i guess asking you guys for your respective techniques do you think um some categories of applications are better for um are like best suited for your technique or um are there another is there another technique that's like probably better or maybe you think the case solution is good for all techniques uh sorry sorry for for all applications um any thoughts also i think a lot of differences based on the security assumption you're willing to take so like i've been working on tendermint things for years now where in tenderness is proof-stake algorithm where you say i trust that over uh that like kind of two-thirds of this validator set is honest but then i can detect their faults and then if they commit some slash them and if you're willing to take that assumption then i think the threshold decryption like security is uh works for like all the uh kind of really all applications i can think of which are kind of siloed to one chain then you do have some like cross chain uh concerns but these are really inherent to all the techniques uh and so i think the reason i think like sgx is uh astrix comes uh interesting for like when you want more than just like uh bump level encryption but you then take the cost like what what happens in spx breaks and similar time lock is like i think interesting if you're willing to make hardware assumptions but not these multi-party assumptions that you typically do in proof-of-stake so i think it's really around the security assumption for time lock burst threshold and then for sgx it's like uh well okay we're taking the lower security because it's cost frequency x and we're instead pivoting to like okay well here what else can we do on top i i think like my argument on that point is that like it's a different trust assumption if you're trusting the the majority of the chain to not do something that can potentially get them slashed it's very different from trusting the majority of a chain to do something that they can never be slashed for you can never prove that they did this so there's there's no there's no punishment for for the validators if they if they if they um kind of front run people there's no way to even know that well you can kind of know but not really but yeah that's my sorry definitely yeah oh i started agreed i spent a while trying to think about this like to what extent is this slashable and uh i feel like the best way to get slashing abilities is is to have the decrypter shares or the the crypters be in uh do the decryption work in an sgx so that way uh they're still forced to be behaving the protocol correctly yeah but you still everyone only needs a cryptographic assumption to like know that their uh their protocol was done correctly uh but then it's sorry as a defense in depth so it's like okay well now you need to you know break it uh trust an enclave and break cryptography and break this two-thirds assumption yeah agreed this is uh definitely hard there's no solution to that problem yeah if there's an offline collusion attack there's no way you can know it well what you need is you want to be able to have a defector report so like in proof of stake the reason this is we can double do double sign protection is that a light client at the end of the day needs to get um the double sign a different signature than the rest of the world and this can be reported so far running the problem is that only the validators actually got these decryption shares so to get a similar guarantee you'd need that any any member of the validator set can defect and prove that hey look this cabal tried to decrypt something when they shouldn't have hmm okay i understand yeah i think so i don't know how to actually do this without like more assumptions uh interesting point but i don't want to take all the time but let's discuss another time i think there's about five minutes left so uh yeah if you want to answer this question or we can quickly go on to the next question so i'm gonna take that as we can quickly go over to the next question um so yes the last question is um we're all dealing with either hardware assumptions like sgx failing or trust assumptions such as some quorum of nodes being honest um or at least incentivized um so how do you guys handle uh failure failure scenarios for um your technique um and if so like how does how does it affect the user how can they recover so as always has been mentioned it's very hard to prevent these key shareholders to collude with each other and therefore i think it's very important to make sure that they're well incentivized to not do this mainly by having a lot of them because if there's a lot of shareholders they will it's much harder to collude and it's easier for a single person to defect and notify the world about this and the other way i think um this should happen is that they are selected in a um in a good way um so not just randomly and not just um [Music] the spot shouldn't be sold to the highest bidder and that's at least what we're trying not to do but instead select them from different organizations from different sets of people to make sure that they're not all not a single person and lastly to give them uh very long-term incentives um so that they um have a financial incentive for the system to or for keeping the system honest and keeping the system like keeping users trusting the system kind of and to do that we probably want to have a kind of dao that does the selection process because it's very subjective you can't really write a cryptographic or economic protocol to do this well i would call that a little bit i mean i think in the case of proof-of-stake systems you have already a naturally incentive-aligned group of participants in the validator set who are because they're staked um aligned in some sense with the long-term success of the protocol and to potentially have sort of out-of-band or chain external reputation on the line plus they have the ability if they are able to coordinate include in large enough groups to commit more serious faults potentially than extracting mvv so it seems like it seems to me like that's a case where there's a group that already exists and you wouldn't need a separate selection process i think i think on that point i i kind of think about the kind of validator set as this like economic group and this is the group that are selected based upon whoever is able to make the most profit from from what they're doing and i see like exploiting this kind of minor extractable value opportunities it's just like another potential revenue stream for them like you've seen this on ethereum when the the ethereum miners started on mass to to use flashbots or from running methods to to increase their rewards and i i'm also super worried about the stakers on ethereum doing this when we move to proof of stake and it seems like just such a natural thing for them to do um i i agree that like having these mechanisms in place will will like some of these mechanisms will reduce the amount of money they're able to extract but i feel like they will they will get more and more sophisticated because because that's just how they make their most money that feels like the natural place for them to do to be you know for us because uh of the hardware guarantees this is um like assuming uh the valid i mean side run side channel attacks are going to be expensive because you have to pay gas and then uh actual physical uh way to hack um the tes is assuming most of these running data centers is not very i think practical um and so so that's how we think about it but like worse comes to worse like you know you end up with exactly in the normal uh blockchain kind of scenario okay cool so i think that ends this panel i'd like to thank everybody for taking the time to answer these questions and for i'm going through the trade-offs um on your respective techniques i guess tina can take the floor