Anna Rose (00:05):
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 promised to change the way we interact and transact online.

Anna Rose (00:27):
This week, I chat with Daniel and Brendan from Polygon Zero. We talk about their early experiments with different proving systems, their work combining PLONK and Halo, which became Plonky one. And the more recent contribution of Plonk plus FRI, which is borrowed from Starks. That makes up Plonky2. We look at why these combinations matter what the technology enables within the Ethereum ecosystem, their acquisition by Polygon and more. But before we start in, if you're looking to jump into zero knowledge tech professionally, I wanna remind you to head over to the ZK jobs board there, you can find job posts from some of the top teams working in ZK. I also encourage teams who are hiring to use the jobs board to find their next hires. We have teams like Polygon Hermez, EF and Protocol Labs there already. So be sure to add your jobs there as well.

Anna Rose (01:11):
I also just wanna make sure that the ZK Hack mini happening now is on your radar. ZK Hack is a two week event with puzzle hacking competitions and ZK tool workshops. It's started on March 1st. It runs until March 15th. This coming week, we actually have the Polygon Zero folks presenting. So if you like this episode and wanna find out more, be sure to head over there. And next week we will be hosting the ZK jobs fair as well as a panel focused on ZK tech. You can actually already sign up for both of these on hoppin in and be notified when they're happening. So I hope to see you there. So now I'll let Tanya the podcast producer share a little bit about this week's sponsor.

Tanya (01:51):
Today's episode is sponsored by Aleo. Aleo is a new layer, one blockchain that uses cutting edge cryptography to achieve the programability of Ethereum, the privacy of Zcash and the scalability of a rollup it's GAS free and gives developers the tools they need to build programs that protect privacy while allowing applications to be regulatory compliant. The same team has also built a new open source smart contract language called Leo that enables non cryptographers to harness the power of ZKPs to build the next generation of private applications like front running resistant, decentralized exchanges, hidden information games, regulated stable coins, and more. Visit Aleo.org. To learn more about the protocol or rollup your sleeves and go to leo-lang.org to start building that's leo-lang.org. So thank you again Aleo. Now here's Anna's interview with Daniel and Brendan from Polygon Zero.

Anna Rose (02:47):
Today I'm speaking with Daniel and Brendan from Polygon Zero. I wanna say welcome to the show to both of you.

Brendan (02:53):
Thanks Anna. Yeah. Long time listener. First time caller here.

Daniel (02:57):
Yeah. Thanks for having us on.

Anna Rose (02:59):
So I've actually been trying to have you come on the show for a long while and I'm so happy. We finally get a chance to speak about Polygon Zero formerly Mir. I also last week had a chance to catch up with Mihailo and map out the whole polygon ZK landscape. And so we'll definitely be referencing other parts of that ecosystem in this episode. If people wanna check that out before now, I was asking you to come on the show for a very long while, but was rebuffed because as I later found out there had been this kind of deal happening. So I feel like what we can start with. I I'd really like to hear a little bit about where to does this start. Let's go back in time to Mir to maybe even before Mir so that we can hear kind of the trajectory that led you to the Polygon Zero merge or acquisition and yeah. What you're working on today.

Brendan (03:54):
Yeah, I mean, for me, I think it begins like with how I got into this space and, and that was wandering into this Stanford auditorium when I was living in the bay area where Vitalik and Dan Boneh. And I think a few others were presenting the original plasma paper. And, and there was this moment during that talk when it was sort of like this offhand comment when Dan boneh was like, he said something, oh, you could just do this all with SNARKs. You could just prove like state transitions on a blockchain with SNARKs. And that sort of just stuck with me. And I was doing other stuff at the time. And, and so I met Daniel at Zcon0 in 2018 and we sort of hit it off and we just started talking more and more. And, so we decided to, I guess in 2019 start Mir, which was, I guess the, the premise was just to use SNARKs to provide privacy and scalability for blockchains.

Anna Rose (04:51):
Cool.

Daniel (04:53):
Yeah, I guess for me, I, I guess before I got into crypto, I had a pretty typical background as a Silicon valley engineer. So before this, I was working at Google, which I joined to work on Google Glass. That was a very fun project for a while, but unfortunately the...

Anna Rose (05:11):
Google Glass, I hadn't thought about that in a while. The kind of, what was it, AR goggles glasses, I guess.

Daniel (05:20):
Yeah, it, it was really the, the hot fun project going on at Google, back then, but unfortunately it got canceled and then I, I just couldn't really find anything that interested me over there. And then I became really, really interested in cryptography and zero knowledge proofs. And I, I thought I was really little bit mind blowing when I heard about how Zcash worked and how it was possible to prove, to provide this really strong privacy guarantee using this advanced cryptography. So that's when I went to the Zcash conference and met Brendan.

Anna Rose (05:56):
This is in Montreal, right? This is Zcon0. I was also there, oh, I did an episode where I interviewed a gazillion people actually from like during that conference, we can try to dig it up. I actually just recently mentioned it on another show. That conference was fantastic. And so that's very cool that you met there, you met at Zcon0 in Montreal, the first Zcash conference. Were you, like, you were interested in zero knowledge, I guess, but like what, what were you kind of meeting as? Were you like, let's do a project together? Did you already have an idea?

Brendan (06:31):
Yeah, so, so I think we were both sort of like playing with different ideas, like, and then, and yeah, we just sort of talked kind of informally and hit it off. I, I, I think both of us had recently left our jobs with like nothing on the other end, so I think there was like a certain incentive to, to like do something and yeah, we, we sort of started talking about like an infrastructure project, like Mir like a new, a new blockchain and yeah. Kind, kind of went from there.

Anna Rose (07:05):
You knew, I guess it sounds like right off the bat though, you knew this was gonna be in the zero knowledge space. Like it was that angle. It wasn't like blockchain first. It was the zero knowledge part. What were the first kind of iterations of this? Like what technologies were you actually experimenting with? What were, what did you plan on building when you started?

