Maybe controversially, it imposes 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 Viva build, who control, I think, like, 90% of the of all blocks. So there's this really strong kind of centralization that you need to rely on these two builders to get these reductions, at least if you want to get them into in a timely manner because they build the most of the blocks there. In the real world and in traditional finance, clear front running is basically is is illegal. And so it has, like, laws against it. This episode is sponsored by NIM, the world's most private VPN that protects your Internet traffic and metadata.

Yeah. Thank you. And great to be back. Yeah. So I'm Luis. I'm with Brainbot. The the company is called Brainbot, and the project is called or the the DAO, and centralized project is called Shutter. Brainbot is this, actually, now older software company started in 2014, actually, back then built the the Python client for Ethereum or was the major contributor, I would say, to the Python client, more than three clients back then. 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 should 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 and then we plug this into different use cases. The one that we're talking here about is is the encryption actions to to combat front running and and real time sensor shipper listens. But, also, we have it built into snapshot, for for voting to encrypt voting and combining it with homomorphic encryption to have, like, permanent private voting. But that's that's a separate topic.

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, people need to combine their keys, essentially, in this protocol such that it's safe. Right? And that they don't don't just send actual key shares around, and it actually is, like, a kind of a a secure process. So you need always, like, a a subset of signers to come together, but it doesn't matter which subset. So so there was this funny there was this crypt really deep cryptography powered homomorphic voting scheme with, like, actual cryptographers set that up, like, out 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 keyholders actually lost the key. And that would have been simply been avoided by using instead of kind of just chummy a signature or just a just kind of three as 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. Do do you have redundancy? And if one or two people are even like, if you scale it a lot, you can have 200 keyholders. Right? Then you can have 50 people losing or right? Or even a 100 or even 80 people not not not having access to their key 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 it, like, you would have you maybe you have collected the the two key shares out of three, then there's 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 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, because there's no single person being able to stop it. And that's important for things like transactions, because if you can prevent decryption, then you can manipulate again the transactions. So if if you can prevent decryption, then it means you can put a 100 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 for censor transactions

if that were possible. Yeah. Oh, you have a free like, oh, it says you have a free option there to to withdraw our transactions, and that's not something you don't want. So but, yeah, maybe I'm jumping ahead that that that's kind of the property. But, basically, those two properties, I would say, make it kind of useful for transaction encryption, and and kind of any of you are in in in front running because you can now use that to encrypt transactions and have the block producer or the sequencer, sort of commit to the order and the inclusion of the transactions while they're still encrypted. So they they receive the transactions encrypted, 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 and execute transactions. And then, essentially, you can't front run because you don't even see 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 employee 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. So it's it's already in itself without fossil without kind of forcing selections through. We have this already have a pretty pretty strong censorship resistance.

Yeah. Maybe controversially, I would say, like, MEV is kind of sort of like or I could say, you could pose this assumption that MEV is kind of bad in general because it is yeah. That that's really what you said as the buck. 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 back in the day, it was called miner except who 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 had a good trade idea, is bad. They they should get it. 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 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 background in MEV, then then it's then it's good for potentially yeah. For 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 there's, like, sort of jumping the queue, or stealing someone's trade. So think about you sending a trade to the chain. It's like you're 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 reorder. And, yeah, 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 the bad form of it, the front running. Funny enough, in the real world and in traditional finance, that sort of clear front running is basically illegal. And so it has, like, laws against it. Yeah. 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 out of sync. The true market price, let's say, now it's $10 10 $10 more and more expensive. The arbitrage the 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 $10 too expensive back to the true true price. And then they get this $10 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, and by arbitraging it back to the true price that that doesn't mean the most classic version of back riding. And you you you'll be able to say that's good because, well, you're bringing the price back to the to the true price on on the exchange rate. It's good for just, like, the stable prices. And then especially if you then think about, like, the how it 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, that they pay back the user, let's say, 90%. Like, I think a usual convention in 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 use vector, it's 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. For you, it feels really for the user, it feels really good to just get money back. 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. Yeah. Mhmm. The funny thing is that you could if you argue strictly from a technical point, like, let's say, like, if you argue with people who are more, like, core developers or more think 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? What 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 Cowswap comes in where you instead of these trades, like, 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, already provides the best price in the first place. Yeah. But in the more traditional trading sense yeah. Yep. I think it's

