History of Plonk, Noir, and the building of Aztec 3

Welcome to Zero Knowledge. I'm your host, Anna Rose. In this podcast, we'll 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 Zac Williamson from Aztec. We cover the history of Plonk from the start of the idea all the way up to his recent work, Goblin Plonk. We chat about Noir, the zkDSL, as well as other advancements in the field, all of which have made a path for Aztec to release Aztec 3, their planned private programmable L2. We also do a quick catch up on the state of ZK applications, folding schemes, and what's on the horizon in our space. Now, before we kick off, I do want to direct you to the ZK Jobs board. There you'll find jobs from top teams working in ZK. So if you're looking to jump into the field professionally, be sure to check it out. And if you're a team looking to find great talent, be sure to add your job to the ZK Jobs board as well. I've added the link in the show notes. Now Tanya will share a little bit about this week's sponsor.

Aleo is a new layer one blockchain that achieves the programmability of Ethereum, the privacy of Zcash, and the scalability of a rollup. 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 stablecoin and more. Visit developer.aleo.org to learn more for questions, join their discord at aleo.org/discord. So thanks again, Aleo. And now here's our episode.

I want to welcome you back to the show, Zac.

Hey there.

This is your 4th time on the show. And in prep for this, I was digging through the archives to figure out like, when did we first meet? What were you talking about then, what were the other episodes? So I'm going to give a little roundup.

Awesome.

Oh, absolutely. Yeah.

Okay.

I mean, we are definitely zk-zk-rollup with the option of supporting zkRollups within our zk-zk-rollup. So possibly multiple ZKs. We'll see.

Yeah. Very happy to, to shill Aztec 3 for as long as I can.

Cool. Cool. There's a bunch of things I want to talk about, but I know that I want to start on the Aztec front and get a catch up from you. Especially because, like even since that interview last year, I mean zk.money; I don't know if that's still a focus? So I think we should share what's going on with Aztec Connect, what's going on with zk.money.

Very happy to talk about that, but I'm wondering, should we go back to the start? Because we first met and started talking about this back when, you know, the world was in black and white and it was a long time ago. Because yeah, it's been several years. But there is a narrative here, which is basically like when I got started with Zero Knowledge cryptography, the goal was always to try and create like private smart contracts basically. You know, take a solidity-like language and add private stake to it as a first class primitive, and then just have an ability to just hack around with building DeFi, building gaps where you can hide information. Originally this came out because we needed that for a very specific application. So I think maybe when we first met, I was the co-founder of a company called Creditmint because we we minted credit.

Whoa.

Yeah. Times have changed

Actually question here, because I know you spoke at like zkSummit4.

Yeah.

But had you been

I was at zkSummit2.

You were at zkSummit 2. Well, did you also speak at the early ones in Berlin? I think you did actually.

I don't think I spoke at zk2

But you might have spoken at zk3. Yeah, I remember that you were the only person in one of, in the breakout rooms who'd used the flip chart. I remember this.

That was Plonk, that was me trying to explain the permutation argument with Plonk and failing.

Wow no! Okay. So yeah, we did know each other even before that episode then.

'BP' - 'before Plonk'.

Before Plonk, I think you make a good point. Let's go even further back. Let's do a little bit of the story from the start.

And actually it makes sense that it was like sort of the business use case that was the first to like be made clear. Yeah. I mean that was always very clear to me as well, the fact that like, how could you run a business if everything is transparent? Like every salary, every supplier's deal and stuff like that.

Yeah. Well, I mean, turns out that you can also just do it if you are some 16 year old anon on Twitter that also works. But for some parts of the economy, you do need proper privacy. So I came to this from, from a very commercial perspective, and I guess I basically got zk pilled later on.

Whoa.

Yeah.

So I started looking into ZKProofs because I'm like, well, we need this for the business. I don't want to go back to my boring old job. This is too much fun. So I started reading about cryptography and learning about it, trying to figure out if we, could port the Zcash protocol to Ethereum.

Wait, I'm just, I just realized what were you doing? What was your background actually?

My background?

I always thought you were a cryptographer.

Oh hell no.

What!

I feel like you might have even told me this on an earlier episode, but I completely have like

I'm very much yeah self-taught when it comes to cryptography. My background is as a failed particle physicist.

Oh.

So I did a PhD in Experimental Neutrino Physics because back in the day I had delusions of grandeur about wanting to be a scientist, you know, spending all my time sketching out equations on whiteboards.

Which you kind of do now.

Yeah. You can take the academic out of academia, but you can't take out academia out of the academic.

Ah, I see.

But yeah, I, I figured that didn't work out. I realized actually I didn't really like research because it was a bit too ephemeral, you know, trying to measure the existence of particles that last for a billions of billions of a second. It's interesting for a time, but I felt like I was, I was basically speed running a midlife crisis and I wanted to do something more real with my life. So I became a programmer for a couple of years to kind of sort my life out, finish my thesis, and then that's, then I met Tom and he's like, I'm doing a startup. Do you want to join? And I'm like, well, yeah, I'm not doing anything interesting. Let's do this.

Cool.

Then that segued into needing privacy, which segued into me reading about cryptography.

Yes.

Which then segued into falling down a crypto rabbit hole

And early on though, you were using a different kind of ZKP.

Yes.

What was it again?

A Sigma protocol. Okay. so, so before Plonk to get privacy we put together like a Frankenstein cryptography protocol using older perimeters than ZK SNARKs. Because basically we wanted programmable business logic, and we didn't want to have to do trusted setups for every circuit we were writing because we wanted it to be programmable. And so at the time, all SNARKs required trusted setups per circuit. So given the lack of other options, I knocked together this very primitive cryptography protocol, which sort of did what we needed, but it was very expensive in terms of computational costs in today's figures, probably a cost about a hundred dollars to do a transaction on Ethereum in terms of gas. But originally I became fascinated by ZK cryptography because it was a new area to me.

I didn't know it existed. The idea that you can prove statements about encrypted data was just radical.

Yeah.

And I kind of realized very quickly, wow, you combine this with distributed ledger technology, you had the ability to actually create you completely ledgers where like the protocol is transparent and trusted, but the actual information trading across it is private. That that could change a lot of things in this world. So I became a bit obsessed with it. Basically, one of my first introductions of cryptography was, I did something which later turned out was a massive stereotype, which is that I got introduced to an actual cryptographer Jens Groth, one of the OG folks. He's created the Groth16 SNARK. He's been in the space for a long time.

He's been on the show.

Yeah. I owe a lot to him because basically I got introduced to him, I rocked up to his office and I'm like, "Hey Yens, I've got this like, amazing new cryptography protocol." It's like, no I'm not a cryptographer, I'm self-taught but trust me, this one works, it's great, it's going to change things. Then he read it in about five minutes. He's like, "yeah, it's broken." So yeah, that was my extremely stereotypical introduction to cryptography.

