#DappCon22 : Day 2 - How dApps Can Be Protected From Front-Running, Luis Bezzenberger

Transcript

[Applause] foreign thank you say I'm I'm Luis um and normally I'm talking about Mev kind of exclusively or shutter is an Mev protection mechanism but today here I'll keep it a little more broad on on basically the this commit and reveal problem yeah um and yeah I'm the product manager at shutter I work at brainwat but shutter is a project at brainbot I'm the product manager so anything more deeply technical maybe you should um maybe we can defer the question to Yannick who's also in the in the audience so and does that work

oh yes so um more broadly speaking than than Mev or um yeah is is a shutter this mechanism enables users to safely reveal private information to the chain and um this is something Yannick came up with a credit to him to for this basically so the the issue is right now basically if you were to um try to reveal it safely reveal something to the to the chain that was previously private it's not possible right so you're trying to do this and then someone else basically steals your information away so so I'm trying a little bit here with stable diffusion so basically without shutter you you have everyone looking at your information

that you're trying to reveal to the chain and they can take it away from you before you've even reviewed it to the chain essentially um with shutter um you can safely reveal it to the chain so I think it's cool that um disable the fusion came up with a female god so and then and then the solution very broadly speaking is Tesla encryption to um to prevent um front running and but also a bigger sort of set of um malicious behavior um on chain um for Mev and I basically have three different exhibits and the first one will be Mev so the so for Mev we want to go from some sort of a chaos situation

an MAV here I'm saying like Bots are fighting other Bots and dutchbots is fixing that to to a great extent but we still have in sub-optimal um sort of situation um to here where we want to have transactions be shielded we want to um encrypt transactions and they can be batched and signed by the block producer while they're still encrypted um such that the block producer whoever the be validator or sequencer um can't even see what's in the transaction so they can censor or front run and then probably speaking we we're using threshold encryption to ensure the actual decryption step so so we need to enforce the decryption and we don't want to have a centralized entity doing this

so so threshold encryption essentially makes sure that that is happening there is there's a first sort of committee based decryption and then also we don't have to trust the centralized and crypto decrypter um and that's sort of how that works so so think of shutter in the lower left corner as this sort of keeper system plus a Dao that that creates um Keys firstly create the the um the encryption key which is used to to um client-side by the user to encrypt transactions um then that's that can pass through the metaphorical um Dark Forest and then the keepers collaborate again basically it's not really how that that works in in the depth in the protocol itself but essentially think of they collaborate

again create the decryption key which is then used to decrypt um so so Keepers keep your keep the the transaction safe basically it's also a stable diffusion thing um so and then um for Mev um yeah I think quoting Stefan who just heard was just which is great it's it's big it's a big um uh there's a lot of Mev already um uh just yeah I don't think I have to Define it because he talked about it um we are looking at this we're looking at the and we're looking at Mev um basically we're focusing on a subset of Mev specifically we're trying to say

um there is a certain level of there's a certain amount of malicious Mev and we're trying to um mitigate this a malicious part of it front right especially front running sandwich attacks censorship and uh yeah and we think that for the end user results in worse prices Fair transactions oh yeah these are examples and I'm sure you know these um and how we are working on this or worked on this um so far as we implemented this aforementioned sort of encryption mechanism first we implemented it as an on-chain Amazon contract system that you can deploy in addition to um to another smart contract that you want to protect that is maybe very

relevant here for the for adapt Focus conference um so that's that's ready and to to implement the the and it can have some use cases the issue with this is that um it's expensive on chain and also it's um it breaks composability for for the transaction path essentially so um we're no longer focusing on that we're focusing mainly um on rolling shutter which um which is this mechanism but implemented into the um roll-up sequencer transaction flow essentially um and and we hope it makes the entire rollup the um front running or malicious mov protected and also adds this level of censorship resistance in a for a

centralized sequencer we also add this censorship resistance level um so for the for the Roll-Ups um we're the the rollouts have this dilemma right now they would say oh should we should we try to optimize for the um for the um any researchers or should we optimize for the end user and we're saying that's not the actual dilemma we think there is a way to um prevent the the malicious Mev and allow through basically or plug-in um with whatever the rollups chosen mechanism is to do with Mev so an example would be optimism we're using um this miva um maybe auctions so something actually optimism could use something

like shutter to prevent the malicious part of Mev and then use them use mivas or something like the flashbots for L2 basically to um distribute the remainder of the b9mev um so yeah and that that's the Mev topic um the and I said it's going to be also different sort of aspects of use cases so the other um the other exhibit is shielded voting and so we're with snapshot together we're we've implemented again the same threshold encryption dkg mechanism but this time not to prevent um front running but rather to ensure information symmetry basically in doubt voting so essentially right now the downloading is

