Episode 261: Proofs, Arguments, and ZKPs with Justin Thaler

Transcript

Welcome to Zero Knowledge. I'm your host, Anna Rose. In this podcast, 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 online. This week, I chat with Justin Thaler, associate professor at Georgetown and author of Proofs, Arguments, and Zero Knowledge. We chat about his academic background and what led him to working on interactive proofs and then on ZK-SNARKs. We then look at the book Proofs, Arguments, and Zero Knowledge, how it came to be, the ZK Hack study group that formed around it, and how

he's been developing this learning resource iteratively with the community. We discuss his earlier work on Spartan, how this implements his thinking about SNARKs, his work on the security of different rollups built with SNARKs and STARKs, and more. I hope you enjoy. And also, be sure to join his upcoming study group if you want to follow along with his next cohort going through his book all about zero knowledge proofs. You can find this over on the ZK Hack Discord. We've added the link to that in the show notes. I also want to quickly let you know about the upcoming ZK Summit 9. The event is happening on April 4th in Lisbon.

Join us for our ninth edition. There you'll find all the latest research and the most cutting-edge implementations of ZK tech. It's invite-only, and the application to attend is now open. I've added this as well in the show notes. Now, Tonya will share a little bit about this week's sponsors. Pairings, Baloo, CQ, Plonk, Pluck Up, Fluk Up, Hyper Plonk, BN254, BLS12381, Fry, Deep Fry, Deepest Fry, FFT, NTT, FHE, Goldilocks, univariate sum check, multivariate sum check, Pasta Curves, Tweddle D, Tweddle Factors, multiscalar multiplication, modular multiplication, LDE MLE Groth16 Marlin Poseidon Anemoi, Rescue, Reinforced Concrete,

Nova, Supernova, Bulletproofs, Halo 1, Halo 2, Halo 3. Now again, but faster. Check out ingonyama.com to learn more about zero-knowledge hardware acceleration. You can find the link in our show notes. So, thanks again, Ingonyama. Aleo is a new layer-one blockchain that achieves the programmability of Ethereum, the privacy of Zcash, and the scalability of a roll-up. If you're interested in building private applications, then check out Aleo's programming language called Leo. Leo enables non-cryptographers to harness the power of zkps to deploy decentralized exchanges, hidden information games, regulated stablecoins, and more. Visit developer.aleo.org to learn more. You can also participate

in Aleo's incentivized testnet 3 by downloading and running a snarkOS node. No sign-up is necessary to participate. For questions, join their Discord at aleo.org/discord. So, thanks again, Aleo. And now, here's our episode. Today, I'm here with Justin Thaler, who's an associate professor at Georgetown and is the author of the book Proofs, Arguments, and Zero Knowledge. Welcome to the show, Justin. Thanks for having me, Anna. Justin, I know you primarily through the ZK Hack Discord. There is a study group there called the Thaler Book Club, and as far as I can see, there's a group of people meeting often to discuss the book you wrote. This has been going on for a

while. I'm very excited to actually get a chance to speak with you and find out more about generally your work and also talk about that. Um we will get more into that study group soon, but I think as a starting point, I'd love to start off with learning a little bit about what got you interested in zero-knowledge tech, in this kind of cryptography. Yeah. So, right when I started my PhD, which I guess would have been in 2009, I was already interested like in in streaming algorithms. So, these are algorithms for processing like really massive data sets where you don't even want to store the whole data set cuz there's so much data. Um, and kind of through an accident, but also because I just thought these things called interactive proofs were really cool. I had encountered them in a in a

complexity theory class. I um started studying sort of the intersection of the two topics. So, there had just been some really recent work um kind of looking at basically what happens uh in an interactive proof if the the data uh being processed is so big that the verifier you want to be a streaming algorithm. So, not even to like store the the input to the computation. So, I started looking at at that topic and that sort of led uh you know, I it's it's a really cool topic. Never really on its own, I think, made like a big impact in practice. Uh but that kind of led me just to looking at interactive proofs in general, forget about the streaming verifier. And also around that time uh there was a really really important result called the GKR

protocol, um short for Goldwasser-Kilian-Rothblum. Just a really powerful interactive proof. Once I I heard about that protocol, uh which actually came from a reviewer of a one of our streaming papers, uh was like, "Hey, you should look at this. It's, you know, seems really general and powerful. Might be useful to you." Um I sat down to try to implement it thinking it would just be awful, right? Cuz the the prover in that protocol runs um in like cubic time um in the size of the computation being outsourced. So, something totally totally impractical. But it turned out that like by looking at these kind of very simple toy problems that the streaming people care about, um I had just kind of understood the techniques a good amount. Um so, when I sat down to implement the GKR

protocol, I realized like you can actually make the prover run in, you know, forget about cubic time. It can run in like nearly linear time. And that kind of makes the jump from totally impractical to practical. Um so, that was like my whole PhD was kind of trying to continue improving, um, especially on the prover time there. And it really didn't have anything to do with zero knowledge necessarily. Um, and then fast forward number years maybe to like 2016-ish. Um, and there was this paper called V SQL, which sounds like it's about databases.

Uh, but really like the key contribution there has nothing to do with databases. So it kind of it observes that you can kind of take these interactive proofs that I had, you know, spent my whole PhD thesis working on and combine them with, uh, cryptography. So what we now call polynomial commitment schemes and then you get a SNARK. Interesting. Right. So it turns out I I had sort of been working on SNARKs without realizing it for a long time. What actual field, this was a question as you're talking I was like, you weren't in cryptography. Was it math? Like what was the PhD department? Uh, yeah, so it was computer science, but like my, um, I thought of myself, I still sort of do as a as an algorithms and complexity theorist. And I've really picked up cryptography just as needed,

you know, um, over time, which is which is one reason I was eager to do things that ultimately turned into this this book, you know, proof arguments and zero knowledge. But to try to make it a little less painful for anyone else to with and not to pick up the cryptography that's needed in this line of work. Yeah. Interesting. You're saying 2016, this is around the time that you started to discover what would become SNARKs. Was SNARKs a thing? Did they already exist at that point? Like were they well known? Yeah, yeah. So SNARKs existed then. Um, they were well known, but the fact that like basically the deployed SNARKs at that point were really I mean I I don't know when Zcash like what year Zcash came out off the top of

