Episode 393 - lean Ethereum Part 3: Security of PQ SNARKs and an update about the Proximity Prize

Transcript

Welcome to Zero Knowledge. I'm your host, Anna Rose. In this podcast [music] we will be exploring the latest in zero knowledge research and the decentralized web, as well as new paradigms that promise to change the way we interact and transact [music] online. This week, in our third installment of the six-part mini-series on Lean Ethereum, Nico is joined by Giacomo Fenzi, PhD student at EPFL, and Antonio Sanso from the Ethereum Foundation. They discuss the theory and security of post-quantum SNARKs, the hash-based proof system that will underpin Lean VM, and signature aggregation in a

post-quantum Ethereum. For these episodes, we have Nico as our host. We are also releasing this in video form over on our YouTube channel. Links are in the show notes in case you want to check it out over there, and be sure to subscribe to the channel while you're at it. In this conversation, Nico, Antonio, and Giacomo discuss the recent wave of research on proximity gap conjectures and the $1 million in proximity prizes offered by the EF, an initiative which has prompted a flurry of new papers on this topic. It's a deep dive into the mathematical foundations that determine how much confidence we can place in post-quantum proof systems. Hope you will watch or listen along to this and other episodes in our mini-series.

And yeah, let us know what you think. Now, before we kick off, three quick points. First, ZK Summit is coming back with its 14th edition. Applications to attend and or speak are now open. It will be on May 7th in Rome, so hope to see you there. Second, ZK Mesh Plus, our paid subscription tier, is rolling. We have already released a few bonus clips from the show, as well as some of our exclusive research reports, like the state of ZK report and its addendums. If you want access, please join the paid tier on Z cash plus.

Third, if you're looking for other ways to support the show, we have donation accounts visible in the footer of our website. So, if you choose to do so, thank you in advance. That's all for now. Links are in the show notes, and here is Nico's interview with Giacomo and Antonio. >> [music] >> Today, I'm here with Giacomo Fenzi, PhD student at EPFL, and Antonio Sanso, cryptography researcher at the Ethereum Foundation. This is episode three of our mini series on the linear Ethereum upgrade, and this one is dedicated to the theory and security of post-quantum SNARKs.

Hello, Giacomo. Welcome back to the show. Hi. How's it going? Good, thanks. And hello, Antonio. Also, welcome back to the show. >> Yeah, thank you. Actually, before we get started, I'm curious, you both have already been on the show. Um, what's been happening with you guys since you were last here? Uh, it's good question. So, I think I was here last time 1 year or 2 years ago, and we were uh with you with Galv. We were talking about uh Stir, Mhm. uh which was like at the time like our like a new and fancy protocol that had uh just gotten out. Since then, we've had a few other cute and fancier protocols, maybe I would say. So, we had like we're with the Warp, uh Tensor Switch, and a few other things and I'm still in Switzerland in uh EPFL, uh

enjoying the mountains, uh let's say, with a a bit of cryptography on the side. Nice. How about you, Antonio? You actually last time you came on, you were talking about uh s- kind of the opposite of what we're doing here, like very non-post-quantum SNARKs, right? >> Exactly. Yeah. Well, we talked about some elliptical stuff, and uh I don't know, someone decided to kill my area of research so >> [laughter] >> there used to be ellipticals, and uh th- th- now they're gone, and isogenies. But lately, uh I've actually tried to pivot from from ellipticals and isogenies, and since then, I've been mostly working on Poseidon, and uh and now like on Stark and then more more in general some proof system and yeah.

That's that's life. Look, we adapt and we learn. So so far on the series we've covered the fact that Ethereum is moving to post-quantum signatures like post-quantum everything essentially. We've learned that we also need multi-signatures for consensus and that to achieve those we're going to be using a SNARK. I've also been told that there is a custom VM being built lean VM and that's actually the topic of next episode. But what I was curious about is what SNARK are we using to prove this VM? Is this like good old classic Groth16? Are we using like off-the-shelf Stue, Plonky2? Like what's happening?

Yeah, so things are like changing a little bit. So from the old type weight of doing cryptography like uh the [snorts] main focus of time or day of this upgrade of Ethereum is about trying to get to post-quantum resistance. So a lot of the techniques that we were previously using cannot really work. So both for like conservatism and for performance like the the choice has fallen towards hash-based signatures. And lean VM is currently like being built on top of like a custom stack of like uh different components like trying to be built for the signature aggregation stack. It would choose this VM organization and then where as the let's call it polynomial commitment plus

