ETHWarsaw 2023: Luis Bezzenberger, Shutter Network - MEV user impact & Gnosis encrypted mempool

[Applause] thank you yeah thank you for having me so um I'm uh Lis working um with Shadow Network um it's a project incubated by um brainbot which is an older sort of software development company in eum space um and I'll be talking um about me the user impact that um that me has and then and then later I'll also talk more in practice of how we can maybe um help uh mitigate it by encrypting the meol and encryption yeah okay I mean I just wear this um so maybe to preest we we really like um we love based lay neutrality and we love B um sustainable Market architecture right and um this is just prefaces what we what I'll be talking to um about and um and maybe to say something as well as as also we think that it relates to accessibility so if your base layer is neutral and if your base layer treats everyone the same sort of and and there's information symmetry then we think we can increase accessibility which is um sort of I think a really important goal um for for everyone working in in in onchain right um maybe a little more on this right on this problem solution set is um I think in the re recent years um mainstream uh and reg regulation has really been hostile towards crypto um I think the the perception is that it's really an unsustainable Market environment from the outside people don't think that it's intransparent um even though we're all about transparency right but it from the outside it looks hostile and um really sort of all these ponzi's front running just a not a nice marketplace right from the outside um so again I think VR B based neutrality via sort of um increasing accessibility um and a more sustainable Market architecture hoping to get back to bring this back and to bring back um mainstream um appreciation of crypto um more specifically so before I was talking about the more General topic of crypto is broken and hostile but what we are more about is sort of this transaction supply chain and we think it's in a bad state in general so so we think it really front running malicious meev causes um this measurable direct um user losses um the the larger issue behind this though we think is it deters new entrance or deters serious investors from from entering the market and indirectly by by sort of quick fixing the the me and transaction supply chain we are um creating these centralization Vector so we're we we're fixing it and we're mitigating some of the issues but usually we fix it in a way where where we're then adding another intermediary um and someone which then can censor again or can um it's a centralization force with entrenching this these actors um so that was just the motivation but maybe taking some one step back is maybe people are not familiar what is what is front running and what is me um so front running is very simple is you're jumping the queue essentially you're you you have some information Advantage you jump in front of another person's trade and you steal that person's trade thus sort of harming that other person because that that person is getting a a worse price me is sort of the the umbrella term is called maximal uh extractable value and um front running is just one part of this so there is actually also not front nonf front running related meev so we generally speaking about back running related me Arbitrage liquidations and those are generally considered to be benign neutral so we are not even want to get rid of this essentially um and one thing to it's illegal the front running is illegal in the in the real world in crypto it's considered harmful and um and detrimental to user experience um so as I said we're first sort of talking about the me user impact and the way um we are talking about this is uh my colleague Yanik um built this model um to simulate diff the user um per impact on user trading performance um simulating as based on varant different transaction ordering strategies um so what do we want to show here how again how do various transaction ordering strategies impact the user performance which one is the best the quote unquote best um and one thing to note is yeah caveat or disclaimer it's really a very simple model and just so more more consider it more like a mental model of how how it works rather than a real world sort of like cat cat simulation of what would actually happen um so what's under the hook is there's a the the assumption is there's just one amm with one single pool users are buying and selling price is moving up and down in the sequence I can either sort of reorder Arbitrage or inject their own orders so yeah that's this model first the first um strategy transaction ordering strategy would be u a random ordering um fully randomly ordered which is um uh unrealistic because yeah there people do see these Arbitrage opportunities and they will try to exploit it but um in this case there would be zero user loss um which would be nice uh however also the price would be um maybe not really true to the market price because it would be very random sort of right again not really realistic um because yeah we have people looking for arbot opportunities this next strategy would be the random ordering but there is arbitrage so the um sequencer can take uh an Arbitrage opportunity after every block um and we see the interesting here part here is the there's a lot lot lot less user loss um so you're seeing sort of um yeah the the user loss is is a lot uh um so so no there is um there is a minimal user loss compared to the first one however the price is more true to the real price the the it it's fluctuating less and we have a yeah um comparing it to random ordering but then there is an Arbitrage after every transaction so the before we had after the block here it's after every transaction this um increas significantly increases the user loss uh and also and the price is um slightly more close to the real price uh and it's pretty inefficient because we have these back running transactions after every order right so uh it's kind of inefficient but but yes there is um yeah and there's more user loss um this one is one step even more sort of it's the sequencer is trying to really maximize um its uh the the back running so he's arbitraging um after every block but he's also reordering transactions to to yeah again maximize his profit um which that increases user losses a lot more um again uh yeah and then the price is going to be always the same sort of yeah and this one is the most extreme form of the sequencer sandwiches every single trade the front runs and back back runs essentially and that really increas that really maximizes the user loss so that's something I think everyone sort of agrees we don't want this right and then we're I would say generally speaking people maybe are somewhere on the spectrum of somewhere in here right where they think it's ideal um and sort of our takeaways from this we think sandwiching again is the most detrimental um strategy and um even simple reordering can actually have uh impact and negative impact um so what we're sort of looking at a little bit is we think that the random ordering with Arbitrage um version so it's um this um we think is the best trade-off so that has the the the price is pretty true to the real price we have minimal user loss um so we have Arbitrage we have no front running so we think this is sort of as we currently look at it is probably the best kind of trade-off right um yeah just some caveats um the model uh is pretty uninformed random there a results in a Zer some model the we're assuming this maximally simplified world uh and and it's just illustrative I think I said this before yeah um but sort of taking this and saying okay maybe this this strategy um maybe some variation of the strategy is is probably the the best outcome for everyone for for the sort of the the the the health of the marketplace with this in mind we think we can create a more me of whereare uh wear protocol infrastructure and and especially sort of one example of this that we're working on we call um that what we call shutter is this encryption of the mol so it's a threshold encryption um technology to encrypt the meol and prevent especially front running so yeah um how does it work so transactions are encrypted batched signed while it's still encrypted so the the the block proposer um cannot see what's in the transactions so they can't really sensor of front run and then we're using threshold encryption to uh remove the the need for trust and to decentralize the encryption decryption role right so we have these Keepers that are running the dkg they are collaborating to generate encryption keys and then decryption keys and that plugs into other protocol infrastructure so we have to ideally it needs to um so deeply integrate with an with a blockchain or rollup and it needs to be a protocol level change um so and but if we do this if we encrypt the me pool again then we can uh the sequencer or block produc block producer can't really see what's in transtions can't front run and we think this really results in this quasi random ordering with Arbitrage I said before this is probably the the most attractive strategy um and generally speaking this increased information symmetry we think leads to this direct benefit for users of saer trading no front running in um the this also I mean if it's you get front run less then you also get better prices so you just have a more profitable trading experience essentially and we're adding this type of realtime censorship resistance because yeah if you don't know what you're sort of committing to you uh can't really censor based on the content of the transactions um so these are the benefits for users um but you could argue that there is kind of um the validators or sequences they're getting restricted right they they they now have to commit to um shielded or encrypted transactions so in a way they're restricting them themselves You could argue that they actually have less power and they can extract less meev um however we actually think there's also some benefits for them so so one is really this image right and you sort of the the positive image you're projecting and saying this infrastructure this protocol is actually a more safe and healthy trade environment um we think that'll that could really have the benefit again bringing in back in um more serious and more Cas more mainstream investors um and then also then by this increasing the overall Revenue again um the other benefits we think are really sort of in the in the real of regulatory benefits a little bit so if you can front run if you can extract me from the outside this looks a little bit more like a financial intermediary because you're yeah you're sort of this power is like an unnatural power and if you're arguing with a regulator what how should you be regulated as a validator or as a sequencer ideally you want to make the case that you are a purely technical provider and not a financial intermediary who can extract value right so so we think by being able to argue that there's no way for you even technically to extract front running rated me that then you have an better argument of plausible deniability of saying okay um well we couldn't even front run so please we should be regulated like a technical provider rather than like a financial intermediary and we're seeing actually some Regulators around the world Mika and and Bank of Bank of international settlement they are making statements towards um also making front running illegal in the like it is in trfi also making it illegal for crypto right so um and all in generally speaking the the sequencer especially can still um collect and distribute backgrounding related me so there still this Arbitrage um aspect to it shutter um we're working on different Integrations so shter itself is um finished the dkg but we are um implementing it into different um other protocols so the one that is actually already live and providing um Shield voting um running live is in snapshot which is um there is actually not the M use case but we're encrypting the like real time results during the vote which we think that helps with information Symmetry and we have over 200,000 shielded votes cast and this is just chugging along I think it's working very well snapshot and us we're thinking that this is actually the more natural and more the normal way of voting right to have a shielded have shielded voting um then what I'll talking about more detail later we we're currently working really with the nosis chain to implement it into the nosis chain um and we're also uh working on this um uh essentially optimism Grant to Pro to explore how to implement an encrypted meol for p stack based rollups and there we have the requirements and architecture ready and just sort of next steps would be yeah actually building it um for the OPC um yeah and the shuttered nosis chain again is this collaboration with nosis chain they have very similar Vision on this Martin um is talking about this uh um frequently on Twitter or in interviews and yeah all the benefits I said before more neutral base layer um sensorship resistance um me front running resistance that's that's what what this is about we have this practical kind of accelerated road map where we first build it as an opin kind of soft for variant um and yeah we think that'll be a nice so first example and reference implementation of this yeah idea which then can be looked upon by other and and copied by other l2s or ethereum even etherum L1 itself um roughly speaking this is sort of our technical architecture um we sort of roughly explaining how it works is the keepers generate first this Eon key which that is um broadcasted to the this um passed on to the key broadcast contract um the users are using this key to derive um individual transaction encryption Keys which they use to actually encrypt every single transaction in our current design they pass on these encrypted transactions to the sequencer contract that's where they sort of are just deposited um proposer listens for those um transactions and and then um uh us uses them to um yeah to then ultimately build the block and propose the block and something I forgot to say in between is essentially by sending into the sequencer contract that's what fixes the order of the transactions in place by them being in the sequencer contract that says okay now they are in this order do they need to be executed um and this is a nice way to also separate so of saying the proposer no longer really has even the ability to order transactions because the orders already fixed in place while they're still encrypted um and then yeah and then at the end Keepers generate the decryption Keys proposer is using the decryption keys to to uh to decrypt and then again propose the block um yeah and the one the one nice thing uh is really this Eon and key derivation method which saves the step of not having to generate encryption Keys every every transaction and or every block so this is saves a lot of um overhead as well but yeah um generally speaking Yeah again we're taking this is pretty practical approach this opt-in kind of soft for approach there's another sort of little shortcut that we're taking in the in initially which is that the RPC provider actually encrypts uh the transactions which not really optimal right then you're trusting again the RPC provider but this allows us just to go to market quicker uh and then the next step would be this deeper enforcement of rules and and an actual hard fog to be able to slash and everything um yeah again collaborative effort working on this in this try sort of setup with nethermind team and the no nosis team um comparing it to other approaches so this is not the only uh way to encrypt the mol or the only way to sort of introduce some kind of front running protection right some other alternatives are to yeah just have the RPC protect against M on the RPC level which good good quick fix we would say but then again what I said in the very beginning we are introducing this Reliance on on centralized intermediaries um and introducing another censorship vector and Trust vector centralization vector so not really a long-term solution in our opinion um you can use um things that trusted execution environments like sgx but yeah you're trusting then a little bit in the chip manufacturer and and there are um vulnerabilities um with this um there is the there's other approaches using verifiable delay function sort of type of approaches which um that that would then require these custom as6 and and there's also some design challenges because that's really a time sensitive thing and yeah again this is this Hardware uh a little bit of a trust in the hardware um there right um super interesting and something we're looking at quite closely is with MPC fhe this really Advanced type of cryptography which would ultimately have the um ability probably to make the entire um to make everything encrypted and just operate on encrypted transactions and then we can solve everything right and also solve privacy and everything but um that's really not really practic practical right now it's not not not cost effective not even close to be cost effective but yeah super interesting to look at in the future and maybe incorporating small parts of it on MPC for example in effect the thres encryption Approach at shutter that we are employing is a very simple um one specific instance of MPC right so we are on that track um already um so I talked about uh shiz nosis chain which is this implementation for an L1 or like a beacon chain type of ethereum chain right um but we're also again building it for l2s um and there there's another in addition to all the benefits of sensor resistance front running resistance um the in addition to the front running there's also this um interesting way to look at it in relation to the sequencer decentralization road maps so in in a way with the encryption um encrypted mempool you can reap most of the benefits of a decentralized sequencer which is especially this real time and strong censorship resistance um without actually having to decentralize so so this could actually open sort of the um the ability or the the optionality for rollups to yeah to have this alternative sequencer decentralization road map um and and this setup then we think has a has in overall then has actually improve proved latency yeah because you still have the centralized infrastructure you still have all the benefits of less complexity and less sort of overhead communication overhead and decentralization um so we think it could actually have um improved latency over this decentralized sequence setup while still being kind of strongly realtime censorship resistant um and yeah again I said this already I think um the the shutter uh the L2 sequencers would still have the ability to extract and um distribute background running related me so that's not impacted by this at all yeah um and then beyond this a little bit what we're working right now uh on is we're also looking into yeah these other Hot Topics I would say in me right shed sequencing intense ofas uh how does an encrypted mempool combine with these right especially um super interesting I would say in in the intense case where initially you would say that an intense based trading narrative is is kind of a different kind of the opposite approach to something like shutter because in the intense in this intense Vision you are revealing a lot of information about your trade beforehand in order to find a better in order for solvers to find a better solution whereas shutter the idea is you're not revealing anything right because you want to be protected against um that um however we think it actually works quite well together either in a way we think it would make sense to really make it transparent what information you reveal right so so so being able to for the user to decide I I now want to voluntarily reveal information um for this part of the transactions but for this other I don't right so these combinations and making it more transparent and giving the user the option of revealing or not revealing um but also just later in the in the in the in the transaction supply chain in the intense based transaction supply chain um you have the issue again you have then solvers or solver builders creating these Sol these matched kind of intents and they're the they building the the these partial blocks right and then they don't want to get front run again from other solvers for example right so so then we would say at this point you will probably probably benefit again from some some sort of um commit reveal or shutter shutter dkg type of system later in the transaction supply chain um yeah and for autoflow auctions we think it combines nicely generally speaking shutter reduces the me and reduces the front running or minimizes it and then using ofas to distribute and kind of distribute uh the remainder of the the um and that's sort of it uh again sort of the the gist of it we're trying to build a more sustainable Market architecture um trying to bring more fairness accessibility to to um onchain use cases um and especially if you're building a rollup yourself or have a def front running um prone dap um would love to get in touch uh and and again talking about me also more generally speaking about about sequence decentralization we're super interested in this also also apart from also more generally speaking apart from the encrypt mol shutter so yeah would love to get in touch and yeah follow us on Twitter um yeah thank you so [Applause] much thanks L um do any anyone have any questions we have some more time uh how are you how will you do uh liquidations and Arbitrage uh if you encrypt the mol yeah good question yeah so without going into the ACT details the the simple way of answering is the way shutter works or this type of encryption Works uh it can only prevent front running where it's at me because essentially you're the easiest way to explain it with the sequencer the sequencer um Can the sequencer receives encrypted transactions and the Order of the transactions is fixed in place right uh so they can't put transactions sort of before this but then they are the first ones and they have the order they have the power then to um decrypt and then to put transactions immediately after in a way right so they can then extract all the back running related me does it make sense sense so so they can't front run because the order is in place of the transactions that are there but then they have the power to to put transactions afterwards because they're still the sequencer right they still have the they still have the the overall transaction ordering um power but the sequencer does not know what he sted transaction yes yeah so so how can can well then then they know right it's revealed right so so it's shutter is a a commit and revealed scheme and then it's decrypted and the the sequencer reveals he he's the one who who receives the key from the keep from the shutter system and then they are the ones being able to decrypt they're the first ones who see everything essentially um uh and they are the ones who are able then to yeah put transactions immediately afterwards they can't change the order but they can then put them right afterwards so they okay there's a um defined ordering and they put transactions at the end of the block or something like that yes or in a separate um maybe any can you can you explain on this oh you don't have a microphone um yes basically so so after the transaction transactions are decrypted then they know the state then they see which Arbitrage opportunities are there and which um which liquidations are possible and then basically in the um um uh yeah basically in the next block in the beginning they can put uh whatever they like in there great uh do we have any other questions does this approach what the shter has uh does it have any uh uh downsides uh on the obvious downside of being being more complex like does it does it impact the user like normal retail user anyway yeah yeah two main two main sort of downsides we would say one is slightly increased cost so this this process costs a little money you know the generation of keys so there would be a small sort of additional transaction fee attached to it that goes to primarily to the shutter Keepers um but we think that'll be offset by again people not getting front run so you'll then have better prices and overall the economics need to need to be worked out in a way and they will I think be easily worked out in a way that um the transaction fee is smaller than the expected loss from not getting front run right uh and it's quite easy because yeah the the losses are pretty huge so we think it's it's going to be quite economical uh to to map to model this especially for larger transactions um and then the other tradeoff is to do with latency so this this encryption decryption um takes a little bit of time a couple of seconds essentially so depending on how you look at it this is like added to it or in in in the L1 case it's it can be even paralyzed with with some of some of the other sort of block production process but if you compare for the sequencer for the L2 case um because the current user experience on l2s is you get this instant transaction inclusion and and transaction um uh result immediately so there it would yeah it would def it would increase the execution latency by a couple of seconds while still having this instant transaction inclusion latency so you would get the result immediately I sorry you would get the transaction inclusion receipt immediately that your transaction will definitely be included and then a couple of seconds afterwards you would get the um result of transaction so that yeah so two tradeoff costs and the other one latency but we think again the latency is actually not really that of a problem depending on what your preference is but we think it should be for normal trades it should be very acceptable to wait a couple of seconds right you're yeah so maybe if you're a high frequency Trader you're not really happy about this but uh but if you're a normal user who just just wants to buy something um you're more should care more about your price um than a couple of seconds right and you sorry I I remember reading some discussion that that kind of makes the transactions that are encrypted end up you know being um happening over two two blocks because you need to submit them and and they have to be included in one block yeah and then they are decrypted and only in the next block you get the the actual result like the execution of the so it kind of yeah this was an earlier design that we worked on where we built it purely onchain as a smart contract kind of solution on top where you don't have to modify the underlying protocol then it would have to work like this then you have this first this kind of um first uh shutter smart contract which then in this next block passes it onto the target smart contract um but we moved away from that design because of that downside also other downsides composability cost so in the implementing it into the protocol um you don't have that specific problem but yeah you have the increased latency yeah but it's just part of the block production then yeah so it's not a second block but it's it takes a little longer okay um I think that's it uh so thank you very much Lou and uh thanks everyone for listening so [Applause] thanks