I think it's a multistage 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 by 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 input. That's how Ethereum works. And I think it's important to have this public input 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 in 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 auth builder, right, that I can sort of trust to a certain degree where I send the interaction 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 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 furthering. 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. So that's bad. And the private mempool is also bad because it fosters kind of centralization and this, like, exclusive order flow. And, also, it just, like, it requires trust. You have to trust the builder to do good currently.

Yeah. Exactly. And then we were very similar, and, you know, you have to make this choice as well. You need to think about, do I send it to where we were at since the transactions? I think, so you would say the highest liquidity is where is on the public exchanges, or you could kind of try to find a more OTC direct kind of peer to peer way to to find someone to to trade against. And then there's these hybrids, like MTFs and these, like, DAC pools where you have, like, maybe a smaller exchange with some level of trust and some level of privacy. Yeah. It's it's a good good way to to mimic to to map it. Yeah.

So you separate to 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 reductions, works with such as and works with some auto flow source, basically. They build the block, but they don't have they are not the ones who have the staked ETH. They don't have the actual power to propose the block. That's the proposals. 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 a kind of danger of a proposal monopoly because sort of Lido, I think, has a lot of ETH in their network state. And the more you get into a vertically integrated monopoly of whether validate has all the power, it was necessary or it is necessary to separate these roles. The stakeholder, 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 blocks. So that's PBS. And that 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 relay sit between the builder proposal, and they are trust you need to trust them because they see the transactions. The proposal doesn't. Right? You can hide the from, the contents from it, but the relay needs to see it. So you need to trust the relay. And in general, there's, like, a fragment or was it still a fragmented and not really perfect p b out of protocol PBS production supply chain with trust assumptions, with issues. Builder centralization is another issue. So what EPBS is doing, enshrined PBS that is is I think it's good for for Glampsterdam, hard fork is to enshrine this out of protocol a out of pro 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, let's say, 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. But maybe back in the day, the the danger was proposal centralization. But now I'd say we have two builders, Titan and VivaBuild, who control, I think, like, 90% of the of all blocks. So there there's this really strong kind of centralization that you need to rely on these two builders to get visual actions, at least if you want to get them in in a timely manner because they build all the most of the blocks there. So then Fossil is something I think would say was 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 next bill at least the next builder needs to needs to include. Otherwise, it's not a valid block. So you've 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 selections. So that that's fossil inclusion list. And and and I think what we're what we're saying is, ideally, you need all three. So EPBS, fossil encrypted mempool. And and Mark from Netherman has coined this really nice time. He says, it's it's it it would be like the holy trinity for censorship resistance because your EPBS kind of gets rid of the relay and kinda makes it makes it reduce that that trust assumption. Fossil makes creates this list of those transactions have to get in. An encrypted mempool is the one that, hides the transactions, and and that is a release from 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%, basically, thing. Yeah. Yeah.

Yeah.

Yeah. And maybe one step back is we I haven't really talked about the EIP. So so the encrypted mempool is just a concept, and we can implement it even, like, out of protocol, something we are doing together with Primaph 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 kinda works is if you can build it in the protocol and that needs, VIP that needs a change in the protocol, and that's yep. You can only do that via VIP. And so so the goal for us would have been to get the to to to schedule so we we proposed an EIP in kinda, like, three months two, four months ago called EIP eight one zero five to and a universal enshrined encrypted mempool, which also quickly doesn't enshrine or the the encryption technology. So not even threshold encrypt not not neither shutter nor threshold encryption would be kind of mandated by this. 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 encryption. They could use touch on encryption. They could use home office. They could they could use MPC that they would like to to use. So we proposed that a couple months ago. And then right after it was, like, a month later, essentially, Lucid team proposed their own. And Lucid is kind of like and Julian from the f and then Justin from from Beso. The core team, I would say, is is is just a small group of people who are pro have proposed this, alternative encrypted mempool EIP called Lucid. To differ in and and then we had two encrypted mempool EIPs, one by us and one by them. But we just kind of, like, joined forces, I would say, the the goal was always the same. 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, aspect of it. And then kind of right before so there's now there's now Amsterdam is the current is the next step, hard fork. But the interesting part would be which EIPs would go into. 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. So and then, essentially, it was the the the story the we were collaborating on Lucid and making the case for it to be included into the Hackathon hard fork. But now there was a decision from the core devs not have that as a headliner, which doesn't mean it's not going in. It's just yeah. But it's, like, a little complexity around this. But, actually, kind of deprioritizing Lucid for the next hard fork, but they see it pretty likely for the a star hard fork, the 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 and 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. Right.

