Episode 210: The Road to STARKs and Miden with Bobbin Threadbare

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 bobbin threadbare the lead at maidan a project recently acquired by polygon we start with a quick starks versus snarks 101 and then we take a journey through bobbin's early work on open source stark libraries how he learned starks and learned rust all

the way up to the project that he works on today that is maiden a stark based zk roll up which is an evolution of his earlier work on distaff vm and winterfell winterfell being a highly performance dark prover developed at facebook's novi this is a very zk heavy episode and i hope you'll enjoy it before we start in i do want to let you know that it's the last chance to donate to the zero knowledge podcast git coin grant during this gitcoin clr matching round it ends i believe tomorrow so yeah if you want to donate this would be a great time to do it there is also a dedicated side round focused on zero knowledge right now so be sure to check that out as well i also want to thank this week's sponsor aztec aztec aims to be the privacy layer for ethereum they believe that unlocking

programmable privacy is the next frontier for blockchains aztek is the first zero knowledge roll-up built from the ground up for anonymous payments and d5 transactions join the thousands of users already sending funds privately on zk money that's zk.money and start interacting with aztec today so thank you again aztek now here is my interview with bobbin threadbear [Music] so today i'm here with bobbin threadbear who's the lead at the maiden project a project recently acquired by polygon he's also the author of distaff vm and winterfell so welcome to the show bobbin thank you anna thank you for having me so bobbin we met back in september october 2019 i

remember you were speaking at a starkware conference and i immediately knew that like you were like a a stark guy i wanna and i know that like the projects and and work that you've done since then are very stark focused i want to start this interview by actually getting a little sense for you pre zk what were you up to kind of what led you to get into this and maybe where did you enter the space yeah definitely so um i actually entered the space relatively recently i would say it was summer of 2018 when i really got into crypto i've known about bitcoin and ethereum way before and the kind of was passively

observing what's going on but really actively got involved in 2018 kind of started thinking about cryptography and you know when i say actively got involved i actually started to learn about cryptography and trying to think through all the uh kind of math aspects of it and kind of more structural things that uh are needed in blockchains and things like that so before that i actually was uh running a small startup it was kind of like a not a i'm not a crypto focus startup it was just a regular web company focused on uh kind of trying to figure out how you can maintain uh like a personal reputation across different services and sites um and it was a very centralized product and i didn't like the aspect of that where basically all your reputation data

is being stored in the single server so i uh one of the kind of motivations for me to learn crypto was figure out how to how can we make it decentralized and as i learned more about crypto i got really interested in zero knowledge proofs and specifically this general computational integrity proofs which are slarks and starks because for whatever reason it was immediately clear to me that this is something that is really needed in blockchains because you know the promise is that you can verify computation and then nobody else needs to rerun the computation and blockchains like basically every node has to re-execute the same transactions and it just seems wasteful to me so uh it was very clear to me that this technology zk will is something that is kind of natively needed in blockchains because it allows you not to re-execute

the same piece of code on millions of machines yeah would you say that you started in though on the stark front or were you kind of generally exploring zero knowledge at this time i would say i started even more broadly on the crypto side try to learn about elliptic curve so i'm a software engineer by training uh and i don't have any cryptography background i'm not a you know math phd or crypto phd or anything of that sort so it was all very new to me so i started to learn about elliptic curves uh kind of other cryptographic primitives and trying to understand how they fit into different protocols like you know signatures and how hashing works and all of that stuff so that was something that i learned throughout basically starting from summer 2018 onward

and uh by i would say by early 2019 i got to zero knowledge and that's where it really clicked for me that this is really exciting and almost you know borderline magical technology and i didn't go right for the starks i kind of like read a few things about snarks and starks but for whatever reason i think starks resonated much more with me than snarks did and um i usually explain this is in my mind and i think many people might disagree but starks are simpler to understand there is very few foundational things that you need to have like you don't need to understand for example how elliptic curves work to be able to reason about how starks work so there is no need for this a lot of advanced crypto that is needed uh for

most other starks like elliptic curves and pairings and all of that stuff and uh yes you can treat i think those as black boxes and still understand how the basic stuff works but for me it was much easier like basically i under i know that even with starks there is a lot of different layers and a lot of theoretical complexity but at least kind of the core mechanism was much more immediately clear to me that was one of the reasons why uh i kind of gravitated towards starks something that i feel we've definitely done on the show before but i'd kind of like to do again today is make that distinction between starks and snarks so i think i've often highlighted what the resulting differences are like how it appears but maybe you can give us a

little bit of insight into what those differences are kind of under the hood yeah definitely well one thing i should probably say up front is that i think the terminology is getting blurred more and more and it's kind of like not always clear what you should call a stark and what is a snark because i think people use them in different contexts and there is like a more kind of formal mathematical definition then you know some people argue about what exactly should be called a stark or a stark but you know going back when they started uh at the time when kind of starks came about snarks existed as in this kind of paradigm where you had to have a trusted setup so one of the things that starks promised was the absence of a trusted

