Keynote: zkEVM Soundness by Arantxa Zapico, Ethereum Foundation

Transcript

All right, thanks very much, Gov. Um, next up we've got Arancha Zapiko from the cryptography team and I know she is very excited to have Dev Connect in Buenoseras in in Argentina. Um, I don't need to share. Okay, welcome. Arancha is gonna be talking about soundness. >> Did you say Did you say I'm from Buenosaris? >> No, no, Argentine. >> Hello. Uh, well, I'm very excited to be today here for two reasons. First of all, I may be late on the week, but I want to give you a warm welcome to

Argentina, to my country. I hope you are enjoying the people, the culture, and the food, of course. And second, as a snack person, I am beyond excited to see how and where you guys have taken snarks. I started working on this like seven years ago. I met Snark seven years ago and in no case I would have ever imagined what is happening with snarks today. So thanks a lot. You really made this like the most exciting field of research. So in this talk we will be talking about the soundness of snarks and we will use that as a path to speak about the security of snarks.

So the idea is that in this talk we can uh discuss a bit how we define measure prove and improve security of the cave apps. So let's start with how we define a security. So a snark is like a proof system. What in cryptography we call proof system and the CKBMS are in these proof systems. So in a proof system we have two parties a prover and a verifier and they will interact for some time and end this interaction with the prover sending some piece of information that we call the seal or the proof. The verifier will check this proof with some rules that we set in ambance. And if the h this piece of information passes all

the verifications, the verifier can be convinced that the prover was honest. The prover was honest by proving that some statement is true. So for a proof system like this, we require two security properties. The first one is completeness. If we design a proof system that both the prover and the verifier follow with a statement that is true the verifier will accept and for some and the second one and the most important I mean not the most important one but the one we will talk about today is sound is soundness so if the prover doesn't have a statement that is true it should not be able to convince the verifier except with a small probability so to prove huge things as the ones we are pro

proving with very small proofs some first time we have to give up something and that is a small probability that the prover may cheat. So this epsilon this probability is called the soundless error. Uh you may also have heard of knowledge sound res error which is actually uh what we are checking and is the chance that the proer will convince the verifier of a false statement. What is more if we speak about MP relations the prover doesn't have a witness for the instance for the relation but is able to convince a verifier knowledge let's honestess is when the we want to make sure the prover there is not only a witness but the provers witness so for CKVMs what we are

proving is execution of ethereum blocks right so our witness is the block and those the soundest error is the chance that the prover can convince a verifier or the entire network of the correct execution of a block that was never executed. So the summary server here is very important. We have to make it as small as possible because the the consequences of having a cheat improver are huge, right? Like we can actually make billions out of nothing if we are able to break the proof system. So how do we measure this epsilon? How does it come? How where does it come from?

So I think of CKVMs in my like cryptoph like this. The rectangles on the on your left are executions of uh snark provers that prove h error traces. And then we have some other provers that aggregate them and probably just grab to have a small proof. But for this talk I will talk only about one of these rectangles. one uh one proof system that proves the execution of an art trace and I will use as an example for our proof system uh an art trace that is proof using fry batch fry and deep ali if you don't know what is that don't worry you can still h you will still be able to follow the talk so

our pro wants to convince the verifier of the execution of a block of actually the the satisfiability of and air trace and for that they will interrupt for many rounds. Each of these rounds some of them have more rounds inside but we can divide the proof system in five parts for this. If you are familiar with fry for batch fry we have the fry batching the commitment phase and the query phase and then for the aggregation of the constraints we can also use deep ali the knowledge soundness of each of these rounds is a probability that a prover that doesn't have a valid witness convinces the verifier and for the entire system we take the soundest error

to be the biggest of these ones why because if I get lucky in one of the rounds and my piece of information that was not a valid witness becomes a witness that satisfies the the checks of the verifier then I can just follow an honest prover uh instructions and cheat so doesn't matter if some of these epsilons are super small if one of them is big then the soundest error of my system is big and my system is insecure so for instance an example if we have a soundless error of 2 to the minus 80 meaning a prover gets lucky with a probability one over 2 to the 80. We

that means that an adversary a cheating prover will need 200 two to the 80 operations in order to break my system. You can think of these operations for today as like just hashes right. So it needs to perform two to the 80 hashes to make sure it will break my system. And we say that such a system has 80 bits of security. Right? Now what happens if I have a system with 80 bits of security? Let's say that I cannot performing two to the 80 hashes according to my sources takes around a month. But what happen if I can perform two to the 60 hashes then I still can get lucky and my chances are one over two to the 20.

And this is a soundest error that we do not accept at all in cryptography. What is more, computing two to the 60 hashes according to my sources takes 40 minutes for instance in an ASIC minor. Right? So we went for a month to uh 20 minutes. The proer is not sure that we'll win but the chances are quite big. So 80 bits of security is not enough. What is enough for us? Well, 128 bits of security is the standard set by the National Institute of Standardization in the United States and the consensus in the cryptography community. So 120 bit 128 bits of security is the security

