Encrypt the Mempool!

ETH Tbilisi 2.1 · April 2026 · 1:07:08

Luis Bezzenberger and Loring Harkness of brainbot and Shutter Network present EIP-8105, a proposal for a native encrypted mempool in Ethereum. They explain how sealing transactions until they are ordered fights front-running, sandwich attacks and censorship, and how it fits the Hegota upgrade alongside ePBS and FOCIL. Full ETH Tbilisi 2.1 event.

Speakers

Topics

From ETH Tbilisi 2.1, hosted by ETHTbilisi.

Transcript

Uh well hello uh good evening to everyone. Thank you for joining us. Well, we're glad that you're here especially that it's raining and it's an Eastern weekend. So really thanks to all of them uh for making to us here and making it here right uh over the over there on the screen you can scan your PO app and you can see the QR codes to our like telegram and X if you want to scan scan it and uh join our communities right so for those who are new here because I am seeing some new faces allow me to just give you a short introduction of what it eats right so the motto is to make Ethereum cyberpunk again, right?

And if pil is just a community by Ethereum enthusiasts, builders, researchers who want to make this community for others who are like them and for us to connect, for us to network and for us to actually build Ethereum in Georgia together. So the today's topic will be about encrypting the meimple right about EIP81 8105 proposal aimed to make Ethereum transactions more private uh before they are finalized with the goal of reducing front running and improving fairness in all the networks. So the speakers uh today we are joined by two guests from

Shatter Network, Luis Bezenberger and Loring Harkness uh who are here to just share their work and insights on the topic. Well, thank you for uh both of you for being here and we're just looking forward to hearing your thoughts on the impul encryption uh EIP8105 where this fits into Ethereum's future and why it matters for users, builders and the broader ecosystem. So, we're looking for looking forward for your presentation. Thank you. >> Um with uh the company is called Brainbot, which is sort of the core developer behind Shutter. Um, Redot's been active in the Ethereum space since 2014.

Um, and since a couple of years, we're building, yeah, shutter network, which is a threshold encryption as a service mechanism. Uh, now also venturing into, let's say, homorphic encryption as well. On the voting side, we're primarily serving these um these two uh use cases. is the encrypted me poolool where we want to make the case that Ethereum uh L1 should have an encrypted meool for front running resistance and real-time censorship protection and also then on the on the side I just briefly mentioned it the for private voting um the same kind of decentralized threshold encryption mechanism we are also applying for voting and it's live inside of snapshot um and again we're moving

sort of to home encryption for threshold controlled homorphic permanently private uh voting. And the way we wanted to set it this up or the idea was that we um start with a with a very brief uh ju just intro us two start with a very brief uh presentation sort of like five minutes and then we will kind of open the the floor and open the little bit of a more generalized discussion. Hey everyone. Uh, I'm Lauren, head of commercial at Brainbot, the same organization as Lewis. Um, I wish we could be there in person with you all.

Uh, unfortunately we can't. Maybe in the future. Uh, and normally at this point, I would wish everyone a hearty GM GM. But, um, I'm actually gonna break from the presentation because I got to tell you what happened to me just now. The craziest thing happened. And um I just got to get it off my chest. So uh you know it's like what 5 5:30 here in Germany and uh you know I've been feeling a little uh low energy today. So I was like you know what I'm going to go get a cup of coffee before the presentation starts. And there's this new place which opened up in my neighborhood. Uh it's called the coffee

market. Uh Lewis I don't know. Have you been there? Okay. So, this place >> Yeah. The coffee market is this crazy place where there's no fixed price for coffee. Uh the prices actually fluctuate based on the time of day and based on consumer demand. And you know, I went in kind of in the middle of the afternoon thinking I could get a cheap cup of coffee, you know, just to give me a perk before we got on stage here. And you know, it's one of these new uh fancy cafes where like you scan the QR code in order to order. And I I scanned the QR code and I ordered my normal Americano.

And it was like, hey, you know, the price is $5. And I was like, cool, okay, submit order. [snorts] And then this uh this window popped up on my phone and it was like, "Hey, like we all know the price is $5, right? Price is $5, but what's the maximum you'd be willing to pay for that cup of coffee?" And I was like, "What the what's the maximum I'd be willing to pay?"

I don't know. I mean, this presentation is kind of important and like I'm feeling low energy, so maybe I'd be willing to pay what, like $50 for a cup of coffee. And, you know, I didn't really think anything of it. And then I went to tap my credit card in order to make payment. And in the split second before my card hit the uh the payment terminal, the price of coffee skyrocketed to $50. And when I touched my card, I ended up paying $50 for that cup of coffee. And like I didn't know what was going on.

And you know, after I had uh gotten my cup of coffee and settled down, I went and I spoke to the manager. And the manager was like, "Hey, look, you know, you said that you'd be willing to pay $50 for a cup of coffee even though the price is $5." [snorts] And so what someone started doing probably is they started buying up all the coffee in the store and in this town, driving the price up from $5 all the way up to $50. And so when you paid, you actually paid like the maximum amount that you'd be willing to pay. And then that person after you paid probably started selling