setup so transparency is something that is what the team starks stands for so you don't need a trusted setup this is not the case anymore there's other proving systems right now that do not require trusted setup like an example would be halo for example doesn't require trusted setup the other distinction between a kind of like a very fundamental difference between starts at the time and uh starts is that the intimatization used so snarks at the time relied on r1cs and you know r1cs is still probably one of the more popular ways to describe computations for uh this proof of computational integrity uh but uh starks had this different type of administration called air and that is a very different thing now nowadays

there is again a bit more blurring of the lines that is happening because uh plonk issue immediation is also kind of closer to air you can even say it's like randomized air with pre-processing and you know things like that there is actually more similarities now but there is still quite a few differences so i would say uh for the most part starks rely on very few cryptographic assumptions so like basically from the cryptography side you use you only need to have hash functions for starks for snarks you still need to rely on elliptic curves and sometimes it you know it could be pairing friendly elliptic curves other times it could be just regular elliptic curves but there is still need to rely on uh kind of more advanced cryptography and that also you know potentially makes snarks vulnerable to quantum computers so one of the benefits

of starks is that they're resistant to potential um you know future quantum attacks because they only they require very little kind of underlying cryptography the other distinction which is i think it depends how you interpret it but basically starks say that they're fully transparent and they don't require any pre-processing which is um you know the video fire just needs to know the error description and that's it and they can verify any proof while snarks frequently um you know requires some level of preprocessing and that you know there's the distinction is that besides verifier and approver there is also this indexer that runs and pre-processes the circuit or something beforehand so that the verifier can evaluate it uh succinctly or verified succinctly so there are

those distinctions that i think are still relevant i actually like have this diagram in my mind whereas there's like two circles snarks and starks and they overlapped and basically anything uh that is non-interactive and transparent and uh kind of scalable uh this is uh kind of falls into the this intersection of two circles i see and that could be you know scalable transparent starks are starks and then non-interactive starks are snarks as well so it's kind of like there's an interesting intersection between them let's talk a little bit about the kind of outcome of these two systems so maybe we can start with like looking at the proof size how are they different uh so the proof sizes specifically like how big of a proof that that gets generated

by the approver and you know how much you need to send to the verifier is definitely bigger for starks but i would say to give like a common uh benchmark is that snarks like growth 16 and plonk uh the proof sizes are tiny and they could be 200 bytes or maybe half a kilobyte or something like that so they're they're really really small for starks um even for simplest computations we're looking at maybe like a dozen kilobytes and then for you know more useful computations that we frequently need to encode like some uh circuit that does verification of a transaction for example uh the proof sizes are in dozens of kilobytes um you know uh 80 kilobytes potentially closer to 100 or something like that so you know rough ballpark it it's very computation dependent and also depends

on the security level that you want but basically start proofs are at least an order of magnitude larger than star proofs and you know in some situations could be like two orders of magnitude larger but i would say this comes with uh this is not necessarily the inherent property of starks but it comes with a kind of this need to rely only on a few very few cryptographic assumptions so if you only rely on hash functions your proof sizes will have to be fairly large as soon as you can rely on elliptic curves you can bring the proof sizes down dramatically uh but then you lose like post quantum security for example so your proofs are no longer post quantum secure so in theory you could build the stark that is uh kind of using you probably heard the term fry as

something that is used in starks but you can use some other polynomial commitment into the fry or you could use some shade fry to be done using elliptic curve rather than you know hash functions and in that case your proof sizes will go down dramatically but then yes you do give up first you give up the post quantum security and second your prover speed is probably is going to increase significantly so the proof speeds when you need to rely only on hash functions for starts especially proving speed is very good very very fast again there is a little nuance in that it depends on the type of computation that you are generating a proof for but for a lot of computations that we do care about starks are very very fast but as soon as you start need to rely on elliptic curves uh you kind of lose some

of the speed advantage as well when it comes to the verification sizes is this is this calculated in time spent on verifying or is there like a like we're talking about proof size but is it also like is it verification time so there are two aspects to it there are there is the proof size itself which obviously the larger proof uh you know you incur a little bit of penalty but there is also a verifier time that it takes to verify the proof so uh for starks even though the proofs are very large um compared to other systems the verification time is fairly small yes yeah because again the only validity hash functions which are very fast on you know modern computers i think the the verification time between starks and

likes let's say growth 16 and plunk are fairly comparable they're not hugely different but as an example bulletproofs is another system it has a very relatively small proof sizes you know 100 kilobyte or maybe like a depends on again what you want to verify maybe slightly over a kilobyte but then the verification time could be significant because it really depends on how big of a computation you try to generate the proof for so the verification time for bullet proofs is linear in the kind of complexity of the original computation which is not the case for starts and snarks where this verification time is logarithmic so there are these two aspects the proof size and the verification time and starts do fairly well on all metrics except for the proof size got it but i

guess like have you also seen a lot of development in that the fact that there's this overlap and techniques have been shared between these two systems do you think that is that proof size actually shrinking or do you think you've hit have we hit the bot like the smallest it can be for now i think the proof size for starks you can't reduce it much more without like giving up something uh so like it will stay in dozens of kilobytes unless you give up one of the things and like what i mentioned for example you can give up post quantum security or you can start losing elliptic curves and then you can shrink down the size you know probably by a factor of 10 or something like that uh but without giving up that post quantum security or maybe something else like prover speed it's it's very

