MEV Is Broken on Ethereum — Can Encrypted Mempools Fix It? w/ Luis Bezzenberger

I spoke to Luis Bezzenberger of Brainbot and core contributor to Shutter Network, about MEV and threshold encryption for encrypted mempools.

Luis comes from a background in distributed systems and has spent years thinking about how cryptography can level the playing field between ordinary users and sophisticated actors who exploit the transparency of public mempools. We dig into how threshold encryption works, why encrypted mempools like what Shutter Network is building, could protect users from front-running without sacrificing decentralization, and what it actually takes to get something like this shipped at the protocol level. We also get into the broader architecture puzzle — encrypted mempools PBS, FOCIL, and why Luis thinks these three pieces together form the holy trinity for censorship resistance on Ethereum.

This episode is sponsored by NYM, the world's most private VPN. Unlike traditional VPNs, Nym uses a decentralized mixnet to scramble your internet data — hiding who you're talking to, when, and how often. You can switch between full mixnet mode for maximum anonymity, or a faster VPN mode for everyday use.

Use the code blockchainsocialist when signing up and get an extra month!

If you liked the podcast be sure to give it a review on your preferred podcast platform. If you find content like this important consider donating to my Patreon starting at just $3 per month. It takes quite a lot of my time and resources so any amount helps. Follow me on Twitter (@TBSocialist) or Mastodon (@theblockchainsocialist@social.coop) and join the r/CryptoLeftists subreddit. 

Transcript

SPEAKER_00 0:00

Maybe controversially oppose this this assumption that MEV is kind of bad in general. Because no matter if there's a good outcome or bad outcome, if the miner receives the transaction profit, it's bad because that the user should get it or the trader who had a good trade idea. So either any one of these three can now come in and say and provide the last key share. So so basically it's kind of like unstoppable and also it's really hard to censor because you don't even know what to censor, right? But now I'd say we have two builders, Titan and Biba build, who control I think like 90% of the of all locks. So there's this really strong kind of centralization that you need to rely on these two builders to get your transactions, at least if you want to get them in a timely manner, because they build all super blocks. Funny enough, in the real world and in traditional finance, clear front running is basically is illegal. So there's like laws against it.

SPEAKER_01 0:52

This episode is sponsored by NIM, the world's most private VPN that protects your internet traffic and metadata. Unlike traditional VPNs, NIM uses a decentralized mixnet to scramble your internet data, hiding who you're talking to, when and how often. You can switch between full mixnet mode for maximum anonymity or a faster VPN mode for everyday use. Pay in crypto or fiat, and even your payment stays anonymous thanks to ZK-powered anonymous credentials. Take back control of your online life at NIM.com. Sign up today using the code BlockchainSocialist and get an extra month for free. Hi everyone, you're listening to the Blockchain Socialist Podcast. I'm Josh and I am here with Luis Betzenberger from Shudder Network. I had Luis on, I think now, probably like two or three years ago, I want to say, to talk about the same topic this time because things have progressed quite a lot. But we talked a lot about MEV or maximal extractable value. In case you don't know much about it, I'll have Luis explain what it is. We talked about it last time, but they've been working on some cool things in Shutter Network around encrypted mempools to protect people from MEV or malicious MEV at the very least. And yeah, things have progressed quite a bit. So, Luis, I don't know if you want to give maybe uh just to contextualize, you want to give a quick introduction to yourself and what exactly is a shutter network.

SPEAKER_00 2:19

Yeah, thank you. And great to be back. Um yeah, so I'm Luis, I'm with Brainbot. The company is called Brainbot, and the project's called or the DAO and decentralized project is called Shutter. Brainbot is this actually now older software company started in 2014 actually. Back then built the Python client for Ethereum, or was the major contributor, I would say, to the Python client, one of the three clients back then. Yeah, and now we're sort of like all in into Shutter, and Shutter, I would say, is a threshold encryption as a service mechanism. So think about like all kinds of use cases that could require kind of encryption decryption, especially where you have the need for decentralized distributed encryption decryption, where not one single person should have uh own this key. And so that's this network, and we call them keepers, the threshold committee that together generate these encryption decryption keys. We call them keepers. So and then we plug this into different use cases. The one that we're talking here about is is the encrypted mempool encryption reductions to to combat front running and real-time censorship resistance. But also we have it built into snapshot um for for voting to encrypt voting and combining it with homomorphic encryption to have like permanent private voting, but yeah, that's that's a separate topic.