It's funny cause it's like don't roll your own crypto.

Yeah.

But then you did

Then I kept going. Yeah, exactly. I'm like, I, I you know what's that? The definition of insanity is trying the same thing over and over and expecting different results. Well,

You did get a different result though.

Well, I did because Yens was, was exceptionally good natured and kind of spent time advising my startup and basically mentoring me in how to actually do cryptography.

Wow.

And so that's what, then with his help, that's where what then produced the original Aztec critical, which was this Sigma critical thing that I was mentioning earlier

Interesting. But then, so even on that one, you had gotten something sort of functional. Yeah. Where does Plonk come in?

And at this point there was like, Sonics had been, was that out?

I think we may have covered that at some point on the show too in detail. I remember doing a study club on that actually.

Yeah. And it was the first actual universal SNARK that was like remotely practical

Although not really feasible, right?

Yeah.

So, the idea was it proved, it showed something, it showed you could do this universal trusted setup, but it didn't necessarily, like, hadn't figured out the sweet spot.

Yeah. Because the prover was extraordinarily slow, so you wouldn't have been able to use it in practice. But it, it showed techniques where it should hey this is possible. And so I looked, I saw the paper and I'm like, I have to figure out your secrets and see if there's something that can be evolved out of it. Which wasn't the easiest thing to do because I do not wish to throw shade. I have an enormous amount of respect for the Sonic authors. They contributed immensely to the field of cryptography. There is a but though

Oh. And that, but is that the paper is not the most, is not the easiest to read. Particularly if you are not kind of completely up to speed with a lingo of cryptography, with the syntax of it.

Sonic paper is split into two components. There's the component where they, they describe a SNARK that's universal, but it requires an untrusted third party helper who has a lot of computational resources. To help make the proof. And then there's the part where you don't need that untrusted third party, but the prover is extremely slow. And that second part was the one I was interested in, but it was also the part that was kind of not really described that well because it was, it wasn't the main focus of the paper, it was kind of an a side, oh, by the way, you can do this.

But this split you just described this isn't, the split does not correspond to like the polynomial IOP and the polynomial commitment scheme or anything. This split you're talking about something else. This is like,

It's different. okay. Because they both had two, like both the modes had two different polynomial IOPs, I believe. Yeah. I spent that was a couple of weeks where I basically camped out at a little bougie artisan cafe that's right next to the flat that I was living in. I camped out there with a supply of iced mochas and a notepad and the Sonic paper. And I went through it line by line, basically grinded through it until I understood how the damn thing worked.

Wow. It sounds like it was because you needed something like this for Aztec to actually work. And this, what we're talking about here is it's still Aztec 1. Yes. Or is this Aztec?

Aztec 1.

Aztec 1, yeah. Because you had created something, but it, did it not work?

Well? So Aztec 1 was, it wasn't, it didn't have any scalability. So the idea was, what it enabled was like private-ish value cryptocurrency transfers on Ethereum. But like, the values were hidden, but the identities weren't and it wasn't scalable, as in, if you like, each, each transaction required a verification occasion on Ethereum. And that cost a lot of Gas, about 800,000 Gas. So, it clearly wasn't a sustainable long-term solution. And we needed something better. We need a better tech. And that better tech did not really exist, and that was causing an existential crisis for me.

So you're sitting in this cafe. Yeah. You're figuring it out. Had Ariel already joined Aztec?

No. Oh. So at the time, I barely knew Ariel, like I met him once at a Zcash conference. Like we shared a cab ride but we didn't really know each other that well. And so that came a little bit later, about a month afterwards. So I, once I cracked the Sonic paper understood how it worked, I'm like, right, okay, is there a way of making this fast? And I was basically drawing blanks there actually. I was like, Hmm, how do I make this fast? Well, dunno!

Did you go to Jens Groth again and ask him?

I didn't because at the time, so he had to stop being our advisor because he joined DFINITY so there was a slight conflict of interest. They poached him, and yeah, he couldn't, so he couldn't help, but his papers did because basically the path that was on before I bumped into Ariel and actually had the the inciting incident, which put it all together. There's a kind of a trifecta of papers that were coming that had come out over the last couple of years that were really, they, whilst they didn't codify it explicitly, they were using this, this kind of general construction of creating ZK protocols using a polynomial interactive Oracle proof and a polyomial commitment scheme. They weren't synced, they weren't SNARKs, not really, but they were for like general purpose compute, and not general, but sorry, special purpose computations.

But they were kind of written by Jens Groth, Jonathan Bootle, that kind of crowd. And I was kind of devouring these papers because, you know, I had a kind of like intuition that there was something there that you could combine this with something, some of the stuff in Sonic and somehow get something working but I didn't really know how to do it. And that's kind of where Ariel came into the scene. Because I met him at some crypto conference in London. I'm afraid I cannot remember the name of the place. It was the company that hosted, it has since gone under. But at the time I was working on a problem where I was trying to create a bespoke ZK circuit for verifying Poseidon hashes. So very specific and it was more of a toy at the time.

I didn't really have a good use case for it, but I was like, Poseidon's a fun hash function. Can you make a, like a very specific kind of like ZK protocol using these, these Polynomial IOP ideas to do it. And I got to the point where I'd almost got something working, but there was this one minor niggling little issue, which is a, basically like the way these Polynomial IOPs work is generally, you know, you'll use a commitment scheme to encode a vector as a polynomial. And then you'll perform some arithmetic of your vectors and use, and basically define some kind of polynomial expression that checks the correctness of that arithmetic. And the problem that I had is for my Poseidon protocol to work, I needed a shift. Basically. I needed to encode a vector as a polynomial and also encode, it shifted form as a polynomial and verify that those two were identical.

And I didn't know how to do that using the, the representations that I was using, which was at the time this, this whole like Lagrange-based thing, which is in PLONK. So long story short, basically ran to Ariel I'm like, hey, you're a brain, you know how this works. Or you know how cryptography works, like do you know how to do this the, the shift thing? Ariel to his credit he spent a lot of time talking with me that day because I was struggling to explain the problem because I was speaking in kind of a bit of a like a butchered language of cryptography because I'm not formally trained in it but he, yeah, he listened. He listened to me.

He translated.

He translated me, yes, he was the PLONK whisperer and he was like, "hmm, I'll think about this". I went away end of the conference, I was hacking around on my notebooks. And that evening I realized, hang on a minute, this problem, like, if you can get this, this kind of, this equivalent of a shift in a polynomial form in this kind of Lagrange-based idea, if you can do this and you can create a universal SNARK, then you could make Sonic fast. I kind of, that it triggered, it clicked in my mind. And I remember it quite clearly because the I had an Apple watch at the time and it it started beeping at me saying, Hey, you're not doing an exercise, but your pulse is like 120. Are you okay? Because I was, my heart was panicked because I'm like, oh my God, there's something here.