difficult to shrink the size um i'm not i don't want to say it's impossible because i don't think i have enough of theoretical background to say that nothing can be done to do it but at least as far as i'm aware there is uh no known or kind of like even uh promising technique to reduce the starts proof sizes uh significantly without giving something up that you know kind of like forms the core promise of what sparks are but i i do want to say that i think the proof sizes are like i think a lot of weight is being given to the proof sizes but i think for the computations that we care about in a blockchain context uh proof sizes are not necessarily that important especially if you can do recursion so if you can

i haven't seen the recursive starks yet but this is something definitely that i'm hoping to build you know sometime in the future but as soon as you have recursive starts the proof size becomes much much less of a an issue because you know you can take a thousand proofs and generate a recursive proof of verifying all of the thousands proofs and you shrank the size of that one proof significantly so um i i do not think that uh i think at this point maybe the proof sizes are somewhat of a disadvantage for starks but uh it's not a fundamental disadvantage uh i think in the future uh we should care about proof sizes much less and when you say the word recursive just for our audience that that means kind of like taking a snark and then making a snark out of that snark that's usually how we hear

about it recursive snarks right sort of like snarkifying snarks as isaac from mino would call it but when you talk about recursive starks is it the same concept that you're like taking multiple stark proofs and then you're potentially creating an overarching stark that combines that yeah yeah that's exactly the concept where you know you have many many proofs and you just instead of uh verified having to verify this thousands of proofs potentially individually you can verify single there is another layer of uh uh stark proofs which aggregates all of this proofs together and then you have just a single proof so you know you go from a thousand proves 80 kilobytes each to a single proof you know let's say 100 kilobytes and that's it nice and so i guess that could be it

could be said that you're starkifying starks but i don't know if anyone's going to use that yes so i think this gives us a pretty good picture of what the stark is also in comparison to snarks something we've covered a lot but let's go now into the projects that you've built using starks or around starks or for starks so when we met you were working on something called jen stark like what was that what was that project this was actually the first project that i started working on in zero knowledge space okay and the way i got to work on this project is actually interesting because you know as i mentioned i was doing this research for my other startup and you know my other startup wasn't doing that well so i kind of decided to sink more time into this and just really learn about you know as

soon as i figured out what snarks and starts were i really wanted to kind of like understand them deeply and see how they could be leveraged even outside of the startup that i was working on and uh as i mentioned earlier uh starks resonated more with me in part because i thought it was simpler and it kind of like made immediate sense to me uh how at least the basics of the underlying mechanics work but also i thought and i know a lot of people who disagree but i think starks are more future proof because you know if we can i have quite you know quantum computers in 10 or 15 years and if i'm going to spend next x number of years learning something might as well do the most advanced exactly yeah so there was very limited resources out there at the time about

how you can learn about stark so to be honest there were some posts from stark where there was the blog series uh from italic so i kind of like went through it and i think one of the things that was immediately useful to me is the italics tutorial on starks because it actually had some python code attached to it and i can read code so it was uh easier so for me the way i learn personally is i try to like build something i learn i learn by building so i was like okay i'm gonna just rewrite this tutorial using a different language so at the time it was javascript which uh looking in retrospect is a horrible language to write starts in because it's very uh you know not performant uh and you get very slow

proving speeds and all of that stuff but uh you know that's what i chose so i basically started out by rewriting that tutorial in javascript and as i was writing it i first of all i understood how the internal mechanics work but also i you know the tutorial was very specific for one type of computation and i saw the opportunities how you can make it you know work more useful where you can take it as a library and you know try to uh generate star proofs while computation so i started to generalize it to something that is not tied to a specific circuit so to say or specific computation and that's what jen stark was that was the kind of general purpose stark approver which you could provide you can you know verify any type of computation with and that's what uh i think i shared

this uh kind of like the early version of this on if research at some point and to be honest the response was incredible uh so like a few people reached out vitalik reached out to me a few other people from the community reached out and asked you know offered support and help and work on that and start where guys reached out and you know invited me to that conference where we met it was very very i would say encouraging to see such a level of response and support and i kept working on this library but then i kind of like in my kind of thinking even the library itself was very difficult to use that you like so that led me to try to think okay how can i make it simpler and that would led me to like thinking about like airscript and

air assembly languages which the idea was that it's how do we make it simpler for regular developers to write start proofs we actually have a video like there is a video recording of like you giving a talk on airscript that i'll link to in the show notes um i know you did just mention air arithmetization but i don't know if we really dug into that like the name air what does it actually mean what is it actually doing yep so air is uh basically it's an acronym for uh algebraic intermediate representation uh and it is the the way uh that you describe computation so that the start proving system can understand it and just to take a step back there is you know if we think about programs that

