Cryptography for Encrypted Mempools with Dan Boneh | a16z crypto Research Series

Transcript

Okay, welcome everyone to today's A16Z research crypto seminar. I'm going to introduce someone who needs no introduction. Uh Dan Bonet, professor of computer science, uh legend of cryptography, mentor to dozens, if not hundreds of people uh in the crypto space. So very excited to hear about his latest on encrypted me pools. Dan, >> awesome. Thank you, Tim. So, thank you also for uh inviting me. This has been a phenomenal week. It's always it's always a lot of fun to visit the lab during this week. Um time just seems to fly away because there's so much so much so many things to do here and so many people to talk to. Okay, so today what I wanted to do is talk about uh cryptography basically that's motivated by encrypted mempools. And uh like I was telling Tim, this is going to be a

fairly high level talk. It's a diverse audience. I felt like maybe going into the details of um how the crypto systems work may be a bit much. So it's going to be a high level talk. I'm going to try to minimize my use of uh Greek symbols, Greek letters. I don't think I fully succeeded, but I'll I'll I'll do the I'll do the best. Um and so everything should be accessible to everybody. So if I say something that's not clear, please stop and ask because this is meant to be understandable by by everyone. All right, so let's dive right in. Um okay so uh just to remind you how the blockchain works at a very high level.

Uh so there's this thing called a mempool where uh into which transactions go to when they're created by users right so the end users create transactions they send them to the chain and then it goes into a mempool where it just sits there until the block producer actually reads transactions from the memp pool. Uh then the block producer creates a block and posts this block on the chain. um and the uh transactions that go into this block just disappear from the me poolool and they appear on the chain. Okay. And that's effectively how um how blocks are created and this process is sort of iterated over and over again. We take transactions from the meool. We make a block, we post a block on the chain uh and then the transactions are deleted from them from

the meool. So the problem uh with this is of course transactions are visible to the entire world while they're in the meool before they are finalized on the blockchain. Yeah. And as a result there's all sorts of problems. Uh for example uh there's me these things uh this thing called frontunning. If you post a transaction that's going to make a large purchase the whole world sees that you're posting this transaction. They could try to frontr run you uh to raise the price just before you your transaction executes. uh because the transactions are public, maybe they're subject to censorship. Uh so there's all sorts of problems that come from the fact um that the mempool is completely in the open. And so there's this idea that's been uh uh proposed a couple of times called uh uh called a shielded

meool. And at a high level, the goal is basically to make it so that transactions basically remain hidden until they are confirmed on chain. Yeah. So you cannot see the transaction until it's too late to frontr run it. Yeah. by the time you by the time you can see it, it's already confirmed on chain. You cannot uh uh uh put your own transaction before the transaction that's just been confirmed. Now, I'm actually being a little vague by what I mean by this. What does it mean to remain hidden until they are confirmed? So, I'm actually not going to specify uh precisely what that means. In fact, u Yim and Prenav are writing a paper now that uh is going to have a very precise definition of what that means. So I'm going to let them uh kind of give the precise definition and we'll just leave it at a at a high level

for now. But I hope it's clear kind of what the goal is. Yeah. So transaction should remain hidden until it's actually confirmed on chain. So I should say this is kind of a desirable property for various obvious reasons. You don't want people to see what you're doing until everything is confirmed. Uh but I do want to mention that there are some limitations to this. So first of all, even though you might think this prevents me, it actually doesn't. Yeah. And I point here to a paper that actually uh uh suggests all sorts of ways that even if transactions are encrypted until they're confirmed, it's still possible to do uh to do MEV. So it's not um a complete defense. And the other interesting fact is that this mechanism sort of requires anti-ensorship. Why does it require anti-ensorship?

Uh because when you submit your transaction to the memp pool, the sequencer can say, you know, thank you very much for submitting your encrypted transaction, but I'm not going to let it into the meool until you show me the plain text. Okay? So you could be censored and forced to uh into showing the plain text. And so there has to be some auxiliary anti-ensorship mechanism to prevent the sequencer from doing that. Yeah. So there's lots of uh kind of nuances about these uh shielded rim pools. I'm not going to get into the nuances here. We're just going to assume this is our goal and the question is how do we build how do we build a shielded mempool? Okay, that's kind of uh where we're headed. All right, so these days um obviously these shielded mess can be implemented using cryptography using

encryption. But before we go into the world of encryption these days there's kind of a universal way to always kind of implement almost any security mechanism you want and that is called a trusted execution environment. Okay, so method number one to building a shielded meool. Uh well, let's see how to do it using a trusted execution environment. So this is actually something that's now deployed on uni chain. So uni chain um it's uh here I site their blog post here from May 25. They actually went live with uh uh a shielded meool uh using te world chain is about to make that to go live with this. So it's a pretty popular design. Basically what the the way this work the way the what these chains are

is firstly there firstly there are L2 optimism stack based chains they use uh uh centralized sequencing based on a trusted execution environment um and what it is actually it's using this technology called rollup rollup boost rollup boost was developed by uh flashbot and specifically rollup boost is based on the TDX um uh TE okay so let me explain how this works and I'm going to explain it at a very very very high level Um it's a little bit aspirational because what I'm about to explain is not exactly what's implemented but it what could be implemented. Yeah. So uh we'll get there eventually. So here's how uh you would do shielded mess using uh using rollup boost. So what happens is

your trusted execution environment. So I should say by the way to be completely self-contained a trusted execution environment is a piece of hardware where computation can take place but nobody can see nobody on the outside can see what computation is happening so there are secrets in the ex in the TE that cannot be read from the outside code can be executed and you're sure that it's executed correctly um and so on yeah so it's a kind of a magical uh uh tool that enables us to do a lot of things so how do we use a TE to do an encrypted mempool The way this works is when the TE first of all first starts, what it will do is it will generate a secret key inside of its belly and keep the secret key to itself. So it's going to be a

secret. Nobody in the world knows what the secret key is other than the internals of the trusted execution environment and going then it's going to publish a corresponding public key. Yeah. So anybody can encrypt to that public key. Now technically what it actually publishes is what's called the TLS certificate. TLS. I imagine many of you know what it's about. It's the protocol that underlies HTTPS um yeah web security. And so we publish uh a a public key certificate uh that's bound to this TE. And then when users want to submit their transactions, what they'll do is they'll send encrypted transactions encrypted under this public key. All right. Again, technically what they do is they establish a TLS connection into the execution trusted