my head. It was around then. So essentially what what people were using was what we now recognize as SNARKs from linear PCPs, which ultimately, you know, led to a growth 16 and very popular today. Yeah, I so okay, so maybe this is something interesting to to describe briefly. So the historical development of all these protocols are like like first people introduced interactive proofs actually in the same paper that the notion of zero knowledge was introduced which is just some like bizarre uh miracle of um ideas. But yeah, people didn't actually use like interactive proofs for zero knowledge until much later, I guess um uh in practice anyway. So it went interactive proofs, then multi-prover interactive proofs, then PCPs, then linear PCPs.

Okay, but in terms of actually deploying these things as SNARKs, it almost went in the reverse order um with the first ones coming from linear PCPs. And that sounds bizarre, but it's it's not a complete coincidence because the reason people started studying linear PCPs was exactly that we didn't have practical SNARKs from regular PCPs. Got it. So, you know, there's this great work of Ishai Kushilevitz and Ostrovsky that kind of uh started introducing these uh linear PCPs with the explicit goal of kind of getting more practical SNARKs. Um and you know, it did take some follow-up work after their paper to get to get it there, yeah.

Fascinating. In the last few years, when you talk about like the linear PCP to the regular PCP, do we use any other terms for that today? Yeah, we don't have practical SNARKs today from PCPs, but uh rather kind of a mix of interactive proofs and PCPs that people call IOPs. There you go. Okay, that's what I was wondering cuz like that the the the terms you just used are slightly familiar, but like I feel like we at least with this show, when we when I started to dive into it, like there you see the introduction of IOPs, and that's sort of the direction that people were going. Okay.

Yeah, yeah. So I thought I always thought like from very early on cuz I was working on interactive proofs, I was like, you know, you can always just remove the interaction with Fiat-Shamir. So we should really protocol designers should be using interaction as a resource that then the resource just sort of gets removed and you don't need it anymore. And at the same time, you know, other researchers were developing like the PCP approach. And I guess in the end it you know, it turns out like you need elements of both. Like everyone was right, no one was wrong, I guess. Nice. Okay, tell me like how at this point, so you've you've been I think in our story it's around 2016.

Yeah, what work are you doing then? What what kind of thing? Like I know the book, I mean I'd be really curious to hear when the book writing starts because we by the time we did CK Hack 2021 the book existed. Yeah. So, yeah, tell me when that happens. Yeah, so I guess those are two slightly different questions. So, with the research, there are two things to say. So, one is So, I've been working on two things between 2013 when I finished my PhD, which was all on interactive proofs, and 2016. So, I was working continuing to work on interactive proofs. And there was some work on implementing these things in hardware and and stuff like that. So, applications that don't require zero knowledge or blockchains or anything like that. And I had also done some work

on multi-prover interactive proofs. And the idea there is I don't know, you might have two computer chips acting as the prover, but they were manufactured in some foundry you don't trust, but it's like a state-of-the-art foundry. So, they're very fast, but they're not trusted. And you might actually be able to like power down, you know, one of the chips so that the provers can't talk to each other. Um and therefore like the the idea that there are these two non-communicating provers actually kind of makes sense in the in the real world. So, that's that's kind of where I was in 2015. Um and then this V sequel paper came out. John Cat, Yuping Zhang, Babis, and some others that kind of had the key inside. This was before, you know, what while, you know, Kate KZG commitments already existed, people didn't really

appreciate this notion of a polynomial commitment scheme yet, but I know Babis had some early work on, you know, extending KZG commitments to multi-linear polynomials and had like kind of exactly the right confluence of knowledge to be like, hey, there here's this key inside like you can just combine interactive proofs with these polynomial commitment schemes we already have and you can get a snark. With that key inside, you know, I realized, oh, we're you know, we've all been working on snarks this whole time and yeah, that's how from then on, you know, my I started studying polynomial commitments in addition to just the interactive proofs and and multi-prover interactive proofs.

It turns out like the multi-prover interactive proofs we had designed like the second prover was literally just acting as a polynomial commitment scheme so you can just cut out the second prover and that that sort of observation sort of led to this work called Spartan which maybe you've heard of. As far as the book goes, so that kind of started with a workshop in 2015, I guess in Barbados. There's a McGill runs runs workshops in cryptography there every year. McGill like Montreal McGill?

Mhm. Yeah. That's my alma mater. Cool. Oh great. Not in math but yeah. But why would they do it in Barbados? That's such a random Oh, okay. So this is the story I've heard. Well, basically somebody donated This is the story I've heard. Well, basically somebody donated a property down there and that I mean that's the short version. So you know, it's in this beautiful location. I think they actually wound up selling part of the property so they just like beautiful luxury hotel right next to this like kind of spare sort of housing for the workshop participants but it's just a wonderful environment. Everyone's kind of there and offline and sitting outside at a whiteboard for the week.

So yeah, I like threw together these notes for this like five-day workshop and then you know, kind of just left them for a couple years until I started at Georgetown and started teaching some classes and started you know, built on the notes. At some point I like threw the notes online and didn't tell anyone about them cuz they were still kind of an embarrassing shape and you know, some people stumbled on them and I got some good feedback and then but where things really like people I guess discovered them as as useful was through ZK-HACK which I guess was a little over a year ago.

Oh, nice. It wasn't like you were presenting this is like finished work like this is my textbook but rather this is a collection and almost a starting point. Yeah, I think so. And the area was just moving so fast by the time you know, 2016 came around and I expanded the notes enough that I'd even think about putting them out in public. And even so I guess recently I did formally publish the monograph in Foundations and Trends in Security and Privacy but I you know, still consider the thing to be you know, quite rough and a living document and will just keep you know, maintaining it and years from now I hope to put out you know, some second version or so it'll just sort of

gradually move in the yeah, as things develop I hope. Yeah, I mean I wanted to ask you about that because I had spoken so the person at ZK-HACK one back in 2021 it was Alessandro Chiesa I believe in his intro presentation or one of it's either Alessandro or one of his students actually who were presenting and people were asking sort of like what are great resources to start he had mentioned your book he had called it the tailor book and we call it the tailor book we understood it as like a finished product but at the same time I had actually spoken to Alessandro about the challenges of writing a textbook at this moment because there were the and maybe still are a lot of kind of parts of this that are changing really quickly and

even like the common knowledge of 2017 on how to do this is quite different from the common knowledge of today, but not not progressively different. Like there might have been almost like backtracks or rethinks or revamps. And so, how do you teach that? How do you write it down? How do you print it? Becomes kind of a hard question to answer. So yeah, like which parts would you say have been consistent? Like do you think there's parts of what you put together that are like, "Yeah, these parts seem to be like standardizing and becoming quite firm." Or do you feel like all parts are kind of up for grabs to change?