we want to prove execution of using snarks or starks we can just take a source code of the program and run it directly through the proving system there is this step that is called arithmetization that basically takes a program as written in some language you know let's say c or rust or um you know javascript or whatever and uh we need to describe it using kind of like a set of polynomial equations and this is the step called the arithmetization and snarks use uh the immunization that is called r1cs that basically takes a computation and describes it as a arithmetic circuit and slarks use this air arithmetization that takes a computation describes it as you know intermediate algebraic representation is it somewhat like the opposite of what

a compiler is doing are you going the opposite way or would it be it's some sort of compiler it's a translator i guess right it's a translator yeah but it is not going the opposite way it's not generalizing i think the original code but it is kind of evaluating the structure of the code and you know in all honesty this compiler is usually at least for in a case of error is very frequently a human who is trying to take the computation and describe it then using polynomials and that's by the way one of the complexities of starks is that it's not trivial of how you take a computation and transform it into air there is quite a bit of complexity associated with it and that's uh one of the reasons for example and then i think we'll talk about this later is that people are

working on virtual machines where you only have to write air once and then you don't have like you can generate any stark proof on that virtual machine but the air part is only developed once rather than for each specific computation okay for uh snarks their communication is called r1cs and it's you know in many ways it's simpler because it's it's easier to compose different r1cs uh circuits so so to say the technique of how you could translate the program into r1css also you know can be automated up to a higher degree degree i think then you can do it with air so there is um quite a few libraries out there that like you know have gadgets for one cs there are very few or if any libraries out there that have gadgets for air because again the possibility of air directly is very difficult

so there are positive mice and i think that's why a lot of people kind of gravitate towards like r1cs and other snarks as opposed to large because of the complexities of virtualization uh but hopefully like with advent of this virtual machines this uh is not gonna be an issue yeah it's almost like do you feel like you're building the foundation so that people can start using this stuff without needing to be in the weeds or are you creating a framework that they can easily make these decisions for how to do it and do it correctly i think even from the time when i started to work on judd stark my kind of end goal was how do i make it so that you don't need to understand cryptography or you don't need to know anything about zero knowledge proofs to be able to generate start proof so uh i

think we're getting to the point we're not you know 100 there yet but we're getting very close to the point where you don't need to be a cryptographer you don't need to really understand starks to be able to use them i think the tools that i've tried to build like starting with jen stark and then air script and air assembly and then this stuff vm that was the next evolution of kind of my journey was kind of trying to make it progressively reduce the burden of like you having to understand cryptography and that is that is the goal and i guess that actually leads us to your next project which was disstaff vm like tell me how somebody would actually interact with this so like we've talked about vms before virtual machines on the show before usually in the context of evm that's the one we say

the most but what is distaff vm so distance vm i think was because it's now superseded by a different vm but uh which we'll talk about later but it's a basically a virtual machine in where there are a lot of other virtual assistants you mentioned evm as another example but it's a virtual machine that has its own assembly language and you can write programs for that virtual machine in this assembly language uh and this is you know regular symbol language you don't need to understand like anything about cryptography to write programs for this vm and the advantage of this vm was that for any program that you write it automatically generates a stark proof so it kind of does the translation uh out automatically for you you don't need to think about how do i need to express my program as air the vm

has its own air and it is able to execute the program that you write and generate a proof for your computation without needing to generate new error for it that's the biggest advantage i think to give a little bit of context about how this stuff vm even came about is that you know i was working on those airscript and their assembly languages and you know i spent quite a bit of time probably close to half a year working on them and i got to some point but it wasn't satisfactory at all it was still very complicated i you know a person who've never seen starks who understood how they work still would have a fairly high learning curve before they would be able to use any of those languages and that led me to think about what is the better way and the the better way in

my mind was building this vm uh but at the time when i started working on it i actually didn't think you know anything useful will come out of it it's like the story or the journey that i went through is very similar i think you had uh z cash people here on the podcast which described how they came up with halo where they started with something that they didn't think was practical it was in the implementation it was like as they were building it in they found this like secret something researchers had kind of missed it was interesting i i wouldn't say that i found the secret but like basically i started working on this vm without thinking it would be very useful or powerful so like you know i i knew some simple techniques that make it could make it work maybe i thought you know it would be very

limited and as i was working on it i discovered that well i think i can now handle if statements i know how to do if statements and then i built if statements and then uh i was like okay and now i think i know how to do loops as well so and then you know and then i worked in some more and it's i i think i know how to do random access memory and basically you know over a course i would say of like four or five months it went from just a toy project that i basically didn't think was going to be useful for anything to something that i now think can support touring complete computations and basically the general purpose vm uh but that i i didn't start out trying to think okay i'm gonna build a turing complete virtual machine it was more kind of like okay let me

experiment and see how things work out in that era though like was airscript the language to write on the desktop vm like basically i'm curious if there was a dsl in there if you had a domain specific language for this or you're using something else so there was a dsl but it wasn't airscript so the way to think about this is that this stuff vm supersedes airscript so airscript was my earlier attempt of how you make starts accessible but it didn't succeed as much as i would like it to have succeeded so this stuff was kind of like starting from a blank slate it did have a kind of the main specific language that's called the staff assembly basically which is the assembly language of the of the vm itself but yeah it's basically you don't need airscript if you want to use this

