The Holy Trinity of Censorship Resistance in Ethereum

Okay, yes, thanks for the introduction. This is going to be a shared talk together with Mark from NetherMind and Luis from BrainBot. As the title of the talk suggests, we are going to be talking about censorship resistance. Censorship resistance probably here in this talk is not much of a motivation, but I'm going to spend one slide on it anyway. So why should we care about censorship resistance?

It's basically one of the core principles of open and permissionless blockchains, and it is the main distinguishing feature to more centralized trading and settlement infrastructure. Or to say it a little bit more directly, censorship resistance is the whole point of why we want to have decentralization. Okay, so we agree censorship resistance is important, but what does censorship actually look like? And for that, I would like to sketch the transaction flow in the current Ethereum transaction supply chain. So we have users that send transactions to the network, and eventually these transactions arrive at the builder.

The builder bundles these transactions into a block, sends the block to a relay, and the relay forwards the block to the proposer. So basically, a transaction travels through three parties, the builder, the relay, and the proposer, and all of these three parties have significant potential to send the transaction. The current state of Ethereum is as follows. Only two builders build currently roughly 80% of all blocks. So two massive impact on which transactions get included into a block and which don't.

Relays are trusted parties, so they can essentially do whatever they want. If they get a block from a builder and the block contains a transaction that they don't like, they just are not going to forward the block to the proposer. And the proposer has the ultimate decision power. The proposer can decide which to propose for inclusion into the blockchain or not. And all of the supply chain is fueled to a large extent by MEV that is extracted from the user transaction.

So this paints a pretty grim picture of the current state of Ethereum because we have a massive builder centralization, we have trusted parties in the form of relays, and we have MEV exploitation of user transactions. Okay, so enough complaining. Let's think about how can we improve the situation. Can we get back to a system that actually has true censorship resistance? And a good practice for this is to think about, in an ideal world, what would we like to have?

Like, what are the properties that we would like Ethereum to satisfy so that we can say we have good censorship resistance? And the first property that we would like to have is we would like to have a timely inclusion of transactions. So if a user sends a transaction to the network, the user should be guaranteed that this transaction gets included into the blockchain within a certain time bound. We don't want to have any trusted intermediaries in this transaction supply chain that can just send the transactions at will. And we want to hide the content of the transactions until the inclusion of the transaction is guaranteed.

And the good news is that we already have all the tools to achieve these properties. We just need to use them in the right way. And this is what we call the holy trinity of censorship resistance, which is basically a combination of three techniques, namely fossil encrypted mempools and ePVS. And I want to introduce these three techniques at a very high level now. So the first one is ePVS or enshrined proposal builder separation.

And the idea here is to enshrine the current PBS into the Ethereum protocol, which essentially allows to remove the trusted relay. And at a very high level, this can be done by just using a committee of attestors instead of centralized relays. And then this committee of attestors can mediate between the proposal and the builder. The second technique is fossil, an inclusion list design that has for each slot. And then this inclusionist committee creates a list of transactions that has to be included in the next block.

So essentially, the proposal is forced to include the transactions from the inclusion list into the next block. And as long as we have at least one honest validator in the committee, we can be guaranteed that transactions are included into the blockchain within a timely manner. And then finally, encrypted mempools, encrypted mempools are the idea of users sending transactions to the network, but not in plain text, but rather in encrypted form so that no one can actually see the content of the transaction. And the decryption of the transaction only happens when inclusion is guaranteed. And this allows, for example, to prevent malicious extraction from user transactions.

Popular ways to design such encrypted mempools are, for example, to use peripheral encryption, trusted execution environments, or delay encryption. And now at a very high level, so we know now what these three techniques are, but how can they actually work together to achieve, again, good censorship resistance in Ethereum? So the flow would kind of be as follows. We have users that send encrypted transactions to the mempool, and these transactions stay encrypted until finally the inclusionist committee includes an encrypted transaction into the list. When this happens, the provider of the encrypted mempool releases some information that allows to decrypt these encrypted transactions.

And we need some kind of committee of attestors that attest to whether the encrypted mempool provider has actually released that decryption information. And if sufficiently many attestations for the decryption information are available, then we expect the builder also to know the decryption information. So we expect the builder to decrypt the encrypted transaction in the inclusion list and to include them in the block at the top. The builder then sends this block via ePBS, so without trusted relay, to the block proposal. And the block proposal essentially checks if this is actually a valid block, so if the builder has correctly decrypted these transactions and has included them at the top of the block.

If the builder has done that, then this is a valid block, otherwise the proposal rejects the block. Okay, so this is it for my part of the talk. This was kind of a high-level overview of this whole trinity, and I'm going to hand it over now to Mark, who will go into some more detail here. Hello, I'm Mark. I work as a core developer on the Ethereum Pro School at Nethermind, and I've been working on implementing the shutter encrypted mempool and also doing some research on encrypted mempools.