that Ethereum deserves. So if you love Ethereum, give Ethereum this 120 bits of security. So how do we prove? How can I prove that my proof system actually has 128 bits of security? So in in my in my mind to prove security I follow the following steps. First of of all you have to know your adversary. What are the resources the time and the incentives it has right? We don't design all system for any adversaries. I hope you don't use the same password for Spotify or for your password manager.

Right? But in this case, we have one good thing which is we don't have that much time. The adversary doesn't have that much time to attack our system. But the incentives are huge. And this is a a problem or something to take into account for the entire blockchain, right? Like the incentives to make money without much effort are huge. And if your incentives are billions of dollar, the resources are also huge because you can buy lot of resources, it's an investment that will pay off, right? Also in terms of resources we can think whether we want an adversary we want to consider an adversary that is postquantum that is has quantum computers or not. We are aiming for adversaries that have lot of very

powerful quantum computers. Step two analyze your building blocks. Analyze and attack the security of your building blocks. I hope you're aware we have in the Ethereum Foundation a Poseidon initiative. So we are putting a lot of resources, a lot of effort led by Dimmitri Koratovich on asking people to attack and to study the security of Poseidon which is the hash function we we hope to use in terms of for instance read Solomon codes. We are also h pushing led by Jako offens and coordinated by Justin an initiative on proving conjectures or disproving conjectures that may be used to analyze

read solomon goals and I put polinomials here we already know polomials enough but they are also a main building block of these systems and yeah the nicest of the building blocks of these systems and once you have your adversary you have a you know the security of your building blocks you had to choose what you are going going to do. So knowing your adversary you can choose what kind of security you want to give and if you are in you have been in ET proofs calls if you have been in Twitter or maybe it print these days this all these words all these phrases may like ring a bell for you so what is happening here I'm not getting into the details I'm not the person to get into the details but in

this fight I would like to like h highlight two kinds of battles that we can choose. We can choose to have probable security or conjecture security. Probable means that we can say what the adversary which kind of effort or which amount of effort the adversary has to do to break our system. Conjecture is the same but we do that based on a conjecture. What is a conjecture? Whoa. A conjecture is something that we believe we hope one day may be proven to be a theory but it's something that we are not sure about. Right?

So why would we use a conjecture? Well, this is a very simplified graph of pro work against security for probable or conjecture security. What does it mean? Again, in order to to prove an error trace with batch fry and deep ali, if we want to analyze the security of our system with conjectures to achieve 50 bits of security, we need 55 queries. 55 queries is pro work. It's proof size and it's verifier work. I just put it as pro work to simplify stuff. But if I want to do it with pro security, we'll need

around 105 queries. So this is the reason why people want to use conjectures. We can get more efficient systems with the same security but conjecture same amount of bits of security. Why wouldn't we use conjectctors? Well, there are a couple of reasons that have like uh came to the light for the this all of this happened in the last three weeks. Uh we had some conjectures we thought they were they were true and then they were proven untrue. They were we have new conjectures that we again hope that they are true. And while we still are putting a lot of resources and energy on

conjectures from now on in the AF we will only consider probable security. So we'll ask teams to report and we will report only probable security. If conjectures nice conjectures happen to be true that will be amazing. We will report that as probable security. In the meantime we don't talk anymore about conjectures. So what is happening nowadays and you have heard that from from the teams in the in the panel and in previous talks is that most of the teams have been in this race of speed that we have set from the foundation they have been working a lot on the efficiency of their systems and not that much in the security. So some teams have let's say between 100

128 bits of conjure security. Uh but for probable security the numbers are way lower. I know saxint achieved 100 bits of probable recently but most of the teams are even between 40 and 80 bits of probable security. So how can we prove this? Um so in this section I will like present what is let's say our discussion inside the crypto team inside the theum foundation with the rest of the CKVM teams and a bit of feedback from from some CKVM teams. So let's let's let's see how security how run by ROM security or soundness works

h in different settings. So this the soundness and those the security of a system is let's say he like heavily relies on two things first the size of the field we are using for our proof system and the size of the extension field we are using because there is from where we sample the elements and the second one is the number of fry queries again if you don't know much about what's the query phase in fry is just there are two things that lead our security. So h I for this uh for this graph I use goldilocks is a field of 64 bits and therefore the second extension

which is the first one I will talk about has 128 bits. So what happens if I do 128 queries using goldilocks to try to prove the art trace using h batch fry and and the pali. Well it happens something like this. If you see for instance the Ali uh face the Ali um round it's around maybe 110 115 bits of security that's cool again this is only problem we don't talk about conjecture security ever anymore but in a freight query because I'm doing only 128 queries we are at 58 bits of security then that is the security of our system right

