An Anti-Collusion Mechanism for Threshold Encrypted Mempools

Transcript

Okay. Hi everyone. I'm Andreas, a cryptography researcher at BrainBot working on the shutter network and I'm going to talk about a novel anti-olusion mechanism for threshold encrypted mess. This is a topic that I also wrote an ETH research post some time ago about. So if you're interested feel free to uh scan that QR code. Um I'm also going to show the QR code later on again so in case you don't make it now. Okay. Okay, I would like to start off by recalling what we refer to um uh uh when we say the term mev. So let's say we have a user in Ethereum that wants to make a trade. For example, the user wants to um buy ETH and sell Smileycoin. Then the

user sends that transaction to the public meool. Eventually a proposer picks up the transaction, includes it into the um block and when the block is included into the blockchain, the transaction is being executed. Um and yeah, the tra trade is being executed. The impact of this trade is that the price of ETH is going uh up and the price of Smileycoin is going down. Now, of course, the proposer knows about this price movement, and what a malicious proposer could do is it could just include a transaction right in front of the um user transaction, which is called the so-called front running. Um, and what this does is the proposer essentially buys a token knowing that

the price of this token is about to go up. And for the user, the impact is that the user buys this token at a higher price. To make this even worse, the proposer could do a sandwich attack where it also includes a transaction right after the user transaction. Um, and essentially for the user mean this means that it buys the token at a high price and right after the user buys the token the price is falling and the value that is being extracted in this uh manner is called um, MEV. And actually a recent report by the um European Securities and Markets Authority estimated that the total amount of mess stolen in Ethereum in this way ranges somewhere between 1.1 and3 billion US.

So this is obviously a pretty big problem that we need to tackle and one promising uh idea to do this is to use encrypted mess. In encrypted mess, the user sends its transaction in encrypted form so that no one in the network can actually see the content of the transaction. And only when the proposer includes this encrypted transaction at the top of the block, the decryption key for the transaction is being released, the transaction can be decrypted and executed. Now, this is a nice design, but there are two uh big problems uh that we need to think about. First of all, where does this decryption key come from? And second of all, what actually forces a proposer to include this transaction at

the top of the block. So for the first question, where does this decryption key come from? Typically, we have something that is called an encrypted meool service provider that provides the network with the necessary keys. So the service provider first provides a public encryption key to the network that users can use to encrypt their transactions. And when this transactions is included uh at the top of the block, the service provider releases the corresponding decryption secret key. Second question, what forces the proposer to actually include the transaction at the top of the block? And there are several different ways to go about it, but one interesting idea is to

use proposal commitments. Proposal commitments essentially allow a proposer to make a commitment about the allocation of the space in the block that the proposer is about to um propose. And the best known example for proposal commitments are pre-confirmations where the proposer can promise to a user that um it is going to include a user's transaction. But it can actually be also used to build out of protocol encrypted me pools. Actually we wrote some month ago another E3 research post about this. So if you're interested again scan the QR code.

So how does this look now? Like how can we build an encrypted mele using proposal commitments? We have the user that sends an encrypted transaction to the memp pool. Um the proposer picks up this encrypted transaction and um and uh sends a public commitment which says I commit to including the decryption of this encrypted transaction at the top of my block. And when the service provider sees this commitment, it releases the uh decryption key because it knows the proposal is now committed to actually include the transaction at the top of the block.

Um the nice thing about this is exactly this accountability. We know that we can hold the proposal accountable if it does not act upon its commitment. And just as a technical detail because this will become um important later on. Uh the proposal commitment is essentially a BLS signature issued by the proposer. Okay. Okay, so this is a nice design, but there's quite some significant power accumulated in the service provider because essentially the service provider um decides when a transaction is being decrypted.

So it makes sense to think a little bit about how do we actually want to instantiate the service provider and there are different ways to go about it. One idea is we can just say it's a trusted party. The other idea is we say we use some secure hardware like a trusted execution environment. Um and then there are cryptographic approaches like using delay encryption and threshold encryption. All of these approaches unfortunately have their drawbacks. Trusted parties kind of self-explanatory. Uh TEES rely heavily on hardware assumptions. Delay encryption has timing issues and also relies on hardware assumptions. And threshold encryption relies on the so-called threshold trust assumption.

And in this talk I'm going to focus on the last one on uh threshold encryption. So just to recap what is threshold encryption actually essentially it is a public key encryption scheme with a decentralized decryption mechanism. So basically it proceeds in three phases. We have a initial one-time distributed key generation where a set of parties that we also call keepers initially generate a public encryption key and a sharing of the corresponding decryption key. In the second phase, a user can use this public encryption key to encrypt the message locally and this encrypted message can be decrypted again by the keepers uh collaborating.

We have typically several properties for such a threshold encryption scheme. The first one is kind of correctness which says if a certain threshold of keepers collaborate. So for example uh I denote the threshold here by t um then this threshold of keepers can decrypt the message. So for example in the previous slide I had five keepers. We could set the threshold to three. That means that any set of three keepers can decrypt messages. And for security we usually say that any set of keepers below this threshold does not learn any information from a cipher text about the plain text. And compared to a centralized solution, this is basically just distributing the trust uh among the set of keepers.

Okay. So how does now at a high level look at threshold encrypted meool. So we have the user that sends an encrypted transaction to the memp pool. Eventually a proposer picks up this encrypted transaction and sends a commitment for this encrypted transaction to the keepers. When the keepers see the commitment, they decrypt the transaction and send it back to the proposer for inclusion in the block. So it seems like a nice design, but there's a problem that I mentioned earlier, namely the threshold trust assumption. This is the assumption that maximum tus one keepers act maliciously.