execution environment and they send their transactions encrypted so they can only be decrypted inside of the TE. Okay, so they send their transactions encrypted. Nobody can see the transactions in the clear and then those transactions get decrypted inside of the inside of the TE and the entire mempool now lives inside of the TE. You notice this is a centralized sequencer. Everything is centralized so far. What does the TE do? The TE basically decides on how to sequence these transactions. So it takes takes them and builds uh blocks out of them. Uh yeah, these are called flash blocks in the world of uh of rollup boost. And these flash blocks are all signed by the TE. These are called these signatures by the TE.

They're called flash destinations. They like to come up with interesting names. Yeah. And so they generate all these uh blocks. And these blocks because they're they came out of the TE, they're all signed by the TE. they're actually considered now confirmed. Yeah, confirmed meaning they're basically the fact that the TE uh signed them means that they're going to go onchain and so it's okay to decrypt them. So, uh once they're confirmed, it's okay to decrypt and so they come out of the TE in decrypted form and then the uni chain validator goes ahead and makes a block out of them and posts it on the L1. So that's going to that's kind of basically at a high level roughly how uh rollup boost works and that allows us to do you know shielded sequencing uh without transactions being available until they are confirmed on chain. So far so good.

Yeah. >> Why can't the validator claim they didn't see the those green blocks signed by the TE? >> Yeah. If they did that the TE would stop working. Yeah. So the TE basically forces the sequence. So you can c certainly it can halt the chain. This is an issue with centralized sequencing, but it would cause the the chain to halt. You can't ignore things that come out out of the TE. Yeah. Yeah. There are lots of Yeah, there are lots of questions around this. This is a fairly complicated. It's kind of amazing that this is deployed. It's a fairly complicated system. Uh but that's kind of where where uh things are now. >> As you said, you can censor transactions. There's no no block no way to block >> on the in on the you can censor the encrypted transactions on the on the inside. Yeah. But there you you don't

know what you're sensoring because it's encrypted. >> You know like who's sending it for example. >> For example. Yeah. But it's encrypted. So ah yeah >> yeah what mechanism is the TE using to decide the order of the blocks? >> Um yeah so okay good. That's >> in the construction of the block. >> Yeah that's a good question. So actually let's let's talk about that. Um so there are lots of benefits to this design. uh specifically you know what they do actually uh this is called verifiable sequencing because they the algorithm that the TE runs inside of it to decide uh how to sequence them is basically based on the priority fees. So everybody provides priority fees and then the TE basically will order blocks according to the priority fees. The interesting thing is you're guaranteed that that's what happened because they you can look at

the code that ran inside of the TE and you're guaranteed that that code ran correctly. So it's actually guaranteed that whatever algorithm they committed to is the algorithm that was used to ver to uh sequence the transactions. Yeah. So very good questions. So this actually already has kind of remarkable properties. Yeah. So first of all transactions like we said they remain hidden until they are confirmed which is what we wanted. The other interesting aspects of this is all of a sudden you can kind of automatically do what's called revert protection. Yeah. So revert protection means if a transaction is going to be reverted, it failed for some reason. You don't actually have to post it on chain. You can just remove it from the entire transaction sequence and it never appears on chain. So this

basically um users love this because if a transaction fails, they don't have to pay for the transaction. It never it's never posted and generally it reduces the size of the chain. So it makes for better chain efficiency. So this is another nice property that you can get from this. And also what's interesting is the TE can also act as a as a co-processor. So this is again a a property that's going to come uh from rollup boost where the EVM can basically say here's a complicated function I want to evaluate maybe I want to verify a jolt uh proof or so rather than verifying it in the EVM I can ask the the TE to go hey verify it for me and the EVM is guaranteed that the verification was done correctly because it's done inside of a TE. Yeah. So it's

a way to also use the tea as a co-processor. This is not implemented yet, but it's it's actually coming. So very exciting uh properties in terms of what it can do. Now it's not all roses. Uh lots there's lots of things left to implement. So for example, I'll tell you there's a current limitation in that these TE signatures, the flash test stations, they're supposed to be verified by the L1. So you can only post things on the L1 if they came from the TE. Well, today this this the L1 actually does not verify this uh these flash test stationations yet. And this is an issue with um this requires changing the optimism L1 uh contract.

And so there's already a request to change the L1 contract, but it takes a while. Yeah. So everything takes a while, but eventually eventually we'll get there and we'll have verification on the L1. Right now they're only posted on the L2. So people can just verify them uh by inspection but it's not actually enforced by the L1 yet. Okay. So that's kind of in the world of TE. So shielded uh sequencers are not too difficult to do uh using a TE. Yeah. >> Doesn't this stage lot of problem that like we can uh for example your TE takes in a sequence of transactions or is it fair of course doesn't know what those transactions are um and then it will output the list of transactions. Usually it does that before those transactions get posted in EI1.

>> So at this point then the control T you can simply turn the TE off restart the T and fee as transaction with extra transaction. >> That's a great question. Oh that's a such a great question. So the interesting thing this is this is an interesting thing about uh the fact that they're using TLS. In TLS you cannot replay transactions. Yeah. So this is it's an artifact of the use of TLS. Uh and we can talk a little bit about what why that's true uh later, but yeah, it's you cannot you'd have to go back to the user and ask the user, hey, can you please resubmit your transactions and that's fine. Yeah, you can't just replay replay them by yourself. TLS has built-in replay protection. Otherwise, when you order an Amazon book, I can replay your order and you'll end up with 10 books instead of one.

>> So, there's automatic uh replay protection. It's kind it's a very very interesting point. Okay, good. So, fine. So we can do we can do this but this required centralized sequencing and it required a TE. So the question of course that's on the table is can we do this without relying on a TE can we do an encrypted mempool without a TE. So to do that uh now we're going to go to the into the L1 where actually we have many validators and the question is can we still do shielded mess uh without a TE and to do that I have to explain the concept of threshold decryption. Yeah.

So that's kind of the the tool that will make it that will make this possible. So let's let me explain what threshold decryption is. So in threshold decryption, what happens is we have a key generator that generates a public key and it generates a whole bunch of secret keys along with this public key. In this case, normally it will generate n keys. In this case, you know, n is equal to three. So it'll generate three keys. Uh it's always amusing that the dot dot dot literally stands for nothing in this example but uh normally you you should think of of n keys that are being generated. These keys are then going to be sent to the different validators in the system. And now a user can basically send in an encrypted message. So the user will encrypt the message to the public key. will send the encrypted uh