SPEAKER_01 3:44

Right. So I remember last time we spoke, we talked a lot about threshold encryption and kind of like uh what you guys are working on there. And there is uh yeah, I think the one of the things you talked about was voting, so like how to do more secure or like private voting, and then there is also this relationship to MEV. I think what's interesting there is just like for people who maybe aren't so familiar, how different cryptographic primitives can be used for very different use cases that you may not think are related, but if you look at it from uh from a cryptographic point of view or from maybe like a computer science engineering point of view, they are quite similar. You can use the same cryptographic primitive for one thing, again for another thing, super common. But maybe if you want to, if you could explain maybe just slightly high level for people to understand like what is threshold encryption and how does it relate to MEV?

SPEAKER_00 4:39

Yeah, the idea of threshold encryption is that you spread the key shares kind of among multiple parties and not just trivially, let's say five out of five people need to come together to combine the key and encrypt decrypt, but rather that you have a threshold of let's say three out of five um people need to combine their keys essentially in this protocol such that it's safe, right? And that they don't just send actual key shares around that it actually is like uh kind of a secure process. So you need always like a subset of signers to come together, but it doesn't matter which subset. Um so so there was this funny, there was this crypto really deep cryptography powered, homomorphic voting scheme with like actual cryptographers set that up, like outs outside of blockchain, but there was like a cryptography thing, a voting protocol, and there was that just made headlines because actually one of the three key holders actually for lost a key. And that would have been simply been avoided by using instead of kind of just Chamese Secretary or just a just kind of three, you need all three key shares, you need just two out of three, then then this could have been avoided, right? So so like that's one property you do you have redundancy, and if one or two people, or even like if you scale it a lot, you can have 200 key holders, right? Then you can have 50 people losing, or right, or even hundred, uh even 80 people not not having access to their keys still still moves on. And the other property is you you never have one single person be able to stop the decryption. So if you think about like you would have you maybe you have collected the the two key shares out of three, then there is no single person of the three people that the three out of five, right? There's no single person out of the three remaining people that can stop it. So either three, uh any one of these three can now come in and say and provide the last key share. So so basically it's kind of like unstoppable. It's it's sort of to a certain degree unstoppable decryption, yeah, because there's no single person being able to stop it. And that's important for things like transactions. Um, because if you can prevent decryption, then you can manipulate again the transactions. So if you can prevent decryption, uh then it means you can put a hundred transactions in, encrypted, and you you just pull back and you just not don't decrypt 99 of them, only the one that's advantageous to you in that in that moment. So so we need that.

SPEAKER_01 7:14

You can censor transactions, like censor transactions effectively, if that were possible.

SPEAKER_00 7:18

Yeah, yeah. Or you have a free like always says you you have a free option there to withdraw transactions, and that's not something you don't want. So yeah, maybe I'm jumping ahead like that. That's kind of the property, but basically those two properties I would say make it kind of useful for transaction encryption um and kind of MEV right and front running, because you can now use that to encrypt transactions and have their block producer or the sequencer um sort of commit to the order and the inclusion of the transactions while they're still encrypted. So they they receive the transactions encrypted. Um and with this key that is kind of like forcibly decrypted. So that there is it, it's no single party can decrypt, but it will be decrypted. They don't even see the transactions, they have to say, okay, this is the order of transactions, this is the transactions that will be included. And only after that sort of commitment from the block producer, only then will the threshold committee release the key and execute transactions. And then essentially you can't front run because you don't even see the not even the party who orders and includes transactions can see the transactions. So it's really hard to front run because yeah, you're not you don't see what to front run. And you also it's really hard to censor because you don't even know what to censor, right? And in Lucid, for example, in this encrypted memory IP, you can hide the transaction sender as well. So it's you can censor. It's funny, like without fossil, you can censor, but you don't know what to censor. So that's that's kind of like the donation. So it's it's already in itself without fossil, without kind of forcing transactions through. We have this already have a pretty strong censorship resistance.