So I'm just going to quickly take you through the holy trinity of censorship resistance and try and kind of paint a picture of how these three mechanisms could all work together. So we're going to just start out by thinking about what happens without an encrypted mempool, with no kind of protection. So in this case, we just go through public mempool. The way that looks like is the user has their trade that they want to send. So in this case, it's a swap from ETH to donut tokens.

They're going to take that transaction and propagate it through the network in the public mempool. And then the builder has them how to decide what transactions are ultimately going to end up in their block and in what order. So the first problem with this is what if the builder is malicious or they want to extract MEV essentially. So the first thing they could do is front run the user's trade. So they could insert their own trades ahead of the users and trading against them and getting, giving them worst execution and kind of extracting value.

And again, they can do this because they ultimately control the ordering in the block. The other thing they could do is send to the user. So since they can decide what goes into the block, they can just decide to completely omit the user's transaction. And one kind of potential solution to this is using a private mempool. And this is quite standard today.

So in this case, the user is just sending their transaction directly to the builder. So it's not getting propagated out to the network. And this can get some benefits. So essentially, there's like a trusted relationship with the but this is not going to give us censorship resistance, right? Because we're just trusting the builder.

So if they, they can still just decide to ignore the user if they choose to. And front running protection, hopefully it will give front running protection. But again, this is a trust assumption in the builder. And I think really we want to do better. The first thing I want to talk about here is FOSSIL, which is a censorship resistance mechanism.

And so here, the user is just, again, sending their transaction through the public mempool. And then now we have this other entity, the includers. So we have 16 includers, who are just randomly sampled from the Ethereum validators. And each of these is going to construct a list of transactions they see in the public mempool. And this is actually going to force the builder.

So if in the case they have space in their block, then they have to put in the user's transaction. This is actually going to give us big benefits of censorship resistance, because now we're not just relying on a couple of massive entities, the builders to decide what goes in. You have this much more decentralized includer set that actually has power. But this is not going to give us front running protection, because with the inclusion list, there's actually no guarantee over what order the transactions are going to end up in the block. So ideally, we want both, really.

This is where encrypted mempools come in. So the way encrypted mempools work, kind of in two stages. So you're going to think about the user's transaction is going to end up on chain, but after one slot, so one additional slot of latency. So first in slot M, the user is going to submit their encrypted transaction. This is going to go through the public mempool, like before.

And then we're going to end up with a list of encrypted transactions on chain, which are called the constraint. So we have all of these encrypted transactions, and they're ordered while they're encrypted. So now this is on chain, and the next slot, this acts as a constraint on the next builder. So now that we have this ordered list on chain, we can actually, the encryption keys will be revealed, so everyone can then see what the plain text actual transactions were. But then now the builder is actually constrained against this original ordering.

So if the builder then decides, oh, I don't like this blue transaction, I'll just throw it out, then we can actually see that and prove and like slash them. Or if they start reordering stuff, all of this is now provable on chain. This actually gives us both of our properties that we need. But we can do even better here. So if I just go back here.

So in this case, we still kind of have a problem here. So the builder in this slot could just ignore this blue encrypted transaction and not put on chain. So the benefit here is if we actually combine fossil with encrypted mempools. So now we have, we still go through the public mempool, but we're adding these two together. So we have the includers, and then we can be sure that all of these encrypted transactions are going to be on chain.

Essentially, we have now like two layers of censorship resistance. One sort of final point, which I'll just kind of tag on here is EPBS. So I've kind of been speaking about the builder to simplify things. But of course, you have the Medbooth pipeline. So the way this actually looks like is we have a builder and a proposer and a relay in between.

He's like a trusted middleman. He's going to facilitate this kind of auction for the block. So this is another kind of vector for censorship. So EPBS essentially just removes this distrusted middleman. So between these three things, I think we can get extremely good guarantees for censorship resistance and run running protection.

Thank you. I'm going to hand over to Lewis now. Hello. I'm Lewis. I work with Shutter as well, just like Andreas.

And I think I only have a couple of minutes left, but I think everything important has been said. But I just want to highlight some of the sort of practical tracks we're working on to get this to fruition or to work towards that kind of that holy trinity. So the first thing is this conceptual work to kind of just figure out how the pieces fit together. We have a blog post on this and we want to publish more. The second thing is really this more elaborate roadmap towards an encrypted mempool for Ethereum in three major stages.

The first one would be just to protect the private RPC from encrypt at this level, then encrypt at the proposer commitment stage. And that's where we're partnering or working with primers on building a POC to kind of fit the encrypted mempool into today's out-of-protocol PBS supply chain. And then stage three is that in-protocol level encrypted mempool, which the main topic of this talk was via Fossil and then also encrypted mempool, and then via ePBS having that kind of no trust assumptions ideally or limited trust assumptions. And then also the encrypted mempool is sort of live on notice chain as well in kind of an out-of-protocol version as well. And then just a little demo.

I'm sure if this plays. Yeah. So this is an MCP server, which communicates with the notice chain and also includes the option to use the encrypted mempool route. And if you do that, if you tell the MCP server, please make a transaction. So I'm using cloud desktop here and I'm using the MCP server.