message in our case it'll be a transaction to all these users and then let's say as long as two out of the three users will decrypt. So you notice they're using their decryption shares sorry they're using their uh key shares to decrypt the transaction. If enough people decrypt namely t out of the n people decrypt then uh those decryption shares can be combined and the message is recovered. Yes. So in this case what I showed you is a two out of three threshold uh decryption. I'm going slowly over this because I gave this talk recently and people are asking me what's threshold decryption. So I want to make sure everybody understands uh what threshold uh decryption is. And the security property is basically if only one server is corrupt. So the adversary controls only one um key share basically

they can do nothing. They can't decrypt. They can't do anything with that single key share. Yeah. So it's a way so threshold decryption is the way to protect a secret key so that you have to break into multiple servers in order to do anything useful. So how do we use threshold decryption to do a shielded mempool? Uh oh by the way I should say threshold decryption is an ancient concept in cryptography. This is like a 40-year-old concept. There are probably 10,000 papers on on threshold decryption. It's a ancient ancient. It's like a you know it's crypto 102 like you learn it on it's week two of a cryptography course. How do we use this to do an encrypted uh mempool? Well, what we'll do, oh, I should say by the way, this is used already on some L1 chains like osmosis and shutter network

and so so on. So, this is actually quite um there's already chains that use this. The way this works is as follows. So, the validators of the chain will generate a public key and they'll publish the public key for the whole world. So, anybody can encrypt transactions under this public key. And then the decryption key is going to be secret shared just like how I showed you among all the validators. Okay. So in this case again three validators they have uh secret shares of the master secret key and then when people submit transactions they encrypt them under the public key. The transactions go into the meool and now what's what's interesting here's the interesting thing of how this works. Basically the block proposer will read some encrypted transactions.

they'll post the encrypted transactions on chain. Now the different validators will go and vote for this block right and as you probably know if once you have twothirds n twothirds of the validators vote for the block the block is uh confirmed on chain and so once the block is confirmed on chain yeah it becomes confirmed and only once it's confirmed then these validators will go ahead and post the decryption shares uh to the chain. Yeah. So first the block is confirmed. So we're guaranteed it's confirmed then we post the decryption shares uh and once you have enough decryption shares uh basically the block will become uh available in the clear and then it will get executed. Okay. So it's very important this happens in two

different steps. First we post it and confirm it on chain and only then do we decrypt. The reason we have to do that is because we can't if we if we post decryption shares before it's confirmed maybe maybe we end up decryting transactions before they're confirmed on chain and that violates our primary goal. Okay. So it's very important that this happens in this two-step process. So this is basically just repeats what I just said that uh decryption shares are posted uh in a later block which means that block execution is now delayed. So, we're slowing down the chain just so that we're guaranteed that we're not decryting before a block is confirmed.

And I can tell you typically, in fact, the decryption threshold, how many shares you need in order to decrypt is basically equal to the confirmation threshold, like how many votes do you need until uh the block is confirmed. So this basically says that if we have if the consensus is live, we have enough people confirming blocks, then there will also be enough people who uh post decryption shares and the blocks will get decrypted. Okay, so that's typically how things are set. So here's here's kind of the amazing thing to me. Threshold decryption is a 40year-old area. Yeah, almost everything that could be said on threshold decryption has already been said in these 40 years. The amazing thing to me is once you put the blockchain lens on threshold decryption,

all of a sudden new problems emerge that have never been considered in the last 40 years. It's like blockchains is like the gift that keeps on giving. Yeah. It's like always new research questions come up um despite the fact that these areas have been studied to death already. So, you know, this is why I love this area so much. It's kind of generates all these new problems. So let me give you a sample of three problems that come that come up from the just from the fact that we want to build an encrypted meool. So the first problem is what I just said. Remember the basic mechanism requires two rounds. You confirm the blocks on chain and then you have to only then you post uh decryption shares. The natural question is why do we do it that way? Why can't we post the decryption shares concurrently with uh

posting our attestations our our votes for the individual blocks? Yeah. So can we do faster confirmation? So can validators publish decryption shares concurrently with their attestation from the block? That turns out to be a beautiful question and that's actually what I wanted to uh tell you about. So this is a recent paper uh that we just uh published and uh the next question is to ask the following is the following question. What is to prevent suppose we do have an encrypted mepool. What is to prevent the validators from actually sh selling their decryption shares to the highest bidder? Yeah, it turns out in traditional threshold decryption, if I sell you my share, nobody knows that the share came for me. You know, if I more precisely, if I sell you enough shares,

nobody will know that the share came for me. So, if I'm a rational actor, if there's no risk to me, of course, I'm going to sh sell you my shares and make an extra profit. But that would undo the whole point of an encrypted meool. So this tracing question is maybe we can deter selling by making it so that if you sell your shares to somebody there will always be a way to trace those shares back to the seller so they can be penalized in some way. Amazingly nobody asked us in the in the context of threshold decryption. Yeah. >> If you sell your share and I just take the if I reveal the share to the public and anybody can take generator to the share and match it with your public key.

Right. That's not but that's not what I would do. So as a as a malicious validator, what I would do is I would get together with a whole bunch of other validators. Together we'll reconstruct the master secret key and then we'll sell the master secret key. And the master secret key has no information about who created it. Yeah. And now there's no way to penalize these guys. So what we can do, so this is uh something that u I did with Aditi and Leo. Aditi, you guys know her very well. This is a paper from two years ago. We basically started this question of how do you build a threshold decryption system. So if you if a bunch of people get together and build what we call a decryption box, that decryption box can always be traced uh to that coalition.

Yeah. Um so there's a deterrence. There's a built-in deterrence into selling uh selling your shares. By the way, the the nice thing about this is again the blockchain generates all these questions and you notice people get excited by these questions. So you notice all the follow-up work that comes up. Um we just wrote the first paper but then all the subsequent work is by other people. So the community gets excited by these questions that are generated uh by the blockchain and it it it it um generates and motivates a lot of extra re additional uh research. So that's kind of uh cool. The last question I wanted to mention is something that uh Vamzi uh uh suggested which is this question of batch decryption which is again if you think a little bit about how the encrypted mele works today we

have a thousand transactions in a block and now when a validator needs to post their decryption shares they will have to now post a thousand decryption shares one for every transaction on the block that's a lot of data that needs to be posted on chain and so the question is if we have a thousand transactions in a block maybe there's a way in which we can take all these thousand decryption shares and compress them into just a small one. Yeah. And in fact the answer is we can do it. And so again this is a paper that's area that Vanzi started back I guess I guess last year and you can see also there's also a lot of pickup uh uh and lots of subsequent work to that. So what I was hoping to tell you about today is a little bit about the confirmation question and if we have