stuff vm got it it sort of covers it up like we're leaving airscript in the past we're moving forward and now i wanna i wanna push forward because i know like just fem's also like midway through the journey i guess maybe maybe not maybe it's still even beginning so let's talk about what you did next i'm going to let you tell that story because i know kind of what came out of it but i don't know what iterations happened in there yeah so i actually you know just vm is still or was still like a you know research type of project and there were a few things that you know i wanted to improve like first of all it wasn't feature complete but more importantly like the underlying proving system i thought was could be improved significantly so it wasn't a very high performance system

for generating star proofs so actually you know halfway i would say i i kind of put staff vm aside for for a little bit and i i joined facebook as uh part of their research uh group and in there i got the opportunity to work on a lot of zero knowledge tech and starts as well i think overall the outcome of this was the winterfell project yeah which is a kind of a underlying like basically a very high performance and capable start prover and you know up to the protocol itself is uh much better implemented as compared to this stuff and i worked on it uh over a course of probably like eight months or so at facebook and had a lot of help actually my experience and working in facebook in the crypto group was uh

extremely positive but i basically was able to collaborate with extremely bright people there and they helped me a lot uh you know i i as i mentioned i'm not a cryptographer so i was able to rely on more kind of a theoretical expertise of people who work there and it was very interesting the environment was very collaborative and very open uh i think uh i'm grateful a lot to be able to kind of have chosen my project more or less freely at the time uh and being able to work on winterfell but at the end so we built winterfell this is a star approver and the idea now is that we can swap it for the prover that was in the desktop vm to make this stuff vm and actually the new iteration of this stuff vm much more powerful so you can rely on this a much more

advanced prover i see so when winterfell is like a component within this vm model that you were already building exactly okay and it's making the prover more efficient is it making the proof smaller or is it making the proof creation faster or what what is it doing yep yep so it's doing a lot of those things but i think uh the way to think about winterfell is that you still need to bring your own air to describe it so it is still at the level of abstraction that is uh not as developer friendly as this stuff for example is so you need to still understand parts you need to still understand air you still need to be able to describe the constraints yourself but you can describe any constraints on on withdrawal and you know it's a general

purpose start prover so it's very similar to what i was trying to do with jen stark in javascript but it's now done in rust it's now done in a way where it can run in multiple threads so it generates proofs much faster the implementation of the start protocol as i mentioned is also up to date to at least what i am aware of so the proofs are smaller uh compared to like the proofs that were generated by uh chen stark or gestaphem uh they're still in dozens of kilobytes but you know roughly half the size of what it used to be with the old uh approvers very cool what was disstaffvm written in originally like you did did you have to rewrite anything for it to work with this with winterfell which was in rust so the staff vm was also written in rust but

i should say that that was my first project in russ so i was still learning rust as i was writing this vm i love how so many of these it's like so iterative it's like your learning project is also like pow like eventually powering these like really powerful things that's cool yes i i think i mean again this is how like by doing i learned by doing so for me like i was like okay i should learn rust what's the best way to do it so did you have to go back and like rewrite any of this or did you get sort of collaboration from i don't know any of your colleagues in in doing this yeah so even though just vm was written in rust uh we basically rewrote the prover for winterfell from basically from scratch i mean it was started kind of the course

started by copying some of the stuff uh underlying components but at this point it's unrecognizable so much has changed in part because uh you know i code and rust better in part because i also understand start protocol much more deeply now so it's kind of a journey where any subsequent piece of code is much better than the previous one cool winterfell uh even though it started out as a kind of core uh stuff prover it's very very different and now i think we'll talk about it later but the next iteration of the stuff vm which is called maidan vm uh is using winterfell at its component but it's also taking the some parts of the this stuff so over the last few months i actually released the release of my vm 0.1 is basically migrating original desktop vm to use winterfell as

the backend prover so now this is what might and vm 0.1 is very cool and this this works this is what i wanted to talk about next anyway i felt like that was going to be the following so maiden is the project and would you say maidan is dissed fvm rewritten around winterfell like it's basically like in that process where you kind of were going back and rewriting some of this stuff it just sort of it did shift it changed enough that you felt like it was actually a new product it is a new product now but it is even going to be a newer product in a few months from now because i think at this point basically the uh maiden vm 0.1 is just the desktop vm using woodruffel approver which makes it more efficient faster proofs smaller

proof sizes but the functionality of the vm is still the same as this stuff you still have the same kind of relatively limited instruction set that you know it still doesn't have random access memory because i never got around to implementing actual random access memory but at the same time like over this year that i was working on winterfell and other things at facebook i've uh realized that there could be a lot of improvements done to to the vm itself to like make the instruction set more useful to android max's memory to adapt it to i would say a blockchain environment where you know you could prove solidity programs using maidan for example uh so what i'm very actively working on now is uh developing this new version of midan vm which will be even more developer