SPEAKER_01 9:02

Yeah, right. We'll go into some of those specifics in a little bit. I just want to make sure we build the foundation for some of the people just to make sure that they catch up to a lot of this stuff because even for me, a lot of the MEV world is such a mystery to me. It's really hard to keep up because of the amount of acronyms and the amount of different words you kind of gotta figure out. You gotta know if you're only if you're on the inside, then you know, you know. But otherwise, if you're not keeping up with it, you may not fully know what all these different words mean. But you know, for just to recap for people maybe who don't know that much about MEV, you know, if I try to explain what it is, it's effectively this. Some people would say feature, some people would say bug of Ethereum, where the mempool or the place where all the transactions go before they're submitted to the Ethereum blockchain. Basically, there's a moment in time where the placement of these transactions can be influenced by the validators of the Ethereum blockchain. And that gives them an opportunity to do all types of things that can that are meant to maybe enrich themselves or to enrich others who pay for their service. And so with MEV, what that means is you could, if you're making a trade, for example, on Uniswap or whatever decentralized exchange, and you know, if you're making a really big trade, you could be presented a single price, but then someone inserts a transaction right before yours that brings up the price of the asset you're trying to buy, kind of almost artificially in a sense, and therefore creating a kind of like arbitrage opportunity for them. So yeah, there's a lot of like that. That's like one version of it. There's a lot of different, I think MEV is just kind of like this general thing about the Ethereum mempool that it is kind of by default transparent and anybody can see it, and therefore validators can can kind of manipulate what and how the transactions are ordered and take advantage of that. But I'm wondering if you could maybe because one of the things we talked about last time as well is that there are different schools of thought around MEV and like ideas around things that are there. Are there some MEV that is good and some MEV that is bad? I know what you guys are working on for Shutter Network is is specifically really for the for the bad MEV, but I wonder if you can explain that a little bit.

SPEAKER_00 11:14

Yeah. Maybe controversially, I would say like MEV is kind of sort of like or I could say I could pose this assumption that MEV is kind of bad in general, because it is um that's really what you said as the bug, right? It's like it's sort of like no matter if there's a good outcome or bad outcome, the the the whoever receives it is probably if that's just the miner, back in the day it was called minor acceptable value, right? So like if the miner receives the transaction profit, sort of it's bad. It it is bad, right? Because that the user should get it, or the trader who ha had a good trade idea um is bad, they they should get it. Um so I would maybe even kind of put it here and say like MEV is sort of bad in general, but it doesn't mean that it doesn't mean that all trading and all arbitrage is bad. It's just that MEV can cover everything. If you if you think about it, it's like if you do an arbitrage in the form of MEV, as a back running MEV, um then it's then it's good for potentially F or even. If you then repay the user, then it's good, right? Yeah. But yeah, so maybe that's that's also jumping the gun. But essentially, how we can kind of simply sort of separate is is front running and back running. Yeah, so front running is what you said before, it is this like um sort of jumping the queue uh or stealing someone's trade. So think about you sending a trade to the chain is like you revealing certain information to the chain that ideally you want to benefit from. Let's say you think that this is a well-priced asset, I want to buy it. That's your trade idea, right? And then somebody else seeing that somehow, and somehow being able to slot his transaction in before, because we have this public mempool and we have this kind of this time, as you said, time in the mempool where you can re-order and yeah, and think about then somebody seeing your cool trade idea, stealing it basically by slotting his transaction in front of it, and then stealing your trade, basically. That that's definitely the sort of the bad form of it, the front running. Funny enough, in the real world and in traditional finance, that's sort of clear front running is basically illegal. So there's like laws against it. Yep. Um, and then and then back running is the stuff after your transaction. So let's say you move the price, your transaction might have had a big impact on a trading pair on Uniswap, maybe move the price out of sort of uh out of sync the true market price. Let's say now it's ten dollars more expensive. The arbitrary the the back running means somebody else then attaching himself directly after your transaction and bringing the price back to the true market price, right? Just like in this case, selling the price from ten dollars too expensive back to the true true price, and then they get this ten dollar profit, right? Because on another marketplace, maybe or even like on a centralized exchange, they can arbitrage that. So they benefit from this price that's gotten out of sync from your transaction, um, and by arbitraging it back to the true price. That's in the most classic version of background. And you usually people would say that's good because well, you're bringing the price back to the to the true price on the exchange, right? It's good for just like the stable prices. And then especially if you then think about like that how it works in practice today is in private mempools, you have this sort of promise, I would say. Sometimes it works, sometimes it doesn't work that well, I would say. But if it works, then you have this promise that the back runner or the searcher um that they pay back the user, let's say 90%. Like I think a usual convention in a good private mempool is the convention is you pay back 90% of this back running arbitrage profit back to the user. And then then it's kind of like from the user perspective, pretty good, right? You you even yeah, better than like in the real world where you don't have that, you you do a trade and you actually get money back from somewhere. Right. So for you it feels really for the user, it feels feels really good that you just get money back.

