Episode 220: The Road to Plonky2 with Brendan and Daniel from Polygon Zero

Transcript

[Music] welcome to xero knowledge i'm your host anna rose in this podcast we will be exploring the latest in zero knowledge research and the decentralized web as well as new paradigms that promise to change the way we interact and transact online this week i chat with daniel and brandon 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 fry which is borrowed from starks that makes up plonky too 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 want to remind you to head over to the zk 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 hermes ef and protocol labs there already so be sure to add your jobs there as well i also just want to 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 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 want to 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 hop in and be notified when they're happening so i hope to see you there so now i'll let tonya the podcast producer share a little bit about this week's sponsor today's episode is sponsored by elio elio is a new layer 1 blockchain that uses cutting-edge cryptography to achieve the programmability 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 zkp's to build the next generation of private applications like front-running resistant decentralized exchanges hidden information games regulated stable coins and more visit elio.org to learn more about the protocol or roll up your sleeves and go to leo-lang.org to start building that's leo-l-a-n-g.org so thank you again elio now here's anna's interview with daniel and brendan from polygon zero [Music] today i'm speaking with daniel and

brandon from polygon zero i want to say welcome to the show to both of you thanks anna yeah long time listener first time caller here yeah thanks for having us on 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 mirror um 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 want to 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'd really like to hear a little bit about where does this start let's go back in time to mirror 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 yeah i mean for me i think it begins like with how i got into this space and and that was uh wandering into this uh stanford auditorium when i was living in the bay area where uh vitalik and dan bernay and uh i think a few others were presenting the original plasma paper and there was this moment during that talk

when it was sort of like this offhand comment when uh dan bernay was like he said something like 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 um 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 and so we decided to i guess in 2019 start mirror which was i guess the the premise was just to use um snarks to provide privacy and scalability for for blockchains cool yeah i guess for me 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 google glass i hadn't thought about that in a while the kind of what was it ar goggles glasses i guess yeah it was really the the hot fun project going on at google back then but unfortunately it got cancelled 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 thought it was really

a 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 um so that's when i went to the zcash conference and met brenton this is in montreal right this is econ zero i was also there 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 um and so that's very cool that you met there you met at z con zero in montreal the first zcash conference um 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 yeah so so i think we were both sort of like playing with different ideas like and then 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 hand so so i think there was like a certain uh incentive to to like do something and yeah we sort of started talking about doing like an infrastructure project like mirror like a new a new blockchain and yeah kind of kind of went from there 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 um what were the first kind of iterations of this like what technologies were you actually experimenting with what what did you plan on building when you started yeah so so i guess we we started talking really seriously in october of 2018 and that's uh right when the original sexy paper uh came out and so that was sort of a good signal because it was like oh 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 sexy and then we found that uh there were some limitations with zexi like it couldn't support um applications that relied on shared state like amms and a lot of the defy applications at the time and so we were trying to to come up with a design that supported those applications uh and also provided scalability with with recursive proofs um so so that was sort of i think the premise i remember like i think we met at the zk summit 4 in san francisco the last in person one that that i did until the next one which is coming up um but

yeah you gave a workshop and i believe at the time it was a workshop on sexy 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 that's 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 how how did you envision this project at that time yeah so so i think at the time uh we had this thesis and in retrospect a lot of it was pretty wrong um so we thought that there was room for a lot of l1 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 to move to this new environment and and that ethereum wouldn't uh accrue like such a big part of the developer mindshare and i think that we can say you know with some caveats that that was not true and that uh it's been really striking how uh in the interim ethereum has really become the focal point for building web 3 and uh crypto applications and and so i think for us like the this realization that ethereum and l2 was kind of where the energy was uh and where like real users 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 uh so business development dev relations like things that they do really well um and we could kind of build in in the l2 uh space was something that was like really exciting to us i want to hear a little bit of that interim time though like between you know you shifting away from sexy deciding like had you already decided around that time like actually we're to focus more on this roll-up model was mir originally like once you were developing the the current form was it a roll-up yeah so so the the focus was definitely on some sort of multi-chain ethereum