time I'll tell you about uh tracing as well. So uh let's dive into the confirmation question. So can validators publish their decryption shares concurrently with their atestation with their vote uh for the block. So this is joint work with Benedict Cartik, Leor and uh Victor. And so let me tell you what the problem is. This turned out this turned into a really interesting question. Um and so yeah, so let's dive right in and let me explain the problem. So from now on I'm going to assume that there is a total of four nodes. So whenever I say the number four, you should be thinking nodes. Okay? And I'm going to assume that the decryption threshold is the same as the confirmation threshold, which is three.

So whenever I say the number three, you should be thinking 2/3 n, right? That's normally the confirmation threshold. And then the whenever I say the number one, you should be thinking n over three because that's the number of corrupt parties. Yeah. So I just want to be super concrete. So we'll use four, three, and one as our numbers. Okay. So what's the problem? So how does this how does this what why can't we or what what's the difficulty with uh doing things concurrently? So here we have our four validators. Yeah, they're all over the world. Each one has a decryption key and we have our block proposer. So the block proposer will read transa encrypted transactions from the memp pool and it will go ahead and propose a block. Okay, so here proposed a block with transaction number one and transaction number three. The remaining

validators will go ahead and vote for this block. Okay, so let's say three validators vote for this block. You notice by they vote for the block and concurrently they decrypt the block. Okay, so they votes and concurrently they publish decryption shares for the same block. So in this case, three validators voted and the same three validators posted decryption shares. So what does this mean? It means that the block is now Yeah. three votes, three decryption shares. So the block is now confirmed and we have three decryption shares. So anyone can go ahead and decrypt the block just as we wanted.

Yeah. So the block is confirmed and it's uh it's finalized and it's decrypted at the same time. Everybody's happy. All good. Okay, this is the good path. The question is what happens now if the block is not confirmed. So let's look at the another case where again the proposer proposes a the same block transaction one and transaction three. But now for some reason only one validator voted for this block. Yeah. So we only get one vote. What happens in this case? We get one vote in one decryption share. So what happens? The block is not confirmed and so we get an empty slot, right? No confirmation, empty slot. However, the decryption share sticks around. All of a sudden, now one decryption share for transaction

number one becomes available and it sticks sticks around in the cloud. Okay, not a problem, right? One decryption share is not enough to decrypt. So, the block was not confirmed and a transaction was not decrypted. All good. Now, let's see if anybody can guess what is the problem. Like, where am I headed? Like, what could go wrong? What could go wrong? What could go wrong? You could get another share in the future. >> Exactly. So the pro the problem is what happens if this happens again. Yeah. So now suppose the next block is proposed. So let's now it's you know transaction one wasn't confirmed. So it's still in the me pool. So let's say the next proposer makes a block with transaction one and transaction two. And the same thing happens again. Only one vote is

received for this uh block. So again the block is not confirmed, right? because it only got one vote. But now all of a sudden another decryption share becomes available. You notice we have our uh decryption share for validator number two from before and now we have a decryption share for validator number three. So now we have two decryption shares. That's not enough to decrypt. We need three, right? So we have we only have two decryption shares. The problem is this is already a problem. And the problem is a corrupt validator. We might have we could have one corrupt validator. A corrupt validator could use its own secret key to decrypt and now it would have three decryption shares and now all of a sudden a corrupt validator can decrypt even though the transaction

is not confirmed. So this is insecure. Yeah, this is a way to valid to invalidate our requirements um because certain blocks are uh certain uh blocks have not been confirmed. But it gets worse. Okay, so so far just one valid one corrupt um validator can decrypt. But what happens if this happens one more time? Yeah. So now we have another block, another proposer also only gets one vote and so the block is not confirmed. Now all of a sudden we have three available shares and now anyone can decrypt. Yeah. Even though the transaction is not confirmed, anyone can decrypt the transaction. So this is why it's not okay to decrypt at the same time as voting for a block. So the

problem basically is you know we have these three slots you know so decryption share for slot k plus one and k plus2 those three decryption shares can be combined together and we can decrypt the cipher text even though the transaction was never confirmed into a block that's the that's the problem that's a security vi so clearly there's a security violation here so what do we do about that what how how can we fix this so um I'm sure it is thinking of all sorts of consensus problem, consensus ways to fix it. I'm a cryptographer, so to me, everything looks like a crypto problem.

Cryptography problem, I should say. Everything looks like a cryptography problem. So, let's try to fix it using cryptographic techniques. And so, what's when you think when you look at this, you say, what's wrong here is that kind of decryption shares from different slots somehow could be combined together. So, we need to prevent that from happening. So, how do we prevent that from happening? And that actually introduces a new concept in threshold decryption. So what's the new concept? It's basically called Yeah. So we want to prevent mixing of shares from different slots. And this brings up this new concept. 40 years of research.

Nobody considered this concept before until the blockchains come along. Yeah. Amazing to me. And so what's the new concept? We call it uh a decryption context. And so let me explain what it does. So a decryption context works as follows. So again, we have our key generation procedure that generates the public keys and the secret keys. We have an encryption procedure that generates the cipher text. I should say, by the way, encrypt for the cryptographers in the audience, encryption typically takes what's called associated data. Um, this is something that's chosen at encryption time. And now the new concept we're introducing is this extra parameter doing decryption called a decryption context. Yeah. So decryption takes an extra argument. Um and finally once we have enough shares we can actually

decrypt the property. The new property is that the decryption will only succeeds if all the decryption shares were generated using the same decryption context. Okay. So if you try to combine shares from different decryption context they don't mix. It's like oil and vinegar. They just don't mix. Yeah. So that's what we want to prevent. And so it turns out this simple idea, this idea of uh adding a decryption context completely solved the problem. So the decryption context we're going to use is going to be the hash of the block. Yeah. And I want you to remember the block always contains its block height. So when I say hash of the block, I mean the transactions in the block along with a block height. Okay. So that's going to be our decryption context. And then you

can see now that um when we have decryption shares from three different heights, we're going to use um the hash of the block which contains the height as its input and those now decryption shares are just not going to combine with one another because they have a different decryption context. Okay, so you cannot decrypt the transactions. That's the idea. Yeah, I hope everybody gets this this point. This is like the key point like please ask if this is not clear. This is kind of the key point of the of the talk. Yeah. That we can cause decryption shares not to combine by using this extra argument. So the point is decryption will succeed now only in fact if we have three decryption shares for one particular block at one

particular height. Yeah. Which is exactly what we wanted. And it turns out when you use a decryption share basically uh it turns out it's safe to concurrently decrypt and vote. So we saved the round that we wanted to do. Now we can actually do that uh using this um using this decryption uh context. And so yeah, in the paper we there's a very formal statement about what is what what does it mean for um consensus to be live and safe in this context. But uh yeah, I'm not going to do that here. This could be >> there's one more attack I guess in which like uh I saw two decryption shares for the same round and then the adversary can like see what the transactions are and decide whether to vote or not based on the content.