Yeah. We want to and together, the Lucid team wants to have this EIP in and create a marketplace for encryption or key provider services. Actually, Lucid's called decryptors. Yeah. It's got the same word. Decryptors, key provider. So we are doing everything to push that the IP gets included and helping implement that. And and then we Shutter would want to be position itself as being a good key provider because it uses special encryption and maybe because it has some of the experience from from some helping push this. But, yeah, it's it's that 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 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 TEE 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 I 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 search encryption is maybe the best technology for this because it has these good properties 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 decrypting. I'm I'm sending a 100 transactions. And then, and then they have all different prices, and they have all different strategies, whatever. And then I just see how the market develops in the next kind of twelve 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 runner to at least to insert transactions and to manipulate where we think that's why, ideally, you would have threshold encryption because then you have a decentralized committee who not no single person can cannot do this attack. And they acknowledge the Lucid team definitely is is aware of this, and they just say, like, it is you enshrine the the simple encryption mechanism, but that's not how they expected medium term to to work out. It is more like you then can then, again, put different tech encryption other thing other encryption technologies on top, and you encrypt the private key. So you encrypt you encrypt the private key of the user with the fresh encryption mechanism, for example, or the t e. 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 recommend kind of to if you're a key provider, use threshold encryption, or if you are a user later than 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, encrypted the on key and then lose it, or you could maybe there would be TE providers, something where you're likely where you have this more of this hardware trust assumption. Yeah.

Yeah. User shouldn't be affected if he doesn't want to. Right? So that's could be a wallet level default or maybe, like, a RPC where you have a default, but you can change it if you want to. But it user should pay for it, we would say, probably. Yeah. But we would say there is a benefit from it. Right? And then you're getting a better price, and we would say that the better price should be more than the fee that you pay to encrypt. 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. Yeah.

in general, it can work the same way as in in the nonencrypted mempool. So people can still background your transaction. And then, again, what we've discussed in the beginning that you can still benefit from it as well, the refund. But there are some differences in the efficiency of that in, 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 background 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 probably after the block. 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 back running in encrypted mails that are allowed in private mails. So I think the the big argument against encrypted mails 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 of a kind of trust assumptions. If you let someone meddle with your elections, 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 assumption. And then, of course, if you move the trust assumption, if you move the trusted broker, maybe in some instances, you get a a worse price. So that's kind of, like, maybe one key. That there's 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. Right? So extreme example would be you have something like thresholds, 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. Concept of the specific or you could maybe do things like post inclusion and 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 the only thing I also like, 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 both. 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. You know, like, AI powered whatever, but encrypted. Yeah. You know, future stuff, definitely. But there's no reason why this should be possible with the advancement of cryptography and with the advancement of compute.

As as a FAG is is was, like, had held back by by compute, but there was, like, a really interesting list a week ago where Intel built a processor that can accelerate this, and it's, like, a thousand times whatever more efficient. So we're getting a lot closer to that being 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 Shredder Network. Yeah. Thanks for coming on again 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. Yeah. Yeah. Thanks so much for having me. And, again, encourage everyone to to look into this stuff. I think during from the f there's a really good thread on saying, why do we need encrypted mempos now? So we're gonna check it out and to to give feedback and to evolve the the designs such that it is acceptable to the to the products.