Brendan (07:24):
Yeah, so, so I guess we, we started talking really seriously in October of 2018 and that's right when the original Zexe paper came out. And so, so that was sort of a good signal because it was like a, oh, you know, you know, people smarter than us are thinking about these same problems. And, and so I think that we sort of came at it from the angle of trying to, to build something like Zexe. And then we, we found that there were some limitations with Zexe, like it couldn't support applications that relied on shared state, like AMMS and a lot of the defi applications at the time. And so we were trying to, to come up with a design that supported those applications and also provided scalability with, with recursive proofs. So, so that was sort of, I think the premise

Anna Rose (08:20):
I remember, like, I think we met at the ZK summit four in San Francisco, the last in person, one that, that I did until the next one, which is coming up. But yeah, you gave a workshop and I believe at the time it was a workshop on Zexe and that was 2019 fall. So you, it sounds like you had been working on this kind of idea for some time, but it's, I mean, as far as I can tell you pivoted - you pivoted away from it, were you at the time already thinking of Mir as becoming like an L1, was it an L2? Did you actually see yourselves as part of Ethereum or yeah. What, how, how did you envision this project at that time?

Brendan (09:03):
Yeah, so, so I think at the time we had this thesis and in retrospect, a lot of it was pretty wrong. So we thought that there was room for a lot, lot of L1s and that if we provided a different programming environment for developers that might offer scalability and privacy, that, you know, they would be really quick to, move to this new environment. And, and that Ethereum wouldn't accrue like such a, a big part of the developer mind share. And I think that we say, you know, with some caveats that that was not true and that it's been really striking how in the interim Ethereum has really become the focal point for building web3 and crypto applications. And, and so I think for us, like the, this realization that Ethereum and L2 was kind of where the energy was and where like real users were, were using these technologies and that I guess jumping ahead to, to Polygon that, that like polygon could sort of fill in the places where we were weak. So business development, dev relations, like things that they do really well. And we could kind of build in, in the L2 space was, was something that was like really exciting to, to us.

Anna Rose (10:20):
Cool. I wanna hear a little bit of that interim time though, like between, you know, you shifting away from Zexe deciding, like, had you already decided around that time, like, actually we're gonna focus more on this rollup model was Mir originally, like once you were developing the, the current form, was it a rollup?

Brendan (10:38):
Yeah, so, so the, the focus was definitely on some sort of multichain Ethereum. Like we, we, we wanted to be able to, to verify proofs about Mir on Ethereum and, and develop proving system that worked on Ethereum. I, I think the, the biggest part of the sort of journey with Mir for me was when we started and, and we raised money and it was actually really scary because it was very clear to us at the time that the technology was not ready. And we weren't sure if the underlying ZK premise would get there. So back in 2019, like Plonk could just come out. Like there, there, there were a lot of, sort of promising signs, but I mean, it took two minutes to generate a recursive proof. I, I'm not even sure that there was an implementation of, of PLONK yet. And so I think for me, Daniel, would, would you say that that was like a little bit nerve wracking to have accepted like venture capital money and, and not being sure if we could build a scalable blockchain.

Daniel (11:38):
Yeah. For sure. And backing up a little bit in those early days, I was actually more interested in building something that, that only used ZKPs for privacy, and then actually used sharding instead as a means of scalability. And the reasoning was just that we know how to do this, and it doesn't rely on any kind of new breakthroughs in ZK technology. Whereas I, I think Brendan felt very strongly that we should, we should kind of do it the right way and we should actually prove every transaction is valid. And to, to me that was like the right approach, but it was also the approach that we didn't really know how to implement back then. It was more of a, a research project. So it was, it was a little bit scary pursuing that approach at first, but eventually we got there and we developed the primitives that we need to, to do recursive proofs very, very quickly and very cheaply.

Anna Rose (12:37):
Mm. How were you building your team during this time? Like you had this vision or you had this sort of like, I lo I love this, that you're kind of like taking a leap of faith, hoping that the underlying mechanisms kind of like caught up by the time you were rolling. Yeah. How are you hiring and, and like, what was your team at this, at this stage?

Brendan (12:58):
Yeah, so, so when we started, I think we were like two months in to having raised funding and being in a position where we could hire when COVID struck and that made things a little bit more challenging. And so I think for us it was really important that we only hire people that like we felt were, could, could really contribute. And and I think I, I would love to say that, you know, we were such amazing recruiters that we were able to do that like intentionally, but instead we, we just got really lucky. And so like we hired William Borgeaud, like, I think now, like one of the top in my very biased opinion, one of the top like applied cryptography engineers in the world. And we just randomly met him at an event in the bay area. And he had to like fly back to Switzerland and like two weeks or something. And so we moved really quickly. But we were a small team. I, I think for all of 2020, I think we were just four or five people. And so we really focused on, on trying to like piggyback on the great work that other teams were doing. Like Aztec, the PLONK authors were doing a lot of work, not, not just on PLONK, but on sort of building the conceptual framework work around custom gates. The Zcash team was, was building Halo. And so in 2020, we initially like our first stab at at building more efficient recursion was an implementation of, of Halo that used PLONK and custom gates. And so I think for, for context we improved recursive efficiency from like two minutes to like 10 to 15 seconds,

Anna Rose (14:39):
Just with that, with that combination PLONK plus Halo.

Brendan (14:44):
Yeah.

Anna Rose (14:44):
And that was Plonky right?

Brendan (14:45):
Yeah. Yeah. Yeah. Plonky one.

