Challenges of Quantum-Safe Privacy on Ethereum

Transcript

All right. Uh, hi everyone. So, uh, in this talk I'm going to try to speedrun uh, why quantum safe privacy on Ethereum uh, why it's it's it's hard. So, what it looks like and why it's hard. So yeah, it's it will be a bit of a challenge, but uh I will try to introduce you the three main issues that uh uh privacy protocols are going to face on Ethereum uh while we are transitioning to uh quantum safe uh systems. So a bit of a context. So I guess now it's a cliche to to say it but uh the quantum time timeline is accelerating and it's

accelerating under the pressure of two uh things. So the first thing is that uh quantum computing in general has seen a recent breakthrough in both in terms of infrastructure and in the algorithmic realm. So quantum circuits have become smaller and smaller. And at the same time the the second thing that is impacting is uh the fact that auto research has made uh has accelerated more and more those two those two those two trends and it's actually uh starting to raise serious doubts about what is public knowledge in terms of what quantum computers are capable of today.

So the first challenge uh is transitioning. So you have this theorem that is well known which is called the Moscas theorem which says that if your time to migrate to safe encryption and plus transition uh makes it u big requires more time than when when the first cryptographically relevant quantum computer is going to be available then uh it's going to be a big problem for you. So this transition uh phase is going to be I think an engineering and people challenge and it might take some time. So for that uh I believe there are two solutions uh one that has been u deployed in zcash which is this concept

of quantum recoverability. So making it possible even though if your system is still using classical cryptography to make it possible for people to recover their funds if there is a quantum computer. So it's zip 2005 um and uh formal verification. Uh so formal verification actually helps you also build some some trust with respect to the things that you are transitioning to quantum safe cryptography. So yeah first challenge. Second challenge it's a hash functions. Um so hash functions uh they are core components of postquantum hashbased snarks. There are also uh important components of um many privacy protocols. Uh uh Zcash today uses an elliptic curve based uh hash function to

build its Merkel tree of nodes. So uh we should pick very carefully that hash function that is going to underpin both the Ethereum protocol and the privacy protocol that you are going to to to to build. Uh there is hopefully lots of progress today in binary field snark. So it's very likely that we will be able to use very lindy hash functions like SHA 256 or Blake. Uh so and we will most likely uh go away from algebraic hashes to go for something that uh we know about more in some sense. So yeah that's the second challenge. Uh so hash functions which one are you going to pick uh for your privacy protocol and your and your and the snark that

underpins your privacy protocol. And the third and final final challenge is uh proof sizes. So as many of you know hashbased postquantum snacks feature order of magnitudes larger proof sizes and so you have two main issues with that. It is that verification requires high gas costs for those kinds of proofs and that it poses important uh bandwidth challenges for meool nodes, right? Because uh your proofs are very large and they are going through your meool and so that can cause uh um um it can be some kind of an attack vector on your meool. So we need to deal with those

proof sizes and the two solutions here you have inme aggregation from EIP8288 uh that is uh in draft stage today and just better codes that allow you uh to make your proof sizes uh basically uh smaller. Uh one interesting auto research challenge is the better.code code challenge which uh is working on making more efficient codebased NS which should lead to smaller proof sizes. >> So yeah, solutions exist for each of those challenges. So transitioning hash and proof sizes and now is basically the time of delivery. Thank you.

All right. So, um, yes, please ask questions. Scan the QR code and you can ask questions. My question to you is, so you mentioned better codes. How much smaller can we make these Starks? Even let's say we had a perfect solution to better codes. Um, like how much smaller could we actually make these? >> Yes, that's a good question. So, you do have lower bounds. Uh, on how much smaller you can make it. I don't know a specific number for it as of now. I think better dot codes makes it possible to reach something like 10% smaller proof sizes. So that's already pretty nice. Um but you do have lower bounds but I don't remember a specific number for it. Yeah. But I believe we will soon

uh Yeah, we Yeah, you should have you should be able to find the answer somewhere. Yeah. Yeah. >> And and personally like what do you think about like lattises like are you a fan of lattises or more conservative on like you know hash hashbased? >> Yeah. So uh I'm personally not that beerish on latises. I think Ethereum has made the choice to uh build the protocol out of a single hash function. Uh there are many cryptographers that aren't that worried about latises. Latises have some very nice properties. Uh they feature yes they feature structure uh but at the same time they offer some nice affordances like homorphism. So I think uh privacy protocols should look into

latises and they are um mostly for note encryption. Uh so yeah that's that's my opinion. Yeah. >> Uh another question that we got from the audience is will Ethereum's approach to solving postquantum actually work. >> Yeah. Yeah. Absolutely. I'm I'm 100% convinced that we are going to achieve this. >> So another question, how can we achieve postquantum security and strong privacy without compromising speed and scalability? Yeah. So, uh that's a good question. So, uh it depends of what we mean by speed. Do we mean speed in terms of protocol in protocol terms or in terms of client side proving? So, uh hashbased uh snarks are very fast. So, I'm not worried about client side

proving. In terms of protocol, it's going to be about inme aggregation using EIP8288. Uh so I do believe that this trade-off is actually not really one because uh aggregation is actually going to help us uh uh go around that that speed versus privacy. Yeah. >> Awesome. Unfortunately, you're out of