This is a little bit of a hard question to answer, right? I I think that the the general kind of organization and presentation of you know, like all all SNARKs having an information theoretic component and a cryptographic component that looks a lot like a polynomial commitment scheme and you put them together and you get your your you know, succinct argument and apply Fiat-Shamir. I think that is pretty stable. Mhm. And at this point, it's largely the details that are changing. And there's been you know, so I've done a a lot of kind of forcing into the exposition like the latest update. And it hasn't felt that hard.

Okay. You know, it's like you know, I can go to a chapter and like just append to that chapter. Like here there's there's more developments. The most recent sort of thing I added just roughly when Nova came out, I guess is a chapter on a recursive SNARK composition. That line of work started with Halo. Maybe that's 2020. Yeah, the Halo one. Yeah. Um And then, wait, wasn't it like Halo one Plonky? Then it was Halo 2. And I think these are similar, right? Like there's a line between them. There's like sort of progress there.

And now, I mean, a lot of teams are using Halo 2. I know that they're like some of the decisions in that have started to like come into everybody's system. Yeah, and and a lot of the benefit of Halo 2 as a system, my understanding is is not necessarily through support for recursion, but it's just a nice also sort of standalone SNARK as kind of, you know, the Plonk polynomial IOP plus either like the Bulletproofs IPA polynomial commitment or the codebase also supports KZG, which is just literally kind of Plonk. Um So, I think you you roughly had the right um trajectory there.

Um yeah, so I'd say I guess the history for recursive SNARKs, at least, you know, as I'm aware of it and sort of covered in the in the monograph, is, you know, you can go back at least as far as uh the Cycles of Elliptic Curves paper, Scalable Zero Knowledge via Cycles of Elliptic Curves. Um like that was studying SNARK composition, but like kind of what people quote full SNARK composition, where you take the whole SNARK verifier, uh you kind of represent it as a circuit, and then the prover proves that it like, you know, knows a satisfying assignment to that circuit. Yeah, so, you know, going all the way back to that was like 2013 or something, you could have like a short chapter on like recursive composition of SNARKs, um you know, with with an

implementation out there. But then the Halo line of work sort of um wound up, in a sense, I I'd say getting SNARK composition without full SNARK composition. If uh that's kind of an incomprehensible statement, but, you know um yeah. Are there moments though where you almost have like breaking changes? Where like some new paradigm comes in and you it sort of means some of the previous research or like in a textbook context it'd be like something you've learned is now going to be thrown out a little bit. Like, oh, we've learned exactly how to, you know, optimize an R1CS, and now we're maybe going to use a very different kind of setup. I know that maybe is a bad example cuz I know people are still using it, but like has there been any sort of like lost work or work that's

kind of going to be pushed aside? Mhm. great question. I haven't really encountered that yet. I've been mostly able to handle things via like addition only, if you will. So like you know, for a long time I only discussed arithmetic circuits, then I added in R1CS in like a very haphazard way where like in the chapter Yeah, so like in the chapter on multi-prover interactive proofs that's where I introduce R1CS which is like a weird place to put it in, but and what happened there was Spartan came out and you know, was kind of extended like sort of the old MIPS I had been working on for example to handle R1CS and like oh now I better put in like the R1CS

presentation and also by sort of generalizing sometimes things get simpler when you when they actually become more general and I think Spartan's a great case of that where I think describing the protocol is actually becomes especially the making the prover linear time. It actually is simpler when the protocol is general enough to handle R1CS. And then I've also added discussion at various places in the book of roughly what is you know these even newer intermediate representations like Plonk-ish arithmetization and Air isn't necessarily newer, but Air is another example. So I've I've been handling everything by addition so far.

I haven't I don't think I've cut anything. You just mentioned I want to come back to this actually, but you are mentioning Spartan. I don't know that we've covered it. I'm trying to place where that is in sort of the research steps. Like at what point what other kind of contemporary works were published around the same time that would maybe help me just time frame wise. Okay, yeah, so timeline Spartan is roughly contemporaneous with Plonk and Marlin. Okay, so this is 2019 I guess. This is like the Snark Yeah, yeah, yeah, Spartan has like a 2020 timestamp on it, but you know, some early version I think was when these things are coming out. Okay.

That's roughly right, yeah. Yeah, so so Plonk and Marlin are both based on what I call constant rounds polynomial IOPs, okay, which is an information theoretic protocol that if you kind of combine with KZG polynomial commitments will get you like a a SNARK of constant length, constant number of group elements. And the universal trusted setup, which was like the main That's the big sell. Yeah, of Marlin and Marlin and Plonk. And then Spartan, because it is the sum-check protocol, unless you start bringing in SNARK composition, right, you will you will not get proofs below logarithmic size, right? So it's never going to get down to constant. All of these works have very nice technical

insights to ensure that they can handle like totally unstructured circuits. Mhm. They don't require like uniform circuits with you know repeated structure or the same little computation repeated over and over again that that that's not required for these protocols and they can do this with sort of a preprocessing phase wherein the prover runs in linear time or close to linear time and that that is actually quite complicated to achieve and all three works sort of under the hood they they have that in there.

Okay, is Spartan also a universal does it need a universal trust set or have a universal trusted setup? So it doesn't require any trusted setup at all. Okay. So it's just if you use a transparent polynomial commitment scheme it's just it's just transparent. And the way I would put it is if you have a circuit or R1CS whatever with repeated structure, it also requires no preprocessing period. If your circuit just is completely unstructured like even writing down a description of the circuit takes you know like the description size is like the circuit size just totally unstructured. It can have like a transparent setup so just like preprocessing so no no like trapdoor that needs to be discarded. Um that's

linear in the size of the circuit. Was there any work that followed it that sort of built on it? Yeah, there's there are a bunch of things now. So, examples include um Quarks, Breakdown, Orion, um and basically these are more or less just substituting different polynomial commitment schemes into Spartan to get different um performance profiles. Interesting. We were talking before this sort of like we we've veered off into Spartan, but I kind of want to go back to the book. I know you don't call it a book, you call it a monograph, is that what you say?

Monograph, I don't know. We can call it a book now. Yeah, at this point. a book now. Okay. I want to bring up a recent tweet because I wonder if this is one of those examples that I was trying to find where like in optimizing in some directions, could you actually be undermining other sort of teams' strategies for optimization? And so this the tweet that I'm mentioning is actually Maybe you can help me explain this. It has to do with Hyperplonk and hardware acceleration. So, tell me a little bit the dilemma here.