Whoa.

But I thought this shifting problem because I just wasn't familiar with the tech, like how to solve it. I was like, ah, it's probably impossible. You know, this is a, this is a pipe dream. Move on. And then the next day at the conference I turned up and, you know, I was walking past Ariel and he just whipped his head around and he is like, oh yeah, by the way, I've solved that problem you you mentioned yesterday.

Wow! Oh, that's so cool. I actually, I want to say we interviewed Ariel last year about a little bit, the history of PLONK on his side. So I will actually try to dig that up and add it in the show notes, but I love that. So you guys met you, you connected and you weren't working together still this was just like people who you knew each other sort of peripherally and this was the point where you started to work together and it was on PLONK.

Not even well-ish. I mean, basically we were there just for one conference. Ariel was moving, was traveling around. And so we, we basically at the, at that conference, we hashed out a way where you could possibly create a universal SNARK, but it was still very, very foggy in our minds, because what became the PLONK permutation argument, I was when Ariel told me like, there's this thing you can do you can solve this problem, I'm like, dude like, do you know what this means? And so we, we basically hit off in a side room and I explained to him Sonic's permutation argument because not many people that would had at the time had really like, dug into the Sonic's permutation argument part because it was somewhat inscrutable. And so like, I wasn't teaching him permutations. Ariel knew all about permutation networks, like they've been around for donkeys years, but how to get universal SNARKs out of them was relatively new-ish.

And so anyway, but, but once, that clicked with him, he's like, "oh yeah, wow, there's something here" and then we had to split because, you know, we had our own lives to live. But then a couple of weeks later, we met at an airport waiting to board a plane to go to a Zcash conference. And I looked at him and I'm like, "dude, this idea that we have" and he's like, "yeah". I'm like, "should we write a paper about it". And he was like, "yeah, I was thinking that too let's write a paper" and then eventually that, that became PLONK.

Did you know when you were doing this how influential PLONK would be?

I knew it was going to be a thing.

Because it's, I mean, it's took over so many systems, like people who were developing their own proving systems sort of sometimes threw them away just to use PLONK and it's evolved, there's like all the variations on PLONK. There's even like PLONKish is like a term, like an adjective now. So like yeah. Did you, did you have any sense?

I mean I had a sense that it was going to be quite valuable for the, for the reasons why I wanted to use it for Aztec because a universal SNARK that's fast enough to put into production systems was completely new at the time. And yeah, I knew it was going to get used. It's kind of why I gave it a silly name because I thought it'll be funny. But I didn't quite realize just how much it would take off and also just how much the community would embrace and adopt it because the PLONKish arithmetisation, it's how do I put this? You know, it would've been very easy for quite, for, for several groups who are you know, companies, institutions, researchers to basically just name their protocols whatever they wanted, as in if they, they, they use ingredients from PLONK but it doesn't mean you need to name it after PLONK. But they've been quite, they've been quite good natured and kept the theme and so it's, it's helped the concept of PLONK kind of worm its way into the, into the wider cryptosphere.

No, but...

I think I misheard somebody and then started this rumour!

There might be an 'Octo-plonk' in the future, but not right now.

Actually, I asked, when I was interviewing Daira and Str4d, I think I mentioned this 'Octo-plonk' also as a probably not real thing and I think they did actually have a vision for what 'Octo-plonk' could be.

Interesting.

So I think it should exist.

Yes. It's going to be like the crypted of cryptography protocols, you know, it's the one you hear about, but it's never, you can never really see.

No, you can't find it anywhere. You can't find it. But, okay. So from there, we just mentioned this like PLONK-ish...

Arithmetisation.

Arithmetisation. That you find in Halo 2. Do you find it in Plonky2 as well?

Yep.

Okay. What else do you find it in?

Where does a PLONKish artihmetisation worm it's way in? Everywhere. I mean well, anything that isn't R1CS or a STARK like AIR is basically PLONKish. Because if you don't want to do a per circuit truster setup. The, the tricky part about doing a SNARK circuit is proving that your wires are correctly feeding into the relevant gates properly basically that your wires are copied where they need to be copied and the way that you do that canonically like the, what, what PLONK showed is that you can do this really efficiently with a permutation argument. So that permutation argument is, is core to a ton of protocols, but, but more, I guess, more, more broad in that, that PLONKish arithmatisation is a way of taking arithmetic that you want to express over vectors.

And that's the lookup arguments basically, lookup tables. We actually asked that question on the latest ZK summit form though. What is the lookup argument? Oh, actually, what is the difference lookup table lookup argument?

Well, I mean I'm not going to claim to have invented lookup arguments generally because they're, they, they go back a ways, but so lookup was just a way up was a way of doing them very efficiently in a PLONK-ish arithmetic type circuit. So what's the difference between lookup table and lookup argument? Lookup argument is a way of proving that you've correctly read from a lookup table.

Yeah, so, so quite a bit because you know, I mentioned at the start, like one of the key driving forces behind Aztec is we want to do private smart contracts. And PLONK on it's own own isn't enough. It's good. It's not good enough so we, we need, we always need more speed and more power make things faster and just what I've been trying to do well, you know, in tandem with a lot of people in this, in this space over the last, well, several years. And so part of that has been improving PLONK. So adding lookup tables, adding custom gates, creating these new weird variants like Turbo-PLONK and Ultra-PLONK. And then something else which kind of changed the game a little bit, flip the board over was HyperPlonk.

Which you didn't do right?

Which I didn't do No, that was

Benedikt.

That was Benedikt and Ben and the Espresso Systems folks. Yes. See, they pipped us to the, to, to publication on that one.

So had you had something like that in the works?

One thing though, if this adding sum check or making it sum check was the change, what was it before? So zero check or?

Yeah. So zero check. So the idea is if you have some arithmetic over your polynomials, you encode your vectors of information such that the resulting polynomials, they vanish on some subgroup.

Yes. And this was the vanishing polynomial concept.

Yeah so the idea is you check your arithmetic is zero modular, the vanishing polynomial of your subgroup and that's what the, zero checks quotient computations so you can place that with a sum check protocol where you basically, instead of encoding things over in a univariate polynomial, you, you incur them as a multilinear polynomial. The idea is if you have a vector of size, N you take log-N variables and you encode your data as a polynomial and there's variables where when you evaluate those, those log-N variables at zero and one, each combination, the zeros and ones gives you one one of the elements in your vector. Hmm. So basically you, you encode your data as, as the elements of a Boolean hypercube, an indimensional Boolean hypercube which I love saying. Whoa. Yeah. It's kind of a weird crossover between zero knowledge cryptography and psychological horror novels,