coffee back into the market. And now the price is $5 again. And I was like, "This is crazy." Like, like, who would buy a cup of coffee thinking that they're going to pay $5 and end up paying $50, right? Just cuz someone can see that order and manipulate it. And I was like, I'm never going back to this coffee shop again. Like, the coffee market is dead to me. I am so pissed off and I just needed to share all of this you with you guys uh because it is unreal.

Um >> crazy place. Crazy place. >> Yeah. Um obviously you guys uh are sitting there thinking um like what th this is a crazy story. This is kind of stupid. Like who would pay $50 for a cup of coffee? Who would manipulate a coffee market? Um, and it's actually kind of a silly story, but it does uh kind of give an insight into just how crazy uh malicious me on Ethereum has become because that exact scenario where someone is making a purchase and a sophisticated actor can see that

purchase order and then uh place their transaction before that order and then after order. Thus manipulating the price and giving the user the worst price and extracting value uh from that transaction reordering attack. That's actually exactly what malicious me is and it's one of the problems which has plagued Ethereum for the past uh four or five years and estimates range uh but one solid estimate we often refer to is that $1.8 8 billion

has been extracted or some might even say stolen from uh everyday normal Ethereum users, people like me and you. And so what we're going to be doing in this uh call with you guys today is we're going to be talking about some of the efforts in order to prevent malicious MEV on Ethereum mainet. And it's actually a super hot topic right now. Um there has been a flurry of proposals uh EIP with different ways uh to uh introduce encrypted mempools. One

solution for preventing malicious MEV. Uh I'm going to hand it back over to Lewis um and he's going to take you through some of the current conversation uh and then we'll kind of have a a fireside chat uh and hopefully field some questions from you all in the audience. Uh but again uh thank you for having us here today. >> I think it's a great intro and I think should make it a little more tangible of what what the the core problem is. Um and um the way I started was uh I want to start this presentation is um even just in general not even just crypto just just just in general what would you expect from from your kind of like your your marketplace right or your financial

ordering machine um to do right and obviously people maybe banks or certain kind of more professional actors would would maybe um put forward this efficiency argument or you want to have very very low latency trading or things like this. I don't think normal people care that much, right? I think they're more interested in just fairness and kind of like you need to have you need to be sure that you're not uh being put at at a disadvantage when when you enter this market, right? is like is crypto and traditional finance when when you trade be that in your broker app with the with the bank or be that in crypto with you know I don't know Solana or Ethereum or Coinbase whatever you

your primary concern is am I not getting exploited or is is it is it going to be a fair environment that I'm trading in here so so neutrality credibility fairness I think is kind of like paramount and and both in credi and cryptos is basically kind of to certain degree fundamentally broke. I mean it works but it also doesn't work that well as I would say in traditional finance it's interesting front running um which is basically what what um Lauren just just laid out basically is the ability to uh see transactions early see your transaction early and sort of jump the queue and steal your trade right so front running so that happens in the real world as

well or happened in the past just kind of was so in general made illegal or at least the the bulk of it. There's still ways that people get front run in the real world. It's quite quite interesting. Um Julian M from from the F has a cool viewpoint on this, but but essentially front running is made illegal. Um but you have all these other problems that are also um and there's I think there's a lot of time and money spent to um ban it and to make it um sort of like and to to enforce trust and to enforce this regulation, right? Um uh but you also have all these other sort of related issues with transaction ordering and

with kind of like where does your transaction hit hit the hit the the exchange for example kind of similar to crypto you have these dark pools. Uh in crypto you have private me pools and in the real world you have these alternative venues for where trading happens. Um, another word for it is MTFs, multilateral trading facilities. The dark pools and MTFs similarly in in a way also in crypto they fragment liquidity and people and certain people want to have want to be able to trade kind of on their own there and be like um have better prices there than than kind of the public markets. So that's also another issue. Then you have this payment for autoflow topic. So um

basically that's kind of the primary income for these new brokers right like Robin Hood in the US and Germany have something called Trade Republic very similar like when you can trade your stocks on on on your app right what happens is your order flow gets sold to these market makers because that's like interesting orderflow right people are seeing oh there might be something to capitalize on your your orderflow right and that's and so your NEO broker sells this autoflow to these market makers and thus they can offer you these extremely low even sometimes like free trading fees because they they monetize your your trades, right? So, um that's kind of another issue. Um, in general latency

and arbitrage just just um creates inefficiencies. And in crypto, we have this thing. There's no kind of like legal or illegal is still like a little bit of a wild west, I would say. Although that's sort of potentially also being discussed to make it illegal. But um you have this this front running issue somewhat addressed by these kind of private mess. But that just means you're taking this sort of alternative route through an a trusted um to to a trusted supply transaction supply intermediary that kind of guarantees you based on his trust that they won't front you. Um which is kind of like band-aid on the problem. So yes, that's that's sort of

like good for for for the immediate problem. Um but then now it creates this trust issue, right? Now you have to trust these people or institutions to not front you and that's kind of like that's the whole point of blockchain. You do not want to trust those intermediaries. So not optimal and also again fragmentation there as well. Um creates all these different places where where ordering where transaction are flowing through not optimal for kind of like liquidity and and kind of like central and and sort of like a good marketplace. Um also we have this builder oligopoly. So we have kind of like with PBS we're separating between proposers and builders in the on the