underlying the the construction. Okay. And so is this a sum-check based uh SNARK? Is this univariate based with our good old like quotients like we like to do or So we're doing thing modern. We're in the 2026 multilinear is the way to go and lean VM is also following this multilinear approach using sum-checks as much as possible. So the old organization is multilinear oriented and it is using at the same time other like lookup techniques like lookup star which I think Tom and Emil will be telling us much more in the next episode but multilinear is the name of the game is recently I think a lot of people have been realizing that this is the way to actually

do hash based proof systems in general and it has a lot of benefits so currently like there's been a big push from industry and like academia alike to move towards multilinear proof systems. And some check of course. Yeah. And so is there a name for this snark? So not really like as far as I know it's just called the super spartan plus log up slash log up star plus where Okay. >> So maybe they need to be a bit more creative. Yeah. >> Yeah. So let's just call it the Lin VM stack for now. Okay. So we have this new snark. It's using components that we are somewhat familiar with or that have been around in different papers.

There was still I guess some security questions. I remember Justin Drake announcing actually on the show a $1 million prize for something about hash based proofs. Can you guys tell us a bit more about what that was about, how that connects to this snark and what the hell happened with proximity apps? Yeah, I can actually just like give a bit of history here, right? I mean um you know like there's always this this this like dichotomy between the security and speed and like hash based snark I mean there is like you can actually play really safe and and go slow or being aggressive on on on on mathematics and on conjectures and and and being fast. And you know

the the tendency in the last years has been like to to go I mean where I have a crypto and blockchain so the tendency was speed and at the cost of potential security in the in the last years. So, what the what was like happening like um we want to have some bit of more confidence on the conjecture we were using on some of this proof system deployment. And there was this this proximity gap prize of $1 million that was announced by Justin Drake and sponsored by the Jim Foundation like $1 million in prizes someone was actually able to to break so I'll give you a counter example or prove this conjectures that are associated with like

to this stark of rye. And then maybe Jacomo wants to since Jacomo is one of the judges of the we'll say this prize maybe wants to spend some more words a little bit. This was giving of context. Yep, absolutely. Yeah, yeah. So, I'm helping out with the with the judging submissions and together with Dan Boneh and I got her known we're writing like a summary because as Nico saying a lot of things have happened in the last month especially like in November a lot of paper come out. There's been a lot of things going on. But maybe let me take a step back on like what this prize is about, what are this conjecture and how they kind of like fit in in the larger like hash-based

landscape. Yeah. Most hash-based SNARKs they rely on like very similar techniques. They're similar to like batching in a certain sense but with some slight like differences. So, for example batching when we are talking about like in proof system is this concept of like I have like many claims which I of which many some of them might be valid, some of them might be invalid. And I want to make sure that I can take many claims, compress them into a single one. And if any of the original claim was invalid, then I would want the final claim to also be invalid. So, in a certain sense I'm kind of like preserving like the validity of the entire like system

into a the single claim. While performing some sign of compression. And this kind of primitives are all the main building block of like um proof systems in general, but Ash base in particular. Yeah. So, in Ash base proof system, this is has to do a lot with error correcting codes. And the condition of when some error correcting codes that have been corrupted over by a large fraction of their code word end up like being bashed into something which ends up like being corrupted in a smaller fraction of the code word. So, in a sense, the corruptions are easy to detect, so at the end the verifier will figure them out. Mhm. But if I'm kind of like reducing the amount of corruptions

in the code word, then this makes the very for the verifier harder to detect things. Right. And the proximity prize is about trying to like figure out effectively how these distance preservation kind of claims end up like behaving in the context of an Ash base snark. Mhm. And we know that for certain levels and fraction of corruptions, we can prove security probably. Right. And and once the noise instead becomes too large, we know that the security cannot be guaranteed. And we know there's like an area in the middle where we don't our current mathematical techniques do not tell us enough to really be able to prove security of the protocols. We don't neither know ways to break security,

neither we know how to prove security. And traditionally people have been conjecturing that this area were secure. And the proximity prize the main objective is to try to like really put the foot foot down on formalizing what these conjectures are and try to spur like research into really figuring out what the behavior will be in these areas. Right. So, just to be clear, it doesn't mean our snarks are insecure. It's just like the way we analyze them and the way we compute parameters changes depending on what the mathematics tell us is true or not, right?