But yeah. HyperPlonk. I think we had, I think Benedikt gave the presentation at actually ZK8. Potentially. So it's pretty, it's like six months ago?

Yeah. yeah, so, so we, we had very similar ideas, but we took our sweet time putting together a paper. Our paper is not yet published for a couple of reasons we, but we're, we're nearly there, so yeah, they, they, they pipped us to the post and got it pretty, pretty awesome work and very grateful that they kept with the PLONK theme.

You recently released Goblin Plonk but this is not this work, right? This is something else.

Yeah. So the thing I was just talking about, at least the one that we are, we're internally we're calling it Honk.

Oh, that's Honk. Yeah. Okay. So you just skipped the HyperPlonk and just went straight to Honk.

Yeah.

Cut out all the middle letters.

Yeah. Yeah. So it stands for highly optimized PLONK with a, with a few silent letters. But yeah, slightly different to Goblin Plonk.

Okay. But why would you keep working on Honk if HyperPlonk already exists? Like will you be adding to it?

So Honk is, yeah, Honk should be adding some several editions to HyperPlonk because the, the HyperPlonk paper treat is a very general description of how do you PLONK when you encode things over a brilliant Hypercubes. So my take on it is that the authors, they wanted to create a general description, which means that they treat the various cryptographic subprotocols you need as black boxes and the paper doesn't describe particular schemes you can use and therefore all the particular ugly engineering hacks and tricks you can use to make it fast, and so things like cyclic shifts are expensive and if you choose specific scheme like multilinear commitment schemes, they don't, they, they become very, very cheap. And so there's, yeah, there's lots of tricks you can do and so I guess our paper is A), it's a collection of the tricks, but B) it's also, it's, it's got a new multilinear polynomial commitment scheme which should be more efficient than the other stuff.

What's it called?

Doesn't have a name yet.

Oh. But what would it be replacing? KZG?

So no, it, it's, it uses KZG as a sub-component. It would be replacing something called Gemini. So Gemini is a folding scheme where you basically, you have a, an like a, an abstract multilinear polynomial, but you, you use a folding scheme to represent it eventually, like to provide a a mapping to map that maps it to a univariate polynomial commitment that you can then open with KZG.

Is this at all like playing on, on the Nova work?

Not quite, no. No. I've used the word folding it, but it's, it's folding in a different way. Most, most of ZK crypto is basically, it's folding schemes and polynomials at it's core I think. And yes, it's just a different way of pop folding different, context.

Got it. Okay. So that's Honk. Now tell us about Goblin Plonk.

Okay. Goblin Plonk. Oh yeah.

You were also just describing, you had to explain some zen, what is it?

Generation Z slang.

Generation Z slang. To help me understand why you decided on this name.

Okay. So it's wider context is one of the things that's obsessing me is the cost of recursive proof composition. To do something like Aztec 3 with private smart contracts, it helps immensely if you can if you have recursive SNARKs as a very, very cheap primitive you can use where, you know, you can just check the credits of proof within a proof and that not add much overhead to the prover. We care greatly about this because if we can do client side recursion quickly, so, you know, proof's constructed in a web browser or a, you know, an old computer with not a lot of memory, if you can do that, then it makes it makes it possible to, to represent SNARK-based smart contracts in a, in a manner that's very intuitive for developers, where it allows you to abstract a lot, a lot more away. And so I've been assess, I've been assessing around fast recursion for ages, and Goblin Plonk is a recursion scheme that I believe we've not finished implementing it yet, but I believe it's going to be exceptionally performant and have very, very low prover costs. And it's called Goblin Plonk because it's, it's when a recursion goes goblin mode

Ah-ha. And goblin mode is lazy, greedy and slothful.

Yes.

That's what you were telling me before.

Exactly. Yes. Okay. And the reason I call it that is because the recursion scheme, it's very lazy in that when you're, when you're recursing elliptic curves one of the big problems is you need to do something called non-native field arithmetic, where you need to do lots and lots of arithmetic modular, a modus, which is not the native modulus that your circuit is using. So generally that's a very expensive thing to do, which slows down provers. And the best way of doing it so far is the Halo 2 curve cycle scheme, which I would consider Goblin Plonk to be very much an iteration of, because it still uses curve cycles but the reason why, but basically it's the, the main innovation is that when you are actually doing your recursion instead of performing all these... take the expensive computations you need to do, and instead of performing them or evaluating them, you cheat, you present a a lookup table which just magically has the results you're looking for, and, and you then you worry about proving the correctness of that lookup table later on in the protocol.

This seems to be a trend though, this idea of like, you push the proving of something to later. This is this like Halo 2's doing it, or rather Nova starts to do this I think, and this is where, this is where it sort of sounds again familiar.

Yeah. So, so it is, it's a good trend because, because it's you know, it's always, it's always nice to make something somebody else's problem.

But isn't it still your problem just later?

Yes, so true. But, but it's, well, there's, there's two ways of why, why deferred computation is valuable. One of them is genuinely as somebody else's problem. The idea is you, like, you have two provers, one has very weak computational resource, one has lots of computational resources, but it's perhaps not trusted. You want to basically, yeah, like minimize the computation that you're weak prover does and defer as much as you can to the strong prover without leaking information to the strong prover. And that's kind of what Halo 2 is doing with these curve cycles and similarly I think, I think it's what Nova is doing as well, I'm not, not, not the expert on that, so I could be mischaracterizing the protocol. Goblin Plonk is slightly different where it is still all your problem as a prover.

But the, the idea is that what you can do is, is as you're recursing you're basically building up a giant lookup table that contains all of these elliptic curve operations you need to do that are over a foreign field. And then at the very end of your like once you've actually computed all your recursive proofs at the very end, and you, you some, somebody needs to prove the correctness of this transcript. And one way of doing that is basically you use these curve cycles, so you commit to the same information over your, over, over your cycle curve. Which basically translates the problem from doing this foreign field arithmetic, doing native field arithmetic, so it reduces the complexity of the problem by about a factor of a thousand and then you, you prove the quality between these two commitments.

And so long story short, it translates the problem of doing non-native elliptical scale multiplication into the problem of doing native elliptical scale multiplication, which are very cheap, and five non-native field multiplication, where if you only do five, that's also very cheap, especially in the Goblin scheme. You can basically create a custom circuit that just does non native-field muls. Doing five of those is actually about the same cost as doing a native elliptic curve multiplication. and my kind of back on the envelope napkin math is that this should be exceptionally prover efficient as in possibly something like 8,000 PLONKish constraints all into recursive verified proof, which would be if I'm right, it would be like at least one order of magnitude I think of an improvement over the existing stuff.

So what does that mean, sort of like in terms of speed, is it like half as long or?

No, like about 10x