doesn't matter how high the other bars are the security of our system in this case is 58. So we are bad at queries. Let's double the queries that we do. And now queries wise we are okay. But all the other faces depend on the size of the field. I'm using a field of 128 bits. Achieving 128 bits of security with a 128 bits field can only be done in very very trivial uh instances. So now we are below uh with the fry button and we have only 78 bits of security. So let's now double the size. H sorry let's use one more extension goldilocks 3 it will be in orange that has 192 bits.

What happen if I do 128 queries? Everything seems very nice but again queries here are the bottleneck. If I don't increase the amount of queries, the security of my system is as 58 bits. What happen if we do goilocks third extension with uh 256 queries? Well, we are getting there. We have 116 bits of security. And now what happened with the 12 bits that we are missing? We could do more queries. But as I say before queries cames with brewer work proof size which is right now the bottleneck to achieve 128 bits of security and then verify your work. So there is a

technique that we can use it's uh allowed to use it's not cheating it's just being smart which is using grinding. Grounding can buy us some bits of security. For instance, can perfectly buy us 16 bits of probable security and then we can achieve the 128 bits of probable security. What is the bottleneck here? Why can't we just apply grinding in this 58 bits of security uh case? Well, because this is how prover work uh grows with the bits of security we can gain from grinding, right? So there is a trade-off and again this is an analysis that we have done with the help of the teams which is very

easy to for me to stay here on stage and say hey this is how you at 228 bits of security but there is a huge amount of engineer work that the teams have to do behind that and we want to uh help them and we want to help Ethereum get the 128 bits of product security that deserves. So what is next for us from the EF and from especially from the cryptography team. So as I said before we will only measure probable security. As Kev mentioned before we will ask teams to have 100 bits of road security by glamor expected to happen end of the second quarter next year.

And we hope we hope no we will require 128 bits of security for HAR which is first quarter of 2027. Importantly these deadlines are like very vague. We don't know when glanc is going to be. We don't know when H star is going to be. So before the end of the year and hopefully in a couple of weeks let's see what's the feedback we will receive. We will set hard deadlines for this and also deadlines for uh proof size from the cryptography team and especially uh actually done by Dimmitri and especially George and Ben. We have set a universal soundness calculator

where we hope to measure the probable security of the different teams. Um so we can compare apples to apples and everything is measured uh with the same with the same system. What we need in order to integrate your your SEVMs into this sum calculator is to please please publish a quite detailed description of the proof system you are using also the parameters and h some engineers improvement that you may have in your code. And again we are aware because of the feedback we have received especially this week that you guys need incentives to do this like this race for speed has

been a huge incentive for speed and we need now to promote and to communicate better and to do even some marketing on the product security. So this is our our new realtime proing 128 bits of product security. Here is the QR code for the soundness calculator. Please do check it. Give us your feedback. Again, we are only trying to coordinate this. It's easy to stand here and like give a vague details of some vague analysis, but you are the ones that are actually building this. So, please give us your feedback.

That's my Telegram, my email. You can reach out. I mean, we are quite easy to reach out uh to anyone in the CKBM team, in the crypto team. you you can also talk to Justin to Alex. So yeah, thank you very much for listening. Thank you Arancha. Um so we we have time for one question before lunch. So this is the most upvoted question. What do you think about provers that are postquantum resistant while Ethereum is still using elliptic curve cryptography?

What about the trend that NIST is pushing forward that the NIST is pushing forward to postquantum while blockchain is a bit behind? >> Well, so h to be honest there is no rush to have pros that are postquantum. Right now we are like from the EF we are moving trying to move Ethereum to postquantum as well. You can see the effort on for instance replacing BLS with hashbased signatures. That's also a an effort that is led by by Dimmitri, by Ben, by by Tom and Justin. So, Ethereum will move to postquantum. I mean, you can decide whether or not to do prequantum and then you will anyways have to do a big amount of engineering

work to move to postquantum and make it to Ethereum. On the third side, I know that some teams for instance are using a growth 16 wrapper on their proof size on their proof to achieve a better proof size. If you ask me now and I hope no one kills me for this, for me that's okay. As as long as it's something that then you can remove, I would rather go to like 128 bits of security and like do the wrapper to have a small proof. Again, this is something that I need feedback on. I like I don't think I have talking talked to any team that is doing a rapper right now like this week but if you see that this is the only way that you can achieve a small proof and still do the broad security okay Alex says no we don't want rappers well yeah that

that part was a personal opinion don't kill the for me it's not a I mean for a for a couple of months it should be okay but yeah no we are not accepting any kind of rapper we go 100% postquantum I mean but we are open for feedback. I am very open to receive a feedback on that. >> Thank you very much. Thanks so