>> Awesome. That's exactly excellent. Thank you for asking the question because there's one more problem. Yeah, there's one more problem which is what happens what do we do with corrupt nodes. So in my in the example where we have four nodes and the threshold is three uh we can tolerate at most one malicious uh malicious node. And so I think the question you're asking is what happens if in one slot we get two decryption shares? So they're both being done with the same decryption context and now the one malicious node that we have can add its own share and then it will be able to decrypt. That seems like an attack.

Yeah, is that clear? So we got two decryption shares uh two votes. So the block is not finalized but now the malicious node can decrypt. So maybe I should pause here and see if anybody sees why this is actually not a problem. Yeah. Uh because you only one node can't prevent a live can't cause a livveness failure. So the block will get confirmed anyway. But if you have two nodes, you're already in a bad spot. >> That's exactly right. That's ex perfect. Perfect. So the issue is this. If you have four nodes total and the threshold is three, that means you can tolerate at most one malicious node. But then when two decryption shares are are published, it means those two nodes are now locked on that block. So the only reason only

way they would become unlocked if if somebody publishes three signatures, three attestations for a different block. But there are not there is no way for three shares to become public because there's only two additional nodes, right? Two nodes are already convinced. There's a total of four nodes. So there's only two additional nodes. It's not possible to publish um three attestations, three votes on a different block. So these two uh these two nodes are already locked on this block which means that this block is actually confirmed on chain. It has to go on chain or the chain will halt and and and so uh and so yeah so in that case it's actually okay to decrypt because the note the transactions are actually finalized that you seem happy.

>> No you you lied to us. You said you're only going to do cryptography but now you're doing >> oh my god I'm doing yes I lied to you. Yes. Yes. Indeed indeed. I happy. Okay good. So I guess like under the hood there's a two round of voting consensus here and I only p publish my decryption share in the second round of vote vote voting. >> No no you publish it along with your uh so once the two shares are published the vote is the block is now finalized so it's okay that the malicious node can decrypt the transactions on its own. >> Okay I I have a question but I'll take it up.

>> Sure happy to discuss it for sure. For sure. >> Yeah please. But isn't there still a problem here about like let's say there there are four nodes right you see two votes go out right and you have some intuition that uh node three is offline right so you realize you're the tiebreaker I can decide whether or not this block is going to be >> okay this is this is out of this you're you're using a different model so the mo the consensus model says at most one node is faulty so if you're assuming two nodes are faulty consensus doesn't work so yeah so only one node can be faulty Otherwise, consensus doesn't work in at all. Yeah. So, if consensus works, this is secure.

>> Yeah. Good, good, good question. >> And this is this requires kind of a high threshold. Uh, >> that's exactly where we're headed. Oh my god, I'm so happy you asked that. That's exactly where we're headed. >> You could do a low threshold uh if you Yeah. had stronger you need. >> Okay, hold on. Hold that thought. Yeah, that's an excellent question. So I couldn't resist actually and you know I've kind of tortured you with explaining decryption context through consensus and all that which is kind of complicated as you can see. Um I want to show you like a really simple example of where decryption context is useful. Yeah. It turns out decryption context it's not it's not just for consensus.

This is really a fundamental thing about threshold decryption that the community just missed. Yeah. And really it has applications to almost all cases where threshold decryption is used. So let me give you one more fun application where decryption context comes up. Yeah. So the example I'll give you is when you try to implement a dead man's switch. So I hope all of you know what a dead man switch is. Yeah. So let me let's say that uh Bob has some secret data and it wants the Bob wants to make it so that if he let's say is incapacitated then his errors are able to get that secret data. So how does he do it? Well, he'll generate a public key and he'll encrypt his password under this public key and

publish the corresponding cipher text. Okay. Um, and now the question is how do we manage the secret key that will decrypt his password? And so what he'll do, he'll uh share his secret key among a bunch of servers around the world. Let's say he does a three out of four uh split. And the way the dead man switch is works is basically on Monday, Bob will send a ping to all the servers. If they receive the ping, they do nothing. On Tuesday, he sends another ping. They do nothing. On Wednesday, he sends another ping. They do nothing. On Thursday, let's say he's not with us anymore. Be polite. Uh, and he doesn't send any pings. If he doesn't send any pings, then you know, some threat, some quorum of these servers say said, "Oh, we didn't receive any ping." What we'll

do is we'll sh send our decryption shares to Bob's heirs. Bob's heirs now have three decryption shares. So, they can decrypt the password and uh, you know, they're happy now. They have Bob's data and uh good to go. That's a that's an implementation of a deadman switch. This is a horribly insecure implementation of a dead man switch. Don't ever do this. Yeah. Let me show you why this is so insecure. What's the problem? The problem is the following. So imagine that on Monday when Bob sends his pings, for some reason there's a network problem and two of the servers don't get his ping. Well, what do they do if they don't get a ping? two of these servers will send their decryption shares over to Bob. I'm sure you see where this is headed. So

that was Monday. So two decryption shares become became available on Monday. On Tuesday, the same thing happens just now with a different server. So one server didn't get uh the ping. So that server goes ahead and sends his decryption shares uh to the heirs and poof, all of a sudden the heirs have three decryption shares and they can recover Bob's password. Even though Bob is alive and well, they recovered Bob's password. This is not a dead man switch. So horribly horribly insecure. So this is this is the problem again. Uh decryption was possible uh even though um uh there was no day in which uh three of the servers did not get a ping. So the solution again is a decryption context. Yeah. So what we'll

do is basically whenever we send our whenever the servers send their decryption shares over to to the errors they'll use the dates as the decryption context and now all of a sudden shares from different dates can't combine. Yeah. Oil and vinegar they can't combine. As a result uh the password remains safe. So the only way you can decrypt is if you receive three decryption shares on one day. Okay that's the point. So I hope this is clear. So it shows you kind of decryption context is kind of this uh very general uh mechanism that basically makes it so that uh you know we can kind of reach a case where there's consensus among the decryptors about when decryption should be possible and it

kind of solves uh solves this problem. Yeah. And again this was only considered because of the blockchain like we had not considered this this this aspect before the blockchain. Okay. So the only thing that's left to do is how do we construct a system that has a decryption context? I kind of explained what it does, but I didn't show you how to do it. [snorts] So you know, in a normal crypto talk, everything I did until I said until so until this point would be about five minutes. And now we dive into math where I kind of show you how the uh crypto systems actually work. Um but I don't want to do that here. Yeah, I'll um come find me afterwards if you want to talk about how this actually is implemented. All I'll say is we give two