protocol level. And um PBS was introduced to reduce the proposal monopoly to reduce kind of the centralization there. But now kind of the issue is as well we have from on the builders who are actually creating the block right um you have only have two builders that are dominating like 95% of all blocks um so that's that's another centralization issue and um also a censorship issue though I think both of these are situated in the US um where in the past you had these talks around censorship and of list so very very likely that they will be regulated in the future not to include certain transactions based on this sanction

lists and of list. So again, that's like it's not a good situation if you have only two major builders kind of being the gate being the gateway and the gatekeeper to to the meool, right? Uh and and we talked about this me extraction and kind of like just a lot of exploited um value, right? Um so enter kind of encrypted me pools and the idea is instead of sending your transaction either to the public me where it's transparent and you're just getting exploited or sending it to a trusted single party where you just have to trust them that they won't frontr run you. Instead it is sort of like encrypted in a either you yourself encrypt or there is a decentralized way

to encrypt and then you send it into the meool encrypted and the block producer they have to commit on the inclusion and order of the transactions while they're still encrypted. So even kind of the validator builder proposer even they can't see what's in the transactions they have to commit blind to the to the inclusion of transactions right and only afterwards do they uh only after this order is like fixed in place only after this there is this decryption step again either by you yourself or by this kind of decentralized um encryption mechanism uh only after that that that's released and then it's executed And that just ensures well even the

validator builder proposer themselves can't see what's in the transactions very hard to frontr run if you don't see what's in them right and very hard to censor as well so that's kind of just like the EI5 uh and and then we kind of like have the opinion that threshold encryption is probably the best encryption decryption mechanism because it's that's this decentralized way of encrypting decrypting but there's also other encryption methods just like just as encrypting yourself or um for example tees which is a hardware um type of encryption decryion mechanism um and why we think this matters is um kind of like primarily it's actually less about front running because again we have kind of

like quick fixed front running with these private mess. So well people have different opinions on why why why it's the why it's important but to me maybe like censorship resistance is sort of like maybe the important one right if you encrypt transactions it's extremely hard to to censor them because you don't even know what's in the transaction right so I think that's that's a major one and again this like reducing centralized trust assumptions in the me poolool um a really big one to me is um the if we create this more fair marketplace and this more accessible marketplace where people don't get front run left and right or where you don't have these like white glove specialized um me pools and and fragmented liquidity

lanes where only certain people have access to. I think we can uh get more people uh to the table, right? We can if we level the playing field basically we can just get more people to to be interested in and be uh and and add just more traders and more people which means more liquidity and to me that means ultimately more transactions better prices everything right so I think that's key to I think to me it's if you build a really good marketplace a trust with the marketplace it just means you attract more liquidity right um also I think applies to inst institutions because as we've seen like in in traditional finance is actually just

like made illegal and just from a compliance perspective some or regulatory perspective traditional finance institutions might not even they certainly they won't feel comfortable trading on a on a marketplace where front running is is possible right so I think it's like that's an argument for making it impossible um as well um And then we talked about this builder um and and private me oligopoly. I think that's something we where the encrypt pool can can level the playing field and even for the builders can actually empower smaller builders to now be actually have have more chance because right now

you're trusting these large builders not to frontr run you. The more you take that trust assumption away and say like we it's part of the protocol that there's no front running, the more we think you empower smaller builders again to to be able to compete with the with the large builders because trust is something that smaller newer builders maybe have haven't accumulated yet, right? Um and then quite quickly what what what are we what's the current status of this? Right. So um we proposed a an something that's called EIP8105 which is this protocol level encrypted meool encryption technology agnostic any it's it's not even specific to threshold

encryption any encryption can be used um and right afterwards the some small kind of team kind of primarily from the EF uh has proposed their own approach to this called lucid very similar approach and that's why we said we should join forces because it's kind [snorts] of goal the goal side is very similar and also on the approach it's pretty similar so uh we join forces to to bring this to um Ethereum uh we it was then not included uh it's pretty likely that it it won't be included in the Higgot hot but there is actually a good chance for it to be included um the next fog the icear

heartfog um because there. It was just listed um on the EF Strawman road map um for AR in 2027. And in general there is a lot of feedback that came from this uh CL this um client process from from the client teams and this voting process which I think is should now lead to us and Lucid team and others iterating on the design and just making it a lot better. So couple of examples here. There is very good criticism um for from flash coming that the that back running um is less efficient in this design. So maybe first

and foremost just briefly the encrypted mele only prevents front running not all me. it can it can by definition only prevent running and back running is still able to ex um there's still ways to exploit the to to to extract backing me which is actually something that people think is good um because that's for liquidations and arbitrage and can actually if you then pay that back to the user is actually kind of considered sort of like benign/g goodme totally possible in both lucid and EIP8105 just the exact way how to extract it is arguably less efficient and you can extract maybe a little bit less of it um as compared to a private meool. Um so