public and kind of it's okay to a certain degree but also not okay to certainly agree because anyone can see what's happening and it influences um uh the voters uh decision making um if they see what's already happening and someone who's voting later has more information available than someone who's voting earlier um so that's just the mechanism of encrypting transactions and then revealing then afterwards and um and it's for the depths for if we consider several not a debt but basically for um for them it's um it's a better commit revealed scheme so they could use a trivia scheme but shutter in this case is better because

there's only one transaction needed from the from the user they only have to do one transaction in the beginning and then it's automatically decrypted and also there will definitely be the reveal so it's there's no um so there's no um the user can't choose not to reveal right um so that's how that will look like Inception on the back end and the admin backend choose shutter and then the transactions will be encrypted um yeah and then um the third example um or topic or we just briefly touched on um because yeah only briefly touch on because it's complicated yeah but essentially um via this mechanism we also think that we can add this level of censorship

resistance um here is as Martin saying that um if you were to implement this structural encryption mechanism basically at the L1 layer um you can because the information will be encrypted um the the validator in this case has it basically has a it has a certain argument of plausible deniability because you can say well I don't know what was in the transaction um that I signed so I can't be held liable for what's for foreign so um we think it can benefit sort of censorship resistance at the L1 or also A2 level um that's why yes talked about this and basically and

where and how what we're doing there is it's a research sort of exercise for us um especially and our next step is there how can we because this proposal that Martin's talking about that he also was um really gave a lot of input on um that's for um ethereum um sort of post merge without PBS so we're looking now how to combine it with PBS and also um there might even be benefits using shutter and Mev boost to reduce the trust assumption and maybe boost and it gave a talk about this at Stanford uh two weeks ago I think so if you're interested in that then watch that talker set so in summary um even broader than Mev shutter is this

flexible kind of commit revealed scheme which can help mitigate all kinds of issues relating to front-running censorship and other with misbehavior on chain um and it's already um it's well nearly live in production is a little bold here um but essentially should go should go live like this week hopefully um for shielded voting um and then yeah for depcon or for the depths there may be a listening adapt developers they can Implement shutter directly as this on chain smart contract version or ideally um kind of deploy at some point when we have that ready on a shutterized front running protected roll up or in in the in the future maybe also on a on a

shutterized L1 yeah and that's that's it [Applause] so we've got about 12 minutes for questions and thank you for the talk I have a question are you guys planning to build to implement a builder that is using a shutter as like their well build strategy yes I think we we discussed it as one of three different options on how to combine

um shutter and and PBS Mev boost um so it maybe maybe Jana can say something specifically about that but but more that more broadly speaking and which layer you implement it it changes which problem we are solving so basically um if we implement it deeply into the protocol we would actually try to solve the actual front running issues if we implement it at the um I think who implemented into Mev booths at the Builder level essentially I think would rather reduce the trust assumptions um for in that context not necessarily to actually prevent front running but maybe that's the correct basically yeah

so that's not a super high priority for us um but could definitely something that that we would be also be interested in doing here um besides running a builder what other uh trust assumptions will be will short and solve between serger and Builders or between Builders and relays um so to answer this for Mev boost yeah the um the the hope would be that because right now you have to trust this relay to a certain degree to yeah so what we can do with feta basically we can um improve the trust Assumption of the relay we can basically make the relay um trustless yeah Mass cow

because the same kind of the same mechanism as I described for basically making the roll up sequencer um I'm kind of reducing the trust Assumption of the roll up sequencer making that kind of front running censorship resistant um basically because if if the relay can't see the transactions um yeah while it's passing through then um then you have to trust it less essentially so they really will not be able to still Mev distill the the block content yeah but there are more trust assumptions are related to how the relay is taking decisions on the Block Builder that's been actually chosen uh is is it related to that or is strictly uh to make sure that relays are not

basically using uh the blog content in order to run maybe a local Builder their own I think the letter I think in that case we were trying to make the the relayer be less trusted less needing less trust cool thank you foreign I feel like distributed key generation as like a thing on ethereum has been pretty well understood in researched now for several years um I'm just it sounds a lot like most of this stuff is really just going live now and more recently um is this really like the first time

we're actually seeing dkg being used in ethereum no no I think it's a I think parity developed a dkg as you say way back in 2017 or something yeah so um I think special about our implementation is about the crypto cryptography protocol itself is is the efficiency of it so because we need to run it basically within a matter of seconds so like five seconds or 10 seconds I think is our Target so that's that's sort of the achievement there that we worked on with these cryptography professors um the Western false and and Chef under zimboski um to to make it very efficient essentially um but other than that you you write the threshold encryption and dkgs aren't something super exotic

um it's it's basically well understood cryptography and um the the novelty here is more to implement it into well for example into the L2 layer or or the um the voting kind of off-chain voting layer there and it's it's maybe also to mention it's it's not as I think it's not as exotic as like um their knowledge um technology or yeah so we think we hope that it would be more yeah better understood less less complicated less less uh more battle hardened than something like a really complicated xenology um proof okay that about wraps it up for

questions still a little bit of time if anybody'd like to know but otherwise let's thank the speaker thank you foreign