Shutter - preventing front running & malicious MEV - Luis Bezzenberger (@bezzenberger) @ETHDubaiConf

Transcript

hi i'm luis i'm going to present about um shutter network um which is a malicious mev and front running protection mechanism essentially most of you may be here or watching online might be familiar with the problem of mev which is a sense for minor or maximal acceptable value it's it's essentially the revenue that a block producer can extract via front running injecting and reordering transactions and it's an emerging issue that now commands up to 50 million dollar sort of per per month just on ethereum alone and it's also applicable to all other

public blockchains so as a very simple example just to go through this is a front is front running and front running is the practice of someone getting a transaction executed before some someone else and essentially being able to buy for example buy cheaper and then even sell more expensive to the to the victim afterwards by having some information advantage or having being able to get your um transaction executed before the victim then suffers from from higher price and potentially a failure transaction and yeah so that's a simple simple example but there's much much more complicated

um arbitration techniques and things like this um why should we care about this so um generally speaking um the the problem isn't really arbitrage that's a it's generally considered a good thing you want to equalize prices on on dexes and everything um and so there's a large portion of mev that we considered non-malicious but what we can probably agree on generally speaking is that front running is is malicious and then um just generally speaking the way how mev is extracted um and and potential monopolies forming around the extraction of mav that's that's would be considered malicious

um and um and that's the focus that's our problem that we're focusing on that's what we want to um solve um so yeah there's this more concretely worse prices fair transactions yeah and then one one more specific case is layer 2 med so generally speaking people don't think about layer 2 mav yet so much because it's not apparent because generally we're trusting the roll-up sequences to not not to extract mev because yeah they're big teams and they they have something to lose if they would front run their own users but that's not an optimal case you don't want to trust your operator that's not not how we do it in blockchain

essentially so so mbv does also exist in rollups and and is it might even become an even larger issue than than on l1 because the roll-up sequences are more sophisticated and more centralized and these are just some some some pictures probably you guys have seen some of these on on twitter and others very sophisticated arbitrage are very um people making two million dollars per per arbitrage yeah just to yeah so that that was just sort of explained the problem of mav and maybe also in layer two and um and now we come to what we are building

our solution which is really speaking is we're using threshold encryption and a dkg distributed key generation to combat front running um on a very high level it works in a way that transactions are encrypted um and signed by the brock producer while they're still encrypted um so that the the block neither the block producer nor anyone else can can see what's introduction so they can also not front run or censor and then and then the the issue with this or if you were to trivially do this with your own private key encrypt your transaction with your own private key that would lead to a free option for the users not to decrypt

afterwards which we want to prevent so the whole system is a little more complicated that's why we use threshold encryption and we use these keepers system so think about sort of a keeper 50 to 200 crypto node providers that collaborate and run these the threshold encryption mechanism dkg collaborate to generate the encryption key which the users are using to encrypt and then the block producer or collater we call them um signs the the block finalizes the order of transactions basically and then afterwards the keepers collaborate again to release the decryption key

um and that's where we ensure that the transaction is actually executed um so we use we solve this free option via um threshold encryption and here's another sort of look at this very simply speaking is these keepers on the left at our lower left side they collaborate and then the on the top the transaction can pass through this metaphorical um dark forest um and then we are implementing shutter so there's sort of the first iteration we've finished mid of last year we built it as a smart contract system which we call onshade it can protect any any one or multiple smart contracts from front running but

it has some sort of downsides that i don't want to get to go into but essentially which we which is why we've switched off focus to something called rolling shutter which is the same mechanism explained explained before but implemented at the roll-up level at the sequencer level so that the shutter is integrated into the roll-up making the entire up mev or malicious mvv protected and censorship resistant um and i will go into more detail on this but just to say um on the other two other efforts we're also sort of pursuing on the side is we made a proposal to a heath research forum

to propose to implement this mechanism into into the actual beacon chain into the ethereum 2.0 which is a but it's a longer discussion there's not gonna that that's just gonna require discussion we're gonna require sort of experimenting um people want for you want to first see how it's how people how the rollups are experimenting with this and whether it works in that level and then we have another thing that uses the same dkg threshold encryption mechanism but not to combat mev but rather to encrypt dowel votes and to make dowel voting more fair and we're working with snapshots on this um there's the overview of what we're

working on and now sort of going deeper into into each of the um these uh things as rolling shutter is again is is sort of implemented into the roll-up shutter intermittent into the roll-up and it makes it ideally makes it possible to maintain a long-term centralized operator a roll-up operator without all these negative side effects that we would see with a centralized operator so currently if you have a centralized operator again they can extract mav they can sensor and then with shutter hopefully these side effects go away and then to quote um john wang from from immutable saber we he says uh the roll ups with the

best mmv mitigation mechanisms will have an edge so i think we think this could be a value add for any roll up um so yeah and we're exploring and talking to a bunch of uh optimistic roll-ups so far and see how this goes um again this is the shatterized beacon chain i i'm not gonna say a lot about this but it's yeah the same mechanism but proposed to implement at the l1 level it's going to be more more sophisticated yeah but feel free to look into this or comment we love feedback on this yes and then shutter governance is is what i talked about is this encrypting dow votes um so essentially there there might be some