the bulk of the paper is about the constructions that add decryption context and about the proofs of security that these constructions are secure. All I'll say here is that uh we can add a decryption context to a very famous public key system uh called the Elgamal public key encryption. In fact, we added to a variation of uh Elgamal called uh uh Shupe Janaro. I don't know why I wrote Jaro. Shup Janaro that is CCA secure. uh basically we can allow we we uh support decryption context in a CCA secure system. Yeah. And this is basically an extension. It's a very efficient extension of that system. So it's quite easy to add a decryption context to a real world uh threshold system. There's no reason not to use it.

So that's the first construction. And the second construction is a generic construction. You give me any threshold CCA secure system and we can add a decryption context to it. The magical tool we need to do it is actually oddly identity based encryption. Turns out identity based encryption is kind of the right way to lift any any CCA threshold system into one that also supports uh a decryption context. Okay, I think that's all I'll say about the two constructions. It's a little painful to me because normally this would be 95% of the talk. Yeah. How how these systems work and how we prove them secure. But I feel like I can't actually end the talk uh without at least telling you a little bit about how we define security for a

decryption context. For those of you who haven't who are not cryptographers, maybe this is useful and that it'll give you a taste for how cryptography definitions actually work. So, so I'd like to kind of walk through this just to show you what these definitions look like. Yeah. >> Do you also have a transformation for CPA secure? And is there a strong reason to use CCA versus >> Well, we can go from CPA to CCA using Okomoto, right? I mean, there's >> if I'm happy with uh CPA. >> Oh, oh, oh, no. I'm sorry. Sorry. No, this is what I said is is not quite right. Um Oh, if you're just happy with CPA, no, no, this doesn't make the definitions and you'll see this doesn't make sense in a C in the world of CPA because the whole point is you're supposed to get decryption shares. In in

C in a CPA world, you can't get decryption shares. So the question kind of goes away if if you're if you're limited to CPA. Yeah. Okay. But I'm glad you asked because this is a good way this is a good segue into how we define security. [snorts] So I want to just very briefly talk a little bit about how to define security for a threshold uh encryption system. Like I said this is healthy for everybody to see um and there's a good good discussion here. So the traditional way of defining or the textbook way of defining uh security for a threshold decryption system and the reason I say textbook way is because this is how we define it in our textbook um uh is actually not the right way to do it. It's a simple definition but it's actually not the right definition. In

the later part of the chapter we give the right definition but let's walk through the wrong definition first. So this is what we call static low threshold which it was referring to before. So the way this works is the following. So security for encryption is always defined as a game between an adversary and a challenger. Okay. So uh the scheme is secure if no adversary can win this game against the challenger. Yeah. So the challenger is this honest party that's going to test uh the adversary and the adversary is trying to do something that it's not supposed to be able to do. So how does it work? Well, the adversary basically starts by saying here is a set of corrupt parties.

Yeah. So I can corrupt up to tminus one parties. So, I'm going to say I'm going to corrupt uh you know Tim and Itai and Nusret. Yeah, those are the people I want to corrupt. What does that mean? It means that uh you, Mr. Challenger, are going to give me the secret keys of those parties. Okay, so the challenger, the adversary gets to say, I want to get a whole bunch of secret keys. Of course, you notice it's up to T minus one secret keys. If you got T secret keys, then there's no more security, right? Because you can just decrypt whatever you want. We're going to give you up to T minus one. you shouldn't be able to decrypt anything. Um, but you can choose which T minus1 parties you want to corrupt. The next thing that happens is you create what are called challenge queries. So

you basically say here are two messages. You, Mr. Challenger, give me the encryption of one of them. Either give me the encryption of M0 or give me the encryption of M1. This is called a challenge a challenge cipher text because my job as an adversary is to say did I get the encryption of M0 or did I get the encryption of M1. So that's one query you can make. And the other query you can make is you can actually ask for decryption shares. Yeah. So you can say, "Hey, Mr. Challenger, here's a cipher text. I want you to give me the decryption share that party number I would have generated for this cipher text." Okay, so that's a pretty powerful adversary that can ask to decrypt anything that it wants. Uh and then finally, the adversary is supposed to

guess whether it got the encryption of M0 or the encryption of M1. And now we say that the scheme is secure if basically this is saying the ad no adversary can actually guess whether it got an encryption of M0 or M1. But it's under a very strong assumption and that is that it never got a decryption share for a challenge cipher text. And this should make sense to you because if it ever got a decryption share for a challenge cipher text well it already has tminus one keys. So if it ever saw one more decryption share, it can just decrypt and then it knows whether it got the encryption of M0 or M1. So without seeing um any decryption share for a child in cipher text, it should learn

nothing about encryption of M0 or encryption of M1. That's the traditional. >> So the decrypt query can ask for any CT except for CT star. >> Exactly. Exactly. Exactly. Yes. So here you're not allowed to ask for any decryption shares. All right. Good. So make sense. So this is how these definitions by the way they're writing this down is a is a real pain. These definitions are quite long to write but this is kind of the intuition for what they're trying to capture. So we call this static and low threshold. Why static? Static is because the adversary had to choose at the beginning of time who are the corrupt parties. Yeah. So you you can talk about an adaptive adversary that uh as the game evolves it can decide on the fly who it wants to

corrupt. Yeah. And Ling has a a sequence of really cool work about works about how to deal with with uh adaptive adversaries. Why do we call this low threshold? Well, the adversary can corrupt up to tminus one parties. Yeah. So that means the threshold is actually as small as possible. Yeah. So the threshold is just one more than the corruption bound. All right. So we call this a low threshold setting. Um exactly. Well, because of that the threshold is as small as as low as as it can be. This is kind of the limitation of this model is again the adversary is not allowed to ask for any decryption queries on the challenge cipher text and that's that's a problem. It turns out the the right model for consensus protocols is actually what's called a

high threshold setting. It's exactly the same game as before. The only difference is this bizarre thing. The only difference is that the adversary is going to bind its own hands and it's going to ask for fewer than two secret keys. This looks counterintuitive, right? Why would the adversary voluntarily ask for fewer keys than what it's allowed to? So, it's going to corrupt not three parties, but it's voluntarily only going to corrupt one or two parties. Yeah. Why does that help the adversary? The reason it helps the adversary is because now the winning condition is the adversary can now issue decryption queries on the challenge cipher text as long as it doesn't issue too many of them. As long as it doesn't issue more than T minus F queries. Yeah,