Anna Rose (14:47):
Plonky one, by the way, just, just a, you just mentioned William, I just wanna highlight, like, he was actually on the show, he was the winner, one of the winners of the ZK Hack competition. And we actually had a chance to chat with him as well. So you had this tiny team, you had started to create some of the research and actually contribute back into it's like, it sounds like at the beginning it was like a lot of scene research implementing research, but at some stage it shifted to you actually contributing more into the research pool at that point, your four people, how did you actually approach it? Like, were you doing implementations or were you doing research?

Brendan (15:27):
So, so at that stage, I, I think it was purely implementations I mean, there, there was a little bit of work. I mean, Daniel, you you'd have more context than, than me, but a little bit of work on like building more complex, custom gates.

Daniel (15:40):
Yeah. I I'd say it's more on the implementation side. We, we've always been more on the implementation side. Sometimes we take different primitives that weren't really to be used together and put them together. We, we have made a few tweaks here and there to the primitives that were already established. For example, you know, the proving system PLONK is really designed to be used within a large elliptic curve field. And we use it in this really small 64 bit field, which sort of breaks some of the sound, this analysis in the PLONK paper. So we, so we had to do a slightly different analysis and figure out like, which checks do we need to repeat? Or how do we, how do we make this work in the field that we want to use?

Anna Rose (16:26):
Why did you actually need the smaller elliptic curve or finite field for that? What, why was that?

Daniel (16:35):
We're just very focused on performance. And in Plonky one, we were able to get decent recursion speed, but it really, the, the bottleneck, there was just field arithmetic for, especially multiplying two field elements. It's basically the same technique that, that is taught in grade school, where we have this quadratic blow up of intermediate results and it ends up being fairly expensive. So with, with a standard 256 field multiplication takes something like 80 cycles on a typical CPU. And our idea was that it, it would just be really nice if we could use a 64 bit field since CPUs can natively do 64 bit multiplication with a throughput that's very, very high.

Anna Rose (17:27):
Did this have anything to do with like Ethereum's kind of limitations? Were you trying to fit into what Ethereum, what allow or was this purely because the speed was too slow?

Brendan (17:38):
So, so both so ethere on Ethereum. You can't really verify Halo proofs because if you think about what a Halo recursive proof is, it's really like an incremental, like verification step. So, so you're, you're, you have all this this computation that you need to check for the proof, and you're sort of like updating an accumulator that you can then check in the final verification step. And so that, that final verification is too expensive form on Ethereum. And so we, we really wanted, I, I mean, the goal was something that was really, really performant and also was like natively compatible with with Ethereum and with other chains. And so that kind of brought us to, like in early 2021, Daniel was, was like, like, yeah, I, I, I really think we can do recursive FRI. And I, at the time I was not a believer.

Brendan (18:35):
I, you know, fractal had had come out and, and it was super interesting work and like this really big breakthrough, but their concrete performance with fractal was like, it took 10 minutes to, to generate a recursive proof. And so like, just looking at where the, the state of the art was, it, it didn't seem like it was reasonable and yeah, I was totally wrong. And, and so Daniel came up with and William and, and the rest of the team came up with some really, really interesting techniques. And, and I think it gets to like this deeper insight that Daniel was describing, which is like, usually when we think about performance and efficiency we think about it like asymptotically, like, oh, we have these operations. And I think that there's this, there's this tendency to forget that like 256 bit field operations that you need for elliptic curves, like are actually much slower than than 64, but field operations. Even if you have to repeat some checks in the 64 bit field. And so I think that, that, that was like a really simple observation, but it, it kind of laid the groundwork for Plonky2.

Anna Rose (19:42):
I kind of wanna keep digging into this a little bit deeper, so I, I wanna understand what part of this, like you, it sounds like you had to optimize, you had to change PLONK a little bit, it in order to work with Halo more efficiently, or am I, or like, I'm kind of trying to understand where like, in that combination, so you're putting PLONK and Halo together. What part are you changing and how?

Brendan (20:06):
So initially Plonky1 was PLONK and then Halo is sort of the polynomial commitment scheme and I guess, recursion approach. And, and so we decided to take out Halo and replace it with FRI which is the, the polynomial commitment scheme or testing scheme used in in STARKs.

Anna Rose (20:25):
And this is sort of your step towards Plonky2, though, right? Like this is where you're like, oh, and actually, where, where did that breakthrough come from? Where were you like, oh, we could do this. Like, was it because Halo sort of hinted at some sort of characteristic that was similar to FRI, but didn't quite do it the way you wanted, like, had you seen some parallels between those two systems?

Daniel (20:50):
I, I think we had some influence from the fractal paper and implementation, as Brendan mentioned, fractal implemented recursive FRI. And at the time it was very slow, but we, we had some discussions with Dev who did the prototype of that. He was sort of optimistic that even though it takes 10 minutes right now that there might be a ton of ways to make that much better. So, yeah, I think that's where we got the basic idea from. And then we just started putting pieces together and looking at like, what if we combine this with PLONK? And then what if we arithmetized it in a certain way, how fast can we make this?

Anna Rose (21:30):
Can maybe we should actually dig into what FRI does differently. So PLONK is a proving system you're using PLONK for both of these are using the same PLONK for both. Or had you adjusted PLONK as well, or used a different updated version? I don't know if you call 'em like

Daniel (21:49):
Yeah, in Plonky one we basically used PLONK as is because we were using the typical size 256 bit field back then. The, the only change was that we used Halo instead of KCG based polynomial commitments, but then in Plonky2 two...

Anna Rose (22:08):
Ah inside Plonk. Okay. I get it. So like PLONK originally was using something else and you replaced part of Plonk with Halo. Got it.

Daniel (22:15):
Yeah. And, and then in Plonky2, we made a few more changes to Plonk. It's still really based on PLONK, but now since we're using a smaller field, we had to redo some of the analysis and repeat some of the checks that Plonk does in order to achieve the soundness that we want.

Anna Rose (22:35):
Would you, I mean, would you call Plonky2 an extension of fractal then? Like, could you say that it is actually like fractal 2? Like, I'm just curious why

