Encryption Tools for MEV Protection in DeFi on Any Blockchain | Liam McDonald - Fairblock
Ethereum Denver·Wed, Oct 9, 2024, 12:00 AM
We don’t need to rebuild DeFi on privacy blockchains. Instead, a modular architecture allows for protecting DeFi users on any chains against harmful MEV attacks that are a side effect of today’s public order flow. This talk explores key encryption tools that prevent a range of malicious strategies. APPLICATIONS FOR ETHDenver 2024: #YearOfTheSpork ARE OPEN APPLY NOW https://ethdenver.com/apply
Transcript
[Music] how's everyone doing we live yeah all right uh great to meet everyone I am Liam uh I'm the head of growth here at Fair block and I'm G to be talking today about encryption tools that can be used for bad meev prevention in defi uh just some things to preface first maybe um I just found out about this talk yesterday um the founder uh who was supposed to give this talk uh his flight got cancelled uh very abruptly due to some uh some septic issues on the plane unfortunately uh it's a pretty disturbing way to get your flight canceled but uh nonetheless we are here and uh I'm really excited to be to be sharing what we've been working on with you guys so so um the second second bit of preface to to say is um while bad me prevention um is one of the benefits of uh the solutions that fair block offers it is uh only a small subset of what we do uh we're working on cryptographic Solutions uh to programable privacy um and the badme prevention side of this is like I said just a a small bit of the benefits that that come from the tool set that we offer um the main point of this presentation is you know the extent of what's now possible on chain with programmable privacy um and you know when we talk about programmable privacy we're not talking about um you know just zero knowledge proofs we're talking about FH we're talking about a number of different cryptographic schemes that that can be brought on chain um with now what's what's available today with with wasum and um other rust based cryptography libraries um so yeah with that preface uh we are not a competitor to flash Bots we are very much working in alignment with uh with what they're doing um but more on like the cryptographic side of bad M prevention um so we respect them we love them they do great work um but we also understand too that uh the design space for bad M prevention um is much larger um and what they've worked on so far is is just kind of a temporary solution with their centralized server so uh with that as as the preface let's get into it um a bit of a itinerary 1 um we're going to be starting off with just reviewing the state of me um going into what is fair block um in introduction or sorry in introduction to our architecture uh threshold ibe applications of ibe in defi uh such as encrypted intents sealed bid auctions uh and more generalized programmable privacy some cool things that can be built from this and what to expect from us in the next year so let's get into it so the current state of me so meev as we all know is the value that can be extracted by privileged actors in any system um this is kind of the the famous hu quote um um some some traditional forms of me include Arbitrage sandwich attacks uh liquidations just in time attacks some some newer forms of me include uh cross-chain Arbitrage uh sex to Dex Arbitrage and opportunities at the bridge and Oracle levels as well um and then in terms of now you know the the mitigation techniques that are now available um we have the encryption side of things which is what we're working on at Fair block um to also preface to we're not working on um on solutions that you know um support good meev um the cryptography tools that we use are really just to prevent some of the opportunities for bad Meb um there's flash Bots with me boost and meev share and then there's also um mitigation techniques at the app design layer such as uh frequent batch auctions and Proto rev so with that that leads us to Fair block uh what is fair block we are a modular ecosystem of privacy enabled infrastructure and applications so we deliver programmable privacy to protocols and their applications to protect users from malicious actors and the downsides of onchain transparency and just to kind of give a bit of color first um on on why we're building Fair block we think that a lack of privacy on chain is one of the bigger deterr to blockchain adoption and that's a major reason for um you know why we're not maybe where we want to be in terms of the whole blockchain adoption scheme right now um because most onchain applications are limited in their designs to a global user base because of a lack of privacy um and up until now most onchain privacy has been materialized into isol ated l1s uh that position privacy more or less as a luxury instead of as a standard meaning that um if we were to make privacy a standard we should be delivering it to protocols and their applications uh so that this privacy can be accessible inside of users favored ecosystems and applications without having to sacrifice ux um so this is how in my opinion we uh create the foundation to uh build stickier apps that attract the next billion users so so with that uh I'd like to go over Fair ring at first uh fairy ring is the foundation of all things that we do at Fair block um it is essentially a key Generation chain that acts as a decryption key Oracle that sends encryption and decryption keys to any blockchain or any application across any ecosystem Um this can be done via IBC or a network of Rel layers that we use called Fairport um and like I mentioned um or sorry um as we are connected to IBC we are also a uh Cosmos SDK chain as well so uh just to kind of go over a bit of the architecture um to lay this out and and how this works um it starts with users encrypting a transaction with a certain onchain condition um this condition could be a certain block height um an asset price a zero knowledge proof uh really whatever whatever data point on chain that you want to program uh your transaction to be decrypted at uh this is possible with with ibe um and so once the condition for decryption uh is selected the encrypted transaction is then committed on chain where it sits in the M Pool waiting for those conditions to be met uh to then be decrypted and executed um once that condition is met the fairing validators are notified uh via fairy port and work together to construct the private key uh they do this by deriving their share of the private key first which is derived locally they will then submit it to fairy ring fairy ring um once a certain threshold of validators private key Shares are met fairy ring then performs a function uh to um to construct the derived private key which is then sent to the the the destination chain uh where the transaction is then decrypted and executed so as you guessed it um if you're in tune with the cryptography World um this process is uh what we call threshold ibe ibe like I said earlier stands for identity-based encryption uh this is what's this is what enables us to um you know choose certain conditions on chain that will be used for uh the decryption of transactions so um in the threshold ibe that that ring runs uh we generate a master secret key we call this the msk uh from an API uh this API just as a preface to will soon be converted into a dkg um based approach where all the validators in the chain are working together to derive the master secret key and and the public keys that are used um and then once that key is generated it's then split up amongst the validators in the network and stored locally um and then when every condition for decryption on chain is met um the validator will then generate their private key share um and then submit it to fairy ring for uh for the deriv private key to then be constructed and then sent to the destination chain so there are a number of of applications that threshold ibe um uh unlocks on chain um but I'm going to focus most of of the rest of this presentation on the applications in defi um because that's you know where we want to kind of show the value here is that um you know there are with with bringing uh TI to defi applications we do help these apps and their users mitigate uh some of the opportunities for badme um and the first one that I'd like to go over is encrypted intents uh so these could be limit orders stoploss orders really any kind of programmable privacy um or programmable or sorry yeah uh programmable trading available on chain um and so you might ask first like why would you want to encrypt transactions um this could be to keep the size of your order hidden uh this could be to retain information asymmetry this could be to protect any of your trading strategies um the point is that you can really program the decryption of these transactions to meet whatever need uh you're looking for so a general flow of of what this looks like is a Trader will submit a intent um say the intent um or sorry say the the intent is set to decrypt at ether price 4K for example um that transaction will then be sent to the app front end um the app front end will then submit that transaction to the chain where it lives in the mempool um where it'll wait for for the conditions to be met on chain uh once that condition is met on chain uh ether suddenly reaches 4K which we're all patiently waiting for um the Rel layers of uh fairy Port will then request the decryption key from Fairy ring fairy ring will then generate the decryption Keys send it to the app chain and then the intent is decrypted and executed for so this design is also really important for sealed bit auctions too um this is something that we've all probably been seeing recently um with paradigm's recent post on leaderless auctions um so the design here uh would be very similar where the the bidder for example uh would submit a bid to decrypt at block height whatever that block height is generally the end of the auction or the end of the round in the auction um that encrypted bid will then live inside of the chain in the meol uh where it's gathered alongside all of the other encrypted bids once that uh that block height is then reached fairy Port uh requests the decryption keys from Fairy ring fav ring sends those decryption keys to the chain um the chain then performs a function to decrypt all of the encrypted transactions in the mempool uh with logic that is then set to select the winning bid that winning bid is then decrypted or sorry executed um and you might ask you know what are some some advantages of this over traditional auction systems uh one of them is that there's no collateral needed to guarantee bids are revealed um like in a typical commit reveal scheme uh the other one is that there's no risk of censorship based on bid amount so each of these things are kind of part of what we considered highly uh in thinking about how how tibe can be used on chain to uh to secure sealed bid auctions and then just maybe to wrap our our our heads around the more like meta approach here um this conditional or sorry this um programmable privacy can be brought to any application on chain um and the flow inside of these applications will be similar um it's not just useful in defi it could be useful in private governance gaming uh the list goes on and on um so in terms of like maybe the one Nuance here that I had mentioned prior is that there is a initial communication between fairy ring and uh the app chain itself where um faing sends a master public key to the application chain um that Master public key is then used inside of the process where the user uh chooses their decryption condition um that decryption condition is basically matched with uh with the mpk um in in order to become kind of like the public key for that transaction and then it's uh kind of the flow goes on from there as as we we we we talked about prior so there are a lot of really cool things to build with programmable privacy on chain um one of these things could be private governance which we've already built for the cosmos Hub um like I've said uh this could also be encrypted onchain intense as well uh this could be Randomness generation for onchain gaming um gambling casinos whatnot uh there's also censorship resistance shared sequencing where decryption is enabled at the sequencer layer um there's encrypted men pools privacy preserving rollups uh private onchain games and and so much more that even we haven't haven't fully fully thought about just yet but are are actively researching um and like I've kind of alluded to earlier uh the design space for for applications on chain with programmable privacy is huge um this is what we think is the uh you know the next big onchain integration um that will unlock the design space for you know the next million apps that will attract the next billion users um so yeah we are we are in the business of uh pushing the boundaries of of what we can do here on chain uh I think is always important to to remember so that's all for now um if you guys want to scan this uh QR code it's our link tree that takes you to our GitHub uh our Twitter all of our docs um you can find us throughout the week uh at basically every event um one that we'd like to get a lot of developers at is um our workshop with door hacks at app chain day um where we can test out these me resistant auctions um with some of our cryptography libraries we've got our test net launch uh scheduled for March 6th right after e Denver um we've got a hackathon with door hacks that's going to be announced soon and uh many exciting Partnerships across the infra and L2 landscape um that will be announced soon as well as opportunities for for Builders to uh to contribute early so that's all I've got today uh thanks everyone thank you for your attention and time and uh we're really excited to see what we'll build with programmable privacy on chain thank you
Automatic transcript — names and jargon may be misspelled.