Right. Okay, so um Hyperplonk is a new um sum-check based SNARK for uh I guess what people call a Plonkish intermediate representation. Um it's kind of a generalization to circuits that um has a nice uh combination of expressivity and now, you know, good backends for it, whether it's Plonk or Hyperplonk. And whereas uh Plonk is not based on um the sum-check protocol, which is some, you know, like multi-round um protocol, Hyperplonk is. Mhm.

And uh there was a nice blog post by Ingonyama, um a company uh focused on hardware, sort of exploring issues uh like comparative issues in hardware. I It's not even necessarily, you know, hardware specific, but just in implementations of the various protocols. Um so, basically, Plonk is a constant-round protocol that you then apply Fiat-Shamir to to make a non-interactive. So, you you get a, you know, SNARKs in non-interactive thing. Um yeah Fiat-Shamir ultimately Well, it's it's only constant-round. So, uh whereas uh the SumCheck protocol is is logarithmically many rounds um in the context of, you know, the size of the circuit or what

have you. So, the the key issue kind of raised was maybe uh there's kind of the prover cannot start working on round two until it knows what message it needs to send in round one. I see. So, it was raising this as a potential bottleneck for when you apply Fiat-Shamir to many-round protocols instead of like one one or two-round protocols, essentially. So, it's basically like in the case of Plonk plus Fiat-Shamir, hardware acceleration is possible because it's very consistent, and the minute you use the SumCheck, it becomes less consistent, and therefore the hardware acceleration efforts would somehow be lost, or does it even like does it undermine the performance if you

try to optimize hardware? I think the the question is always what is the bottleneck in the prover implementation, and if we're developing special-purpose hardware to implement the prover, you know, you have to be very aware of, you know, bottlenecks in hardware implementations in particular, right? Okay, what one nice thing about SumCheck-based techniques, I guess these are still the only techniques known that avoid FFTs for the prover. Anywhere, the FFTs come up fast Fourier transforms, they come up for the prover in um for multiple reasons. Uh basically, what one can be um like if you're using FRI as your polynomial commitment scheme, the prover has to do FFTs to like evaluate a polynomial on many different points. Um

but also Plonk, which doesn't necessarily use Fry as a polynomial commitment scheme, it uses KZG, FFTs come up there too because of dividing large large polynomials. And if you use SumCheck instead, uh you can avoid those FFTs. So so this this blog post from Ingoyama was specifically focused on FFTs as a possible bottleneck versus SumCheck as a possible bottleneck. Um now, you know, asymptotically speaking, FFTs are super linear time. It's like n log n time. And and the SumCheck prover um can be implemented in linear time.

Um so the question becomes like well, what's the bottle You know, what's actually worse? Is like n log n time in practice actually worse than like linear time, but you have like more rounds you're applying Fiat-Shamir to? There was discussion about about that. And then there was additional discussion because a lot of the projects that are especially if they're heavily focused on recursive SNARK composition and proof aggregation, they kind of never apply a monolithic SNARK to very big circuits, right? So they might like break a giant circuit up into many many many small circuits.

And then do recursion of them after the fact. Exactly. And in that setting, you'll never apply an FFT to a vector that's particularly big. Mhm. So so these teams sort of, you know, have this view, which I think is is quite reasonable, although I you know, I there counterpoints to be made um which uh I did try to you know, convey my own you know, perspective of counterpoints. Um which is, you know, FFTs really only become like a bottleneck when things get really big and like maybe through recursion, we'll just never have to uh uh apply them to really big things ever.

Mhm. You're not working in hardware right now, are you? Not not actively, yeah. Um you you years ago, there was some work, which is something I mentioned on Twitter, where on hardware implementations of some check based just actually interact to prove so it was before you know they were used to make snarks. Through that work I know I know what the bottlenecks you know for the prover were in hardware through that work. Mhm. Yeah. I feel like though this is like I'm due to do a hardware one. It's a hot topic. Yeah, it'd be great to to hear more. Yeah. And I know that there's a number of teams that have actually pushed that forward. But one of the questions I've always had about this and this kind of goes back this this is it's an interesting theme both through your tech like creating educational material as

well as investing in hardware acceleration where it's like how standardized are the techniques? How decided is the industry as to which of these strategies are they going to focus on? And I know I do realize like there are trade-offs so some use cases might be better suited for some of these things. But if you are investing in hardware which starts to become like a pretty significant cost, are we as an industry or as a as a field ready for that? Because you know once you start stamping these things out like they're harder to adjust I guess. Right. I mean yeah, I'm happy to you know share my own personal thoughts which are not necessarily you know that informed you know at the hardware level which I'll do a full episode eventually so

we'll get some other people to weigh in too. So for the prover anyway like in every snark like out there you know there's only a handful of of bottlenecks typically right which is either a multi-exponentiation um an FFT Merkle hashing or field operations that are not coming from an FFT. Okay, so which is a bottleneck depends on you know which polynomial IOP you're using which polynomial commitments can be using and how big is the circuit you're dealing with.

The fact that there's such a small handful of bottlenecks like sounds good like let's just design hardware like to handle each of these things and but I do think there are still significant moving pieces in terms of like what what hash functions we're going to use to build these miracle trees, what what fields we're going to work over, what cryptographic groups we're going to use. And in order to build hardware for this stuff, presumably you have to fix a choice of that. So I do worry that if these choices are still in flux, you know, as particularly with ASICs, right, which have my understanding is it takes a while to build them and like, you know, things can shift under your feet as you're building them.

That is my personal sort of high-level take on on the space at the at the moment. Interesting. Did you dive into hash functions in the book? No. So there is discussion in various places of SNARK-friendly hash functions. And I mean but basically just saying, "Hey, like There's a black box. It it exists. Okay, okay. Right. You know, there are hash functions that we believe are, you know, collision resistant or act like a random oracle and that are, you know, turn into smaller circuits than, you know, your standard off-the-shelf ones. Um Yeah.

In what you're doing, do you have a focus on this is actually just a general backstory There's a question more on your backstory, but like have you had a focus on security? Has that come up for you? Or do you feel like that's sort of a separate part of this ecosystem from what you're working on? Yeah. I mean so security is intrinsically connected to performance because that, you know, the tension between the two. I mean they're like essentially always in tension to some degree. That tension different projects might make different choices about where to where to be in that spectrum. So I have started looking at sort of security more carefully, concrete security in particular. I got into this because I was preparing a survey talk on on rollups this summer. I was visiting