Brendan (22:47):
Fractally too.

Daniel (22:50):
Yeah. I I'd say it was somewhat inspired by fractal. We didn't really use any of the arithmetization that fractal uses. So technically they're not too similar just that they both use recursive FRI.

Anna Rose (23:05):
Got it. And in your presentation, Brendan, at ZK day in fall, you had said that Plonky2 consists of Plonk plus FRI plus wizardry. So tell me

Brendan (23:17):
Very obnoxious.

Anna Rose (23:19):
Is there another, is there anything else sprinkled in there that we should know about?

Brendan (23:24):
Yeah, so, so I mean, the way that I sort of look at it is it's not like a, this amazing breakthrough to decide like, okay, Plonk is a, is a SNARK or an arithmetization , an argument system and FRI is a polynomial commitment scheme. We know that we can use these together. So let's just like put them together and see what happens like, but I think the really cool work was in building the actual arithmetization to make certain things really, really efficient. So like in Plonky2, we use a really wide, circuit model. So there are a ton of wires and this allows us to do beside and, and which is a hash function, very cheaply. And so I think both that the like circuit engineering level, and then at the, low level optimization level, like we found this, this really cool prime, which is, our teammate Hamish called it the, or named it, the Goldilocks field. So it's defined as, 2^64 - 2^32 +1. And so it has this like really, really nice structure for, CPUs and for doing arithmetic - really efficiently. And so I think like it, the wizardry part just refers to really, really solid engineering work, that was done at, at both of those levels.

Anna Rose (24:42):
I'm curious, like, what's the outcome, you know, you're, you're talking about it's, it's improved basically on the original Plonky, but what had changed. So like now is this something that could be verified on Ethereum? Is this something that, you know, does it have certain characteristics that are new, I'm curious to hear?

Brendan (25:05):
Yeah. So, so the upside is that it can be verified on any smart contract platform that supports cryptographic cash functions, which is huge. And, and it is really, really performant. So previously our recursion performance was about 10 seconds and now it's 170 milliseconds. And so we were super proud of that and like getting below a second for recursion efficiencies is cool. And there are a bunch of other like performance benefits for like, beyond recursion for making like arbitrary proofs really fast.

Anna Rose (25:39):
When you talk about this performance, are you talking about the performance of the verification or the performance of the proof generation?

Brendan (25:47):
Of the, the prover.

Anna Rose (25:49):
Of the prover, but this is, is this happening in a smart contract on Ethereum or is this happening sort of off chain?

Brendan (25:56):
So it, it would be happening off chain. Okay. so you generate a proof off chain and then the, the verifier is really fast too. The proof sizes get a little bit bigger, but I, yeah, I have a personal rant on why proof sizes don't matter for blockchains, but I can save that.

Anna Rose (26:13):
And yet you've worked on improving that or wait, when you say proof size, is that different from proof time?

Brendan (26:21):
Yeah. So, so proof size is like

Anna Rose (26:23):
Okay, sorry, sorry.

Brendan (26:24):
Yeah, no problem, yeah. So, so the prover is faster. The proofs get a little bit big, but I would argue that that isn't, isn't really ....

Anna Rose (26:32):
Well, yeah, to me, it's like, if you're looking at efficiency, you're really, you care mostly about how quickly it can be verified. So if the verification time doesn't change and the proof generation time is faster than I guess it is good. I don't know.

Brendan (26:47):
We, we think so

Daniel (26:49):
If we're sending the proof to Ethereum, we do have to pay attention to proof sizes because Ethereum charges. I think it's currently 16 GAS per bite of transaction data, but, there is a proposal to reduce it quite a bit in order to help scale rollups like ours. And if that goes through, then our GAS cost on Ethereum will actually be just as low as any other proof system.

Anna Rose (27:17):
But this is, this is dependent on like an EIP. That's always a little challenging, those, those take oddly long times, but do you feel like, is this a noncontroversial one that you think will pass?

Daniel (27:32):
I, I think so there, there was some pushback about passing it immediately, but I think the pushback was mainly around testing and, you know, it's kind of a drastic change to be pushing through quickly without so much testing and development.

Anna Rose (27:48):
Do you know which EIP that is?

Daniel (27:49):
I think it was 4488.

Anna Rose (27:52):
Okay. For anyone who's not familiar, EIP is what is, what does this stand for?

Brendan (27:57):
Ethereum improvement proposal.

Anna Rose (27:59):
Yeah. And I guess there's probably some documentation on this. This needs to then go through sort of the, the soft governance to before it gets implemented. I just realized in this conversation that I had never really understood, I never really dug in on the impact of proof size. Tell me a little bit more about this gas price idea. So maybe give me a few numbers. So right now that you, you mentioned like the proving time, I think you said was 170 milliseconds, is that correct?

Brendan (28:30):
To generate a recursive proof

Anna Rose (28:32):
To, to generate a recursive proof? Is that the last proof to go and be verified?

Brendan (28:38):
Yeah. So, so we can like wrap there. I'm not sure how deep we wanna get in in this. Go for it.

Anna Rose (28:44):
Yeah.

Brendan (28:44):
Yeah. FRI has this parameter called the blow up factor. And so there's this really cool trade off between proof size and proof time. And so for us, when we're generating transaction proofs, we want to minimize proof time and we don't really care about proof size, but then at the end, once we've recursively aggregated all these transaction proofs, we are now paying we're, we're metered on proof size. And so we want to change the blow up factor so that we can minimize proof size. So there's a slightly more expensive proof that occurs at the end of that process, which is basically to shrink the proof that is the final step before going to Ethereum.

Anna Rose (29:24):
And this is the recursion.

Brendan (29:26):
Yeah. So, so the recursion would be in like the intermediate steps, like, like we, like, we have this this set of transaction proofs and we want to like recursively aggregate them. And so we put them into a tree and each of the intermediate nodes is a recursive proof.