And if you tell it to make a transaction, it checks the balances and then makes an encrypted transaction, as you can see. And then from the left, we head over to the encrypted mempool sort Explorer, and we can see it is now submitted. But because we don't have, not all validators have switched on the ability to process encrypted transactions, we need to wait for a slot. This went a little bit fast. We have to wait for a slot that is shutterized basically and encrypted.

And then that just happened. And the validator processed the transaction, included the encrypted transaction, and it was included and essentially shielded. Just a little sort of practical demo how we envision this to sort of very soon work in practice. And it just so happens that it's cool that we think the UX paradigm is shifting anyway. So I think it's going to be on this way, it's going to be cool to combine the next level sort of UX paradigm of, let's say, an MCP server with this higher level of sensitive resistance.

And you can run this locally, right? You can run the MCP server locally, and you could also plug this into a local LLM, right? So this can all be very local and very end-to-end encrypted essentially. Yeah, so thanks. Thank you.

Thank you, Luis. Thank you, Andreas and Mark. We have a couple of questions if you guys want to take on questions. Do you want to take some questions? If you have, guys, questions, you can scan the QR code and submit your questions right now.

I think we won't be able to show the screen now, but I will be reading them out. So the first one is what is, maybe you can come to the stage. Yeah, we won't be able to show the screen, but I will be reading them out. The first one is what is the threat model around the decryption committee membership? How are they disincentivized to colluding with the block builder?

Yeah, that's actually a very good question. That is a big problem to disincentivize collusion. Ideally, we would like to have the committee to be consisting of attesters or validators, because we anyway kind of have to rely on the majority of them being honest. Um, we are currently working on other solutions to kind of, um, like more technical cryptographic solutions to, um, yeah, actually, um, make collusion impossible. There's some academic work on it, um, in the last one and two years that is not really practical yet.

But, um, yeah, we are on it and working on it, but it's a good point, um, that this is an issue. Yeah. The next one, uh, is have you thought about data leakage at gossip time of transactions to the mempool? Um, yeah, this, this can be a problem. I mean, the kind of, uh, everything is, uh, encrypted of the transaction that's actually going to end up on chain.

Um, but there is certain things that you're technically, uh, leaking just by sending this transaction. So you can kind of stuff like the time, the, um, the size of the transaction, that's kind of an address, which actually has to sort of submit the encrypted sort of blob transaction on chain. Um, but there are like, uh, various techniques which can be used to kind of, um, obfuscate this kind of information. Um, but yeah, like, I mean, the simplest one is like four to hide the IP address. Um, time, you can kind of send in some fake transactions in terms of size.

You can like the size of your transaction. So there's kind of different things you can do to, to avoid leaking any information. Yeah. Um, before I go to the next one, just a reminder, you can actually upload questions if you want to see one of them answered before, but I'll go with the next one. Um, what do you think of an approach that gives integrity to builder's behavior via TEE in private mempool?

Yeah. So, I mean, um, the TEE sort of builder, right. Um, is in some ways an alternative and can also provide an encrypted mempool via the TEE. Um, but that is, um, if you just use a TEE, that is sort of a, to us is more like a stepping stone towards having like a full cryptographic solution because the TEE is a strong hardware trust assumption, right. You need to, um, you need to rely on the fact that sort of like, let's say Intel, um, did not include a backdoor.

And yeah, so it is, that's what's being used today, right. We're, we're seeing on Flashbots and other, others are using TEEs and build on it and other sort of frameworks to have the builder run inside of a TEE. But, um, we see it as, again, just more stepping stone towards, towards the full cryptography solution. And then also it can be complimentary. So, um, a company, a dev house, Polycrypt has built, um, this two layered approach where you have a special, um, cryptography, which there you rely on the decentralization of the, the committee nodes, um, and the cryptography.

And they combine that with TEEs and that every, each of the keepers, what we call them is run inside of a TEE. So then you have a really cool sort of double layer protection. I think that's a really cool way as well to combine and enhance. The next one is, um, is there a price to pay in terms of latency? And so, yeah, you're going to end up with, um, an additional one slot of latency, um, to get your transaction on chain.

But if you're kind of, um, have a high value transaction where you're really worried about being front run or that it's not going to end up on chain, then I think that, you know, hopefully there'll be a price, price worth paying. And maybe the last question, uh, are there any ways to decentralize relays or get rid of them? Yeah. So very high level, um, you can, um, use the same approach. So essentially something like a special encryption approach or a, um, you, you can use that to detrust in, in, for example, in this way, and also chain, we detrust the validator because they have to commit on including encryption actions, right?

In the same way you could sort of take the centralized trust assumption relay and detrust it with a special encryption approach as well. Um, there's at least two, there's a talk from, from Yannick, um, all the talk, um, uh, about this, um, I think from, from SPC, uh, and there is a newer paper as well on this from someone else called something like, um, removing the trust in relays. Yeah. So there's this idea that definitely exists. Yeah.

And also EPBS, like that is kind of, um, one of the selling points of it is that it brings all of the whole, what was the net boost building pipeline into the protocol. So you don't have relays anymore. Like you no longer have this trusted middleman.