misbehaviors that that people in dow votes uh endow voting are experiencing so one one simple example would be if a large whale can um sway the the vote last minute um because they'll see how many votes they need to sort of buy or borrow to to they know exactly how many votes they can they need to to sway the vote last minute something we see see quite a lot and then so the idea would be if we were to shield the voting if we had encrypted votes that would prevent them deter them from even trying trying to do so and there's some other um sort of game theoretical behaviors that that we will have hopefully um

improve with this encrypted voting and yeah so it's a commit reveal scheme um and we're working um mostly with snapshot to to integrate it directly into snapshots so any any dow can then uh any snapshot dao can then can then access it um quite soon and then also clara's claris is a guy should be familiar with this it's an it's a court system arbitrage system and they sort of their game theory benefits from um having the again having the votes be shielded um so they could also benefit from this and some early talks with them um this is just a small thing my colleague janik built this is a it's a game as a dow to dao game based on

based on shutter so it's a diplomacy implementation but dows are collaborating and dowser collaborating with the other to fight other dows but it uses shutter to encrypt game moves so that the the game moves aren't um uh observable by the other dowels before they even execute it and then this is just a just a small um announcement or not announcement but just want to do some advertisement for this um larger event um at um in the context of devconnect in three weeks i think is this mev day which is a full day of exploring all kinds of

movie related topics and we co-organized with flashbots and um cow swap on this so if you guys want to attend there we would encourage to apply so yes you have to apply to it essentially so yeah again we our goal overall is to partner with um especially those who need anti-mav solutions or anti-front-running solutions um or if you're talking about the shutter government and other things like this um ux friendly combat and revealed schemes so yeah love if you um like follow us on twitter or contact me afterwards yep thank you that's it yeah yes sir so we uh we already take

questions from the audience so if anyone has anything to ask we can give you the mic any questions so far well probably i've got the question like uh where exactly are working like like are working in broad already and with which chains is possible to like see your benefits so the this first effort um what i call unchained shutter so the smart contract system that you can um deploy to protect any any smart contract that's um working and it's in fact deployed in the context of this game on norse chain

but our main focus is called rolling shutter um so the roll-up implementation isn't isn't live yet but should be coming out very soon so we actually haven't announced it yet so this is a sneak peek here so we'll announce it maybe today or coming days so yeah but it's also quite far in the development so it's also going to be released quite soon and then who are we collaborating with so yeah we're exploring with all the major ors and then also talking to some of the side chains so so nosy chain for example because yeah but only ors or for now for now or ours because again they're more probably more quick to um to be viable we've all we've talked to some zk revolves in the past but sort of for now

the focus would be on os okay and what about like l1s that work with them as well yeah so that's our track with the sort of publishing it to each research forum and getting feedback from from the ethereum foundation there and some other people and then again this is they're not going to be adopting it anytime soon but smaller chains like gnosis chain they also want to create their own beacon chain right they are open or interested in in prototyping it uh earlier than ethereum itself sort of yeah but is it easy to implement uh rolling shutter on chain or like no the

the rolling shutter is easy on the on the for the roll-ups and then implementing it into the l1 is a much it's a more involved um process and going to take longer okay okay it's interesting because we are all here so working on like uh launching our own chain so maybe we can try to integrate with you somehow awesome yeah and one another path to this would be to if it's a mbm compatible chain is to is to have a rolling shutter so have a shutter mvv protected roll up on that chain at the first so just try it out and then yeah so notice there's already is optimism and arbitrary running on those as well so so that's also another sort of maybe smaller step you

other chains can take to to prototype this okay great thank you very much thank you so no more questions okay thank you oh yeah there is one question sorry i missed the earlier part uh can you explain the mechanism in short uh in brief like how exactly does it work yeah so i'm not going to none of this is like too detailed but you can read um on our blog post but so yeah very briefly again transactions are encrypted um and then

batched and signed while they're still encrypted uh and signed by the correlator or validator or rollerball data while they're still encrypted and then afterwards um get decrypted and then the complexity there again sort of the keepers that collaborate to generate the encryption key um to to that's broadcasted released and then the whoever um submits a transaction uses that that key to encrypt sends that encrypted transaction to the to the block producer rock producer signs and then keep us collaborate again to generate the decryption key and that's used then to decrypt and then it depends a little bit on the implementation who

exactly decrypts but yeah either one of the keepers or we have another role called decrypters depends on which level we we integrated does that help the question here oh yeah i have a question about the claro's integration how would a uh dispute resolution layer uh work exactly in this regard like how how would that look like same same as before just that you don't see the uh that you don't see what the current telly uh so you would just say you just

submit your vote and you and and only um after the the voting period is over it would be released okay thank you so it seems that no questions for now no more questions so we're going to let you go finally thank you very much for your talk yeah very interesting technologies you're working on you