Exactly. Exactly. >> Okay. So, maybe there's a lot of luxury that we have in a space cryptography in that we don't really have to rely on cryptographic assumptions other than the collision resistance of an edge function. What it basically means is that the proof system can be fully proven secure in the random oracle model. Mhm. What this means is that the if we believe the random oracle, we can give like concrete you know, information theoretical guarantees on the soundness of the of the protocol. This is different, for example, from elliptic curve in lattice-based cryptography where a better algorithm to like solve certain problems would make progress in breaking the cryptographic system.

Yeah. So, we know like that the we know that the our analysis guarantees security up to some point and we do suspect that security is also guaranteed after this point up to some point after which actually there are already would be attacks. And our like maybe there are information theoretical attacks, maybe there are concrete attacks that one could mount, but basically uh yes, this is yeah. Just just want to add that actually, from my perspective at least this millennium prize kind of met the objectives. It was like in the span of a 1 1/2 month, we got more progress on the topic uh more more than 1 1/2 month than in years of research. And actually, a

little trivia, uh I guess like me and you or like the people that were in the room in Cambridge uh seen live how these ideas was one of the the the first idea that actually like the first like draft on the on the conjecture actually was was born and that was actually pretty exciting. That I'm I'm talking about of course about the retreat in Cambridge. That was amazing. Yeah, and we've actually mentioned that in the first episode with uh Justin. So, this problem of can I batch and still have the right distances was sort of this proximity gaps problem.

Um there were five or six papers that came up pretty much within like two three weeks of each other. All talking about this problem, showing negative positive results. What What did they do? Like what does it mean? So yeah, there's been a lot of progress and there's been I think five or six papers. I actually have a list of them in front of me. So the first one was this paper by Ben Diamond and Angus Cruickshank. Mhm. Which was closely followed by one by Elizabeth Cruickshank and Alistair Stewart.

Then there was one by Eli Ben-Sasson, Dan Carmon, Uriel Aboucaya, Swastikoparty and Shubhangi Saraf. Then there was one by Ran Goya and Venkat Guruswami. Mhm. >> And then there was one by Sarah Alessandro D'Angelo and Ignacio from EPFL. Right. And and all of them had slightly different like results which are kind of hard to survey together but let me let us try to do that. So >> Mhm. Okay, before this explosion of papers we basically knew the following. So remember before I was talking about this fraction. Yeah.

>> So there's one value of this fraction which is called the Johnson bound which is a very classical measure in coding theory. If the corruption is less than the Johnson bound then we know the security holds unconditionally. Mhm. So we know for the codes that we care about for linear VM and for like STARKs in general, we know that uh this construction is secure. Mhm. Beyond a certain other fraction which is called the capacity we knew the security cannot hold. When we're when the fraction of corruption is a is more than this capacity bound then we know that there's no security can be guaranteed. Mhm. And nothing was really known in the middle.

Okay. So, this is the status quo before like all this paper came out. Then there were like the the the Diamond and Gruen and the Krichen and Stewart papers. What these papers showed roughly was that the the correlated agreement error, which is the name for this property of a patching things, um actually cannot hold somewhere like which is the at a fraction of corruption which is slightly smaller than the the the capacity value. Okay, so it's inside the range where it was unknown until then.

Exactly. Exactly. So, it this is a quantity that corresponds roughly to the Elias bound. Uh which is another like classic information theoretically coding quantity. This is like close to like the close to the capacity bound, but far enough that actually uh this attack would degrade the secure Well, this attack this analysis would degrade the security of like the uh some of the deployments in practice by I think if I'm correct it was uh three to five bits. So, if you deploy like a system with 128 bits of security, a conjecture security, then this would

uh reduce it to 125 bits, for example. Yeah, opening a parenthesis to your jackpot like what What surprised me a lot about especially like the the second paper by by by Stewart and Krichen is that actually uh surprisingly from my perspective, the result that they that they managed to to to to achieve, they use a really old paper that is like from 1964. So, you would expect this answer will have uh an answer like that will use the modern technique. Instead like they really use a really bound from the '60s and that was this amazing to me at the beginning. Right.

I guess at the end of the day these are very like fundamental problems of like counting fractions of things, right? And when you start to talk about like counting things and like looking at polynomials then there's a whole depth of literature like in mathematics that you can go and take from. Yeah, and it's really really beautiful as well. Like uh in a sense it was not uh unexpected. Like we knew there would be like a phase transition at capacity. So at after capacity everything would be broken. So, you know, one of the questions that we had at this retreat in Cambridge was like, "Look, I cannot believe that one little bit below capacity actually think will magically be safe. There should be like a somewhat