like we we wanted to be able to to verify uh proofs about mir on ethereum and and develop a proving system uh 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 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 primitives would get there so back in 2019 like planck had just come out like 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 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 skilled election for sure and backing up a little bit in those early days i was actually more interested in building something that that only used zkp's 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 think brenton felt very strongly that we should we should kind of do it the right way and we should actually prove

every transaction is valid uh and 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 wow um so 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 um how were you building your team during this time like you had this vision or you had this sort of like 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

um yeah how are you hiring and like what was your team at this at this stage 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 uh kovitz struck and so 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 um 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 just got really lucky um and so like we hired uh william borgio who's like i think now

like one of the top in my very biased opinion one of the top like applied cryptographies uk engineers in the world um 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 uh moved really quickly um but we were a small team i think for all of 2020 i think we were just four or five people um and so we really focused on on trying to like piggyback on the great work that other teams were doing like um aztec the block authors were doing a lot of work not just on planck but on sort of building the conceptual framework around custom gates

um the zcash team was was building halo and so in 2020 we initially like our first stab at um at building more efficient recursion was an implementation of of halo that used uh plonk and custom gates and so i think for for context uh we improved recursion efficiency from like two minutes to like 10 to 15 seconds just with that with that combination plonk plus halo and that was plonky right yeah yeah yeah funky one plunky one by the way just just uh you just mentioned william i just want to 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 actually contributing more into the research pool at that point you're for people how did you actually approach it like were you doing in implementations or were you doing research uh so so that stage i think it was purely implementations uh i mean 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 yeah

i'd say it's more on the implementation side we've always been more on the implementation side sometimes we take different primitives that weren't really designed to be used together and put them together 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 soundness 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 why did you actually need the smaller elliptic curve or finite field for that why was that um we're just very focused on performance and in plucky 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 um so

with a standard 256 bit field multiplication takes something like 80 cycles on a typical cpu and our idea was that 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 did this have anything to do with like ethereum's kind of limitations were you trying to fit into what ethereum would allow or was this purely because the speed was too slow so so both um so ether on ethereum you can't really verify halo proofs because uh if you think about what a halo

recursive proof is it's really like an incremental like verification step so so you're you you have all this uh this computation that you need to check for the proof and you're sort of like updating an accumulator that you can then uh check in the final verification step and so that that final verification is too expensive uh to perform on ethereum and so we we really wanted i mean the goal was something that was really really performant um and also was like natively compatible with uh with ethereum and with other chains and so that kind of brought us to like in early 2021 daniel was was like yeah i i really

think we can do recursive fry and i at the time i was not a believer i you know fractal had had come out 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 didn't seem like it was reasonable and yeah i was totally wrong and and so uh daniel came up with and william and the rest of the team came up with some really really interesting uh 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 um we think about it like asymptotically like oh we have these uh operations and i think that there's this there's this tendency to forget that like 256 bit field operations uh that you need for elliptic curves like are actually much slower than uh than 64 bit field operations um even if you have to repeat some checks uh in the 64-bit field and so i think that that that was like a really simple observation but it kind of laid the groundwork for plunky too i kind of want to keep digging into this a little bit deeper so i want to understand what part of this like you it sounds like you had to optimize you had to change plonk a little bit 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 so initially plucky one was planck and then halo is sort of the polynomial commitment scheme and and i guess recursion approach and and so we decided to take out halo and replace it with fry which is the the polynomial commitment scheme or testing scheme used in um in starks and this is sort of your step towards plunky too 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 um characteristic that was similar to fry but didn't quite do it the way you wanted like had you seen some parallels between those two systems i i think we had some influence from the fractal paper and implementation as brendan mentioned fractal implemented recursive fry and at the time it was very slow but we we had some discussions with dev who did the prototype of that and 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 planck and then what if we arithmetized it in a certain way how fast can we make this can maybe we should actually dig into what fry does differently so plonk is a proving system you're using plunk for both of these are you 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 them versions like um yeah in plucky one we basically used plunk as is because we were using the typical size 256 bit field back then um the the only change was that we used halo instead of kcg based polynomial commitments

but then in punky 2 that's where planck okay i get it so like plonk originally was using something else and you replaced part of plonk with halo got it yeah and then in plucky two we made a few more changes to planck 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 planck does in order to achieve the soundness that we want would you i mean would you call plonky2 an extension of fractal then like could you say that it is actually like fractal too like i'm just curious why yes