there are I think there are strong approaches to bringing that backing efficiency to the same level as for private mess. Um which I think one of them is postincclusion ordering maybe some other ideas. Um, and by the way, just all in all, I don't think it matters even that much because it it certainly is better than it would be in the public meool. Uh, so if you compare against priv private mess, there might be some efficiency losses, but if you compare against a public me um that's certainly kind of like um better this the situation should be better for the user because they're not

getting fun. Um there's talks about potentially combining with frame transactions with kind of like this UX um account abstraction type um EIP and then I think there is definitely a push for it. It should be ideally as postquantum resistant as possible. There's a strong push from the Ethereum Foundation to make everything no every addition to the protocol should be um every cryptograph cryptography addition to the protocol should be postquantum resistant um which it is um both the AP815 and um Lucid are because they're encryption technology agnostic. It's just you need to make sure that there is

actually um sensible and good encryption technologies that fulfill that criteria. Um then while kind of this being figured out and we're kind of working on on I would say the next generation of this EIP uh we uh are also just building out of protocol. So one thing that's been live actually for uh a longer time now is an out of protocol version of the encrypted meool on Nosis chain and that's actually supported by the nethermind and Aragon client. So recommend everyone to to check that out.

But um for Ethereum one, we're also bringing that to Ethereum one via um together with PrimeF which have this um builder and proposal commitment scheme called me commit and we have built this um together with the prime team have built this um encrypted meool lane basically into that and um that's really uh ready for builders to adopt. So if you know any builders or if you are working at a builder um talk to us we would love to have you guys be part of that and and support it so that we can have um a an out of protocol version of the encry before it gets fully implemented deeply into the protocol. Um

that's kind of it and uh just showing the EF strawman road map where you can see the encryptment pool here is is scheduled for 2027. uh 2027. Um yeah, and along with other other things. And here very brief sneak peek on this the the swap demo app and AMM for this shutter primev or encrypted meool x me commit out of protocol implementation.

Um yeah that's it. And we think uh yeah we think [snorts] by making the memp pool kind of by bringing back the public so maybe that's something I forgot to say the public me is broken kind of everyone agrees uh so that's why people are choosing these private me pools um and I think the encrypted me is a way to bring back the public meool and level the playing field and by doing so I think we're doing good in making Ethereum more attractive to to everyone. So uh Lewis, you were talking mostly about encrypted mempools and the efforts to implement them on Ethereum mainet. Is this the first time

um that a blockchain has sought to implement encrypted memples or uh are there examples from other chains um outside of Ethereum mainet? Yeah, good question. I would say Ethereum is or the Ethereum ecosystem I would say is leading the charge definitely um because that we have already proposed this a couple of years back [snorts] um together with the Nosis team. So I would say Ethereum is certainly kind of like leading the charge and then Nosis chain with the crypto me and Nosis chain I would say that's the first one the first life implementation

um but definitely not in the vacuum here. So definitely other chains have been looking to the same the same thing either inspired by by our efforts or coming to the same realization independently. Um so maybe uh one notable one notable one was Anoma very early on um they had a DKG kind of like proposed inside of the of the protocol. Um we've seen uh I think we've seen recently more recently we've seen APAs um uh proposing one as well very very similar approach um uh and then uh yeah and maybe really noteworthy but

still within the Ethereum ecosystem um is the arbitum ordering sort of design. So they arbitr was famously really kind of pro- fairness and pro kind of fair ordering. Um sometimes maybe even too like too too fair or too optimistically fair where where maybe dashboards or other more efficiency minded people would say it's doesn't work this way and it kind of like creates weird sort of like spamming situations. So they initially had this like really like fully like fair ordering protocol where first in first out and that's um worked somewhat well but that that also really is like

is is a fair ordering protocol not encrypted but but I think they're they're have their goal align and that they want to actually get get fair a fair transaction order right um and they have since updated it which is to something that's called time boost um and and and then the decentralized time boost version together with espresso that's also relatively similar to our approach with the thresh encryption and the consumer pool. So our definitely noteworthy in in that in that space as well.

>> Cool. Um there's a important concept which we kind of uh just gave the most surface explanation of which is um really at the core of shutter and that is commit and reveal threshold encryption and um for everyone listening uh it's probably good for us to dive into that in a little bit more detail because it underpins everything that Shudder does from uh malicious V prevention with encrypted memples to private voting and other applications. So to break that down for you, there's commit and reveal, threshold encryption. When we talk about

commit and reveal, this is a special type of encryption which is really important not in the sense of making something private and hiding it away uh forever and always from everyone. Um this is a type of encryption which is particularly applicable in simultaneous move situations. Um where it would if one player were to see the other player's move before making their own move and use that information asymmetry to their advantage.

uh then they could potentially uh win every time or exploit or manipulate uh the game for their desired outcome. Uh a really good example of this is rock paper scissors. That's a classic simultaneous move situation where one two you have to show rock paper or scissors and the other person has to do the same. And it works really well when you're in person because uh we trust each other um and our reflexes aren't fast enough to see the other person's move before making our move.