10x, okay

If it genuinely is 10x less fewer constraints. and so yeah, so basically the idea is then you can just use it as a cheap commodity, primitive and recursion no longer becomes like a difficult problem.

Oh wow.

which would be really nice.

Is it, is it solved or is it like work in progress?

So we're implementing it because we're implementing lots and lots of things at once and so yeah, we are doing our best. But

Ah, I see

One of the things that I did with Goblin PLONK was, I just published it as soon as I had the idea, I just wrote it up and threw out into the world because I want, I figured, you know, the more eyeballs on it, the more people can break it, improve it, etc.

Yeah, but you have to implement it to really know if you

Exactly, yeah. Until then I'm just bullshitting. It's just basically me with a megaphone saying, I've got this amazing idea, you know? But she goes to the school next door and you can't see her.

I want to kind of bring in the topic of Noir to this conversation about PLONK because Noir, is it Aztec specific or is it PLONK specific?

Neither.

Neither. Oh, okay. So Noir is a DSL, is ZK domain specific language? And this was released when, like eight months ago or so, 10 months ago.

Yeah, yeah. About that. Yeah.

And we've, we actually hosted a workshop for zkHack3. Where we got to actually see Noir in action. I think that there's a lot of people who are very excited about it. I always thought it was like the PLONK native. Okay. Tell me, tell me then what is Noir.

Okay, so Noir it's our attempt to create a very generalized ZK programming language where the idea is it exposes a very high level programming language that's Rust like. The idea is that it compiles down to ZK circuits, but we deliberately made it platform agnostic because we didn't want this to just be, you know, the Aztec thing or the PLONK thing because, well, it's an open source project and we want as many people to use it as possible.

Does it like favor PLONK? Is it more like usable with PLONK? Is there any benefit to like, or is there any connection?

I mean, I would say it's faster with PLONK because PLONK is the fastest alphabetization scheme out there, but that's my bias. So it's, we want it to basically be the LLVM of SNARKs where it compiles, it doesn't compile to circuits or constraints. It compiles to an intermediate representation called ACIR - Abstract Circuit Intermediate Representation, where the idea is then once you have an ACIR program, then you can take any cryptography backend that you like and convert that ACIR into constraints for that backend specific previous system. So basically equivalent to how computer program languages in general are constructed. The idea is you have a language front end like Rust or C++ or I don't know, Haskell, where you have your front and the actual like language you code in, whether it's semantics as rules, etc.

And then the, the language compiler doesn't turn your programme into machine code. Generally what it will do is it will turn it into, well, LLVMIR, low level virtual machine intermediate representation. It turns it into a, basically a kind of proto assembly, but for an imagined virtual machine that doesn't really exist. So that's what the language front does, and then the language backend takes that intermediate representation and actually turns it into machine code for a specific computer architecture.

Okay.

And this is how you can have a program that you write once and it compiles to Mac to Windows to iPad, iPad to iPhone, to, you know, to tons of different CPU architectures. And so we are taking the same approach with ZK languages. So Noir is a language front end for ACIR. SO it has its own special Rust like syntax that compiles programs to the ACIR representation, but that's where kind of Noir stops and then it's somebody else's job to take the ACIR and turn it into a actual ZK second.

What would it work with then? Would it work with Arkworks?

Yeah I think

Would Arkworks be the second part of that?

Yeah, yeah, exactly. So Arkworks would be the backend, I think. I'm not sure we either have or are working on an Arkworks integration. We have a GNARK integration as well as the the Aztec.

Yeah. The GNARK one was, that's the consensus.

Yeah.

Okay. And but is Noir more than on the same level as Circom, is Circom doing the same thing as Noir? Does it also compile down to?

Yeah, it's doing a similar thing, but Circom is a bit more, I believe it's a bit more integrated in that Circom has a R1CS backend and a PLONK backend, but there that they're tightly integrated in the language itself. So it's not, it doesn't really give you an intermediate representation that you can then compile using some other kind of proving system. So it's a bit less abstract in that way and less modular.

I see. I see. But like, so actually yeah, what you're saying though is because it has this intermediate representation, where does the PLONK part start? Is that like after that?

After, yes.

Okay.

So you can, your backend can take those, the IR and turn it into R1CS constraints and then compile those into a second, or can turn it into PLONKish constraints and compile those into a PLONK circuit.

Could it do something in like the Miden error kind of context? As well?

Yeah. I mean, it might not be the fastest because you are, you're seeking a program and converting it into VM code for like, you're taking the IR for Noir, and then turning it into Polygon Miden Assembly, which is again, another form of IR.

Yeah.

And then that gets turned into a VM second. So you could do it. Absolutely, it might not be the fastest, but you could do it.

I see, I see. At the recent zkHack, I know a few people, you know, started to work on Noir and used Noir. Is Noir meant to be the language that like a hacker could build a little ZK project with?

100%

Okay, so it really is, because like that's what's sort of unclear, like the way you described it though, like you're still sending it into this Intermediate Representation (IR) context. Like if you just use Noir, you still need to use that second part, don't you?

You do, but the idea is so an actual build of Noir. A deploy version of Noir will choose a specific crypto backend to use. And so the goal is to present an abstraction layer to the developer where they just write their Noir program and they just click a button and it compiles to a circuit with a smart contract verifier they can deploy to an EVM chain

Underneath that they don't need to know about

Exactly. The idea is the end goal is for it to be turnkey effectively where you just code your Noir program and then you just run it and you don't worry about anything that's happening under the hood. I'm not going to claim we're there yet but we are working, we are working very hard to get the language

Would Noir then be also used with something else like, say you wanted to create like, I don't know, some like front end application that then on its backend, not back backend, we're not talking circuit yet but like where it, but it's going to be using ZKPs under the hood.

Yeah.

Would you be using something like Solidity on the front end or JavaScript or something and then you have actually it wouldn't be Solidity, it'd probably be JavaScript. So would you be using something like JavaScript then Noir then, like it's automatically using Arkworks?

Yeah, exactly.

Is that kind of what that looks?

Yeah. The release of Noir that you're using would contain either like an integrated Arkworks backend or a Aztec backend or GNARK backend. You would just have, you would have a tool chain. I mean, we have a tool chain now which does this. Although it yeah, for the Aztec backend at least a tool chain where you just compile Noir, it gets turned into a proving key/verification key. You can make your proofs and it's relatively straightforward and yeah, we have a JavaScript wrapper around it all. So that you're building a front end website that uses Noir, that whether the user needs to make a a Noir proof. You can do that all by making JavaScript calls.

Now that we've gotten to this point, I'm like, Aztec as an entity. Now we have to dig into it because I have always thought about Aztec as almost like a rollup, right? Like like, cause we did the ZK rollup episode and you know, you said it first, it was like a smart contract directly on Ethereum and then migrated to this like, rollup concept. But now what you're describing the fact that it, like, is Aztec Arcworks then?