a16z. So I was I was looking at what various projects are are doing today. And it was a really interesting learning experience that kind of let let me both to there are some interesting questions there and also just important conversations I think for the community to have. So I started trying to you know bring these issues up into into conversation. So I can I can elaborate on on that a bit if you'd like. Go for it. Yeah, tell me about that. So you know there I guess these issues today are particularly prominent in in snarks that use fry. Like that's the deploy those are the deployed snarks where this tension between performance

and security is particularly strong. And so it's natural then that that's where you might see projects you know kind of choosing to be a little more aggressive on the performance side of things. And when you say tension do you mean like kind of they're on either side of a of a spectrum? Like is it sort of you are going to get great performance but less great security or vice versa? Is that what you mean? Yeah, the the simplest way of thinking about things is just there there's a direct tension between verification cost and security level. So I'll elaborate a little bit on there's actually kind of a three-dimensional spectrum between like prover time and verification cost and security level.

Roughly speaking like the the bigger the proof the you know more bits of security you have that is the sort of more computational effort should be required to kind of produce a convincing proof of a false statement. And you know in in practice you know verification cost translate to gas cost you know if these things are deployed on ethereum say you know so like every blockchain node in the world has to like run the snark verifier. So you know you can reduce those gas costs by sort of getting more aggressive with the security.

And you know there are ways to kind of push verifier cost onto the prover whether it's through recursion or something called the fry blow up factor is another way you could do it. But basically, if you kind of fix the you know how you're treating the prover, there you know, it's the tension is directly between verification cost and and security. So, when I when I kind of sat down to look at what the various projects were doing, there were two things that I was a little bit surprised by. So, what one is like not at all project specific, which is it's just really hard to figure out what the you know, a lot of the projects are doing.

Ooh. Just like documentation and how clear they are with like open sourcing some of the stuff? Yeah. And you know, it also this makes sense like the focus on building things and you know, as long as you know, they're they're comfortable, they're not going to get you know, owned or something like maybe that's enough for today. But yeah, so you know, it turns out like a lot of these things are kind of the specs are either academic papers or just the the code. You know, whether it's solidity contract or something.

And maybe that code is accompanied by like a short white paper that's short on details or something. And then with with fry based on arcs in particular, how secure they are is like not necessarily hard coded into the code. It's kind of a parameter that's like passed to the smart contract or something. So, that means you might have to actually go like on chain to actually just see what is the security level. So, there is like a whole lot of of this I was discovering. And then another thing I I discovered was just like talking to people in the ecosystem who like work on this stuff is just not that many people are aware of what a lot of the projects are doing.

And in some cases actually had like the you know, were mistaken about what other other projects were doing. And and just you know, general like the security properties of fry are like somewhat complicated to describe. So, you kind of put all this together and I thought that there should be some discussion about that. And you know, like the the way I thought going into this you know things were supposed to happen is you know these verifiers like they live on chain anyone can inspect them and that's why we have confidence like we don't the whole point is like you don't want to have to trust anyone including like whoever wrote that smart contract right?

So I thought I kind of thought that there it should be well known what these smart contracts are doing and like how secure are they and it seemed basically just to not be. So I thought it was important to have a discussion that what happened in the open. Are you talking about a lot of these systems that are still sort of on testnet? Are they start like are they only partially rolled out? Could that be one of the reasons why it's not as clear or would that be maybe something that the teams would would say are the reasons? Yeah so a lot of these fry based projects are still in testnet as my understanding so like Plonky2 you know risk zero you I know that you go to their website and you know there's like you know no guarantees yet that you know things haven't been audited or whatever.

So StarkWare is is deployed so that was one that I was you know kind of able to look on chain at. And they they have posted a whole bunch of materials in like a GitHub which was very helpful and and things like that. But when I saw the security level that was being used in StarkWare's deployed systems I didn't feel it was high enough so I sort of tried to explain why why I felt that way. And more generally just explain like what's happening cuz again it's like complicated to just describe all the intricacies. They recently announced on Twitter that they in the next the next time they update the system they'll move up from 80 bits to 96 bits of security which I think is great. Yeah so there was also some some discussion that I saw on Twitter

between StarkWare and Matt Matt Green who's a faculty at Hopkins. There was discussion about training wheels for the rollups so this is I guess that there's a Vitalik blog post that describes kind of levels of training wheels. Um and I think that the upshot is that all of the the rollups um that are deployed today um are still on training wheels. Um and what that essentially means is they're they're permissioned. Yeah. So, only only the rollup provider or essentially can update the state of the system. Um So, may maybe anyone can submit proofs, but the proofs basically don't do anything because only the rollup provider can update the state of system.

And you know, there might be you know, with StarkEx maybe there's um you know, they've they've moved one stage up in the training wheels. Um And I guess the point I wanted that might be worth raising just the the following. So, if things are uh permissioned, it might be more reasonable to have um a security level whereby the basically proofs can be forged. Mhm. You know, my main concern is uh in terms of raising this conversation is to make sure that the security level is high enough that either it's infeasible to forge proofs or at least it would be like more expensive than what it would cost to just attack the L1.

Mhm. Um you know, to acquire like enough stake to just like attack Ethereum's proof of stake directly or something. Um and I I don't think 80 bits is is at that level, which is why I was raising the the issue. Um and and 80 bits by the way can mean multiple things. And so, I've tried to explain exactly what it means in this context. Even with the permissioning, if the if the rollup is really protected via permissioning, Okay. I still think it's important that uh proofs be unforgable uh for two reasons. Okay. So, so one is um maybe a slightly paranoid, but I think still worth worrying about, which is um if if the rollup provider's keys get compromised, then somebody can act as the rollup provider and advance the

state of system. And if the the proofs are forgeable, then you know, they can they can prove anything they want essentially. These keys must be hot because the roller providers are posting proofs multiple times a day or whatever, right? So, you know, it's not maybe that likely a compromise, but like it in centralized exchanges, I guess like best practice is to make use of cold wallets, right? Exactly because if something's hot then you can't fully protect it from hacking like ever. So, I think even in permission settings while the training wheels are on, we still want these proofs to not be forgeable. Got it.

Um yeah, so one other comment I wanted to make is is just like since like especially since FTX um I think rollups have been correctly you know, kind of contrasting themselves, you know, as uh to something like FTX as as self-custodial. Mhm. And if if the system is really protected by uh permissioning Then right? Like self-cus- Is it you know, that you you do have to trust the roller provider not to uh forge proofs, right? It's protected by the permissioning, so. That's interesting. So, here I mean in the original question it was about security. And what I'm hearing here is there's like the two forms. One is like the actual proof creation security when this is where you're saying like it could be forgeable versus the permission