friendly and i can talk a bit more about like what i mean by that but uh it will basically support uh languages such as solidity and other high-level languages and will be specifically tailored to blockchain work and i can uh my vm itself is a part of a bigger project which we can i guess talk about in in a few minutes yeah i mean i think we need to now like mention some big news that happened recently and then we can maybe dig a little bit deeper into like how what kind of the plans are for midan but yeah so i think it was a few weeks ago maybe a month ago uh that we we heard that actually you know someone who had worked on winterfell was joining polygon that was the way that this kind of came across so yeah tell us a little bit about this

move and what this means for maidan yeah so at facebook uh you know i worked on winterfell but i uh one of the things that i still really wanted to do is kind of make this kind of transition to build or develop stuff vm further and uh while there i got approached by polygon guys and they talk to me about kind of their vision of how they will enable polygon suit of solutions and things like that and you know it made a lot of sense to me i think it is fairly clear uh right now that they're they're betting very heavily on zk attack and yeah there are a number of kind of different solutions already being developed and uh mikhail from polygon knew about this stuff vm even way back when i was working on it he didn't know about me working at facebook because um

bobbin actually is not my real name so i work on the different names in different places i guess that's fair i only know you as bobbin yes i'm going with that name yeah so basically like the reason why people didn't hear about me for a year because i was working under a different name and winterfell was released under a different name as well and then you know i talked to him about my work on winterfell and uh like what i would think about the next evolution of this stuff yeah and i think it fit well into their view of how this one is uploaded strategically so i got the opportunity to come and work into polygon to kind of make estafian a much more powerful vm and build a layer 2 solution a rollup around it as well so there was a name change from the

staff to maidan kind of to signify that this new vm is going to be much much more powerful and you know there is a lot of new things that i think justify the name change and uh it is as i mentioned going to be just one component of the overall so once the vm is built or at least is in the stage where it is powerful enough to support uh the types of computations that i needed to build a roll up or a general purpose roll up there will be work starting around trying to make this into a layer two solution that can execute arbitrary smart contracts and generate stark proofs for them very cool does this have any sort of echoes of zk evms like when you you know here you're talking about a vm in itself so you can actually do quite a

lot there's like a stark that's going to act sort of as the that's the connector i guess to the l1 between like an l2 and a1 yeah like because we had jordy on the show jordy hermes also a company that's now part of the polygon family and there we had talked about the zk evm idea so would you put that in a similar category or is it a different vm like does it not actually interact the same way the l1 would so it is a different vm but i think kind of the overall goal is i would say similar it's just the route to that goal is for example with geordie and uh for maidan is different uh i think at this point in time there are quite a few projects out there that are building uh different types of zero-knowledge virtual machines uh there

is uh you mentioned hermes and jordy there is darkware with cairo there is a zk sync with i think they call it gk evm or something like that and i think there is a two or three other projects that are trying to build virtual machines that are automatically generating zero knowledge proofs it seems like this is uh the way at least in all the people's minds forward in terms of how you can support very uh organically zero knowledge proofs on you know in the blockchain world so this virtual machines only make different tradeoffs and different different design choices and i think there's pluses and minuses to those choices and i think the space is very early in terms of figuring out you know which set of those choices is the correct or maybe appropriate for a given

use case uh so you know to to compare with georgia's approach that you uh mentioned so george is building a very close to evm replication of the vm exactly we talked about it like opcodes will be the same and i remember it was something like you take a let me see if i see if i do this right but i think he's you take a stark like construction and then you snarkify that and then you write it on chain so he's there's actually this combo i mean those are very valid design choices there is a reason why you would want to do that let's say support edm at the up code level because you know it will uh make it much easier for people to migrate smart contracts might and vm takes slightly different approach so there is a vm that is different from evm

there is going to be its own uh assembly language that has its own op codes but the idea is that it will be powerful enough for you to be able to compile solidity into it so that you you can't migrate the smart contract basically at the bytecode level but you can migrate it at the solidity level so there is it may be a bit more involved in terms of migration but you know there are other pluses and minuses that you know it offers one of the benefits for example is that i'm really interested in is supporting other languages besides solidity in maidan so you can potentially have a safer language or something that prevents you know has more rigorous static analysis or something like that that you know potentially could eliminate some bugs and things like that interesting what do you kind of imagine like if the

two projects and i i feel like it's not the only one for a polygon but i know that things maybe haven't been announced yet by the time this airs but if you're both kind of building this out do you sort of see even in the polygon universe like two of these running for different purposes potentially interconnected or do you do you picture them both connected only to the like the the l1 i think it's it's possible i think it's too early to tell how exactly the architecture will work out just because uh the stage of the the development is fairly early but you know yeah i don't see why they can necessarily serve different use cases and be interconnected for specific purposes you know i think all of that is possible but again it's very early and uh i think the way we work on this is actually very

collaboratively within polygon we have uh like weekly meetings where we discuss like the the things that each of us is working on and as you mentioned there is more than just uh hermes so like the the team the zk team at polygon is fairly large at this point in time so it's very exciting to have these conversations and basically share ideas on uh how like i'm trying to solve something and you know somebody might have already sold it and then if i will you know have some solution that somebody is trying to figure out so we've uh it's actually been very interesting by the way just to kind of like as an aside as i was leaving facebook one of my concerns was that i had this really awesome team that worked uh you know i worked together with facebook and i wasn't sure what it