No. Sorry to confuse you.

No, no, but this is where like, I want to

I'm asking is the question basically why, why are we doing this with Noir?

Well, it's almost like now that we've, we've described PLONK. Then we've described Noir and what we haven't really described is like Aztec, which brings all of these things together and that connection point I think I want to understand.

Sure. So the reason we're developing Noir, like this is very much like transparent. We have very ulterior motives.

You have what?

Ulterior motives so, you know, in terms of like, we want Noir to be a public good that is open source. Anybody can use it. They can build their own backends, their own front ends. They can basically just use it however they want, even if it doesn't touch any other Aztec system. And yeah, it doesn't, doesn't benefit like Aztec as a company directly and well, why is that? It's because what is the interstate for Aztec? We are building a zk-rollup. A layer 2, where the layer 2 is effectively we want to recreate the smart contract ecosystem that Ethereum has, but as a layer 2 where you have private state as a first class default primitive, basically things become private by default. Where as a developer you can write your smart contract and then just like, just trivially easily just include private data in your program, in your program logic.

So that needs a lot of disparate components to work. You need an exceptionally fast zk proving system. You need like an architecture that enables all of this, that represents programs as ZK circuits, and then represents evaluating these transactions over these programs inside some kind of zk-rollup architecture. you need the entire layer 2 architecture coded up as recursive zk-SNARKS, and you need language that you program these contracts in.

Okay.

And this is where Noir comes into the picture, because we want, like, we plan for Noir to be the smart contract programming language for Aztec 3. So we want to very much grow the developer ecosystem for Noir just generally, as in it's a positive sum win-win game for everybody is, and we build Noir as a general purpose language that, you know, doesn't need to plug in Aztec 3 just commands the SNARKs or STARKs or whatever you want to basically make it easy to write ZK programs. And the bigger that developer ecosystem is, the better it is for us, because then the bigger the stable of developers is that could potentially write Aztec 3 programs and smart contracts.

Where is the circuit going? That's a good question

If you could you kind of understand why I'm confused here.

Yeah, yeah. Definitely. I mean it's

It's like I know a lot of the parts of this but the actual way that a smart, like an application on this rollup using ZKPs in its fullest form. Like for privacy then is also connected to this main chain. Base chain. This is where I get confused.

Okay. So, so I can try and describe the Aztec 3 architecture at a high level. I'm about to record a one and a half hour presentation that describes the full architecture.

I'll try to find it if it's out by the time I release this

Yeah. But so I'll try and give it quicker, so the idea is, to start with let's take a Noir contract.

Okay.

So at least once we've added all the functionality we need into Noir then you'll be able to define your contract as a set of public functions and private functions where a public function can modify public state. So it'll be like state as in the kind of state that you have already in a Solidity contract. Variables, mappings, et cetera.

Is this state also on the rollup though? This public state on a rollup?

Yeah. Yeah. So it's going to be, it's,

It'd be like what optimism has or something

Yeah. Yeah. It's going to be like part of the L2 state database.

Okay.

And the new private functions which modify private state, where this state will, again, it'll be part of the rollup, but it'll be encrypted and it's going to use the similar abstractions that Zcash use and Aztec use where you have this idea of a UTXO set on switch transaction objects and nullify set, where the idea is like when you add, you can add encrypted data to the UTXO set, and then you can effectively delete it adding its nulliy to another nullify set. Unless you have the decryption keys, you can't link a nullify to a UTXO and therefore if you've deleted a UTXO only you as the deleter know about that.

But the challenge of UTXOs has always been like, there's no programmability in it. It's just about like transfers.

Well, that's, so the way we are representing it as a UTXO, it's just very abstract as in the state that it encodes is not at the protocol level. We don't know or care about. It is not values, it's not identities. It's just 64 bytes of information.

Okay.

Very much like a storage slot in Ethereum. Well, the idea is then the Noir contract you're writing, that's the thing that's defining the rules around when what state that state is, like, how it's encoded, how it's changes. So you can write, say, a private token contract using a combination of these private and public functions. And the idea here is that these functions get converted into SNARK verification keys. And a contract on Aztec 3 is defined as the set of SNARK verification keys that correspond to all of the functions of that contract

Private and public?

Yes.

Does each contract then have like a unique way of the interaction between those two? Like I'm just curious, like how do you still keep state if like part of state is private and it's just a blob of data and it's not in any sort of like account system?

Well, it's in a Merkle tree

But it's private and like, does this Noir contract, is it still able to go in and like retrieve information from it?

Yeah. That's hard. But yes. So the idea is basically when you are actually constructing Noir proofs or simulation and et cetera, you are basically your Noir like the Aztec client effectively has a private state store. And so when you are kind of, when you're running a Noir program to make proof, et cetera, there's basically the noir intermediate representation has like state read op codes, state write op codes. And then when you are executing, turning those OP codes into constraints, then you've gotta send requests to a private state store to say, hey can I read this information? Like I've got a storage slot, can I get the UTXO and the underlying data? And then that private state store, it has its own permission security rules to say, well, either yes.

Okay. I can, I'm going to give that to you or like, no, get lost. I'm not giving you my secret keys. So the idea is that basically inside the layer 2 kind of like state databases, we have a contracts Merkle tree, like when I use Merkle tree that's in this context, it's basically synonymous with database. It's just a way of representing a database.

Yeah.

So the Merkle tree contains leaves that represent contracts, and each contract leaf is its own mini Merkle tree that contains all the verification keys for the functions.

Okay.

And so that uniquely defines the contract. So if you're sending a transaction on the Aztec network you basically need to construct a proof over something that we call the kernel SNARK. So we're very much using the, the Zexe nomenclature here. And this is very much kind of a

Very much derived from XXI was kind of the OG that attempted doing this. And what the kernel snuck will do is, well, it'll fish out a verification key from the contracts tree that you are requesting check it exists and then you'll provide, the reusuable provide proof for the correctness of that function call that will then get verified recursively by the kernel circuit. And then the kernel circuit's going to do some logic. So it's going to basically grab the public inputs out of that SNARK circuit, and those public inputs are going to be interpreted according to a contract ABI. And so basically, so some of the public inputs are going to represent chain state. Some of them are going to represent state updates that the user's trying to make, except things like that. And the kernel snuck's job is to check the validity of all of that to make sure that you're not lying you're not presenting the incorrect chain state.