with T minus F queries, it can trivially uh win the game. With less than T minus F queries, it should not be able to. Okay, so the reason the adversary will bind its hands and ask for fewer decryption uh decryption shares, sorry, fewer key shares is so that it can issue um as many decryption shares as it wants. Yeah, that's kind of the that's kind of the reasoning. And it turns out uh this high threshold settings is sort of uh natural in the consensus world because in fact in the world of consensus the corruption bound is dramatically lower than the decryption bound. Yeah. One is n over 3, one is 2 over3. So it matches with what happens in consensus. Uh it turns out in fact

it's much harder to prove security in these high threshold settings. We even have separation results that say there are systems that are low threshold secure but not high threshold secure. So there's really is a stronger notion of security. And the point this now allows me to kind of explain how we model model a decryption context where a decryption context basically says the adversary can ask for as many decryption shares on the channel and cipher text as long as all of them have different a different decryption context. Yeah. So and this is why the adversary wants to bind its hand. So you can ask for many many many decryption shares on the channel cipher text. The only requirement is they have different decryption contexts. Okay. So

this is this is how we model the security the security game for a decryption context. And the constructions that I showed you before basically satisfy this definition. Yeah. Make sense? Any any questions so far? Yeah, please. So, so you could make the same, you know, the the same change also for static low threshold, right? You could you could say you could >> Well, not really, right? >> Okay. No, no, I hear you. Okay, good. Thank you. >> Because in the low threshold, T minus F is zero. >> One is one. >> Yeah. Yeah. Well, T minus F is one, so you're not allowed to ask any decryption queries.

>> Yeah. Yeah. So, that's exactly that's exactly the difference. And I should say, by the way, exactly the same thing. You could also modify to the world of adaptive corruptions. So there's probably probably going to see more papers dealing with uh decryption context for adaptive corruptions. So there's there's there's actually more uh interesting work to do here. What I'll do is actually I want to show you one more quick thing. I was going to talk a little bit about about the accountability question but I think maybe I'll skip that and I want to show you uh one uh more cute thing uh which is also in a realm of threshold cryptography but in a different setting.

So, so far we talked about threshold decryption. It turns out there's a similar concept uh in the world of threshold of of signatures called threshold signatures. And so, let me tell you um about kind of an interesting development in that world as well. Okay. So, what is a what is a threshold signature? Threshold signature works the same way. So, there's a key generator that generates a public key and a bunch of secret keys. We give the secret keys to the different signers. This time it's about signatures to the different signers. Uh then uh a user comes along and says, "Hey guys, please sign this message M for me." And if two out of the three uh agree to sign, then uh the user is able to uh get a signature on the

message. Yeah. So again, this is a two out of three settings. Okay. So I violated my rule for not using Greek letters. I have to use one Greek letter. I cannot use anything other than sigma for a signature. And it's the same same idea that basically if one secret key gets revealed that doesn't reveal anything doesn't help the adversary do uh do anything. This threshold signatures come up a lot in the blockchain world. Yeah. Generally when you manage wallet secret keys you know these wallet secret keys will manage billions of dollars. You want to protect those secret keys and often you would protect them by splitting them up into shares such that even if you lose a few shares there's no harm done. Yeah. So this is used very heavily in the in the blockchain space. So almost if any of

you have any have any crypto hopefully you guys are thresholdizing your your secret keys. If not maybe you should run home and thresholdize your secret keys. Okay. Uh the one thing I'll tell you is that it's a little sad but um Satoshi kind of made a mistake that we we we are paying still paying for in that Satoshi chose to use ECDSA as a signature scheme for for the Bitcoin network. ECDSA turns out is quite difficult to thresholdize. Yeah. In other words, um we can't do what I'm showing you here. Here I'm showing you you send a message, you get a you get a bunch of responses and poof, you have a signature. With ECDSA, if we want to thresholdize it, it requires a

multi-round protocol that's fairly complicated and people often get it wrong. There's a lot there have been a lot of mistakes in industry uh in building threshold threshold uh ECDSA. So it's a little unfortunate that this is a very complicated thing to implement in the real world. Well, I want to show you uh an easy way to thresholdize ECDSA. Easy way. All right. So, uh to do that I have to tell you about a huge hammer. This is like almost a kind of a nuclear bomb in its power in cryptography. This huge hammer huge hammer is called fully homorphic encryption. Okay. So, what is fully homorphic encryption? Um fully homorphic encryption is this magical tool. Yeah.

is all allows you to encrypt a message X under a public key and then for any function that you choose a server can compute this function on encrypted data. Yeah. So you can go the server can go for an encryption of X to an encryption of f ofx for any polinomial time computable function. Okay. So we can compute an encrypted data and then whoever has the secret key can then decrypt and recover f ofx. This is like super useful uh super useful tool. It's a very big development uh in cryptography. Maybe the if you haven't seen this before, I'll tell you that like a uh the you know the FHE 101 that we always use to tantalize people is you can imagine sending your encrypted

query, your search query to Google. Google can run their entire search algorithm on the encrypted uh query, get the encrypted result, send that back to you, you decrypt and you get the result without Google ever learning what you uh what you quered for. Unfortunately that will take about a billion years to run but module of that everything works. Yeah. Yeah. So that's kind of where we are. Oh actually this is what I wanted to say here is just in terms of performance just so you see the performance of FHE this is a nice benchmark from Zama. If you want to ev evaluate a 50 layer uh neural nets in in clear text it takes about a third of a a third of a millisecond uh to run it in FHE takes about 3,000 milliseconds to

evaluate. So you can see FHE costs are about a,000x over uh clear text computation. Okay, it's a good good number to remember. Uh the overhead is about a 1000x. Um um yeah, let's let's leave it at that. Uh so there's been a lot of development in the FHE world. There's a very nice uh programming environment for it. Uh and so on. One critical point for us is that in fact FHE secret keys can be very easily thresholdized. Yeah. So I can take an FH secret key, break it up into pieces and very easily we can decrypt in a threshold manner like we saw in the pictures before. So given that let me show you that in fact any signature scheme can be made into a very simple threshold signature scheme in particular

ECDSA can be made into a very simple threshold signature scheme. So this is our one of our papers from uh 2018 and so the way it works is as follows. uh what we'll do what the key generator will do is it will publish an FHE encryption of the signature secret key. Okay, so this is public for the whole world to see. There's no harm in doing that because the key is encrypted. Doesn't help you. And now when the user wants to sign a message, it'll send the message to the three servers. What the servers will do now maybe it takes a little bit of focusing to understand how this works but what the servers will do is they will run the signing algorithm on the encrypted secret key. So the