SPEAKER_01 15:29

Yeah, so it's like you created an arbitrage opportunity and maybe you get a little bit of that back for creating that in a sense.

SPEAKER_00 15:37

Yeah. The funny thing is that you can if you argue strictly from a technical point, like say like if you argue with people who are more like core developers or more things people who think like IT guys, less like trade trading guys, they would say that's also stupid and bad because why did this thing happen in the first place? Why did why did why did the user move the price out of whack? Why why why isn't there already a more efficient pricing mechanism there that already immediately gives the user the better price? That's where things maybe like Housewap comes in, where you instead of these trades by going back and forth and then paying back, maybe you have a mechanism that that solves and gives you and ideally provides the best trade. Um already provides the best price in the first place. But in the more traditional trading sense, yeah. Uh I think it's yeah.

SPEAKER_01 16:35

It would be interesting, I think, to like uh I would love to talk to you know these two different camps of you know people who view Ethereum as like an IT system, or it's like like a technical system, versus those who view Ethereum as a financial system, like a financial infrastructure, which I think provides like different perspectives on whether or not like you know these types of I don't know if natural is the right word, but like the kind of unavoidable market dynamics that occur in these things, whether they view it as as good or bad, something to fix or something to simply let be. So one of these or or like yeah, one of the solutions or the thing that you've been kind of talking about are encrypted mempools. So this is yeah, basically a way to hide what are the transactions in the mempool so that the validators are not able to influence how these transactions are ordered, so that they can create these MEV opportunities. Could you explain a bit maybe how, like what is a mempool and maybe what are some of the other solutions? Like get us up to date on like what is the thinking on potential solutions around MEV? Because I know you've you've mentioned FOSL is one, and I know there's also PBS. There might be other ones that I'm that I'm forgetting. But yeah, if you want to maybe give us a high touch of all these different solutions so we can know the landscape.

SPEAKER_00 18:02

