Shutter: Preventing Malicious MEV and Frontrunning

Transcript

hello everybody my name is ulrich i work for brainbot and today i'm gonna talk to you about shutter network which is a system for combating front-running and malicious mev on ethereum uh and as a bonus we will also introduce some uh new um discovery we've recently made in cooperation with uh clara's that shutter can also be used as an improvement to commit reveal ux so as a very brief overview of the content of the talk first a refresher on what mev is

then an overview of what shutter is how it works and what currently is usable on chain and what the future will bring in the next coming month so currently we do have a solution that is ready to be deployed on main chain with existing dapps that require some adjustment to the dap's smart contracts and also has some [Music] limitations for example it's not compatible with defy composability which may or may not be a downside for some applications

we are working on other application domains that will solve that problem in the future watch out for our announcements from our site in the future there and also in parallel we're working on cooperation with claras they are an on-chain court arbitration system [Music] and they currently face some ux challenges due to the command reveal scheme they're using which i will go in more go into more detail later um yeah and this corporation that we discovered that shutter is a nice improvement on that ux so what is front running in meb you probably already all know that but let's just very quickly cover it

um mbb is for minor or maximal extractable value and basically any minor block producer sequencer that has access to transactions before they are included in some form of block or whatever has the opportunity to gain value by injecting their own transactions censoring transactions reordering them or also more subtly also changing timestamps parent blocks and thereby for example changing the block hash and influencing randomness as an example so frontrunning probably everybody knows this but very quickly

some user wants to submit a transaction to a default x the miner sees that the price is moving because of this transaction so he can submit one transaction before the users and one afterwards to extract some value that reduces the user's gains and thereby is considered malicious so the user receives the worst price which is of course not in the user's interest so what solutions and workarounds currently exist at the moment the application layer has to take care of not being susceptible to front running for example if you don't rely on

exact time stamps or don't use block hashes for randomness you can use complete real schemes which we will get to later there are also batching mechanisms and other systems those are all necessary at the moment but put all the burden of preventing front running on to the application developer and also leads to the application of effort in a lot of systems so it's not optimal another option is to democratize the extraction that is for example what flashboards is doing with the mev gath that is slightly better because it distributes the value extracted onto many users of the system

but is also in our opinion not what we should aim for um so another option is an mev resistant base layer where the transaction execution already is resistant or even completely immune to front running that could either be a new l1 l2 or a middleware somewhere in between and that is what we basically call the various application domains so as mentioned either it could be a new l1 or l2 chain um you could also use some centralized institution that just promises to not front on you but that's obviously not desirable in a

decentralized system and then you have the current smart contract system on ethereum which is where shutter comes in so what is shutter it is a way to prevent front running by using encrypted transaction and distributed threshold encryption um so in the current on-chain system that we have finalized user submit encrypted transaction they are collected into what we are calling a batch which is uh covers a number of ethereum blocks just for efficiency reasons so we don't have to do all the encryption

uh back and forth for every theorem block and every one of these batches is encrypted with their own key so the miners don't know what the transactions actually contain until the key is revealed after the batch is finalized and that continues just for batches continuously so how do you how do you encrypt this and where do the keys come from so one option would be for the users to pick a key themselves which on the first first look sounds like a good idea but actually it's not because the user would

gain the free option by that which means he could simply submit two transactions uh for example one uh betting on rising price one betting on uh falling prices and then just reveal the one that turns out to be advantages for him so that would break many assumptions of existing default systems so we can't do that um then we could use a trusted third party to generate the keys that is of course not desirable in a trustless and decentralized system so that's out too and then the solution is to use a committee basically what we do in all kinds of layers of those systems in shutter we call those the keepers

and as long as there is an honest majority the system will work so it can tolerate a number of militias users also offline uh offline participants and they perform distributed key generation via threshold encryption basically so how does on-chain charter work then for every batch the keepers generate a new key pair the users use the public key to encrypt their transactions send them to a so-called batcher contract after the batch is filled up or the time of the badges is over the keepers decrypt the transactions

send them to the executor contract which then interacts with the target contract on chain and that is also already the downside of the system in its current form we require that the contracts that are used with shutter are modified to only accept transactions or in let's say in most cases only accept transactions from shutter and not from regular users because then you would be open to front running and mev again and this in turn also breaks composability which is for most applications a problem as we will see soon there are some that

still work with that scheme and it also slightly increases latency but that may or may not be a problem depending on your application so we are currently working on the next phase of shutter that will solve many or maybe even all of those problems we are not yet ready to announce exactly what that is but uh watch for an announcement in the near future and now we come to a use case that we recently discovered while in talks with clara's so committed reveal is a way to combat front running as we've already mentioned and in some sense shutter itself is a

combat reveal system that does automatic reveal so quickly summary what is commit reveal they are very useful for for voting's blind auctions but they have downsides the ux is not great there are additional transaction costs and users may not reveal because they just forget or don't want to spend the extra money for the second transaction so in a voting example users submit a commit which is just a sorted hash of their actual vote and after the voting period is uh done they will submit their actual vote as a reveal um

and that has the mentioned problems of ux that users have to remember to do a second transaction days or weeks later depending on on the specific system and also to on-chain or on native chain whichever chain that is transactions are required so the shutter committee real solution solved those by the users simultaneously sending the traditional commit on chain and also submitting a encrypted reveal to shutter and then at that point they are done and everything else will be handled by shutter so once the reveal period uh the vault period is over the keepers will decrypt the

user's transactions and submit them as a batch to the voting contract and in voting applications uh composibility is usually not a big issue so for that the current system is very usable so now you might say we still have two transactions per user plus one reveal transaction so how is that better and we still also have fees for the keepers and also the battery wheel may need changes to attack contract but it's not a big deal in our opinion so the solution is a shutter can be run on an l2 or sidechain because in this specific application we don't actually need direct smart contract interaction between the

executor contract and the target contractor chain so therefore the submission of the encrypted votes can be very cheap for example if run on x die and the reveal transaction is amortized across all voters because there is only one needed and the more the bigger the number of voters the cheaper it gets of course also the keeper fees are expected to be relatively low because it will be mainly fixed operating costs and not uh or rather the per transaction additional cost to keep us are incurring is really low because they're not doing that much they're just generating keys mainly so um

one partnership we're currently in the early stages of is as i mentioned with clara's they are an a chord arbitration system on chain where it's not for cases where it's not possible to have like a automatic machine decision if something is is the way it should be or not so classic cases of contract disputes um stuff like that um the in their system the jurors are rewarded for voting with the majority since they can't it's a system to decide who's right so that can't be an uh a priori decision which is the right vote so this leads to a conflict of interest

for the jurors because they might just want to vote with the majority to gain the reward and this is why clara's usually uses oh intends to use a commit reveal system i think they at the moment don't necessarily do because of transaction costs and ux problems um yeah but it's a problem if the jurors just do this to gain profit and not to actually vote and solve the case so the next version is going to be on some roll up and there is where we will we are looking to implementing shutter in some way as i

described before to solve the commit reveal scheme as optimized ux basically yeah that's already already it time is almost over that's my name you can find me on social media and github and stuff on under that handle and shutter network is looking for projects and partnerships both in the current implementation we have and also for future collaborations also with our upcoming improved version and brainward is always looking for great people to work with us so if you're interested please give it a

look thank you you