Um, but just imagine um that we played a lopsided game of rock paper scissors where we counted to three, you had to show your move and then we counted four, five, six, and I got to show my move, then it would be completely unfair. It wouldn't be a simultaneous move situation anymore. Um so the way that we can make this simultaneous move situation more fair and neutral is by uh essentially um encrypting the moves uh when people commit to that.

[clears throat] So you can imagine uh a kind of partition between me and my opponent. I show one, two, three, and then I lock in that move. And then the other player locks in his or her move. And once uh both moves are locked in, then the partition is removed and the results are revealed. That's kind of the essence behind commit and reveal encryption. And if you think about it, uh private voting is another wonderful example. um not even thinking about uh Dows or uh blockchain based voting, but if you think about like putting your uh

ballot in an envelope and then in a locked ballot box, that's actually kind of a manual form of commit and reveal encryption, which keeps all ballots secret until the end of the voting period. Um and then the second part of that is threshold encryption. So going back to uh so threshold encryption is basically instead of uh relying on a trusted third party in order to provide the encryption and decryption service, you rely on a distributed group of nodes which collaborates to generate encryption and decryption keys. And this

is a very uh decentralized and robust way of doing encryption. It does start off with an honest majority assumption or an honest threshold assumption. Um but there are layers of uh security that you can put in place in order to kind of provide a backs stop to that uh honest threshold assumption. One of those is you can do staking and slashing so that if any of the nodes is acting dishonestly uh they'll have an economic penalty. And then there are some cutting edge cryptographic techniques including uh cryptographic snitching where if one node does try to collude maliciously

with other nodes, then um the other nodes can actually see that malicious behavior, generate a cryptographic proof of the bad behavior um and then use that to both penalize the malicious node and to get a bounty. or a reward themselves. Um, and this is really, um, you know, at the heart of everything that Shudder does. And so, um, I'm going to ask another question of Lewis specifically to encrypted mess. You mentioned, um, that someone could encrypt their own transaction, that they could use a decentralized, uh,

encryption provider. Um, I guess the question is with EIPA105, is Shutdder looking to enshrine our version of commit and reveal threshold encryption into the Ethereum core protocol or uh is something different being proposed? >> Yeah. No, exactly. Um, definitely not. So um the idea is to keep it open and generalized and to say that um any encryption technology that satisfied satisfies a very general and broad kind of like interface spec should be allowed um and and especially any key provider

any should be allowed to to provide keys. Yeah. Um and just to name but I would say just to to make kind of nail down or also to reiterate a little bit why threshold encryption is kind of uniquely suited to do this is one yeah it's just this decentralized way right so you want to decentralize it right um but especially the the unique property of th encryption is kind of it solves this last look problem or this kind of like this free option problem um so the if If you encrypt with your own private key, that would also be decentralized, right? Because everyone encrypts with their own private key. But [snorts] then there's a kind of a game

theoretic issue because if you encrypt with your own private key, then you have an option later not to decrypt and then you can actually invalidate your transaction and pull back your transaction at a later point. And why that's a big problem is because there's always an option kind of in so if you do a say you commit to buying ETH at $1,000 I don't know and then there there's going to be some time let's say 10 seconds where the price fluctuates up and down if you then if you've already committed to it and then afterwards you can just pull back your trade because you've seen oh the price went against me

maybe price in the meantime went to $990 you now no longer want to buy at a,000, right? Um, so you'll just pull it back and you invite a transaction and that's this free option. So you have a free option not to decrypt essentially if you yourself encrypt. And now imagine this more elaborate attack where you just send a thousand transactions at varying price points of ETH, right? And you just always just select the best one for you, right? So that's kind of like then clear clearly sort of break the [snorts] system. Um so you want to have it decentralized and you need to eliminate this free option to make it just like work and sound right. So that's kind of

this unique unique thing for thresh encryption because it kind of like enforces decryption uh and you're not the one who decrypts and it does so in a decentralized way where there's no so the cool thing is always like if like tw say 12 out of 17 nodes need to um need to come together to to decrypt is like this threshold of 12 compared to the total number of nodes of 17. So let's say all the nodes are come together like 6 7 8 9 and then you're at like 11, right? So you just need one more key share to then get to the decryption. So you have 11 but you need 12, right? And then there would be a theoretical free

option, right? Where one person could say, "Oh, I'm not releasing my key share. I can now uh I can now kind of have this free option not to decrypt." But um because now there's still seven there's still up to 17 left. So you still have um eight people left, right? No, better math. Six or something, I don't know. 12 17us, right? You have a good a large number of of um of actors um which all of them can can submit the last key share. So you're taking away the option to decrypt from the option not to decrypt from one person to suddenly there's all these people who all can choose to to to

submit the key share and decrypt. So really making it extremely easy to get it to get decrypted especially then if you scale it to 200 nodes right then there's really like pretty sure that it'll get decrypted. Um so that that that's kind of this like um property of uh this is nice property of of like kind of uh unstoppable decryption and sort of like it will be decrypted that that's why we think encryption is probably the the best approach but yeah still keep it generalized and keep it open especially keep it future proof right there might be much cooler and much better cryptographic systems in two years two three years down the road which we want