Anna Rose (29:42):
Got it. But at the very end, you wouldn't call that a recursive proof as well. You called it compression.

Brendan (29:48):
We, yeah, we definitely would, it just has a different cost, so it takes longer than 170 milliseconds. And, and it's really like, it that's 170 milliseconds for like a one to one recursion. And so if it were like two to one, it would take a little bit longer.

Anna Rose (30:03):
I see. And when you say one to one, it's like a proof recursed one, like one proof recursed, but if you tried to combine two and recurse them into one, that would be double the time.

Brendan (30:15):
Yeah. Roughly.

Anna Rose (30:17):
Okay. What is the time on the last one on this last recursive proof?

Daniel (30:21):
Yeah, I'd have to double check, but I think it's under 10 seconds now. There, there are a lot of knobs that we can turn. If we want to get it down to one or two seconds, then it would just be slight, a slightly larger proof, but wouldn't really make much difference.

Anna Rose (30:36):
I wanna kind of go to the other end of this. Like you sort of had painted this picture. We're kind of focused very much on this last proof. That's verified on chain, but like how much can you put into this? Like, I'm kind of like, let's go further back towards the actual rollup part of it, the action. Like how much are you able to batch or put into this thing? And maybe if you can compare it to anything, we already know

Brendan (31:05):
The tree depth for the, the tree that contains transaction proofs that the leaves. And we aggregate into a single proof. That's not really bounded by like, at least in any practical sense. And so we can take a lot of, a lot of proofs and, or a lot of transactions and then recursively aggregate them. It's, it's a slightly different approach to like StarkWare where we have a batch and we're generating a proof that proves validity of the entire batch. We are taking a single transaction proving that that transaction is valid and then aggregating all of those proofs into a single proof.

Anna Rose (31:39):
Mm. And going step by step, I guess. So you're doing multiple recursion. Is there a similarity here to like the Mina system where they're also using recursive proofs, like deep in the actual L1?

Brendan (31:54):
Yeah. Yeah, definitely. I, I, I think they were sort of the pioneers for, for this approach. And I think since it's been a similar approach that's been taken by Aztec and zkSync and there are probably other rollups as well.

Anna Rose (32:10):
What would you say? Like, you know, you sort of said that there's a lot of, it's quite high. Like the amount of transactions could be quite high. Is there any limit, is there anything that you would say, like, you'd want to cap before you do one of these? Cause like I way I always understand this is like, you're kind of, you're doing a rollup after a certain amount of time. I'm maybe also thinking a little bit more on like the Arbitrum episode that I did. And like, and after a number of transactions, you're kind of doing a check-in point with the main chain. How are you thinking about that? Like, do you want to decide, oh, we, we do wanna cap the transactions maybe even just so that there's not so many layers of recursion, cause I'm guessing each one of those costs something in terms of time.

Daniel (32:53):
Yeah. I I'd say there are a few potential bottlenecks. So one is just sequencing before we begin this proof generation process, we need to put the transactions in order in such a way that there are no conflicts, no invalid transactions. So that's not really about proofs. That's just kind of the traditional blockchain bottleneck. And then besides that, there's just could potentially be sort of an economic bottleneck where we just don't want such a huge number of proofs that it becomes very expensive to generate all of the proofs.

Brendan (33:28):
Yeah. We're, we're, we're sort of limited because like we're paying a fee every time we want to, to have a proof verified on Ethereum. And so we need to like amortize that cost across transactions that are submitted to each block. And so you sort of want to fill, or like pick a batch size that you sort of have a decent assurance that you'll be able to fill. So it's cheaper.

Anna Rose (33:52):
Got it. I actually, in thinking about a system like this, like recursive Snarks, I mean, I had this episode with the one sub for Zkopru and he made this comment that rollups are just DApps. And then I was like, what? Then I was like, that was a little bit mind blown, but I realized this is something I'm curious about, like in a roll up like yours, where it's recursive and, and since it's built, like there's an on chain smart contracts, there's an on chain, is each recursive step actually also interacting with a smart, is that like happening within the smart contract? This is where I'm like maybe a bit confused, I say sort of off chain, but like, can you kind of explain what at what points the smart contract itself on the main chain it's doing something.

Brendan (34:38):
Yeah. So, so every time a proof comes back, so all of the proof generation happens off chain. That, that's funny. That example, because that's, I I've been trying to explain that to people outside of crypto in that, in sort of a similar way, like you're effectively depositing your funds into the smart contract. And you're basically just like giving it to some guy to some like committee and they can do whatever they want, but at the end they have to, they're sort of forced to behave, honestly, because they have to produce this proof in order to, to verify a state transition. And so the smart contract just handles the bridging logic and then verifies each new proof.

Anna Rose (35:19):
But on every step, this is the question I have, like, does it verify each step in the recursive process?

Brendan (35:25):
Just the end,

Anna Rose (35:27):
Just the end. Okay. It is just doing the end, but then, but then why is it expensive? Cause you use that term expensive for the different, like the, the, before the last proof proofs.

Brendan (35:38):
Yeah. So, so it it's just, I think like pre EIP 4488 it costs like a million gas to to verify a Plonky2 proof. It's an estimate because we haven't done the implementation yet. And then after we anticipated it'll cost about 200,000 gas. And so that's just like an expensive transaction. And so you want to kind of minimize that if you want to deliver low fees to users, the proofs in the recursion tree, when they like, before we compress that last proof, they would be really expensive because the proof size is just bigger. So if we didn't do the compression step and we just sent it to Ethereum, then we would just pay more gas.

Anna Rose (36:21):
Okay. But it, because there's that final recursive start, it will be consistent actually. You'd have, it's not that if you include more transactions or you add more layers of recursion, that that last one would actually be more expensive. That's always gonna be I guess consistent.