or permissionlessness. The idea of a decentralized byzantine sequencer is like the bridge, the thing that connects the rollup to the actual main chain. If that's permissioned, then that is also like a security it's a centralizing force that could potentially be a security issue. Is that is that correct? Yes, I it's not the centralization of the sequencer that's critical. I think that's important for censorship resistance. Okay. You know, the so the sequencer kind of decides like what transactions get proved. Mhm.

Um and so if it just like refuses to include Anna's transactions, then you can't And being censored. Yeah, yeah. Um so this this is about kind of centralization of proof submission, um which is so it's protecting the state of the roll up from attackers. There are two ways to that you could do that. Okay, so so one is to make the proofs unforgeable. So nobody can like, you know, act like, you know, Anna transferred her funds to me when she didn't.

Mhm. Or it can be protected by permissioning which says like well only the roll up provider can submit proofs and as long as the roll up provider isn't trying to steal from its own customers or something like it doesn't matter. And the training wheels mean it's permissioning. Yeah, yeah, okay. So this there's two kinds of permissioning. There's permission sequencers or like one sequencer that's centralized or the actual creation of the proofs plus that often like paired with a transaction. I guess that's sort of what you're describing here or like The thing is aren't they usually like batches that are then there's a proof attached to a batch.

So like could someone actually exclude or like change the actual transaction in the batch? I realize they all have different settings and maybe not all of them use this technique, but yeah. Yeah, so I think that the proofs protect against somebody kind of putting a transaction in the batch that like never existed. Mhm. You know, basically you prove you know like a a digital signature from from Anna. So Anna must have really authorized this transaction. Yeah, so they're protecting against like fake transactions which is like how you can steal money, right? You say someone whereas a separate concern is is censorship resistance which is not fake transactions, but just

like refusing to put real transactions, you know, have them be processed. I see. I see. So the FTX comparison then would be something like I mean these bodies still have seemingly like quite a lot of power. So to compare themselves as like the antithesis of FTX is maybe a step too far at this stage, right? Like they're not there yet. There's a firm distinction I think between like 80 bits and and 100 bits, right? And the distinction is somewhere between that level, forging proofs really becomes truly infeasible, you know, with like current known attacks.

So, 96, this move that StarkWare proposed, does that solve it? So, okay, so here's my personal take on like what is correct security level, I guess. Um 96 bits of security, you know, the way FRI-based projects tend to be using that means there there are certain conjectures, they're basically assuming known attacks on FRI are optimal when they and and you know, in order to succeed with probability close to one, you need to do like two to the 96 hash evaluations to find a convincing proof of a false statement. Yeah, so somewhere between like two to the 80 and and two to the 100, really that that number of hash evaluations like truly becomes infeasible today. I was doing um So, like the Bitcoin network, according to my calculations, which hopefully I

didn't mess up, does like two to the 80 hashes every hour or so today. So, just to give you a sense of what might be feasible and what isn't. Now, that that you know, that their hash function is not what's securing these FRI-based SNARKs today, but yeah, just with enough investment in ASICs or something like we could do two to the 80 like every hour, you know, I mean, it's an insane investment in ASICs, but you get the idea. And so so here here's my take on on security, right? Like the accepted cryptographic practice is really 128 bits is you know, so like SHA-256 256 means it's giving you 128 bits of security. And you know, I don't think 100 bits is attackable, but you know, like the someone could come up with a better attack or you know, who who

knows. Um so, I I do think when projects choose the 100-bit level, you know, I'm not worried that they're going to be attacked, you know, today, but my personal take is they they are still like not following standard cryptographic process or like practice, Um and sort of just signaling that performance is like a priority over over security, I mean, is my personal take. So, the main reason I raised this discussion is to ensure that the security is high enough that it's really you are inheriting the security of L1 by using the SNARK according to known attacks.

But even at like 100 bits, I'm not worried about the known attacks, but you know, I feel like um you know, kind of long-term, it might just be, you know, healthier for the ecosystem to kind of signal like a real focus on security rather than eking out like that last little bit of performance that you can eke out. Mhm. It is trippy. When you're the builder of these things, they're definitely like you're you're the voice from the it should be the proof it should be more secure and there's probably others who are like, "This thing's too slow. Make it fast. It has to go faster." Yeah, okay. Or cheaper, yeah.

Yeah, exactly. So, I'm not I'm not out there building it, so it's very easy for me to say this stuff, but you know, I do I do find the messaging between like, you know, the performance is is great, and and also like, you know, we can always just get more GPUs and push the the cost onto the prover and like they're they're almost costless, so don't worry about performance. It's just like a little bit of a discordance with, you know, then having the security level like a little bit aggressive. So, anyway, there are lots of roles to be played to keep the ecosystem healthy, so I'm happy to play one and the builders will play another, and yeah.

It's funny. I like Kobe and I actually just went on the Epicenter podcast as guests. I went to the other side. That was fun. Um but one of the questions that Frederico was asking us was about which of the rollups is best. Which of the ZK rollups is best? And like we were like, "Oh, we don't know." And I'm curious now that you've done this research, would you have a preferred? Do you think there's one that is doing better? No, I don't I don't have strong feelings on this. I think you know, there's a lot to roll ups besides just like the the snark being used a a lot.

And there's a lot of innovation happening on those like non-snark related aspects of of the roll up. So censorship resistance is like basically unrelated to you know, security of the snark and the developers that are building on the L2, you know, like the community. All these things are are probably even more important than how performative the snark is. And like I have expertise in one like very very narrow Yeah yeah yeah. topic. Yeah, so no, I don't have Cuz there's like the tooling and the language and all of these things that would come along with it.

That's cool. When yeah, when making that decision. So I just want to bring it back to the study group. There has been a failure book club study group that's run twice now. There was one that started as mentioned right during ZK Hack 1, which was 2021. And I could see that running I mean, I wasn't in it. So for me it's like I've been, you know, I see the chats, I know that there's meetings, but yet I know a few people who are part of that. Gerste for example has like we've done an interview about like how useful that first She was she was part of the one that was like six people, the really small first one. And I know when there was an announcement to do a second one, there was a lot of interest in that.

Tell me about the experience. Like you I guess at some point discovered that people were doing this study group all about your the work you had put together. So yeah, what was that like? So I think Thor reached out to me and and told me about the study group pretty early on in the first one. So I think they basically just started over when I once I joined. Um and even the second one, I think you know, a big crowd showed up for for the very beginning and then it's it's kind of down to like the same kind of you know six seven person size Yeah.