Why do we have to assume this? This is because if we have more than t uh t or more keepers that act maliciously, they could just collude and uh decrypt transactions prematurely and try to frontr run them. And actually this is a problem that several academic works have looked at in the last one or two years. And these academic works have done good progress to kind of reduce this threshold trust assumption. But there's not really any practical practically feasible solution yet. However, these works they have looked at the general case of using threshold encryption kind of for any use case and in my talk I'm kind of just interested in encrypted mess. So the idea is can we maybe find a way to reduce this assumption for the

specific case of encrypted mess. Um the good news news is yes and I would like to kind of first at a high level um explain the idea or how to think about it. So if we think about it what do we really want to prevent? We want to prevent that keepers can decrypt transactions before the proposer has actually committed to including the transaction. So we want to make it somehow technically infeasible for the keepers to do that. Um maybe just to clarify again, the malicious me extraction can only happen before the proposer commits because after the proposer commits um the keepers are actually supposed to decrypt or said differently if the proposer does not

commit then the transaction stays encrypted no matter how many keepers act maliciously. Okay. Now how can we achieve that? And I'm going to show this at the example of shutter. Chatter is a commit and reveal scheme that uses threshold encryption. It has several use cases such as shielded onchain voting, sealed bit RFPs, and especially encrypted me pools. And there's one property about shutter that is particularly interesting, namely the decryption key in shutter has the form of a BLS signature. And now that I say BLS signature, maybe you remember that I mentioned BLS signatures before, namely when talking about proposal commitments. So the main insight is really the following two observations.

We have decryption keys and shutter that are BLS signatures and we have proposal commitments that are BLS signatures. So why don't we just combine these observations and we say we use a proposal commitment as a decryption key. So how would this now look like? How can we use this insight to build an anti-olusion mechanism? Let's say a user wants to send an encrypted transaction. So it encrypts the transaction first towards the keepers and then it takes this encrypted transaction to encrypt it again towards the proposer. So we have essentially like a doubly encrypted transaction and the user sends this doubly encrypted transaction to the meool.

The proposer picks up this doubly encrypted transaction and sends a proposal commitment for this doubly encrypted transaction to the keepers. And remember that the proposal commitment is a BLS signature that can be used as a decryption key. So what the keepers do now they receive this doubly encrypted transaction and they receive a proposal commitment. So they use the proposal commitment to kind of take off the first layer of encryption uh kind of to remove this doubly encrypted transaction and obtain the single encrypted transaction. and a single encrypted transaction the keepers can now decrypt with their own secret key and then they send back the the plain text transaction to the proposer.

So why does this achieve exactly what we want? Um essentially we wanted to avoid that keepers no matter how many of them are malicious can decrypt transactions without the proposal commitment. And since the proposal commitment is is necessary to kind of take off the first layer of encryption, without the proposal commitments, the keepers cannot do anything. So this is exactly what we wanted to have. Uh I want to add a little bit of discussion. So one reason why I'm kind of excited about this is that it comes with essentially no overhead. At least if we talk about encrypted meuts using proposal commitments, the proposer anyway has to send a commitment. So we might as well just use it as a

decryption key. The only little overhead that we have is that the cipher text uh is a little bit larger. One might wonder why do we actually need keepers if the proposer has the ability to use its commitment as a decryption key. So maybe we just use the proposer uh kind of alone for decrypting transactions. But we actually need the keepers to hold the prop proposal accountable. If we didn't have the keepers, then the proposer could just locally generate its commitment and locally decrypt transactions and frontr run them.

And finally, uh one drawback of the current uh design is that the user has to encrypt um currently a transaction for a specific proposal, which is of course not that great from a usability standpoint. Um but we can just let the user encrypt towards several proposals using something that is called um multi-reient encryption. And then the final point that I kind of want to make is that the main observation of this talk should really be that we can use BLS signatures as decryption keys. And this is actually not my observation. This was observed by several academic works before. But it can be um very useful in Ethereum in

general. So I showed here how we can use this for an encrypted meool using proposer commitments um and using threshold encryption. But we could also use this for encrypted mess using other technology such as trusted execution environments. And we could also use this for um encrypted meps that don't use proposal commitments but for example that use fossil which is an inclusion list design that also uses uh BLS signatures and in general BLS signatures are used kind of everywhere in Ethereum. So there might be other use cases and um every one of you is invited to think about use cases where can we can use this observation.

So yeah, just as a conclusion again, BLS signatures can be used as decryption keys. Uh BLS signatures are widely used in Ethereum. I just showed kind of one uh use case of how we can use this for encrypted mess via proposal commitments, but we can probably use this observation more widely in Ethereum. And with that, I'm through and thank you for your attention. Does anyone have any questions? Oh, I can see already. Yeah, thank you. Uh, I'm curious if you can comment on the concrete deployment settings if you have any. Uh, like how

many nodes are we talking about in the threshold decryption contortion and how are they incentivized to operate these nodes? So, this um anti-olusion mechanism is not deployed yet. Um we do have in shutter we do have a set of keepers that is running uh that has currently um on that it is running on nosis chain and I believe we have seven keepers but I'm not exactly sure on the number right now. Yeah. Is there any explosion in the overhead if you if you on board like let's say 100 more. No, this is this should be um completely independent of the set of keepers, right? Because it's just kind of like this proposal commitment that is used as a decryption key. This should be

completely independent of the set of the keepers. Even even the cy tech site, sorry for quoting the mic. Does anyone else have Yeah. So for the cipher tech size, that's a good point. So ideally, we want that the user encrypts transactions to several proposals because the user cannot predict which proposal will actually include the transaction. Um and then of course the cipher text if you do it trivially the cipher text grows linearly. Um but you can use multi-reient encryption which kind of reduces the size of the cipher text. Now cool thank you. Any other questions?

All right let's have a round of applause. [Applause] [Music]