Brendan (36:36):
Yeah. You, yeah, exactly. And so, so that's a really nice thing. Obviously not to take anything away from StarkWare, we heavily like use their research and, and like, they're amazing, but they end up paying more gas under their current approach because the size of the proof depends on the batch size. And they have to sort of make this trade off between proving time and proof size. Whereas we can sort of get the best of both worlds where we can optimize for proof time when we're generating those proofs and then optimize for proof size at the end. And that circuit that we're optimizing for proof size is really small. So as Daniel said, it only takes 10 seconds to compress.

Anna Rose (37:19):
Could they do something similar though? Do you think they will?

Brendan (37:22):
Definitely.

Brendan (37:24):
But we so, so I guess uh William just finished. So, so we did Plonky2, which is recursion and we used STARKs like air based STARKs for our transaction proofs. And so William just finished the recursive of STARK verifier. And so I, I think we're going to rebrand to recursive StakWare.

Anna Rose (37:46):
I dunno if you're gonna be allowed to do that. That's good..

Anna Rose (37:55):
Yeah, this is cool. And actually this speaks to maybe a question I have about some of the other teams you're mentioning Starks and I have had Bobbin Threadbare who's doing the Miden work at Polygon as well as Jordi and David from Hermez, but on the Miden front, I think it was in that episode that he mentioned this recursive STARKs. And it's interesting though, that your team is doing it. And I'm curious, like, would you say like, is Miden and Polygon Zero distinct entities or are these like the same thing? Because like, are you, are you tackling a problem from opposite sides or are you actually working together?

Brendan (38:35):
Yeah, so definitely working together. We're, I think I would say exploring different parts of the design space. So all three of us Hermez Miden and zero we all use STARK VMs. Okay. And there are a lot of design choices and it's unclear, like which will be best suited for verifying Ethereum transactions or Ethereum compatible transactions. And so I think it's been super nice to be able to work with, like we work with Bobbin and really closely, and it it's been really good to, to see sort of his research on STARK VMs and then be able to kind of cheat off his paper a little bit and incorporate some of his work into, into what we're doing. And, and vice versa, like he's using the Goldilocks field. And and so, I mean, I've been like really pleasantly surprised since we've joined Polygon at the level of collaboration and, and how useful it's been both with Hermez and, and with Miden

Anna Rose (39:36):
It's a really interesting constellation that has been put together. Do you feel though, like, are all three projects moving away from the SNARK? Like is, is the SNARK going to be tossed to the waste bin? So much for SNARK-tober? We're gonna need something else?

Brendan (39:56):
Well, I mean, if...

Anna Rose (39:57):
Stark-Tober maybe?

Brendan (39:58):
Maybe, maybe that would make Eli Ben-Sasson really happy. Yeah, but

Anna Rose (40:04):
Was it STARK? Was it SNARK-tember or SNARK-tober? I forget which one came first.

Brendan (40:08):
I think it was SNARK-tober. Yeah. Yeah. I mean, I think just to be pedantic, like Plonky2, I think is still SNARK because we do like the processing step. And, and so, but I, I, I do think that, that you're, you're getting it, or you're making a really good point, which is that the, like the line between like, oh, these are STARKs and these are SNARKs is sort of blurring to everyone except like the very precise, like academic that enforce like definitions that, that in the blockchain sense, don't, don't necessarily make that much of a difference.

Anna Rose (40:42):
And do you feel like, cuz it does sound almost like these hybrid Frankenstein? I'm sorry. It's not a better like combinations of these pieces of these different protocols that all get put together and then walked around a little bit. Sorry, I just keep going with it Franken-SNARKs.

Brendan (41:00):
I think, I think Plonky2 is beautiful. So, so I, I strongly object to the Frankenstein characterization, but for the record. But no, I, you you're totally right. I think people are, are just experimenting at this point and, and, and I think definitely with the work that we've done, I think that a lot of people are, are taking a second look at FRI and sort of some of the design choices and, and properties that, that different systems have.

Anna Rose (41:27):
Why do you work on this? Like what, what is the goal of this work to make it more efficient to make it cheaper? Like, are you also working towards sort of this ZK EVM model that we had talked about with Jordi, which is this idea that you would have, you know, an EVM working as EVM works, you know, within a rollup, or is your goal at Polygon Zero different?

Brendan (41:54):
So I think the, the eventual goal is the same, but the, like, I think Polygon has the luxury because of how big it is and because of how successful they've been and actually attracting users and developers they have the luxury to explore the design space. And so what the Hermez approaches is, it's so super cool. They're trying to like take EVM bitecode and actually simulate its execution in a SNARK. And so we're taking a different approach, which is, let's try to develop a VM that runs in a STARK that's really, really efficient. And then let's see if we can take Solidity or Yul code and compile it to byte code that executes in that sort of computer running inside a Stark.

Anna Rose (42:41):
This is a little bit more like the zkSync approach too. Right? Like they work with like under the hood, there's something else like the op codes are different, but there's a, a way to compile Solidity into what they need to, what that machine needs to read. Would you say that like Miden's approach is similar? Like, is that cuz I think that's what we had talked about actually with Bobbin and so under the hood, there's going to be kind of different op codes, a different system. Would you want eventually to have native a native language to write on that? Would you, would you only focus on this EVM compatibility with this, with the compiling down or would you also potentially be trying to develop something under, under the hood that people can directly interact with? Basically. Do you want like a, a native DSL at some point? I think I just, I think I repeat it. I don't think you say native DSL, do you, I think you say DSL. No, I know.

Brendan (43:35):
No. I think that's it

Anna Rose (43:37):
Like native domain specific language anyway