yeah 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 fry got it and in your presentation brandon at uh zk day in the fall you had said that plonky ii consists of plonk plus fry plus wizardry so tell me [Music] very obnoxious is there another is there anything else sprinkled in there that we should know about 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

park is a is a sarc or an arithmetization an argument system and fry 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 planky 2 we use a really wide circuit model so there are a ton of wires and this allows us to do poseidon and which is a hash function very cheaply and so i think both at the like circuit engineering level and then at the low level optimization level like we found this this really cool prime which

is uh our teammate hamish called it the or named it the goldilocks field so it's defined as uh 2 to the 64 minus 2 to the 32 plus 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 um that was done at both of those levels i'm curious like what's the outcome you know you're talking about it's it's improved basically on the original planky 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 uh yeah so so the upside is that it can be verified on any smart contract platform that supports cryptographic hash 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 efficiency is is cool and there are a bunch of other like uh performance benefits for like beyond recursion for making like arbitrary proofs uh really fast when you talk

about this performance are you talking about the performance of the verification or the performance of the proof generation of the the approver of the approver but this is is this happening in a smart contract on ethereum or is this happening sort of off chain so it would be happening off chain okay um so you generate a proof off chain and then the the verifier is really fast too um 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 and yet you've worked on improving that or wait when you say proof size is that different from proof time

yeah so proof sizes sorry sorry yeah yeah no no from yeah so so the prover is faster the proofs get a little bit bigger um but i would argue that that isn't isn't really material 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 then i guess it is good i don't know we think so if we're sending the proofs to ethereum we do have to pay attention to proof sizes because ethereum charges i think it's currently 16 gas per byte of transaction data but okay there is a proposal to

reduce it quite a bit in order to help scale roll-ups like ours and if that goes through then our gas cost on ethereum will actually be just as low as any other proof system but this is this is dependent on like an eip that's always a little challenging because those take oddly long times but do you feel like is this a non uh controversial one that you think will pass i think so 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 do you know which eip that is i think it was 4488 okay for anyone who's not familiar eip is what is what does this stand for ethereum improvement proposal yeah and i guess there's probably some documentation on this this needs to then go through sort of the the soft governance to be before it gets implemented i just realized in this conversation that i had never really understood 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 you mentioned like the proving time i think you said was 170 milliseconds is that correct to generate

a recursive proof to generate a recursive proof is that the last proof to go and be verified uh yeah so so we can like wrap they're i'm not sure how deep we want to get in this part yeah fry 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 um but then at the end once we've recursively aggregated all these transaction proofs we are now paying uh we're metered on proof size and so we want to change the blob 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 a three and this is the recursion yeah so so the recursion would be in like the intermediate steps like like we like we have this uh 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 um is a recursive uh proof got it but at the very end you wouldn't call that a recursive proof as well you called it compression we yeah we we definitely would it just has a different uh cost so it takes longer than um 170 milliseconds and it's really like

that's 170 milliseconds for like a one to one recursion and so if it were uh like two to one it would take a little bit longer i see and when you say one to one it's like a proof for cursed ones like one proof or curse but if you tried to combine two and recurs recurse them into one that would be double the time yeah roughly okay what is the time on the last one on this last recursive proof yeah i'd have to double check but i think it's under 10 seconds now 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 a slightly larger proof but wouldn't really make much difference i want to 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 roll-up 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 the tree depth for the the tree that contains uh transaction proofs of the leaves and uh we aggregate into a single proof that's not really bounded by like at least in any practical sense um and so we can take a lot of a lot of proofs and 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 uh into a single proof and going step by step i guess so you're doing multiple recursion is there a similarity here to like the mena system where they're also using recursive proofs like deep in the actual l1 yeah yeah definitely i i think they were sort of the pioneers for for this approach and i think since it's been a similar approach has been taken by uh aztec and

uh zk sink and there are probably other roles as well 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 because like i mean the way i always understand this is like you're kind of you're doing a roll up after a certain amount of time i'm maybe also thinking a little bit more on like the arbitrarium 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 want to cap the transactions maybe even just so that there's not so many layers of

recursion because i'm guessing each one of those costs something in terms of time yeah 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 a economic bottleneck where we just don't want such a huge number of proofs that it becomes very expensive to generate all the proofs yeah we're sort of