to be competitive with as well. >> Maybe just a quick note when Lewis mentions uh keep it generalized, what we're really talking about is allowing or creating a uh competitive marketplace for key provider services for encryption and decryption services. So we could imagine that um some users which have low value transactions um they may be willing to trust a TE uh because it's fast and cheap and it has hardware assumptions.

uh other users which have high value transactions or sensitive transactions uh may uh prefer uh to use threshold encryption uh and rely on cryptography rather than hardware. In the future it might be or some other type of encryption. Um but really giving users a choice there. At this point um I understand that there are some questions from the audience. Uh so I'd love to open it up to the floor um and we can dive into the topics which are most interesting to you.

>> Uh thanks a lot to come here actually. Uh I'm glad you really low. We talk a lot like on on X and on Telegram and I'm very thank to to be here and it it was a it was a very like um exciting conversation actually that that that you do uh because I had like some question and you totally like take all of the points that that uh that I that I that I wanted to ask. So now we start the um Q&A session. Uh so the uh this section will be hosted by Davidid which is here and we are trying also to because we uh take the um people from the audience

when they ask the question to come here and so you will be able to see them uh in in in face that I know that with remote events it's very difficult because you don't see the [laughter] the actual audience and um and so thank you so much to be here and now we start this this section. So, hi once again. Thank you for the presentation. Uh, Loring, my first question is with you. Uh, I loved your story about the coffee. However, uh, was it just an analogy to set up the energy for the presentation or did this really happen?

>> No, this is um just a story used to illustrate u what me would look like in an everyday situation. Uh but for better or worse it did not happen. >> Okay. Thank you. Uh well then the next question would be I will start with a couple of basics once once however I want to know uh when do you expect an encrypted mele to be on Ethereum mainet? So um it's really a decision which is up to the uh Ethereum core developers and the Ethereum client teams which are in charge of implementing

uh changes to the Ethereum core protocol. But um there were a couple of proposals to have encrypted mempools as a headliner for Hegotaa which is not the upcoming hard fork but the one after uh that one. uh those proposals were not accepted and so there seems to be a uh rough consensus that uh encrypted mess are likely to be implemented in AR um and that is also supported by the Ethereum Foundation's straw map which was published recently as well and to

give you a specific calendar date um I think we can expect to um uh take place uh probably in uh August or September of next year. >> All right, thank you. And the next question would be to Lewis. Uh I just want to know will the encrypted meme pools uh add any noticeable latency to the transactions? Just want to add one one thing to the question before um because we're also working on this auto protocol version of the pool with prime. So um I think that's an opportunity to get it in

earlier. Um and it depends a little more on adoption from supply chain in like builders. So it's a little more of a uphill battle if we go this this route but um at least there will be the option for people to use it. might take a little longer to to um for a transaction to go in, but that that will be an option hopefully very soon. Um but yeah, um will there be a latency impact? Um uh yes. Um so essentially the way we think about it is it depends on the EIP and depends on the exact approach. But ours and lucid essentially we would say that if you do a transaction in this

block then it'll then if you don't send it through the encrypt pool it would have the chance to land in this block right in the the one n right whereas if you use the encrypool it'll be the earliest of it that it'll be included would be at the top of the block in n plus one so so depending on that it yeah it means like kind of like it'll and in the next block. So you you you you don't have if you do it now, you don't have the chance that it lands in this block. It'll always be the next block was kind of like the way to think about it. Um but but like yeah I I think like in the grand scheme of things latency doesn't for Ethereum doesn't really matter because you have kind of this 12 seconds

or in the future maybe 10 or sorry 10 seconds or maybe in the future maybe have six seconds. Um, and I would say all the encryption technologies that we're looking into and all everything should kind of be well below that, right? I think we can get threshold encryption also kind of in to the to the order of 100 milliseconds to decrypt. So I think on the time scales we're talking about in Ethereum, it the the latency and this like time to decrypt doesn't really isn't really that big of a deal. might may be a bigger issue for like Solana because there's all about like super low latency or like mega e right where you whereas everything about low latency that then maybe the decryption

step and all of that stuff adds more latency that's yeah >> uh thank you I believe people from the audience have additional questions >> yeah thank you guys for coming and speaking today uh I'm Fry and I've been going to these events for a while and before I asked my question. I just wanted to say I'm primarily an Ethereum maximalist. Uh even though I've messed around on other chains for the most part, I always come back to Ethereum. Can't really give up on it. So if my question seems a bit harsh, I just wanted to start by framing that in this way so you wouldn't think I was just being an Ethereum hater. Uh with the future bringing potential existential threats to blockchain, we're starting to

see serious media outlets come out and say things like quantum computing, AI could break blockchain, and all these different types of existential threats. To me, it feels like the ability to solve problems, especially simple ones like this that have taxed users nearly $2 billion during the lifetime of Ethereum. It seems like being able to solve those problems is particularly important. So my question is why has it taken so long for this solution to be implemented and it seems like it's just such a great fix to something that's been taxing users for such a long time.