message is in the clear the secret key is encrypted. Each server now will run the entire signing algorithm on the encrypted secret key. What they will get what they will get from that is the encrypted signature. Right. The signing procedure is a function. We can run the function on the encrypted data. Yeah, the encrypted data is the encrypted secret key. What we'll get is an encrypted signature. So we do this and lo and behold all the servers will get an encrypted ECDSA signature. Now what do they do now? We just use the fact that FHE is easy to thresholdize. So the secret key that the servers will hold will be the threshold FHE key. They each decrypt Yeah, they each decrypt uh their

encrypted signature. And if we have enough decryption shares, the signature just becomes available in the clear. Yeah. So we get an ECDSA signature uh as a result of this. This is a one round ECDSA threshold signature. If you tell a cryptographer that you can do this, this sounds impossible. Yeah. Like this is like again 30 years of research trying to thresholdize ECDSA. We cannot do it in one round. The only way we know how to do it is through this universal thresholdizer. So we get a one round protocol for standard ECDSA signature. The only issue is we have to run the entire signing algorithm on encrypted data. So the question is how well does this work in practice? Does anybody want to guess how long does this take? Just throw a number. How long does it take to

run this in the real world? >> 10 minutes. >> 10 minutes. Okay, good guess. So the current world record is two days. So two days per signature. Yeah, two days per signature on a 64 core machine. There's a nice uh demo implementation of this. It's kind of funny. He says you can start the signing process and then while it's running you can go read about how my code actually works. Yeah, it'll take you two days and by then you'll get the signature. The problem with this is that ECDSA is defined modulo a very specific 256-bit prime. Yeah. So arithmetic modulo a very specific prime is very slow to do uh in FHE. So what this is kind of uh what I was wondering about can we speed up can we build an FHE system that's designed to work well

modulo um specific primes you know prescribed primes and that's actually what we just did. So we built a new FHE system that uses um like multiple levels of what's called um residue number systems. So residue number systems is just a fancy name for saying Chinese remainder theorem. Yeah. So we use kind of multiple levels of Chinese remainder theorem and um it turns out we can actually do very fast FHE arithmetic specifically for the ECDSA prime. This will speed up FHE for the purpose of ECDSA threshold signing. And so just to give you some numbers, this is my student Jong who actually went and implemented this. You can see the the the main thing I want you to look at here is with the existing FE implementations, this is the throughput.

With the new implementation, this is the through throughput. It's about a thousandx uh speed up in throughput. Yeah, thousandx. Pretty cool. So now multiplications takes take about 0.1 seconds. Every ECDSA signing is a couple of hundred multiplications. So this should work. This should be able to thresholdize ECDSA not in two days but in a minute. From two days we go to about uh to about one minute. Okay. So the cool thing is uh even though this is now only implemented for multiplication uh on a laptop, this is just on a this is just on a MacBook Pro, nothing fancy, it would be super cool to actually try to implement this on a GPU. A GPU should give us another 10 to 100x uh speed up

um to the point where we could get to subsecond one round ECDSA signature signatures, which would be mindboggling. That would be truly I think the blockchain industry would be uh quite happy if we could do this. So there's like a project here waiting for someone uh for someone to do it. Uh it would be pretty cool when we uh if we can actually make it work. >> Yeah. >> Your implementation does it use any specific properties of the ECDSA prime or could you use the do the same uh exercise with another prime using?

>> Yeah. Yeah. The prime is zero. It's independent. Yeah. You can do it for any prime. Yeah. Uh in fact the bigger the prime the better. But uh uh yeah, but we can do it for any prime. So yeah, so I think I'll stop here. So I hope I showed you that uh basically blockchains just keep on generating incredible research questions in cryptography. It's like this is why I love this space. It's like literally the new kind of directions in cryptography. So many of them just come uh from the blockchain. And yeah, specifically for threshold decryption, you can see lots of questions that come up here. I'm kind of excited about this question of if the universal thresholdizer can be made practical.

this would have real implications and applications in uh to uh to wallets and to uh exchanges. So hopefully that can actually be uh be demonstrated. So yeah, I'll stop here and thank you very much. >> Low threshold versus high threshold paradigm also generalized to signatures and the unforgeability game. >> Yeah. So there it's kind of less uh it does but there it's kind of uh oh no no sorry yeah it does actually. So this um this question of whether you can you can ask for signature shares on a message >> on the on the challenge message. Yeah that's uh that actually comes up there as well.

>> There's no really challenge me >> on the forge on the forgery. I need to just forge a second message. >> There's actually a a couple actually uh ling also has some papers on this. There's a couple of papers now that actually study that study that model and it turns out um if you don't modify the schemes then it takes stronger assumptions actually to prove security in that model. If you modify the schemes you can get away with uh simpler assumptions. Yeah, that that it's interesting that's been studied. There's actually five or six papers that already study signature low thresholds uh signature high thresholds. In the decryption world, there has not been much uh much work on that. Yeah, cool.

It's a good question. Is this uh FH scheme able to do both uh like your curve operations in reasonable time and binary operations or do we kind of have to pick one or the other like oh wow that that's a great question. I see. I see. Um, right. So, yeah, it turns out the binary operations are actually Yeah, you don't even need any of the fancy Yeah. So, the answer is yes. You don't even need any of the fancy residue number systems to do binary operations. It's just when you move to do large field operations, that's when that kicks in. But it it works concurrently. So, it's kind of just an encoding issue. So, you cannot use the encoding and then do binary operations.

>> But that means you can mix and match like Exactly. Okay. Because you can imagine like one interesting use case here where you have uh EC operations and binary operations is like TLS, right? Where >> like ECDH is hard to do in a thresholdable manner and well I guess not ECDH but like a lot of things are hard to do in like you either have to do ECDHH and then you have to do like cha or AES something like that. If we could do both of those relatively quick on big GPUs maybe you could have high threshold ZKTLS. >> Oh the whole of ZKTLS do FHE. Oh my god. because I mean it's I mean it's fun but uh if you can do and binary maybe >> yeah for sure no that's a really really good idea um that would be amazing if if that could be demonstrated one thing

I'll say though is for signatures you know every signature also involves hashing first right but it turns out the hashing can be done outside of the FHE so there we that that hashing is kind of for free uh so so at least we don't we don't need to worry about expensive hashing uh in the FH space but in for signatures but of course once once we go to TLS that then it comes comes up. So that would be that would be an incredible demo to show. Yeah, if you can do if you can do that in under a second, oh my god, that would be amazing. >> Cool. Thank you very much.