was gonna be a polygon like but i think uh so far i can say that experience has been very similar in that where there is a lot of people who are deeply understanding crypto and zero knowledge and you know i collaborate them you know almost on i wouldn't say daily basis but definitely like uh you know on weekly basis and we kind of discuss all these things and so this has been a very good outcome in my mind do you also feel like leaving a big kind of corporate i mean you built winterfell as an open source project which is awesome but it was within a corporate um now you're in a crypto company i guess we'll call it web3 company do you feel like is there is there more openness also with the community outside of the

org because you're in this new situation or do you feel like actually in facebook they were pretty open as well i think so there are two aspects of it there is the aspect of like working with uh directly with your colleagues which i think and facebook was pretty open it was very like everybody was fine with open sourcing things it was very collaborative environment as well and you got all the freedom to be honest you know as part of that research organization and i can speak for a larger company because you know i've only been exposed to like this crypto research organization within uh novi which is like part of facebook it's been a very open and free environment to experiment and kind of i mean the mandate was that we are working on future tech so we can take this kind of uh experiments and figure out what you

get to be real yeah you get to do kind of like the fun stuff the other aspect of it is where you need to interact with the outside world and when you need to go through kind of all the bureaucracy of the large company that was much less kind of streamlined as it is for example in polygon because even something as simple as giving the outside interview it requires a lot of approvals even trying to publish i know i remember trying to get someone on for winterfell i was just told like nah you're gonna have to go through tons of stuff so i was like okay fine i i think like one example just to contrast uh again a larger organization like facebook versus a smaller uh kind of more nimble i would say like position like polygon is that when we wrote the blog post about winterfell it took about

like a month and a half before we could publish it uh so the blog was already written but it had to like be approved there was like other teams involved that needed to do this i think within polygon we wrote the blog within a week basically and published it so again like within the crypto research team we wrote the blog was ready but it then took another month and a half to get it published and here it was much much faster and you know there are objective reasons why some organizations need to be slower and get you know layers of approvals but uh you know those are the the facts totally yeah i mean it has purpose we i mean i think it's understandable why they need to do that i don't think it's out of like maliciousness that they take longer but it is from the outside especially when

you are just kind of trying to get some insight it's a bit frustrating and and it sounds like you're in a little bit more of an open space now i kind of want to keep going on that idea of like the open source tech space so far in the stark world there's been one large project starkware that has sort of dominated a lot of the narrative and thinking and research around starks do you feel though like is it time that there's going to be actually like a pretty full outside open source version of starks coming do you see that sort of on the horizon well first of all to talk about like open source starks uh i think there's been implementations already so like even starting with like as early as my well even before than the jen stark

was a kind of an open source implementation of starks i think there were other implementations i think uh you had dramko at some point they also worked on the open source dark prover and then winterfell at full practical purposes it is an open source tag prover even right now you can use it now you know some of the aspects you know it's it's an evolving project it's uh it's a research project in some ways where you know you probably shouldn't just use it in production just yet but hopefully with time it will get to the point where you can use something like winterfell for uh in production if you wanted to have this custom custom air that describes your specific computation i do hope that over time people will migrate more toward using vms because it is much simpler like you if you don't need to

learn how the cryptography android operates and how you need to write errors for example uh it does make it much more uh simple i i do think uh like one of the i don't want to say deficiencies but the complexities of starks has been that you had to like learn this air thing before you could do anything useful and there were and i think still are very few people who understand them deeply enough to be able to write uh errors for sophisticated programs out there and uh this is not necessarily the case for whatever reason maybe because it came first maybe because it is simpler like r1cs is much better known so like uh it is i don't think the deficiencies of stark is that necessarily lacking open source implementations i mean there is even an open source implementation from starkware for iftar uh it is that

they were extremely complicated to use without kind of like they didn't have their own dsls that were simple enough or it basically required you to spend a lot of time on this like scaling this learning curve before you can do anything useful with them but now as we have you know start where it has cairo and we're working on modern vm those should be much simpler and i do think you know other vms might come around as well somebody could build it but i do think that the path forward for kind of making this more accessible to developers is this type of virtual machines which make it much easier for people just start using them that's interesting i do feel like there was like a lot of mind share spent on snarks especially in like 2019 there was this like what was it snarktober

i think was the name um when you just had research paper after research paper coming out just around snarks primarily and you didn't or or i haven't felt that in the research side around starks except for from primarily like the stark community which is quite small it's it's been mostly around starkware but yeah are you already meeting groups that are trying to get into it and maybe maybe with these vms coming online they could actually start to do something with these and use and kind of tap into the properties that starks have that are that are unique i i think for one i see more people or more projects kind of making use of different star components such as fry for example like there's other projects out there that are trying