again. But it's interesting who that six and seven person group is because those people tend to move go on to like you know work in the industry quite quickly. So it's it's a cool exercise I think in in seeing who goes through it. Yeah, and this is one you know I kind of wrote the book the the book was just like a series of brain dumps that kind of got improved over time. So it was kind of written for kind of for my myself or something. So it's a certain level and yeah, I do think a a lot of people you know start start reading it and are like oh I would benefit from uh you know some less detailed reading first and yeah, so the those

that have have stuck with it um I guess the fact that they've stuck with it means they've they've felt it it it was a useful resource and it is very detailed. So I would hope that then they'd be able to dive into building and so forth. What did you get out of doing this? Like why why would you cuz you were at a lot of the sessions and what is it like to go through it with this group of people learning? Yeah, so it's a it's a wonderful experience and I mean I I view it selfish for me because um it's just night and day how much I think the presentation has improved by just getting like continuous feedback on like kind of what wasn't clear what could use what people are interested in you know kind of more detail on

whether it was clear or not. Yeah, the book would just not be anywhere close to as as useful or sort of polished as it is today and still not very polished without that. Um and it's also just an enjoyable to interact with a group of of people who are you know this intelligent and just excited about the material. It's really been a unique experience for me in that regard. Do you think you might do another one cuz I know you've you're sort of getting to the end of the second one as far as I can see. No, I'll definitely I'll definitely do it. Um you know, I I think I'll definitely do at least one more and you know, unless I just get like way too busy for some reason, I'd be happy to literally just do this ad nauseam because again, I view the book as a

living document and it'll just kind of keep getting better. Uh I I hope. Yeah. I do wonder if this is like the new way to learn. A lot of the people learning with you are I mean, they're they're on a Discord server. They're some of them are anonymous. So, it's like it really is it's not like a class. It's there's no barrier. There's no like block. People can join or leave. But yes, it's it's really nice to see this happen. And it's what the Thaler study club has done actually has inspired a number of other study clubs. We've been running one around the whiteboard series. We want to do a lot of these. There's I mean, I know there's been talk of the Moon Math Manual maybe having a study group as well. Have you seen that by the way? Did you ever have

a look at the Moon Math Manual? Uh I haven't. So, I I definitely should which maybe um that's maybe that's exactly the thing to point people to um as kind of a precursor. Yeah. Well, I wanted to ask you the question that so many people ask when they join for example, the ZK Hack Discord or like first joining one of the events that we're doing and that is what should people know or do research on or read up on before they start to explore some of the ZK topics that you cover? I think that uh the only technical topics um that are really required by some comfort um with is is finite fields and elliptic curve groups and

with elliptic curve groups actually fairly recently based on latest feedback, I did try to put some self-contained discussion of that in the book, but like very very brief. I think a lot of a lot of readers particularly um engineers like you know, don't feel like they they understand something until they dive into the weeds. And so, like, with elliptic curve groups, like, you really can largely black box them um and understand like just a, you know, hand- like a paragraph or two. Um and like basically that like a curve element is like two finite field elements and um like that, you know, the base field and the scalar field are different things.

And like literally that's about it. And that's what I tried to put in the book. But I think people, you know, might feel more comfortable with a more in-depth analysis of that. And then finite fields you do really need to be comfortable with at least like, you know, what what is like addition and multiplication modulo a prime, right? Um And so, for elliptic curve groups, there is a uh kind of a a couple blog posts that I think are really great. Um there's like a gentle introduction and like an overview of um BLS12-381, which is a pairing-friendly curve that's very popular today. And for for fields, um there's like a really nice book which it kind of in the spirit of of mine is just kind of been online forever uh by uh Dan Boneh and Victor Shoup. And it has a nice appendix on finite fields. So,

that's what I started the combination of um you know, those three sources, and they're nicely all online, is what I started pointing people to. Yeah. Fantastic. I will for sure get these from you and put them in our show notes. Um and maybe we can even pin them in the group or something so that people can easily find that. So, I want to hear, given the work you've been now doing in this space for many years, what's exciting? Like, do you focus primarily on still the deep research or there use cases, maybe at a higher level that are starting to emerge that get you really excited?

There is a lot of room for major performance progress still even after all these years of um you know, significant effort devoted to it. Now, I have a I have a funny view. I think this goes back to the Twitter discussion recently of different perspectives um based on projects using recursive composition very heavily versus maybe my own where I have not focused on recursive composition in my own work. As a historical viewpoint on recursive composition, you know, this it was originally introduced almost as a way to take like a crappy snark and make it less crappy.

It's like if if the runtime of the prover is you know, super linear in the size of the circuit you now you don't want to apply it to a giant circuit, right? Because you know, the cost for the prover just kind of get worse and worse and worse in the sense compared to just like evaluating the circuit. So the idea is you break the computation down into like tiny circuits and just apply the the snark to each tiny circuit. And from that point of view I guess it seems clear that you know, there are two ways to make improvements even if you are going to use recursion. So there's like the crappy snark which I shouldn't call the crappy snark but you know, so there's that the base snark that you are going to kind of bootstrap recursively to handle bigger circuits

and then there's like how you actually do the recursion. And so I think even with with recursive composition there's room to improve the the base snark. There's another perspective entirely which is as soon as you decide that you're going to represent a computation as a circuit or you know, air or plonk or what have you kind of accepted immediately like six order magnitude like overhead for the prover compared to you know, if it was just going to check the witness directly you know, with like no proof of correctness or something.

Was this the blowup that starks experienced as well because they were using fry? No, this is not fry specific at all. It's just so I I have a blog post for 316 Z where I try to explain how I think of this which I don't think is a unique you know, viewpoint. There's sort of two sources of overhead that call the front and overhead and the back and overhead. The front and overhead is like once you decide you're going to use a circuit but forget about actually proving anything about the circuit how much more expensive are things now like so how how much more expensive is it to evaluate this circuit over some finite field gate by gate versus just like running a computer program to check the witness for validity. So I call that the front-end overhead and then the back-end overhead is like how much more expensive

is it to for the prover to prove it knows a satisfying assignment to the circuit compared to just like evaluating the circuit and I think ballpark like we have kind of both sources of overhead down to roughly you know very roughly like three orders of magnitude but they multiply together so now you have six orders of magnitude right and and yeah like both sources of overhead like are parallelizable away so you can throw tons of GPUs at this and I think this you know I hear a lot of you know like six orders of magnitude no problem we'll just have more GPUs and they're cheap and it's fine which is a reasonable perspective but it's like very clear that like there are things people want to do where you just can't you know yeah exactly so I remain optimistic and I've