I think it's a multi-stage answer to that. I think first, maybe what is the mempool? The mempool and especially the public mempool is this yeah, this place where transactions are sent to, where they wait sort of before PPS it was just validators and validators look in the mempool, and there's different prices, right? The different amounts of gas fee attached to the transactions. So they just pick and choose out of the pool and build their block and then execute, and then they get paid for it. So that's the public mempool, that's how Ethereum works, and I think it's important to have this public mempool because that's the simplest way where anyone can access it, right? And now what's been established in the last three years, I would say, is private mempools. So you because we have this danger of front running and sandwich attacks and the public mempool, people just say, okay, why don't I create a separate route that where I maybe I find a validator or an odds uh builder, right? That I can sort of trust to a certain degree, where I send the transaction directly to them because they have the last look, they have the opportunity to build the block. So they can kind of like hide the transaction from anyone else, so there's no uh front running going on, right? And they can take it and they build it in there privately, and then yeah, that way you can prevent front running. So they have these vectors of kind of exclusive private order flow going in more directly into those transaction supply chain intermediaries that have the access to building the block, right? So that's kind of public versus private mempool. And what we're proposing and what the lucid team is proposing as well is saying we should have a public but encrypted mempool. So we should not create little private pockets of order flow going directly to centralized intermediaries in the mempool to prevent front running, but rather we should make the public mempool be the place where you can safely send transactions in and have them be encrypted by default and have them be decrypted sort of all at the same time. So you eliminate this kind of information asymmetry that stems from either this, like the public mempool had what was broken is broken, right? And because there's front running, because there's different people have different can access the information at different times. Well, that's bad. And the private mempool is also bad because it fosters kind of centralization and there's like exclusive order flow, and also it just like it requires trust. You have to trust the builder to do good, currently.

SPEAKER_01 20:33

This is also just to say, maybe this is very common in traditional finance as well, that you create these private spaces where order flow of trades goes through as uh yeah, for like over-the-counter type of deals. It's I guess I equate it to kind of what private mempools are that basically you you you send to a private administrator of a separate mempool or a separate like space where trades can happen to have a little have more privacy that they guarantee, but kind of you lose maybe there's a certain like trade-offs that that go with that, but yeah.

SPEAKER_00 21:12

Yeah, exactly. Yeah, and then Ru it's very similar, and you know, you have to make this choice as well. You need to think about do I send it to where everyone else sends the transactions. I think so you would say the highest liquidity is where it is on the public exchanges, or you could kind of try to find a more OTC direct kind of peer-to-peer way to find someone to trade against. Um, and then there's these hybrids like MTFs and these like dark pools where you have like maybe a smaller exchange with some level of trust and some level of privacy. Yeah, I think it's it's a bit good way to to mimic to map it.

SPEAKER_01 21:50

Yeah. So could you explain a bit? Maybe so like these are these are two other terms that get thrown, maybe they're quite different, but fossil and PBS, which in whichever order you. think makes sense to to kind of tackle those just to explain it high level?

SPEAKER_00 22:03

PBS is proposal builder separation. So you separate the in the back in the day there was validators, they were they built the block and they also validated it and they also proposed it and they also like they there was only one rule. And now you split it up you say the builder is the one who selects these transactions, works with searches and works with some order flow source basically. They build the block but they don't have they're not the ones who have the staked eth they don't have the actual power to propose the block. That's the proposers. So they give it to the proposers and actually they only give the block header so the proposer doesn't see what's in the transactions. So that way you kind of we remove a little bit of power from the proposer. And that has the advantage again there was this kind of danger of a proposal monopoly because sort of Lido I think has a lot of ETH in their network staked and the more you get into a vertically integrated monopoly of where the validator has all the power it was necessary or it is necessary to separate these roles the staker the ETH the guy who owns the ETH shouldn't be necessarily the guy who builds the block and knows about the transactions and what the right order to optimize the block. So that's PBS and the in the past there wasn't in the protocol there was out of protocol just like bolted onto Ethereum and you have these relays and the relays sit between the builder proposer and they are trust you need to trust them because they see the transactions. The proposer doesn't right you can hide the from the content from it but the relay needs to see it so you need to trust the relay. And in general there's like a fragmented or say there's still a fragmented and not really perfect PBS out of protocol PBS transaction supply chain with trust assumptions with issues builder centralization is another issue. So what ePBS is doing enshrined PBS that is as I think schedule for Glamsterdam Hardfork is to enshrine this out of protocol a out of the the the PBS form into the protocol and you sort of get rid of the relay. And then you just have builders and they get a ticket to execute and you kind of you remove the reliance on the relay and you make it more fair and and more yeah. That's PBS and EPBS yeah crucially none of these prevent MEV and none of these and and also I also wouldn't say they're a silver bullet because you separate the roles but you can still have vertical you can still have proposal builder integration where they just are legally the same or they just have they just pay each other money or talk to each other in some backroom. You're not necessarily eliminating this centralization risk you're just improving somewhat and making it maybe cleaner and and and crucially I would say also is we still have this really bad builder centralization. So that there's this really strong kind of centralization that you need to rely on these two builders to get your transactions at least if you want to get them in in a timely manner because they build all the most of the blocks in so and then fossil is something I think we would say pretty separate which is a false choice inclusion list. So that is a is the the the problem there is kind of censorship resistance and you create a list basically of transactions that the the next build at least the next builder needs to needs to include otherwise it's not a valid block so you it's a mechanism to really make sure that you could probably can never have like perfect censorship resistance in block n in from from in this perspective but what you can do is you can have a list in block n and that carries over to block n plus one the next block and then the the the at least the next builder is forced to build to to include those subjections so that that's fossil inclusion list. And I think what we're what we're saying is ideally you need all three so epbs fossil encrypted mempool and mark from the other one has point this really nice term he says it is it would be like the holy trinity for censorship resistance because your epbs kind of gets rid of the relay and kind of makes it makes it reduces that that trust assumption fossil makes creates this list of those transactions have to get in an encrypted mempool is the one that uh hides the transactions and and that is a really strong censorship vector in itself because you don't even whoever still would be able to censor can't even see what's in them. So you're yeah and and the the best then the the the highest level of censorship resistance is one that you send encrypted and through fossil right because then it's like 100% all go in basically thing yeah yeah I would love a meme of the father the son and the Holy Ghost having and then all three of these together as infinity for censorship resistance on Ethereum. Yeah.