limited because uh 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 got it i actually in thinking about a system like this like recursive snarks i mean i had this episode with uh one sub for zikapro and he made this comment that roll ups are just daps 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 it's smart contracts there's non-chain logic 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 is doing something yeah so so every time a proof comes back so all the proof generation happens off-chain uh okay that that's funny that example because that's 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 um in order to to verify a state transition and so the smart contract just handles the bridging logic and then verifies each new proof but on every step this is the question i have like does it verify each step in the recursive process just the end just the end okay it is just doing the end but then but then why is it expensive because you use that term expensive for the different like the the before the last proof

proofs yeah so so it's just i think like pre eip 4488 it costs like a million gas to uh to verify plunky two proof um okay that's an estimate because we haven't done the implementation yet and then after we anticipate 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 uh sent it to ethereum then

we would just pay more gas okay but it because there's that final recursive strike 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 going to be i guess consistent yeah yeah exactly and so so so that's a really nice thing um 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 to compress could they do something similar though do you think they will now that they they saw what you did so i guess uh william just finished uh so we did pocky2 which is recursion and um we we use starks like airbase starks for our transaction proofs and and so william just finished uh the recursive stark verifier and so i i think we're going to rebrand to

recursive starkware i don't know if you're going to be allowed to do that um that's good 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 maiden work at uh polygon as well as jordy and david from hermes but on the maidan 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 maiden and polygon

zero distinct entities or are these like the same thing because like are you are you tackling a problem from opposite sides are you actually working together yeah so definitely working together um we're i think i would say exploring different parts of the design space so all three of us uh hermes maiden and xero um we all use stark vms um and there are a lot of design choices and it's unclear like which will be best suited for uh 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 really closely and 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 um and and vice versa like he's using the goldilocks field and um and so i 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 uh both with hermes and with with mine 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

[Laughter] so much for snarktober we're gonna need something else well i mean if it's starktober maybe uh that would make ellie bencisson really happy um yeah but uh was it start was it snark timber or snarktober i forget which one came first i think it was snarktober yeah yeah i mean i think uh just to be pedantic like plonky too i think is still a snark because we do like a pre-processing um step and and so but i i do think that that you're you're getting it or you're making a really good point which is that like the line between like oh these are starks and these are snarks uh is sort of blurring to everyone except like

the very uh precise like academics that enforce like definitions that that in the blockchain sense don't don't necessarily make that much of a difference and do you feel like because it does sound almost like these hybrid frankenstein sorry it's not a better way like combinations of these pieces of these different protocols that all get put together and then walked around a little bit sorry i'm gonna just keep going with it frank and snarks i think i think plucky too is beautiful so so i i strongly object to the frankenstein characterization but for the record um but no you're totally right uh 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 taking a second look at frye and sort of some of the design choices and and uh properties that the different systems have 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 jordy which is this idea that you would have you know an evm working as evm works you know within a roll-up or is your goal at polygon zero different 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 um they have the luxury to explore the design space and so what the hermes approaches is it's super cool they're trying to like take evm bytecode 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 into stark that's really really efficient and then let's see if we can take solidity or yule code and compile it to bytecode that executes in that sort of computer running inside of stark this is a little bit more like the zk

sync 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 um would you say that like maidan's approach is similar like is that because i think that's what we had talked about actually with bobbin 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 like 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 native dsl at some point i think i just i think i repeat it i don't think you say native dsl do you think you say dsl no i think that's native domain specific language anyway um 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 yule then 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 so 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 snarks so if we were really starting with a clean slate i'd say we would design things fairly differently do you imagine i mean i had this chat a little bit with me hilo 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 easy 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 yeah i think so so a good example is we profiled a bunch of ethereum transactions and the average ethereum transaction makes cha three or makes 13 uh sha-3 hash invocations 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 a stark friendly hash function poseidon and so i think that there will be a lot of

changes there in terms of like functional changes um i'm not sure what do you think tina 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 um so it sounds like it sounds like you're more like looking 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 question for the whole polygon or maybe whole ethereum i don't 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 yeah maybe a little bit above uh my paygrid 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