Daniel (43:41):
I would say a lot of the design choices that we're making as we're designing this VM are really tailored to Ethereum and, and tailored to what kind of operations or computations Ethereum apps are doing. So if we were to design something that's really separate where we're not compiling from Solidity or Yul, then I, I think we would design it differently and we would use more native field arithmetic and less binary operations. Because you know, the Ethereum apps do a ton of binary operations. That's really been, our focus is how do we take those and make them relatively efficient as much as we can, but it's, it's not really a great fit for STARKs. So if we were really starting with a clean slate, I'd say we would design things fairly differently.

Anna Rose (44:33):
Do you imagine, I mean, I had this chat a little bit with Mihailo this idea of like EVM as currently like the end goal, because there's so many solidity devs and people are familiar with it. The contracts exist to redeploy on EVM compatible chain is very easier right now. But like I think the question I had was like, are you also evolving EVM? I was in that episode, but like, are you also evolving it? Are you thinking about changing it? So it doesn't actually, it's not exactly one to one.

Brendan (45:03):
Yeah, I think so. So a good example is we profiled a bunch of Ethereum transactions and the average Ethereum transaction makes SHA-3 or makes 13 SHA-3 hash notifications. And those are really, really inefficient for sort of computing inside a SNARK or STARK. And so we are switching that out as much as possible with STARK friendly hash function beside. And so I think the, there will be a lot of changes there in terms of like functional changes. I'm not sure what, what do you think Daniel?

Daniel (45:39):
Yeah, I'd say right now we're focused on how do we get to 99% compatibility? So we're taking, making a few tweaks, like Brendan mentioned that could potentially break strict compatibility, but for the vast majority of applications, it should be fully compatible.

Anna Rose (46:01):
Mm. So it sounds like, it sounds like you are more like looking you're you're, you're not necessarily gonna change this, but you're trying to get as close as possible to it. Do you think, I mean, this is more philosophical though. Do you think like this maybe is even a, a question for the whole Polygon or maybe whole Ethereum? I don't wanna say competitor, but like the EVM compatible world, like, is this something that will evolve past what that is on Ethereum eventually? And I I'm throwing it to you guys. I know you might not, maybe this isn't something you're thinking about, but

Brendan (46:38):
Yeah, maybe a little bit above my pay grade, but I think it's, it's really hard because you want to maintain backwards compatibility for existing applications on Ethereum. And so I think making really significant breaking changes to the EVM is just hard. I think it's sort of an open question. Whether another chain will come along, like the, like certainly there are, there are aspects of the EVM that I think in retrospect, everyone agrees or maybe not the best design decisions. But I think this is sort of cliche, but I think a lot of people would say that that's sort of how technology evolves and you know, the best tech doesn't always win. And so I, I think it'll be really interesting over the next five years to see how the EVM evolves, how sort of the crypto landscape as a whole evolves and whether there are like whether other chains or other programming environments pop up that just give like a uniformly better experience relative to the EVM. That's not our focus, but yeah, just a sort of interesting question.

Anna Rose (47:44):
Yeah. And that's, that's sort of the question for cuz I know that the Polygon project and the teams are very, very Ethereum focused, but I wonder like with the research and the, the construction that you've created, like, could you, I mean, I assume, I assume you could, but you could you have a different like VM compile down to what you have underneath the hood I'm guessing yes. You just have to create different logic.

Brendan (48:08):
Yeah. I think that the, the question would be whether it would be because we're making so many design decisions that are sort of tailored to the EVM and EVM compatibility, whether something else would be more inefficient or, or whether it would be better to, to create another VM that makes slightly different design decisions, like maybe a heavier use of, of native field elements or something like that. And then that might be a better option to compile to.

Daniel (48:37):
Yeah. And I think Cairo is a very interesting example of how we could do this, where they have Cairo itself, which is not really designed for Ethereum at all, as far as I know. And then they of this compiler, which translates Yul intermediate code down to the format that Cairo uses. And I think that that might not be the best approach if we want to make Ethereum applications as fast as possible because ideally the internals of Cairo would be designed for based on what competitions are done in the EVM. So our approach is really to make the VM very tailored to what's happening in the EVM, very focused on making binary operations as fast as we can. And then I, I, I think if we wanted support a brand new language that was more SNARK friendly, we would probably do that as a separate VM instead of compiling both to the same format, we would probably come up with a completely different format. That's not really tailored to the EVM at all.

Anna Rose (49:46):
Mm. And I know that actually like on the Miden inside, that's what Bobbin is doing in a way. I know that there is a different language and a different VM.

Daniel (49:57):
Yeah. Yeah. I think there's an assembly language right now. I, I think there is maybe a little bit of influence. It is basically a binary machine that deals with binary 32 bit in integers. And I wonder if he might have done it differently if it weren't for the goal of EVM compatibility.

Anna Rose (50:19):
Hmm. I wanna ask you keep mentioning this term Yul actually don't know what that is. What is that?

Daniel (50:26):
Yeah, it's a intermediate code format. That's the solidity compiler compile solidity code to before it's converted to EVM instructions.

Anna Rose (50:38):
Okay. And what you're saying is Cairo goes Cairo-Yul base,

Daniel (50:43):
I think for, for StarkWare Yul is converted to the format that Cairo uses. But it, I haven't really taken a close look at it.

Brendan (50:52):
So it, it would go from Solidity to Yul to we, we're calling it ZK byte code or system zero byte code or something.

Anna Rose (51:00):
Okay, cool. That's actually really helpful to, to parse that. Can you tell me a little bit about how, how you picture, like once this is developed and you have this sort of functional EVM running, like you can basically, or EVM compatible underlying chain and, and actually, I, one of my questions is where are you at? But like, let's get to that after. Like how would it actually be working? Like, would you then a roll up, is that kind of the end goal that you're a rollup? Or do you have, like, I don't know, some other format you picture yourself becoming.