been saying this for years without ever giving anyone like really compelling examples that we will just avoid circuits for applications people do really care about in the past I've given these things people really don't care about like counting triangles in a graph or something where I knew how to do it but one thing I think is like we we already know how to do this and someone just have to build it is when people evaluate neural networks today when they train them when they then do inference with the trained up network largely what they're doing I'm told is just repeated matrix multiplication and and moreover like the you can represent the matrices over finite fields because they're really dealing with small integers and they sort of naturally get turned into field elements so we have special purpose snarks where

you never see a circuit in them for this kind of computation so I think this will help to basically let like kind of the blockchain do learning, you know, learn in real time from data on chain as more and more data gets on chain and really the learning's happening off chain and it's just getting proved uh to the blockchain that the learning's being done correctly. What do you mean there that this you throw out the circuit? The circuit of what? Which part if you're still dealing with some inputs? Do you still have a circuit somewhere? Yeah, so the the neural network itself tends to just be like multiply some matrices, take the resulting product matrix and like apply a bunch of uh like what people call nonlinearities, you know, ReLU gates or something to them and then like do it again. So you just

have these alternating like matrix multiplies, uh ReLUs, you know, repeated over and over again. Um and and we would still need to like handle those like uh you know, ReLU gates with by like kind of representing the ReLU operation as a as a circuit and applying Okay. you know, a general purpose SNARK to that. Uh but with matrix multiply, what'll happen is like the prover in its own head will just like you know, compute product matrix. It doesn't matter how it does it, you know, um and and then with like uh a low order amount of extra work, it'll actually prove that it has like the correct product in its head.

Um whereas like the the traditional way to do this uh most naively would literally be to like represent the matrix multiply operation as a circuit and when you apply a SNARK to that circuit, the prover is proving not just that it knows the product but that it computed it in a specific way. The next step would be to apply something called Free Vold's algorithm, which is like um just exploiting the fact that um like if I told you what the product matrix was and I actually sent that to you, um you could actually check that it's correct faster than computing it from scratch.

Mhm. But if you use that in a SNARK, the prover would still have to cryptographically commit to this product matrix, which itself could blow away this whole goal of um having kind of a low order runtime overhead for the prover to compute the proof. Um so, with these special purpose SNARKs I'm referring to, you don't even have to have the prover cryptographically commit to these product matrices. Interesting. This all I guess all falls under the category that people might be starting to hear about, just like ZKML. Yeah, so the application domain would be um ZKML in this in this situation. Um Yeah.

Is that just generally a field that you're kind of excited about? It's something where I I you know, kind of even I uh as like not a particularly application focused researcher can see the potential of and where I think um the special purpose techniques um can really make a dramatic difference in. And I think we'll see some more examples of this um soon. Yeah, which uh you know, I've kind of just been saying with uh with no justification for years like we should we should be aiming to like get rid of the circuits completely. Oh.

And and now I'm hoping we're we might actually achieve that um sooner rather than later. Yeah. This might be a question more for the like the episode we do looking more into that, but do you see it as the combination of these techniques, does it help like you just described the blockchain learn or does it help with the models and the use of the models? Like is it helping both sides or is it more like we're using neural networks to like do something into the blockchain? Yeah, I think it's uh it is both. So, you know, there there's also situations where people want to you know, a bunch of different entities want to learn from their combined data, but you know, they're not willing to reveal their data

to the other entities and you know, maybe they're willing to you know, allow the output of uh the learning process to be revealed, but not the raw data or something. Uh so, these techniques could definitely help allow that to happen. The privacy part then. Yeah, exactly. You know, allowing like these smart contracts to to learn from on-chain data like and and forever like more data goes on-chain and they update Um you know their classifier or something, like that doesn't necessarily require any privacy, but you know then you can bring in privacy too and this can help like kind of protect let people learn from training data without revealing it to the learner or something like that, yeah.

Interesting. Or the other learners, yeah. Yeah. It is true of course that like you know what the training algorithm does need to know the data, right? So someone has to know the data, right? And then unless you start using things like FHE which is way more expensive than SNARKs today and stuff, but yeah. True true true. Cool. So I want to hear a little bit about your most recent work. I'm so happy to hear study group's going to happen again, so people can definitely find you there if they want to learn with you, but what are you working on at the same time? And and yeah, what sort of generally are you focused on? Yeah, so I guess well one thing is is finding more of these applications that you you know you kind of these special purpose SNARKs that don't use circuits at all might be amenable for for just

kind of night and day performance improvements. Um another thing is kind of moving again to if you did have a circuit, but the circuit was was really big and you weren't kind of breaking it into small pieces, I sort of been working for a while on what we call linear time SNARKs and this basically means we allow the prover to do like Merkle hashing and field operations, but we don't consider linear time like multi-exponentiations or FFTs. And so there's been I mentioned some of these systems before like break down Orion. Now HyperPlonk also has a part of the paper that's getting into the action and I think this is prime for more more progress to kind of we they already have a good prover to the goal now is really to get the verifier cost lower. And then

I'm also interested in like actually, you know I've I've now kind of raised this issue of like how much security is like really enough. Um so I think it's worth actually like implementing the known attacks and seeing exactly what they cost so I can make much more precise statements than like oh, this is how many hashes the Bitcoin network does. Oh, this is what some researcher did, you know, 3 years ago and reported in a paper. So, I think that's important like scientifically and just as as projects sort of decide where they want to be in this trade-off curve between security and performance. So, that's summary of things I'm interested in now.

Cool. You mentioned earlier sort of the work you had done with A16Z. Tell me a little bit about your involvement with them. What's next there? Yeah, so so starting next week, I'll be joining their crypto research group full-time as a research partner. And I'm really excited about that. It's it's a wonderful group of of people and a wonderful collection of of companies to interact with just kind of be in the center of of everything. You know, especially over the summers, the the research group has been bringing in tons of visitors. So, that's how I started with them last summer. It's just a really exciting environment. So, I'm I'm really psyched to start full-time next week.

Nice. Justin, thanks so much for coming on the show. And it was great to meet you and get to hear more about like the work you've been doing. It's been really fun to see that group kind of active and you in it. But yeah, it's been great to meet. Yeah, you too, Anna. Yeah, thanks so much for having me. It's great talking to you. I want to say a big thank you to the podcast team, Henrik, Rachel, Adam, and Tonya. And to our listeners, thanks for listening.