smooth phase transition between when we're secure and not secure." And this particular like uh consideration were kind of like what guided some of these uh papers in the attacks to look at this boundary region and see what what issues were to arise. Right. There was like some of the negative results and then there was like some of the positive results. Okay, so negative again we mean like within the unknown area some part of it is actually unusable for security analysis. Positive result I guess you mean on the other side like pushing beyond what we knew.

Exactly. Exactly. And on that so there was the paper by um Eli Ben-Sasson, Dan Carmon, Ulrich Aboc, Swastik Kopparty, Shubhangi Saraf. So they showed a lot of things. This paper is a is a kaleidoscopic paper. It has like both negative and and positive results. But among the positive they showed for example that for like Reed-Solomon code which are code that we like particularly appreciate in proof systems not only they they bound to also Johnson bound as I was saying before, but they showed an improved error.

So that the bound up to the Johnson bound is actually like the error of this batching step is lower than what um it than what they were previously thought. Okay. So the result is positive in the sense that we get better errors than what we thought we had before. But it's not positive in the sense that we can use our analysis beyond the Johnson bound. We're still limited by the Johnson bound. Well, yeah, for getting beyond the Johnson bound, actually there there's there was the first positive result. It was a breakthrough by Goyal and Gossami. So >> Okay. for people who are like Noga Gossami is incredibly gifted coding theorists, one of the like most celebrated the that I know like from the Gossami Sudan

algorithm among many many other things. I cannot understand how to understate how many of the contributions in coding theory come from this camp. And they what they showed is that actually for some specific of code and in fact for random linear codes mutual correlated agreements or the a strengthening of this batching property that I was talking about actually old almost up to capacity for this specific kind of codes. Okay. So these codes are all are also very related to Reed-Solomon codes. They are either like folded Reed-Solomon codes, univary multiplicity codes, or random linear codes. Uh Reed-Solomon codes

or random linear codes. Even these are like the more extravagant ones. Yeah. Like especially these random linear codes Reed-Solomon code is like I'm going to pick a Reed-Solomon code at random according to some procedure. >> And with high probability it will have good properties for us to to use. Mhm. So for these random codes I would be able to actually prove security up to very close to capacity. Okay. So this is still concretely the these are asymptotic results are still missing like a lot of things. We cannot use these random codes. Right. Like we wouldn't have an efficient snark from these random codes.

Exactly. And even the folded codes, which are explicit codes, we've run the numbers. It doesn't really seem like they end up like giving a practical benefits over just using the probable analysis for Reed-Solomon codes. But this is like the first analysis to my knowledge which actually manages to get beyond Johnson bound in any capacity for like for correlated agreement. Okay. So I guess there's still a lot of open questions in this area, right? There's still what kind of codes. We know that some codes go beyond the Johnson bound.

But not the ones we're using right now. But also the ones that go beyond so far not like as efficient as the ones we have. >> [gasps] >> So there's still like an open little area there, right? Right. Just if I can quickly open a parenthesis about the paper with mention before Jack of Iliben system of if someone is looking for small project even for students that are curious. This paper is full of Easter eggs for negative results. So there are like a lot of failure of correlation agreement for special primes or for it's like a lot of little examples that in my opinion can be extended a lot if someone can again like standard for special families of primes and stuff. There are like some weird corner cases and there are many

little corner cases. And in my opinion like if someone is looking for a nice little project to to spend a weekend is it's nice. Listen up people. Is this just like something you would do pen and paper or is this something you can do like numerical examples of and like I can code something up and try to find It's a mixture of that in my opinion. It's like it really like with a bit of help of of of course like Sage or Magma will will be better. Fair. So you guys also haven't mentioned so far but you've also co-authored a paper on the topic. It's not specifically about proximity gaps as far as I understood but like a special case.

That is used in Starks. Yeah basically like what do what do we did like we more focused on instances of Stark that are actually deployed. Now if you go back quickly on on how Stark was used in the past that in mind that they they share the fact that they were working over bigger primes or the field was like I don't know at the beginning Stark was using the same prime of a the size of like an elliptic curve so that I was really happy with that like 156 [laughter] bits I the primes are like nice. If you look like now the Starks that are used in in production they are like either 31 bits or 64 bits and you know for me at the beginning was like a bit mind-blowing that actually