>> Um I think very good question. Yeah, I think it's um and I think there's many reasons and maybe we're overstating a bit how simple it is. Yeah. So I think there it um it it does require relatively extensive protocol changes for for this to to work. Um uh to both the consensus and the and the execution client. Um and and also I would say one I would say one big criticism people definitely can have is that the none of the encryption technologies is is perfect in this regard. Yeah. So the thresher encryption you have this trust assumption where you

still need to trust that x amount x percentage of the nodes are are honest um tees uh as Lauren said you have this hardware trust assumption so you need to trust sort of like Intel or whoever they don't have a back door and also you have this hardware requirement on nodes that would have then have to run this specialized hardware that has this TE or SGX or compatibility um so I think that's that's a valid criticism and where maybe some people would say let's wait a little longer even to for us to have the p perfect kind of matured cryptography so that it's like kind of like fully end to end safe and and and and yeah um but I think the reasons are kind of like

coordination awareness um maybe one maybe one thing that has slowed it down is actually private mess right because because the the without private man pools the the problem would be a lot more obvious and people would get front run left and right yeah so you'd see the graph and the front running is going down so people would say great that's so we saw front running right so that's a little bit of a of a misconception I would say because again we saw front running but by but by introducing strong trust assumptions and maybe even introducing a censorship factor right because now you have these these private me pools where they they can not just frontr run but they could also now censor your transactions

So um I would say private mess might even have slowed down this track but the general answer different factors complexity um awareness uh yeah great question. >> Uh thank you very much first of all for this meeting uh thank you the organizers having a it was a very informative like uh slides. Um my questions are uh as a builder how much does the ape uh affect the builder side or is it more a provider side uh change to ecosystem >> um both I mean would change both right

but um as specifically on what happens to the builder's bottom line right would be a question um I would say the yeah so like very simply speaking kind of like the the the total me would be reduced by the amount of front running right so the pi would kind of like in the first place get a little smaller to distribute right um again I think there is a way to make it such that the same backunning efficiency and same way to background can be applied so in our view it would be only the front running that would disappear or the front running type of me so and then you make the argument for builders

and searchers and validators. Usually that gets split up, right? You have some amount of me and that gets kind of like distributed between between um between the searcher or found the opportunity, the builder and the and the proposer and then maybe even some of it gets gets paid back to the user depending on on Yeah. But so so I think arguably the pie gets smaller by by the amount of front running. Um, so you could argue the income for builders would shrink slightly. Yeah. Which I think is a fair argument. It's that's not that's probably not good for builders, right?

It's not good for their for their income. However, I would say one a couple of things. Um, that one is I think everyone kind of agrees that front running isn't like a very sustainable to way to sort of make money. Um, again, we've seen it as even illegal in the real world. Might might become we've seen even comments from regulators that they see me and front running in crypto similarly to front running in the real world. There might be even like ideas to regulate it. Um number two, it scares away users, right? So, uh it's just not like you see it with rollups, right? Rollups are definitely not front running the users um or kind of like trustworthy rollups like Optimism or

Arbitum are they have they can frontr run their users. they could they are also just choosing not to right because they know it's just extremely bad for adoption right so so I would say everyone agrees front earning will go away or is already been going away just it's just a question of how exactly does it go away and who and how um are we just eliminating it by now we're trusting someone not to front or are we kind of fixing it on on on the lower level hopefully that answers the question >> thank you Louis I really liked your answer actually because the second question of mine was about me. Uh so are you saying that uh it essentially disappears.

>> Um and yeah no so uh I tried to explain that basically I would say we roughly separate between front running and back running. Front running is the one where you jump in front of someone and back running is the one that your trade does something change the price of an asset and that like let's say disliff difference of the price to maybe a price on another DEX which is maybe more true to the true market price. So that creates this 1% arbitrage opportunity.

So back running means you attach yourself directly afterwards and exploit that right. So um front running can be uh can be basically solved by this encryal approach. back running cannot um or not not reasonably and and that's actually not a bad thing in some ways, right? Because back running people actually uh even either they tolerate it as a as a okay thing or they would even say it's a good thing because arbitrage makes prices be better across taxes and and if you pay back the arbitrage profit to the user that even gets him a better price as well. Um so we would expect

that just the front running um profit uh um just just the front running ME disappears or gets shrunk by a lot and the back running MUV remains and again as I said before I think that the front running that's that's that's I would say in general the consensus that you that front running is not a sustainable way to to earn income even flashbots or other kind of people who are deeply into me this the systems how they set it up are already kind of like set up in a way that uh that they're choosing kind of based on trust not >> so you're bas uh as I as I understand you're basically saying that you can

still see the trend of me in but in the past not in right now with front running >> yeah yeah I would say the the the the front running will go away anyway right uh and back running ME will remain because uh that's just arbitrage, right? In the real world, there is no ME. In the real world, you just have trading and arbitrage and front running and front running is illegal and stupid and back and and kind of trading and arbitrage still exists and that's good because arbitrage means you're you're exploiting all the little inefficiencies. Yeah. So, I think that's the same level you could just think about in crypto as well. Uh front