SPEAKER_01 27:19

So before we get into Shutter Network the last question I want to ask is about the latest EIPs or Ethereum improvement protocols around encrypted mempools. So there's been a lot of action around there you guys have proposed a couple of things and you mentioned your proposal on encrypted mempool is not coming in this next update but in the one after that I believe could you give and they also have like they're all they all have crazy names Glamsterdam Hegota I think there's another one I don't remember but yeah would you want to share some of the latest news on these EIPs and on encrypted mempools so we know what we're dealing with at the moment right now.

SPEAKER_00 27:54

Yeah and maybe one step back is we haven't really talked about this EIP right so the encrypted mempool is just a concept and we can implement it even like out of protocol something we are doing together with Prime F and for MEV commit and what what we have deployed on Gnosis chain is also an out of protocol version of it. But the the the strong where it actually kind of works is if you can build it in the protocol and that needs an EIP that needs a change in the protocol and that's you can only do that via an EIP. And so so the goal for us would have been to get the to to to schedule so we we propose an EIP and kind of like three months three four months ago called EIP 8105 to and a universal enshrined encrypted mempool which also particularly doesn't enshrine or the the encryption technology so not even threshold encryption no neither shutter nor threshold encryption would be kind of mandated by this would be an open interface for any encryption technology and any key provider. So what we what we say is there should there needs to be the notion of a key provider but but anyone can can be a key provider they can they can use just simple normal encryption they could use threshold encryption they could use home or they could use mpc that they would like to to use so we proposed that a couple of months ago and then right after like a month later essentially Lucid team proposed their own and lucid is kind of like Julian from the EF and then Justin from from BeSu at the core team I'd say is is is just a small group of people who are have proposed this alternative encrypted mempool EIP called Lucid. It differed in and then we had two it was two encrypted mempool EIPs one by us and one by them but we just kind of like joint forces I'd say the the goal was always the same and the implementations also didn't actually differ that much so there was this period of where we where we merged a little bit the the technical aspects of it and then kind of right before so there's now there's now is the current is the next step hard fork but the interesting part would be which EIPs would go into Hegota um that's that's the one afterwards and we withdrew our EIP out of the discussion to fully support Lucid so that just so that we have no fragmentation. But now there was a decision from the call devs not have that as a headliner which doesn't mean it's not going in it's just yeah but there's like a lot of complexity around this but potentially kind of deprioritizing Lucid for the next hard fork but they see it pretty likely for the A star hard fork then the one afterwards we also learned a lot from kind of listening into these ACDE calls can only recommend everyone to to have a listen here there. It's very interesting how the core dev teams are deciding on EIPs and are voting on them and there's like a little bit of tactics as well and some politics.