you could work on this prime field and still be safe. But um What what do we notice with Giacomo and after we learned that we were not the first one that noticed this property is that the alias bound that before was mentioned by Giacomo basically like could be seen in the multi-faceted way namely like usually you work over over this small fields but you actually work over extension field because you know you need to you need to work over extension for example if you're working with the 31 bits prime you you want to to work on a six extension field fifth extension field and so on. Cuz we want our randomness to

be at least you know 128 bits exactly within more than one field element. Exactly so what the first thing that we notice is like that actually in this case there are multiple alias bound because basically the domain that you're working on is over the best field but you work over the extension field and basically like then you will have the multiple alias bound you have the Elias bound over the base field that is actually smaller than Elias bound over the extension field. Okay. So, you're still working uh on the code over extension field, but with the domain you sample over the base field.

And and basically what what happens there are having this multiple Elias bound, well, weird things can happen and uh Giacomo start to to to apply a bit of a more uh theoretical framework there and uh yeah, this this interesting results came came out. Maybe Giacomo I spend a few more words, but basically we've seen that there was about 10 bits degradation uh of security for a project they were using for example Stark over 31 bits. Okay. And one thing which is interesting to talk about is attack and which is also similar to the Christ and Stewart paper is that we're not really attacking the property I was talking about before and this property of like uh

um you know, batching claims. Yeah. If you do the security analysis for like world-like protocols, there's another term that shows up in the soundness analysis which is related to a very classical problem in coding theory which is the list size of a of a code. Mhm. So, basically this the question is like I have like a corrupted code word, so I have some fraction of the code which is corrupted. In how many ways can I complete this code word by replacing the the corrupted part to get like a uh to to get a valid code word. Right.

So, if I were to replace the errors with real symbols, how many how many valid code words would be possible? Essentially. Exactly. Okay. Exactly. And depending on how many fractions there are, like if the fraction is very small, there's just not much I can do to get a valid code word, so maybe there's only one single close code word. Mhm. But once my fraction increases, this is where you become in what's called the list decoding range. Then there's many way that I could complete this this code word. And so what our like paper shows apart is that for a lot of these marks, this error term which depend on the list size is inherent.

And in fact like as part of the proximity prize, we're going to have two problems. One of them is about bounding this mutual credit agreement property that I was talking about before. And the other one is about the you know, by now 60 years old problem of like list decoding of Reed-Solomon codes beyond Johnson bound. So we're going to have these two parts which are important and yeah, until the attack as Antonio was saying, we were using the the fact that the list size of the extension field code can be related to the list size of the base code.

And the Elias bound is like more effective in degrading security when the when the alphabet size in this case the field is small. And so for like practically deployed system, this ends up giving you like a better attack uh than before. Okay, so your paper describes a a concrete attack? Not concrete. So this is an information theoretical like let's say like it's an information theoretical way in which you can show that these protocols have less bits of security. Like it seems still plausible that like computationally it is unfeasible to find like satisfying an attack to again the protocol.

And I think it's a very interesting problem to to look at directly, but this definitely like degrades the security of the protocol from like being information theoretical to actually being computational. Mhm. Just to connect to the to the the first attack that Jack described at the beginning, for example, the growing attack. Yeah. You know, there they only had like three bits of security and the degradation here you have like additionally 10 basically, right? Mhm. And they also that one was not constructive. They would say, "Okay, there is this degradation." But there was not It's not was not a construct constructive attack. Say, "Okay, you you follow the steps." I see.

I have a very stupid question, which is if we had our system, we thought it was 128 bits, now you have a 3-bit attack, a 10-bit attack, we're still way above 100 bits of security. Why should I care? So there is this psychologically threshold Right. I mean, we in cryptography we are all Someone last time can from the this can from, but basically like we have this 128 psychologically threshold that we don't want to go under. Because if we start to say go under, say, "Okay, why 128 120 180?" When do you stop? So we really chose to have like 128 bits. I think the crypto theory world agreed that 128 bits

is the number we want to stay at. Right. I agree that if we are 125, it's not the end of the world. There's not really real attack. But if we really want to stay on this We want to call it psychological threshold, let's call it like this. And after all the series of attack, it's clear that we want to stay on the 128 bits probable security. So I think that at the moment people are gave up on the conjectural security because, you know, of all these things that happened, right? So And then they're like at a point when you're deploying like a very large system, like for example, Ethereum, and you might need to choose a set of parameters that you hope you will not have to change for like the next like, you know, maybe say 100 years.