The user's not trying to make state reads that don't exist, et cetera. And so one kernel proof basically represents the correct execution of a private function. The way we use recursion, the problem is that take a theory, for example, one transaction may be constructed out of multiple function calls to different contracts. If I'm, for example, if I'm trading on Uniswap, my Uniswap transaction is going to talk to at least two token smart contracts. There's probably other contracts that Uniswap talks to, to do things that get price fees, et cetera, et cetera. And so what you really need is composability, how do you get composability between multiple contracts in a zk-SNARK world with privacy preserving properties? And this is where we add recursions. So we have this concept of a core stack. So the kernel circuit contains two data structures basically arrays like vectors that isn't your private function calls and your public function calls.

And when you start your transaction, your private function call stack has one item on it, the contract you're calling. But once it's processing that function call, one of the results from that can be that your function call can instruct the kernel circuit to add more function calls to the functional stack. And so the idea is what the kernel circuit's doing, it's a requester structure where it's verifying a previous iteration of a, like a previous kernel circuit proof if one exists, and then it's popping a function call off the function call stack processing it, and then conditionally adding more function calls onto the function call stack if that is required. And basically what you can then do is by iteratively computing kernel circuit proofs, you can wind your way down to eventually that your function, your private function call stack being empty. And at that point, your proof is ready to be sent to a rollup

Sequencer.

A sequencer. Yes. To be, to be, to be aggregated into the roll up block.

In this case you've used the term recursion. But are you talking about recursion in the ZK sense?

Yeah.

Or is it SNARKs recursive SNARKs.

Yeah. Because the kernel circuit has to verify the correctness of function proofs, which is a SNARK circuiting a SNARK circuit. And also if your transaction is consisting on more than one private function, then you have to repeatedly compute kernel circuit proof square at each iteration. Your kernel circuit is verifying a proof of the kernel circuit at the previous layer. Which is another layer of chunk of recursion

Wild. I do feel like I'm going to need to see slides.

Yes. Yes.

Which I think we will see at some point.

Yeah. Well, our architected documents are finally public. We finally got them in a state where amazing. We're happy to show them to the world.

And so, yeah, I want to see this, I want to walk through, like, when I get to re-listen to this, I want to see it kind of with some imagery. So if you can send that my way, I'll add it to the show notes for folks as well.

I will do. Yeah.

This is fascinating. Aztec 3 was teased on the last episode I did with on Aztec with Joe and Charlie, but like at what stage is it? Like yeah, is it close or is it like, or which pieces maybe are already built?

Yeah. So we're, we are building it in anger but it's a very

In anger?

Well, sorry, it's a turn of phrase as in

Okay.

We are like, we're going ham on it as in like, it's the focus of the company

Going ham on it?

Can I swear on your podcast?

Yes, you can swear.

Ham stands for hard ass motherfucker.

Oh okay. You're working hard.

Yeah.

Okay. That's what you mean. Okay.

Yeah

Kobe created like a translator for basically like British terms too.

I see.

For other people. And I feel like we need to use it a little bit with you, but okay.

Possibly, yes.

Go for it. So you're working hard on it.

Okay.

We don't want to do the thing where we're like overly optimistic with our timelines because this whole industry is very, it's got a bit of a problem with actually correctly predicting launch dates but we are hoping to get a local developer testnet out by the end of the quarter. So that'll be something where you can deploy the Aztec 3 network to your local machine. You can write Noir contracts, deploy them to local network, test them, run them.

Wait, you mean this quarter?

Yes.

So like Q2?

Yeah. End of Q2.

To be very transparent this local testnet will not have provers enabled. The goal is to basically present our planned manner of interacting with the chain, how you write contracts, how you deploy them, basically presenting users and developers with the developer experience and getting feedback from them about how it works and then at a later point when we're launching our testnet, we will integrate our tech into it. Because we, we are developing everything in, in kind of in parallel.

Wow. I want to ask about Aztec Connect and ZK Money, because these were other products that we did talk about in the last show.

Yes.

So you, what do we call disbanded them? No, you

Sunset.

You've sunseted them

We've sunsetted them.

Okay.

Yes. So, so Aztec Connect was, I mean, one way we consider it is basically a bit of a trial run for Aztec 3. As in, at the time our tech wasn't advanced enough to get general purpose programability in, but we did have a tech to produce a zk-rollup. So as Aztec Connect goals was really to demonstrate a) privacy is useful on chain.

Yeah. Yeah.

It's not just a mixer. You could do cool things with it like DeFi and that is valuable and that a) it's possible you, you can deploy zk-rollups to production. These are things you can build nowadays and

Was it almost like a custom application

Yes.

For, on this very kind of like, not fully fleshed out, but like just the proof of concept, the MVP, I guess

Exactly. Yes. The idea is that instead of the users programming circuits, we as a first party company, we programmed a small set of circuits you can interact with on the Aztec Connect network. And yeah, basically what part of it was also just for us to get experience about building zk-rollups, deploying them into production. Actually shipping something and, you know, dog fooding our tech and making sure that we have the experience required to make it work. We would not be able to build Aztec 3 without the experience of deploying Aztec connect without a shadow of a doubt. However, we've been having internal debates over several months about what to do with Aztec connect because it was consuming quite a lot of resources, engineering resources from us because it was our first go at doing zk-rollup.

And so as the architects, I'm very, very confident saying that it had some architecture problems, it had some, you know, some issues that we wouldn't do again. That just design choices that at the time when you were figuring things out for the first time, you know, what we ended up with was a system where you needed an enormous amount of domain knowledge to solve problems that cropped up and so we ended up in a place where a lot of our most senior engineers were basically working full-time

Troubleshooting?

Troubleshooting, keeping the network alive, building the improvement center to make it, to improve its stability as it grew. And basically it was reached a point where effectively as a company, we had two children. We had Aztec Connect and we had Aztec 3. And at some point, you know, we

Had to make a choice

We have have to make a choice, you know, sometimes you've got to take your second most favorite child and take them out behind the shed and

No, no, no

I'll stop the imagery that I don't give parenting advice but basically we needed to focus our resources on Aztec 3.

Okay.

As an organization, you know, where 50 people, which for Web3 is large for everything else, it's pretty tiny.

Yeah.

And we needed to pull our resources and focus in title on Aztec 3.

Got it.

So that's what we're doing.

Yes. I'm fairly confident it is a pure execution problem now.

Okay.

A very big one. But in terms of the tech PLONK and Goblin Plonk ought to be more than good enough.

Okay.

So yeah, there's like, there's big things we need to execute on. Like we need to build our sequencer software and our prover, like third party bureau software because we want to launch this from day one, decentralized. And there are some unique challenges when you have privacy involved that change the architectures of like how to coordinate sequences and provers. Yeah. So there's this, it's a lot of complexity there. There's lots of network engineering, there's lots of critical engineering. Lots of second building, second design but yeah, it's a very challenging execution problem. But the technologies is all there.

Wow. You were one of the judges with me actually.

Yes.

That is the absolute intention