running is cheating like you're jumping the queue, right? And back running and arbitrage is just trading and you're just make it just means somebody is is exploiting arbitrage opportunities and it's actually positive. >> And uh I'll ask one more question. Uh the M actually is uh a subject that I had a close like relation to because uh I do my projects with uh account abstraction and uh I don't I my third question is about how much that will affect like the meme pools of uh like you know ERC 4437 u meme pools uh because I I think it's uh public it's more public will uh the change also

affect the ERC 337 mean pools >> yeah I mean I mean for now like it's generally just compatible with that right and it doesn't really affect it so obstruction should just work but yeah then you're you already you already said it correctly like there is a second there's another meool there in front of the public meool that would then be public and then there the me can be extracted So um so then the encryp on the protocol level is kind of like useless because you already seen the transaction before. Um so so yeah that that would need I think that would just need to be addressed separately either by another round of encryption for

example um or again alternatively like assumption there where you say you have to trust the the account abstraction or say like pay master or whatever it's the the one who kind of like is control of that of the transaction. Yeah. >> Hey guys, uh I'm Zach. Thanks for the talk. Um, I had a question about back running and um, because like you're saying, back running is is just arbitrage and generally a good thing. Um, so is all the back running pushed into the next block or are are there ways or ideas of how to let people back run in a single block?

Not not all back running but the back running of those encrypted transactions would happen immediately afterwards. Yeah. So uh yeah does that answer your question? >> Yeah. So, so no block no back running in the same block, right? And then are there all the Oh, maybe something we forgot to mention is all this just optional, right? So, all you would still have unencrypted transactions, encrypted transactions and unencrypted transactions. So, um this just a new transaction type. The encrypted transaction is just a new transaction type and of the and the back runninging

of those transaction would happen in yeah at the top after the top of the next block. Uh, are there ways to let people back run in the same block or um has anyone think thinking about how to let people back around immediately after trades and stuff or just >> uh do you mean for the encrypt transactions because that's that's kind of like not possible, right? Because they're not even revealed at this time, right?

They're just revealed at the top of the next block. So that's when and the builder who builds the next block just has then the ability to extract the the back runninging there. >> Okay, cool. Yeah, that's all. Thanks. Yeah, there's um I think um there is a really interesting deeper conversation there to to be had to how exactly it is extracted and essentially I'll say the problem one problem that the current designs have is and I touch on try to touch on this on the slide that it's basically just one big transaction that you do after the encryption transactions

and that back runs all of them. So whereas currently every individual transaction gets back run in the private me pools. So arguably the depending on how you view like from a system perspective the one transaction is more efficient because don't need to do thousands of little transactions. But from a trading perspective the individual backgrounding is more efficient because everyone kind of gets background and everyone can get paid back. So if you also have this assumption that really like always everyone gets paid back the users then then I think there's a good case to be made that the the private me back running is more efficient. That's why I

said like ideally we have a design where the same level of back running efficiency and the per transaction back running is reintroduced to um to it but but I think we don't have that currently but I think it's conceptually possible if this proposal 8105 never ships what is the next best path for protecting users from malicious meth that's the question >> good question I'm biased No. So today definitely I would say choose your poison from the uh existing private me pools. Um I am not sure how much it matters between

let's say flashbos protect and me blocker and and all the others. Um so yeah I think you as I said kind of the public mele unfortunately is broken. um probably not recommend anyone to to to to trade there if they're are worried about let's say your slippage and and things and getting front run. So yeah, I would just use one of these private me pools. Um that that mean that that that's saying like if you want to use uh any decks I would say if you are fine with getting with a specific deck which is cow swap I think that's a great incentive as well right so cow swap is an am or a an exchange design which is inherently a

lot more mev resistant um because you have dispatched options and you're optimizing around um around trader welfare and not around profit. Right. So so say um uh some trust is some as well. We've seen a big exploit happening there as well um in recent just a couple of weeks ago. So you need to trust those solvers to a certain degree that they actually find a good solution for you. But um if you do that then cow swap is a good alternative. Um so that's for today.

Then medium-term, I hope the primev crypto pool gets ready. Then um plugging that as a good medium-term solution hopefully once they're ready and then long-term into the >> uh thank you very much. Would you like to add something? >> Um actually I I don't have question because I think we pretty much like wrap up everything. Uh but um in closure uh I really want to thank you guys to to Kane because I think that manual encryption and since like the discussion started is uh is something that is very

important for the long term of Ethereum in general and uh and so thank you guys to do like all of this artwork in all of this time. >> Thank you so much for having us. Um, just as kind of a mandatory shameless plug, um, if you are interested in learning more about Shudder and our work, uh, please go to shutddter shter.network and you can find all the information there. If you're interested in encrypted mempools, uh, just do a quick search for EIP8105 or Lucid Lu

encrypted meals. And of course, uh, you know, this isn't something, excuse me, uh, this isn't something that we can implement alone. Um and so if you are a wallet, a protocol developer, a block builder, uh if you um even a uh just a a user on Ethereum, um you know, please think about how you can contribute um to implementing encrypted mempools um whether it's on a technical level or merely just hopping on X and saying that you're bullish um on

encrypted meles for uh censorship resistance and preventing toxic me. >> I'm bullish on it. [laughter] Thank you so much guys. Thank you. Thank you.