SPEAKER_01 31:27

So cool yeah do you want to maybe then let's a little bit of a deep dive on what you guys are building with shutter network and how exactly this works and yeah what is what is I know you mentioned it's you guys are are kind of slated to get in on on one of these later EIPs.

SPEAKER_00 31:43

Yeah would you like to share more about about shutter network yeah we want to and together with Lucid team want to have this EIP in and create a marketplace for encryption or key provider services. Actually in Lucid's called decryptors but it's kind of the same well decryptors key providers so we are doing everything to push that the IP gets included and helping implement that um and then we shutter would want to be position itself as being a good key provider because it uses thesh encryption and maybe because it has some other experience from from from helping push this but yeah it's it's it that's basically it's it's open to anyone and we've also been informing and getting other key providers on board such as a lit protocol and fairblock and and Zama and there's other there's a lot of other cryptography projects and a lot of them now also have either centralized or decentralized say key generation committees maybe the most interesting one is space computer with they should they shoot the key generation the enclaves they shoot them into space right so so it's basically also like a tee but the but it's TE in terms of you can't get to it because it's in space and so that that that's one as well that that's to have as a key provider. Yeah. So so that that's kind of the goal and and then I think we already talked about how we think threat encryption is maybe the best technology for this because it has these good properties of kind of redundancy. So so our EIP is fully encryption technology agnostic. Lucid says we are enshrining an extremely simple just encrypt decrypt symmetric kind of key thing into the protocol and and they are expecting the the users to encrypt themselves and then decrypt but that means like user has to encrypt and then later has to decrypt as well that's really annoying for the user and again it creates this free option that the user can then say okay I'm not decrypt I'm sending 100 transactions and then I'm and then they have all different prices and they have all different strategies or whatever and then I just see how the market develops in the next kind of 12 seconds or six and I just withdraw I just not don't release the keys for 99 of the transactions and the one transaction that was the best for me I let it execute so that's sort of like a then again a little bit of a way to to to front run or to at least to insert transactions and to manipulate where we think that's why ideally you would have dash encryption because then you have a decentralized committee who not no single person can can do this attack. And they acknowledge the elusive team definitely is aware of this and they just say like it is you enshrine the the simple encryption mechanism but that's not how they expect it medium term to to work out it is more like you then can then all again put different tech encryption other tech other encryption technologies on top and you encrypt the private key. So you encrypt you encrypt the private key of the user with the threshold encryption mechanism for example or the te. So then it's like a little more complex but you have the same outcome where you have universal kind of different encryption technologies and pro and decryptors they call them. Yeah but that's a long way of saying we think threshold encryption is probably the best solution right now we have to that problem. So we would recommend kind of to if you're a key provider use threshold encryption or if you are a user later then to use to to use a key provider that uses threshold encryption right but yeah by no means kind of the the only option you can also say like encrypt with your own key and elusive or you could maybe there would be TE providers something very likely where you have this more of this hardware trust assumption.

SPEAKER_01 35:38

Yeah. Like the direction you think it's meant to be going is like not actually enshrining the specific cryptographic process for how your maybe your sp your transaction is protected from MEV but that there is a marketplace or there are different options for maybe different levels of of security that you want and I assume these are these options would be would be paid for by by the user. I mean I would think that this may shift a little bit I don't know if that would necessarily change the user experience but it might a little bit like on uh how how do you see kind of like this affecting the user or not?

SPEAKER_00 36:17