um i think it's sort of an open question whether another chain will come along like like certainly there are there are aspects of the evm that i think in retrospect everyone agrees or maybe not the best design decisions um but i think this is sort of cliched 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 then 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 yeah and that's that's sort of the question for because 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 yeah i think that 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 whether it would be better to to create another vm that

makes slightly different design decisions like maybe a heavier use of native field elements or something like that and then that might be a better option to to compile to 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 have this compiler which translates yule 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 computations 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 think if we wanted to 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 um and i know that actually like on the my inside

that's what bobbin is doing in a way i know that there is a different language in a different vm yeah yeah i think there's an assembly language right now um i think there is maybe a little bit of influence it is basically a binary machine that deals with binary 32-bit integers and i wonder if he might have done it differently if it weren't for the the goal of evm compatibility i want to ask you keep mentioning this term ewell i actually don't know what that is what is that yeah it's a intermediate code format that the solidity compiler compiles solidity code to

before it's converted to evm instructions okay and what you're saying is cairo goes cairo yule base i i think for for starkware yule is converted to the format that cairo uses but i haven't really taken a close look at it so it would go from solidity to yule to uh we're calling it zk byte code or system zero byte code or something okay cool that's actually really helpful to to parse that um can you tell me a little bit about how you picture like once this is developed and you have this sort of functional evm run like you can basically or evm

compatible underlying chain and actually i uh 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 become a roll up is that kind of the end goal that you're a roll up or do you have like i don't know some other format you picture yourself becoming yeah so i think our focus is on and this isn't novel to us uh starkware and cksync have also kind of proposed this but um roll-ups end up being a lot more expensive than what's called a volidium 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

all tell ones 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 roll up 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 sidechain environment that's still guaranteed uh by zero knowledge proofs i think um it's kind of the way forward for for us so you are going to do that opt-in opt out what does that look like actually

like is there does somebody have a dashboard where they can choose this or is it like they're acting within a different system does the dap do the like the contract deployer actually make that call yeah so so i think the uh the contract deployer would make that uh determination it might also be possible to do it at the transaction level but i think it would be at the contract level um there's also a concept that's been floated in the talks that you've given or like maybe just general polygon talks which is horizontal scaling what is that what is that in this context 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 i think when i heard it i thought you meant sort of like additional roll-ups so like new roll-ups separately acting in a in this horizontal way but what you're talking about is within a single kind of roll-up or valydium basically within like an instance of polygon zero you'd be doing this horizontal scaling by just doing this recursion at the different

levels exactly do you envision though a world where you do deploy polygon zero multiple times or do you really picture it being like a single instance 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 roll-up that's not really the

main roll-up that's just used to help scale also do you have a validator set like do you actually have some internal security or are you purely dependent on the main chain security 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 uh so it's like a side chain in a lot of ways but without the security drawback of a sidechain since we have validity proofs then these takers can't just vote to commit something that doesn't make sense or that contains double spends or anything like that i think the hermes team

has proposed a few different ways to avoid having a separate validator set but we see kind of like for us the lines between being a separate l1 and being in l2 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 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 that l1 itself has a fork 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 wanted to ask and i realized you're not using it anymore but what is it um so it has a

really pretentious uh meaning which i think i maintain is like kind of cool so in the 19th century when russia was still operating under serfdom um 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 uh yeah and so the so so that's fine it's you know great uh the problem is that no one can pronounce it or spell it uh i think the ticker was already taken so it was a pretty easy decision to uh

to reprint that's good well thanks for answering that burning question that i had from for many years um and i guess it won't matter anymore because you're using a different name but also good to know cool well i want to 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 is what it was what it's become i guess i do have a last thing which is what's next i i do want to hear if you have any upcoming things that we should look out for yeah so i think uh i think recursive starks have been uh like recursive verification of airbase starks has been completed and we're going to be

releasing more about our vm and our compiler in the not so distant future yeah 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 kinds of stuff like that that is a little bit complicated to support that we're working on right now cool i also want to 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 going to be giving a

talk on polygon zero and the work you're doing so yeah i'm excited to see you there and i want to say a big thank you again for coming on the show thanks for having us yeah thanks for having me santa it was a lot of fun cool i want to say a big thank you to the podcast producer tanya the podcast editor henrik and to our listeners thanks for listening you