Then you you like things that do not We probably cannot give you surprises. Mhm. And in this hash space, the security in the probable regime is like a very like uh attractive kind of like uh landscape in that you could I can put my foot down and say like look we understand these things well enough that they will not be an attack if I use it in the proven regime. So Okay. The these small attacks they kind of like shaking our conflict because before we also thought that in the conjecture regimes we understood things well enough but this turns out not to to be the case. Okay, so I guess that's the important part, right? Is we thought we knew things and then within a month a

lot of like security degradation was shown and So we can't be confident that we know things anymore. Is that mostly what it is? Right, indeed. Let me take the time to shield a tool that has been developed by the cryptography team at the yeah. And basically I developed this tool that we try to to compute the the soundness of the ZK VM projects that is called this tool is called Sound Calc. And basically at the at the beginning we were supporting conjectural cases. So we were actually the tool per se you could actually plug um some configuration and and having um and and I mean like the bits of security that are in the

in the conjectural case or at capacity or for Johnson bound or unique decoding. But now like after all these years of attack we actually don't support anymore the the conjectural case. We stay either the unique bound or on the Johnson bound. So and you know we don't we decided to give up completely on the conjectures at least like Sound Calc wise. So guys I think we're reaching kind of time. Um I didn't want it to I didn't want to end the episode with a question about what comes next. You know what questions are left open for the security of post-quantum SNARKs and even maybe for the proximity prize.

So this is a wonderful area. I could talk about this for a long time because I think there's a lot of super exciting questions regarding the security. Okay. I think we can like kind of split them into very different buckets. So, there's kind of like the overall security of Ash base and Stark in general. Yeah. So, this encompasses this question like for example, you know, Fish mirror security. Uh like if I compile something in the random oracle, what kind of guarantees can I get about the the overall snark?

So, there's been lot of progress on this. There's the security of recursion. This is incredibly interesting and important topic. There's This is like kind of security of like the compilation process of like taking like a an information theoretical tool like an IOP and then compiling it with Merkle trees. Mhm. Then there's the coding theoretic questions which I think there's also a lot uh to do like we in the proximity prize write up we're calling these things the grand challenge. So, there's the grand challenge is like really understanding for Reed-Solomon codes where does the phase transition happen? Where do we pass from somewhere where we can show security to somewhere where we have no proof showing security.

So, this is like the grand challenge but there's a lot of other interesting things. So, for example, there's you know, Reed-Solomon codes have been great but there's another beautiful families of code like Steelman codes or repeat accumulate accumulate codes. What kind of properties do they have for mutual credit agreement and uh list decoding? Mhm. Or what is it that they have even? This is also not particularly well understood. By the way, those are the codes used in breakdown and blaze, right? Exactly. Cool. Another question about the relation between primitives like uh list decoding and correlated agreement.

Mhm. Does one imply the other or not? Is there like we know from for example Christian Stuart and like the Ben-Sasson Carmon Escopartich Shur off and paper that there are some relations between the two but it is uh so for example, like proving MCAs seems to be as hard for a Solomon code as proving list decoding, which is a very well-studied question. Up to capacity, of course. Um, but we don't really have like nice clean understanding of what's the relation between the two.

So, these are also interesting questions. There is the question of like more positive energy generators. This is something that like Ale Z, Ignacio, and Sarah have been working on. There is this very nice paper by Crasoon and Kavenimean on trying to exploit some properties of like twadic fields to try to get like better attacks on MCA. There's a lot of very interesting like work which I think can be done. Like uh In a sense, there was a psychological barrier, as Antonio was saying in a in another context, that we couldn't we didn't have the tools to do anything beyond capacity, beyond the Johnson bound, sorry.

And now with this Flores paper, it showed that there's actually there's like a very like interesting and like deep area of research beyond Johnson bound um and close to capacity, where I think people can do progress. So, and these are very beautiful, they're very cute questions about polynomials. And right. I find it extremely fascinating that this is just like really just polynomials. So, you have plenty of work for the years to come. Um [laughter] from a status as well as well, like this is the field of hash-based proof system. I probably you already talked in previous episodes, but I mean, we we have a not new new hash function we are using everywhere. This is like Poseidon, Poseidon 2. And this is a really central

piece of the security of all the system. And yeah, we just put another million on actually the the security of Poseidon. That I think it's going to be exciting. Well, guys, thank you very much for coming on the show. It was a pleasure hosting you both. Thanks a lot, Miko. Thank you for inviting us. Always pleasure. I I to say thank you to the podcast team, Anna, Rachel, Henrik, Tanya, and Hector. To those of you catching us on video, thanks for watching. And to [music] our listeners, thanks for listening.