to rely on fry and kind of marry like george's uh thinking you know planning to use them there are other other ones out there that i'm aware of so i do feel like the understanding from kind of people who are very deep in dk tech of what starks are and how they can be used and you know how different components of start can be made with different components snarks is increasing uh a lot and that could lead to some interesting kind of outcomes but yeah i also do think that if we work hard enough and make those vms accessible enough people will not even need to care about like what proving system i'm using or you know they can uh they don't even need to know that the underlying proving system of might and vmware starks or something like that they just know that there's zero knowledge proof generated

and then this is the properties that it has totally so going forward i mean we just you mentioned before that right now maidan is basically just staff with the winterfell prover architecture but like what is the future of midan on on the technical level what do you already see on your roadmap to change so there are quite a few improvements that uh we have in mind for might and specifically so as i mentioned earlier one of the things that this stuff was liking is random access memory so this is something that we're bringing in uh that will make maiden vm fully touring complete but there are two other things that we're trying to we're kind of working toward with my vm the first one we want to make it extremely developer friendly so there should be no difference between

let's say a developer writing code for my vm versus like some other like vm that is not necessarily tailored towards zero knowledge proofs and uh getting a little bit into technology right now so most of the vms that i'm aware of that are out there they kind of expose a lot of this you know it's not necessarily cryptography but you need to understand so like you don't work with integers within the vm you work with you know field elements for example and we're trying to make it so that this is not the case you only have to like if you wanted to you can you can just use 32-bit integers that the vm understands and that's what the vm kind of natively supports there are a few other things but basically the idea is that to make it almost indistinguishable from a regular vm so there is no additional kind of

overhead that you need to learn about anything that like a regular developer would not be aware aware of already so that that's one aspect the other aspect which is maybe a bit further down the road is that we're trying to build it so that it's kind of at the core of the vm you can support kind of privacy in the future so as an example most roll-ups right now they're used for scalability purposes they're not used for privacy purposes i think there are some roll-ups like from aztec for example that do work for privacy purposes as well but you know most uh roll-ups in their current shape are used for scalability and this is what kind of the original not original but the immediate goal of mine and project is as well but we do want to make sure that you can there is a road map or clear road map of

how you can get to let's say something as complex as privacy preserving smart contracts where it's not only that your transfers are private like you know even on other networks or in kind of privacy preserving systems you you can provide privacy for simple transactions uh but what we want to achieve is privacy at the smart contract level where if you want to hide the code and uh you know you don't want to reveal the code of your smart contract you can still do that and you know the vm is being designed in such a way which uh naturally should lead to something like that i mean there's still a lot of questions to answer in terms of how this will uh work how this will work and still be interoperable with ethereum and all of that stuff and this is something that we'll be solving next year

but there is a very clear understanding like even the way the programs are defined and built is that you can hide parts of the program and reveal just the part that you want the public to know uh and still generate the proof for the entire program for example yeah i mean you're so right though like the zk boom in a way came because of the scaling question not necessarily because of the privacy question but there are a few teams that have retained that privacy ethos but also bringing privacy back into the models so in your case like you're i guess using these starks for both the kind of the ability to create a roll-up something almost to like scale a blockchain but are you also using starks in that model for privacy or do you use something else for privacy no no the idea would be to use targs as well we

will need to have the recursive targets to to this efficiently so this is something also to work on but i think with the vm model once you have the vm a recursive start is definitely possible and you know it should be fairly efficient so the idea is that once we have recursive starts and we have this kind of foundational components that allow you to you know hide different parts of the program within the vm you will be able to support privacy preserving smart contracts on the blockchain wow that's really exciting i want to kind of go back just real quick to the beginning of this conversation the snarks versus starks and how they differed do you actually take any ideas or insight that you've learned like that are happening in the stark world or do

you feel like this is completely a new path like the underlying builds the kind of cryptography the the things you're using are different enough that you you don't need to or you can't borrow from the snark world there is some boring going on already i think for example the the changes to my vm that i'm working on right now they flow directly from some something that clunk was doing earlier this you know permutation based checks and this is a very powerful technique that in the original version of the staffing it wasn't even used because i wasn't aware of how to use them but now that these techniques permutation base checks are being used widely in the kind of community i mean i don't want to say because i'm not sure i know the full history of how it started out but uh

you know plonk was one of the systems that popularized it and i think you know stark war is using the the same permutation based checks in cairo for example and they're very very powerful cryptographic techniques that simplify a lot of things so there is definitely some crossbollination is going on and then i think uh you know things from stark as uh as i mentioned long tradition is somewhat it's not the same as air but it is it has a lot of similar uh ideas in it so they're not two separate ecosystems as i want to say there is there are differences but there is also i feel like with time the differences are getting more and more blurred rather than becoming more accentuated yeah i love that it sounds amazing i mean i like that idea of sort of using these

techniques from the different proving systems and then finding out like i'm just wondering if like down the line will ever be able to like mash up the acronym tarx oh god i'm not allowed to name things i think there is enough invested into different namings right now that probably is not going to change that much well we'll see anyway cool thanks bobbin for coming on the show and sharing so much of this journey and actually like kind of giving us an a fresh look into the stark world what's on the horizon and with the project maiden good luck with it thank you so much thank you for having me i want to say thank you to the podcast producer tanya the podcast editor henrik and to our listeners thanks for listening

[Music]