Yeah user shouldn't be affected if he doesn't want to right so that's it could be a wallet level default or maybe like an RPC right where you have a default but you can change it if you want to but yeah user should pay for it we would say probably yeah but we would say there is a benefit from it right and you're getting a better price and we would say that the better price should be more than the fee that you pay to anchor it right at least I'd say on the whole I think for Ethereum and for the general sort of market health and for the general prices we definitely think that it is a net positive so that's where and the fee won't be a large right it would be a very small fee but yeah.

SPEAKER_01 37:03

Like you're paying like a less than a penny I guess or something or around a penny or something like that for per transaction to do this.

SPEAKER_00 37:11

Yeah.

SPEAKER_01 37:12

Anything else that you would want to leave the the audience to to know about and like where should they where can they learn more about what you guys are building and and more about encrypted mempools?

SPEAKER_00 37:22

One interesting topic is how does backrunning work in in the encrypted mempools because it still works the same as in general can work the same way as in in the non-encrypted mempool so people can still back run your transaction and then again what we discussed at the beginning that you can still benefit from it as well and get a refund. But there are some differences in the efficiency of that and essentially let's say private mempools might have a an edge so we think encrypted mempool will definitely be better than public mempool also for kind of like in terms of trading efficiency and and this type of backrunning efficiency but for a while it might be that the the encrypted mempool might not be better than the private mempool because you have these ways of more efficiently refunding because you can back run after every transaction and then the encrypted mempool will be probably after the block. But that's one interesting nuance where where it is an interesting I think topic and it would be I think very cool for people to look into there might also be solutions to that. So there's no there's no strict problem with allowing the same efficiency type of background in encrypted maps that are allowed in private mempools so I think that the big argument against encrypted would be it's not as efficient or you can't because you can't meddle with the transactions as much you you can't get the same benefits out of it for for the users right just by nature of it being encrypted you have less control and then the core argument is well it doesn't really matter it's more it's really more about kind of trust assumptions. If you let someone meddle with the transactions maybe they get you a better price but maybe they don't because you have to trust them right so the just removing those trust assumptions and then of course if you move the trust assumption and if you move the trusted broker maybe in some instances you get a worse price. So that's kind of like maybe one key that this is a trade-off but I think there's also a really big area of of research and of like how can we fix that because in principle it should also be possible to replicate the same sort of intelligence in a more trustless and encrypted setting. So extreme example would be you have something like threshold homomorphic encryption where you could run the same kind of back running algorithms and then kind of do an on-chain version of this and deliver the same efficiency but do it fully encrypted and fully rule based and fully kind of trustless. So in theory that could be possible just like homomorphic encryption isn't fast enough for this for this specific or you could maybe do things like post-inclusion ordering and there's a whole I'd say there's a whole really interesting research area of how can we allow the same broker type of because one thing also in the real world you can go directly to an exchange or you can go via broker. Broker might get you a better price but is again this trust assumption where you have to trust the broker to get you a better price. So I think the best future would be you have well you have this privacy and you have no trust but you also have like some intelligence some predictable and some trustless level of intelligence that can get you a better price. Yeah future stuff definitely but there's no reason why this shouldn't be possible with the advancement of cryptography and with the advancement of compute so I think next next time you come on you'll be telling me about the the AI.

SPEAKER_01 41:07

So we're getting a lot closer to that being um viable then well thanks so much Luis for coming on to the podcast I'll make sure to have a bunch of resources in the description if people are interested in learning more about what you guys are doing at Shutternetwork.

SPEAKER_00 41:22

Yeah thanks for coming on again for the second time you're a two timer and teaching us about some of these cryptographic primitives and protocols that we should know more about me and again encourage everyone to to look into this stuff I think dream from the F did a really good thread on saying why do we need encrypted mempools now so whenever check it out and to to give feedback and to evolve the the designs such that it is acceptable to the to the code.

SPEAKER_01 41:49

Right. Encrypted mempo thank you so much if you like what I'm doing here consider supporting the show on Patreon. Your contributions help me keep doing this work and dive deeper into the politics of decentralized technologies. I promise you absolutely zero financial returns no airdrops and your investment may go to zero but you will get good content. Check out patreon.com slash the blockchain socialist to support the show