Even though Aztec 3 is not ready.

Yes. So you don't need Aztec 3 for Noir. Noir compiles straight on its own to ZK circuits.

Oh yes.

These verification keys, you can deploy verifiers to Ethereum, you know, we have a see fantastic team building, we've got amazing people. Like this really is the brainchild of Kev who as close to an RL-anon as I think you can get. He doesn't have much of an online presence, but anyone I

Have tried to get him on the show multiple times.

Oh dear

To no success so far.

Yeah, but you'll see him crop up from time to time in photographs when you know, if people are taking pictures and he's not aware but yeah, I mean, I think anyone in the space knows about Kev like we've got an amazing team building this, the goal is for it to be something that you can absolutely just quickly write programs, you deploy, hack around with. So if we're in a place where in November where people are not comfortable using Noir, like that is, you can hold me to account to this, this is a massive failing on my part.

Okay.

As CEO of Aztec, if we can't get Noir to a state where it can be used like that.

So by next zkHack, in-person hackathon.

Yeah.

We should be able to build things with Noir. Maybe you already can.

Yeah. You can do it today. Yeah, I mean there were a couple of hackathon people that did bring answer with Noir. Noir as a product is relatively new. And so we definitely have work to do on the tool chains and the tooling, but like we've got an entire team now focusing on that and should be pretty plug and play fairly soon.

Like, given that, like, because Circom has been out there a lot longer.

Yeah.

And it has, I mean, what's crazy is you've seen things like the Xerox Parc group just build all these tools around it. Does Noir need to build the same tools or is there something portable? Like, could you somehow use some of this?

So I'm not sure how much of it can be used because the paradigms are very, very different between Noir and Circom.

Okay.

Where because Noir has its own language, its own intermediate representation, where we had some very different designs for Northern Circom where for noir we wanted to make sure that most important thing for Noir is to present an abstraction layer for developers that's intuitive. So what Circom does is that the coder writes to define your constraints in your circuit. And the code writer defines the witness assignments to those constraints is different and that can cause a lot of foot guns for new developers. And it's not a very intuitive way of writing programs. What we wanted to do was unify those two where, you know, when you are, you program your like a regular language, and then the compiler front end is clever enough to figure out both what constraints that turns into and to derive the witness assignments. With that we have been largely successful but it does mean that, you know, it's a different language. The tooling is not quite the same. We are also more modular, which means that you know, we can't build like the , we then you then need a kind of an integration with the backend, which adds a small amount of integration complexity, but means it's, well it's much easier, it's possible to add like, other backends of the proving systems.

Yeah, yeah. Without having to like hard code them. I mean, it's not really hard code, I guess the language, but like whatever.

Yeah. Like as in like put a PR into the Circom

Yeah.

Repo. You, you don't have to do that with Noir. And so yeah, we are very hopeful for the language. we would like to see a lot more backends. We'd love to see every backend, like every cryptography module supporting Noir, because I think it could be a way of creating relatively agnostic apples to apples benchmarks for all these proving systems.

Yeah. That would be good. Yeah I want to, I think we're almost at time, but I did want to talk to you just about like the general ZK space.

Yes.

Quickly. Where we're at, I mean, we're recording this about two weeks after, or not even after this, this crazy week of events that me and my team put together. And you were at, and actually we're recording here in person at a place where we're going to be seeing more ZK stuff.

Absolutely. ZK week at Zuzalu.

Yeah, we're, I mean, when it comes to the ZK, we are both, we're old, you know,

Ancient,

We're fossils, you know,

The elders

We are, I mean it's such an insane

It's funny though, the cryptographers who made this up in the eighties are kind of like, you are not the elders.

But anyway. I know, but the thing is, Anna, we're cut from a different cloth. You know, those, those OG cryptographers, they were the academics in the ivory towers. But we do something a little different here. We do cryptography on the street, you know, we don't publish on euro crypt. We write HackMD observations, you know. Yes. We

ZK hustle

Absolutely.

That's gotta be a hackathon project soon. If it isn't already

Street crypto?

Street crypto or ZK hustle.

ZK hustle.

I don't know what that is, but

Yeah, we'll figure it out. It's going to be something. So, so I guess to the question you asked about, like how has the space evolved?

Yeah.

I think one of the things that was really, really positive to see was just the energy in the last zkHack you organized, because really for the first time you had people coming to the space who would complete, like not cryptographers, like didn't know much about ZK at all, and could actually build stuff, actually build ZK applications with the tools and technology that, that this community has built. And that is really, really exciting because we've been trying to do that for years.

I know.

And it's always never been ready. It's always not been quite good enough. Or like you've got to like, you know, you've got to understand cryptography, you've gotta understand like very, very complicated tool chains to do anything and now things are slowly changing.

Yes.

We're kind of almost there now, and

I know

that's really exciting.

Yeah. I was just thinking that like last year you could do things, but you would often, and if you look at like, the programs that existed, I mean, I think Xerox Parc was an amazing example of this where like they got things built

Yeah.

But they weren't built in a weekend.

Yeah.

It was often like someone would set out to build something

Yeah.

And then realize that all of this tooling was missing. And so then would have to build the tooling and over a few months could kind of create that hackathon project.

Yeah.

Now, and I mean, those also developed into full comp, like full projects and companies and stuff.

Yeah. Yeah.

But this past, you know, this zkHack was so crazy to see that like in 48 hours people could actually start to do things.

Yeah.

And it's still hard and I don't think it's like, it's,

Oh, it's still like chewing glass.

Yeah. Yeah.

It's not, I don't think any of us would say it's easy and the tooling is nowhere near as good as, you know

Or something. Yeah.

Language and platforms but it's getting there. Yeah.

And you're also seeing, I mean, even this week it was Eth Tokyo is just happening, I think it's just wrapping up now. And there's a ton of projects that are using ZK. We've been seeing that at the Eth global events and stuff, like more and more ZK use.

Yeah.

And so, yeah, I can't wait to see what this year brings in terms of these projects. And just like the ideas that can come out of a hackathon these are the things that could like, be used by people and potentially have incredible impact. So it's very exciting.

Absolutely.

Cool. Zach, thanks for coming back on.

Thank you. Thank you. It's been a pleasure. It's been a pleasure.

And thanks for doing this recap of sort of the history of PLONK and pre-PLONK and Aztec. I think for folks who hadn't heard those earlier episodes or like newer, I think this could be really great to add some context. Most people have like, heard about PLONK.

Yeah.

Not everyone knows where it came from, so this is cool. Yeah.

Happy to talk about it. It's been a long road

and we're not done.

Oh, no. We've barely started.

Cool. All right. Thanks Zack.

Cool. Cheers.

I want to say thank you to the podcast team, Tanya, Henrik and Rachel, and to our listeners. Thanks for listening.