Brendan (51:36):
Yeah. So I think our focus is on and, and this isn't novel to us. Starkware and zkSync have also kind of proposed this, but rollups end up being a lot more expensive than what's called a validium. And so, so keeping transaction data off chain for most transactions allows us to, to kind of compete for users with, with side chains and with alt L1s. And I think that what the success of Polygon has really demonstrated is that like different users require different trade offs between cost and security. And so I think being able to be flexible and give like high value accounts, access to a ZK rollup where they know that data will be made available on Ethereum and giving more fee sensitive users access to be able to make transactions on like a side chain environment that still guaranteed by zero knowledge proofs, I think it's kind of the way forward for, for us.

Anna Rose (52:37):
So you are going to do that opt in, opt out. What does that look like actually, like, is there a, does somebody have a dashboard where they can choose this or is it like they're acting within a different system? Does the DApp, like the contract deployer actually make that call?

Brendan (52:52):
Yeah, so, so I think the the contract deployer would make that determination. It, it might also be possible to do it at the transaction level, but I think it would be at the, the contract level.

Anna Rose (53:05):
Mm there's also a concept that's been floated in the talks that you've given, or like, maybe be just general Polygon talks, which is horizontal scaling. What is that? What is that in this context?

Daniel (53:17):
Yeah, just the idea that using these recursive proofs, we can really scale out to a large number of transactions. We can parallelize the work so that we have many machines generating these transaction proofs. And then as we build this proof tree, we still use this high degree of parallelism to scale to a large number of transactions without really sacrificing latency.

Anna Rose (53:43):
I think when I heard it, I thought you meant sort of like additional rollups. So like new rollups separately acting in a, in this horizontal way. But what you're talking about is within a single kind of rollup or validium, basically within like an instance of Polygon Zero, you'd be doing this horizontal scaling by this recursion at the different levels.

Daniel (54:08):
Exactly.

Anna Rose (54:09):
Do you envision though, a world where you do deploy Polycon Zero, multiple times, or do you really picture it being like a single instance?

Daniel (54:18):
I, I'm not sure if that would work well, because when we have contracts interacting that are on different rollups, then users might have to exit and enter another rollup. But maybe if, if there was an application that, or certain applications that really didn't have other dependencies, maybe something like a game that doesn't really interact with the rest of the ecosystem, then that I think that could work where it's on this rollup. That's not really the main rollup. That's just used to help scale.

Anna Rose (54:53):
Also, do you have a validator set? Like, do you actually have some internal security or are you purely dependent on the mainchain security?

Daniel (55:01):
Yeah, so our design is almost like a side chain where we have our own committee of voters who are voting to commit blocks on this, a separate chain. So it, it it's like a side chain in a lot of ways, but without the security drawback of a side chain, since we have validity proofs, then these stakers can't just vote to commit something that doesn't make sense or that contains double spends or anything like that.

Brendan (55:30):
I, I think the Hermez team has proposed a few different ways to avoid having a separate validator set, but we, we see kind of like for us, the lines between being a separate L1 and being an L2 are, are really blurry, especially when validity proofs are involved. And we, we see like a validator set secured by Matic sequencing transactions and then generating proofs,

Daniel (55:53):
Maybe just to add to that, I think our system will actually have three levels of finality because of this design. So the first level would be when the voters on the side chain decide that they've, they've all voted to commit some block, a block on the side chain. The second level would be when proof generation has completed for that block. And then everybody knows that the block is indeed valid and the final level would be when the checkpoint has been sent to the Ethereum bridge, that would provide a stronger guarantee because then we know that there can't be any forks unless the L1 itself has a fork.

Anna Rose (56:36):
Okay. Interesting. I think we're kind of getting close to the end of this interview and I realized there was a question I forgot to ask earlier on. And that was what, like, what was the name Mir? I think when I was trying to get you on the show originally, that was one of the questions I had wanted to ask, and I realize you're not using it anymore, but what is it?

Brendan (56:57):
So, so that's a really pretentious meaning, which I think I, I maintain it like kind of cool. So in the 19th century, when Russia was so operating underserved them there were these Russian political theorists and philosophers that were trying to come up with an alternative form of organization that would be kind of distinctively Russian. And so they came up with the Mir, which is like this self-governing collectively owned commune that huh. Yeah. And so the, so, so that's fine. It's you know, great. The problem is that no one can pronounce it or spell it. I think the ticker was already taken, so it, it was a pretty easy decision to to rebrand.

Anna Rose (57:39):
That's good. Well, thanks for answering that burning question that I had for for many years. And I guess it won't matter anymore because you're using a different name, but also good to know. Cool. Well, I wanna say a big, thank you to both of you for coming on the show and exploring like kind of walking me through what Polygon Zero what it was, what it's become, I guess I do have a last, which is what's next. I, I do wanna hear if you have any upcoming things that we should look out for.

Brendan (58:11):
Yeah. So I think I think recursive STARKs have been like recursive verification of air based STARKs has been completed. And we're going to be releasing more about our VM and our a compiler in the not so distant future.

Daniel (58:28):
Yeah. I'd, I'd say right now we're very focused on getting EVM support working, which is a fairly large project, especially things like we have smart contracts that create other smart contracts and then do yeah. All, all kinds of stuff like that. That is a little bit complicated to support that we're working on right now.

Anna Rose (58:48):
Cool. I also wanna just highlight that if anyone is interested in learning more about what you've been talking about, you'll be presenting at ZK Hack on March 8th which should be coming up very soon and yeah, you're gonna be giving a talk on Polygon Zero and the work you're doing. Yeah. I'm excited to see you there. And I wanna say a big thank you again for coming on the show.

Daniel (59:10):
Thanks for having us.

Brendan (59:12):
Yeah. Thanks for having us Anna. It was a lot of fun.

Anna Rose (59:14):
Cool. I wanna say a big thank you to the podcast producer, Tanya, the podcast editor Henrik and to our listeners. Thanks for listening.