Anna Rose: Welcome to Zero Knowledge. I'm your host, Anna Rose. In this podcast, we will be exploring the latest in zero knowledge research and the decentralized web. As well as new paradigms that promise to change the way we interact and transact online. Anna Rose: This week, I chat with Bobbin Threadbare the lead at Miden 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 Miden a STARK-based ZK roll up, which is an evolution of his earlier work on Distaff VM and Winterfell. Winterfell being a highly performance STARK 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 wanna let you know that the last chance to donate to the Zero Knowledge Podcast Gitcoin grant during this Gitcoin CLR matching round, it ends I believe tomorrow. So yeah, if you wanna 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 wanna 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. Aztec is the first zero knowledge roll up built from the ground up for anonymous payments and DeFi transactions. Join the thousands of users already sending funds privately on ZK money that zk.money and start interacting with Aztec today. So thank you again, Aztec. Now here is my interview with Bobbin Threadbare. So today I'm here with Bobbin Threadbare, who's the lead at the Miden project. A project recently acquired by Polygon. He's also the author of Distaff VM and Winterfell. So welcome to the show Bobbin. Bobbin Threadbare: Thank you Anna, thank you for having me. Anna Rose: So Bobby and we met back in September / October 2019. I remember you were speaking at a StarkWare conference and I, 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 wanna 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? Bobbin Threadbare: Yeah, definitely. So 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 you know, way before and 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 actually started to learn about cryptography and trying to think through all the kind of math aspects of it and kind of more structural things that are needed in blockchains and things like that. So before that, I actually was running a small startup. It was kind of like a, not a, not a crypto focused startup. It was a to a regular web company focused on kind of trying to figure out how you can maintain like a personal reputation across different services and sites. 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 a single server. So I one of the kind of motivations for me to learn crypto 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 SNARKs 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, the promise is that you can verify computation and then nobody else needs to rerun the computation. And blockchain is like basically every node has to re-excute the same transactions and it just seems wasteful to me. So 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. Anna Rose: 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? Bobbin Threadbare: I would say I started even more broadly on the crypto side, trying to learn about elliptic curves. So I'm a software engineer by training 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 do learn about elliptic curves 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 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 I usually explained this as in my mind, and I, 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 for most other SNARKs, like elliptic curves and pairings and all of that stuff. And 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 I kind of gravitated towards STARKs. Anna Rose: 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. Bobbin Threadbare: Yeah, definitely. Well, one thing I should probably say upfront 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 than you know, some people argue about what exactly should be called SNARK or a STARK, but you know, going back when they started 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 like what the team STARKs stands for. So you'll need a trusted setup. This is not the case anymore. There is other proving systems right now that do not require trusted setup, like and would be Halo, for example, doesn't require trusted set up. The other distinction between a kind of like a very fundamental difference between STARKs at the time and SNARKs is that the arithmetization used so SNARKs at the time relied on R1CS and, you know, R1CS is still probably one of the most popular ways to describe computations for this proof of computational integrity. But STARKs had this different type of arithmetization 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 PLONK is also kind of closer to AIR. You can even say it's like randomized AIR with pre-procesing and, you know, things like that. Totally. There is actually more similarities now, but there is still quite a few differences. So I would say 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 fairly elliptic curves. Other times it could be just regular elliptic curves, but there is still need to rely on 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 you know, future quantum attacks. And because they own, 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, and they don't require any pre-processing, which is you know, the identifier just needs to know the AIR description and that's it. And they can verify any proof while SNARKs frequently you know, requires some level of pre-processing and that, you know, there is the distinction is that besides verifying and the prover, there is also this indexer that runs in pre-processes the circuit or something beforehand, so that the verifier can evaluate it succinctly or verified succinctly. So there are those distinctions that I think are still relevant. I actually like have this diagram in my mind where they like two circles, SNARKs and STARKs, and they overlap and basically anything that is non interactive and transparent and kind of scalable this is kind of falls into the, this intersection of two circles. 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 intersection between them. Anna Rose: Let's talk a little bit about the kind of outcome of these two systems. So something that's often cited is like the prover size and verifier size. And I feel like every time I try to cite the example, I end up mixing them up, but let's, let's clear it up. So, you know, maybe we can start with like looking at the proof size, how are they different? Bobbin Threadbare: So the proof sizes specifically, like how big of a proof that it gets generated by the prover 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 benchmark is that SNARKs like Groth16 and PLONK - the proof sizes are tiny. They could be 200 bytes or maybe half a kilobyte or something like that. So they're, they're really, really small. For STARKs even for simplest computations, we are looking at maybe like a dozen kilobytes and then for, you know, more useful computations that we frequently need to encode, like some some circuit that does verification of a transaction. For example the proof sizes are in dozens of kilobytes you know 80 kilobytes potentially closer to a hundreds or something like that. So, you know rough ballpark it's very computation dependent and also depends on the security level that you want. But basically STARK proofs are at least in order of magnitude, larger than SNARK proofs. And, you know, in some situations could be like two orders of magnitude larger. But I would say this comes with 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 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 a STARK that is kind of using you probably heard the term FRI as something that is used in STARKs, but you can use some other polynomial commitment into the FRI or you could instantiate FRI, to be done using elliptic curve rather thank 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 gonna increase significantly. So the proof speeds when you need to rely only on hash functions for STARKs, especially proving speed is very good very, very fast. Again, there is a little of 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 need to rely on elliptic curves you kind of lose some of the speed advantage as well. Anna Rose: Mm. 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? Bobbin Threadbare: So there are two aspects to it. There are there is the proof size itself, which obviously the larger proof you know you incur a little bit of penalty, but there is also a verifier time that it takes to verify the proof. So for STARKs, even though the proofs are very large compared to other systems, the verification time is fairly small. Because again, the only validating hash functions, which are very fast on, you know, modern computers, I think the, the verification time between STARKs and like, let's say Groth16 and PLONK are fairly comparable. They're not hugely different. But as an example, Bulletproofs is another system. It has relatively small proof sizes, you know, under a kilobyte, or maybe like a depends on, again, what you wanna 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 bulletproofs is linear in the kind of complexity of the original computation, which is not the case for STARKs and SNARKs where this verification time is logarithmic. So there are these two aspects, the proof size and the verification time, and STARKs do fairly well on all metrics except for the proof size. Anna Rose: 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, like the smallest it can be for now? Bobbin Threadbare: I think the proof size for STARKs you can't reduce it much more without like giving up something 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 loosing elliptic curves, and then you can shrink down the size probably by a factor of 10 or something like that. 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 I'm not, I don't wanna say it's impossible because I don't think I have enough of theoretical background to say that that nothing can be done to do it, but at least as far as I'm aware, there is no known or kind of like even promising technique to reduce the STARKs proof sizes significantly without giving something up that you know, kind of like forms the core promise of what STARKs are. But I, I do wanna 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 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 in, you know, sometime in the future. But as soon as you have recursive STARKs, the proof size becomes much, much less of an issue because, you know, you can take a thousand proofs and generate a recursive proof of verifying all of the thousand proofs and you shrink the size of that one proof significantly. So I, I do not think that I think at this point, maybe the proof sizes are somewhat a disadvantage for STARKs, but it's not a fundamental disadvantage. I think in the future we should care about proof size is much less. Anna Rose: And, 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 Mina 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? Bobbin Threadbare: Yeah, yeah. That, that's exactly the concept where, you know, you have many, many proofs and you just instead of a verifier having to verify these thousands of proofs potentially individually, you can verify single, there is another layer of STARK proofs, which aggregates all of these proofs together, and then you have just a single proof. So you go from a thousand proofs, 80 kilobytes each to a single proof, you know, let's say a hundred kilobytes and that's it. Anna Rose: Nice. And so I guess that could be, it could be said that you are starkifying STARKs, but I don't know if anyone's gonna use that. Bobbin Threadbare: Yes, yes. Anna Rose: 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 genSTARK, like, what was that, what was that project? Bobbin Threadbare: This was actually the first project that I started working on in zero knowledge space. And the way I got to work on this project is actually very 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 STARKs were, I really wanted to kind of like understand them deeply and see how they can be leveraged even outside of the startup that I was working on. And as I mentioned earlier STARKs resonated more with me in part, because I thought it was simpler and it kind of like made immediate sense to me 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 have, you know, quantum computers in 10 or 15 years, and if I'm gonna spend next X number of years learning something might as well do spend on something that will.... Anna Rose: ...the most advanced. Bobbin Threadbare: Yeah. Exactly. Yeah. So there was very limited resources out there at the time about how you can learn about STARKs. To be honest, there was some posts from StarkWare there was the blog series from Vitalik. So I kind of like went through it. And I think one of the things that was immediately useful to me in Vitalik's tutorial on STARKs because it actually had some Python code attached to it and I can read code. So it was easier. So for me, the way I learned personally is I tried to like build something I learned, I learned 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 looking in retrospect is a horrible language to write STARKs in because it's very, you know, not performant and you get very slow proving speeds and all of that stuff, but 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, I, first of all, I understood how the internal mechanics worked, 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 generate STARK proofs for other computations. So I started to generalize it to something that is not tied to a specific circuit, so to say, or to a specific computation. And that's what genSTARK was. That was the kind of general purpose STARK prover, which you could provide. You can, you know, verify any type of computation with. And that's what I think I shared this kind of like the earlier version of this on ETH Research at some point. And to be honest, the response was incredible. 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 StarkWare 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 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, you like so that led me to try to think, okay, how can I make it simpler? And that's what led me to like, thinking about like AirScript and AirAssembly languages, which the idea was that it's how do we make it simpler for regular developers to write STARK proofs? Anna Rose: We actually have a video, like there is a video recording of like you giving a talk on AirScript that I'll link to the show notes. 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? Bobbin Threadbare: Yep. So AIR is basically it's an acronym for Algebraic Intermediate Representation. It is the way that you describe computation so that the STARK proving system can understand it and just take a step back. There is, you know, if we think about programs that we wanna 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, you know, JavaScript or whatever. And, we need to describe it using kind of like a set of polynomial equations. And this is the step called arithmetization and SNARKs use arithmetization that is called R1CS that basically takes a computation and describes it as arithmetic circuit. And SNARKs use this air arithmetization that takes a computation, describes it as, you know, intermediate algebraic representation. Anna Rose: Is it somewhat like the opposite of what a compiler is doing? Are you going the opposite way? Or would it be some sort of compiler it's a translator, I guess, right? Bobbin Threadbare: It is 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 errors, very frequently, a human who is trying to take the computation and describe it in 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 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 specific computation. Anna Rose: Okay. Bobbin Threadbare: For SNARKs, their computation is called R1CS and it's, you know, in many ways it's simpler because it's, it's easier to compose different R1CS circuits. So to say the technique of how you can translate a program into R1CS is also, you know, can be automated to a higher degree, I think, than you can do it with AIR. So there is quite a few libraries out there that like, you know, have gadgets for R1CS. There are very few, or if any libraries out there that have gadgets for AIR, because again, composability of AIR directly is very difficult. So there are positive mind. And I think that's why a lot of people kind of gravitate towards like R1CS and other STARKs, as opposed to SNARKs because of the complexities of arithmitization. But hopefully like with advent of these virtual machines, this is not gonna be an issue. Anna Rose: 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? Bobbin Threadbare: I think even from the time when I started to work on genSTARK, 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 STARK proofs. I think we're getting to the point where not, you know, a hundred percent there yet, but we're getting very close to the point where you don't need to be a cryptographer, or 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 genSTARK and then AirScript and AirAssembly, and then Distaff 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. Anna Rose: And I guess that actually leads us to your next project, which was Distaff AVM, like, tell me how somebody would actually interact with this. So like, we've talked about VMs before virtual machines on show before, usually in the context of EVM, that's the one we say the most, but what is Distaff VM? Bobbin Threadbare: So Distaff VM I think was because it's now superseded by a different VM, but, which we'll talk about later, but it's a, basically a virtual machine in where there are a lot of other virtual machines. You mentioned EVM as another example, but is a virtual machine that has its own assembly language. And you can write programs for that virtual machine in, in this assembly language. And this is, you know, regular assembly language. You don't need to understand, like anything about cryptography to write programs for Distaff VM, and the advantage of Distaff VM was that for any program that you write it automatically generates a STARK proof. So it kind of does the translation 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 the proof for your computation without needing to generate new AIR for it. That's the biggest advantage, I think, to give a little bit of context about how Distaff VM even came about is that, you know, I was working on those AirScript and AIR 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 better way in my mind was building this VM. 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 Zcash 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. Anna Rose: Oh yeah. 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, that's interesting. Bobbin Threadbare: I wouldn't say that I found a 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 I was like, okay, 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, it basically didn't think was gonna be useful for anything to something that I now think can support Turing Complete computations, and basically the general purpose VM. But that, I, I didn't start out trying to think, okay, I'm gonna build a tour, complete virtual machine. It was more kind of like, okay, let me experiment and see how things work out. Anna Rose: In that era though, like, was AirScript the language to write on the Distaff 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? Bobbin Threadbare: So there was a DSL, but it wasn't AirScript. So the way to think about this is that Distaff VM supersedes AirScript. So AirScript was my earlier attempt of how you make STARKs accessible, but it didn't succeed as much as I would like it to have succeeded. So Distaff was kind of like starting from a blank slate. It, it did have a kind of domain-specific language, this called Distaff Assembly basically, which is the assembly language of the, of the VM itself. But yeah, it, it it's basically, you don't need AirScript, if you want to use Distaff VM. Anna Rose: Got it. It's it sort of covers it up. Like we're, we're leaving AirScript in the past. We're moving forward. Bobbin Threadbare: Right, right. Anna Rose: And now I wanna, I wanna push forward because I know like Distaff VM also like midway through the journey, I guess maybe yes. Maybe not. Maybe it's still even beginning. So let's talk about what you did next? I'm gonna of 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. Bobbin Threadbare: Yeah. So I actually, Distaff 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 improving system I thought was could be improved significantly. So it wasn't a very high performance system for generic STARK proofs. So actually, you know, halfway I would say I, I kind of put Staff VM aside for a little bit and I joined Facebook as part of their research group. And in there I got the opportunity to work on a lot of zero knowledge tech and STARKs 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 STARK prover. And you know, up to the protocol itself is much better implemented as compared to Distaff. And I worked on it over a course of probably like eight months or so at Facebook and had all of help, actually my experience working in Facebook at the, in the crypto group was extremely positive, but the, I, I basically was able to collaborate with extremely bright people there and they helped me a lot. You know, I, as I mentioned, I'm not a cryptographer, so I was able to rely on more kind of a, a theoretical expertise of people who work there. And it was very interesting. The environment was very collaborative and very open. I think I'm grateful a lot to be able to kind of have chosen my project more or less freely at the time. Yeah. and being able to work on Winterfell, but at the end, so we, we built Winterfell - this STARK prover. And the idea now is that we can swap it for the prover that was in the Distaff VM to make Distaff VM and actually the new iteration of Distaff VM much more powerful. So you can rely on this, a much more advanced prover. Anna Rose: I see. So, 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? Bobbin Threadbare: Yep. Yep. So It's doing a lot of those things, but I think the way to think about Winterfell is that you still need to bring your own AIR to describe it. So it, it, it is still at the level of abstraction that is not out as developer friendly as Distaff for example is. So you need to still understand STARKs. You need to still understand AIR. You still need to be able to describe the constraints yourself, but you can describe any constraints on Winterfell and, you know, it's a general purpose STARK prover. So it's very similar to what I was trying to do with genSTARK in JavaScript, but it's now done in Rust. It's now done in, in a way where it run in multiple threads. So it generates proofs much faster. The implementation of the STARK protocol, as I mentioned, is also up to date to at least to what I am aware of. So the proofs are smaller compared to like the proofs that were generated by genSTARK or Distaff VM. There's still in dozens of kilobytes, but you know, roughly half the size of what it used to be with the old provers. Anna Rose: Very cool. What was Distaff VM written in originally? Like, did you have to rewrite anything for it to work with this with Winterfell, which was in Rust? Bobbin Threadbare: so, Distaff VM was also written in Rust, but I should say that that was my first project in Rust. So I was still learning Rust as I was writing Distaff VM. Anna Rose: I love how so many of these it's like, so iterative it's like your learning project is also like eventually powering these like really powerful things. That's cool. Bobbin Threadbare: Yes. I, I think, I mean, again, this is how like, by doing, I learned by doing so for me. Yeah. Like I was like, okay, I should learn Rust. What's the best way to do it Anna Rose: 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? Bobbin Threadbare: Yeah so, even though Distaff VM was written in rust we basically rewrote the prove for Winterfell from basically from scratch. I mean, it was, it started kind of the core started by copying some of the Distaff underlying components. But at this point it's unrecognizable so much has changed in part because you know, I code and Rust that in part because I also understand STARK 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. Winterfell even though it started out as kind of core Distaff prover it's very, very different. And now I think we'll talk about it later, but the next iteration of Distaff VM, which is called Miden VM is using Winterfell of its component, but it's also taking some parts of Distaff. So over the last few months, I actually released the release of Miden VM 0.1 is basically migrating original Distaff VM to use Winterfell as the backend prover. So now this is what Miden VM 0.1 is. Anna Rose: 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 Miden is the project. And would you say Miden is Distaff VM 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? Bobbin Threadbare: It is a new product now, but it is even gonna be a newer product in a few months from now, because I see at this point, basically the Miden VM 0.1 is just the Distaff VM using Winterfell prover, which makes it more efficient, faster proofs, smaller proof sizes. But the functionality of the VM is still the same as Distaff. We 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 realized that there could be a lot of improvements done to the VM itself, to like make the instruction set more useful, to add random access memory, to adapt it to, I would say a blockchain environment where, you know, you could prove solidity programs using Miden, for example. So what I'm very actively working on now is developing this new version of Miden VM, which will be even more developer friendly. And I can talk a bit more about like what I mean by that, but it will basically support languages such as Solidity and other high level languages and will be specifically tailored to blockchain work. And I can Miden VM itself is a part of a bigger project, which we can, I guess talk about in, in, in a, a few minutes. Anna Rose: 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 Miden. But yeah, so I think it was a few weeks ago, maybe a month ago 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 Miden? Bobbin Threadbare: Yeah. So at Facebook you know, I worked in Winterfell, but I one of the things that I still really wanted to do is kind of make this kind of transition to build or develop Distaff VM further. And while there, I got a approached by Polygon guys and they talk to me about kind of their vision of how they want to evolve Polygon suite of solutions and things like that. And, you know, it, it made a lot of sense to me. I think it is fairly clear right now that they're, they're betting very heavily on ZK tech and there are a number of kind different solutions already being developed. And Mihalo from Polygon knew about Distaff VM even way back when I was working on it. He didn't know about me working at Facebook because Bobbin actually is not my real name. So I work on the different names in different places, I guess. Anna Rose: That's fair. I only know you as Bobbin. I'm, I'm going with that name. Bobbin Threadbare: Yeah, so basically like the reason why people didn't hear about me for a year, because I was working under different name and Winterfell was released under different name as well. And then, you know, I talked to him about my work on Winterfell and like what I would think about next evolution of Disttaff VM. And I think it fit well into their view of how this wanna approach this strategically. So I got the opportunity to come and work to Polygon, to, you know, make Distaff VM a much more powerful VM, and build a Layer 2 solution, a roll up around it as well. So there was a name change from Distaff to Miden kind of to signify that this new VM is gonna be much, much more powerful. And you know, there is a lot of new things that I think justified the name change. And it is, as I mentioned gonna be just one component of the overall. So once the VM is built or at least is in a stage where it is powerful enough to support 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 2 solution that can execute arbitrary smart contracts and generating STARK proofs for them. Anna Rose: 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 gonna act sort of as the it's the connector, I guess, to the L1, between like an L2 you in L1. Yeah. Like, cuz we had Jordi on the show, Jordi, Hermez 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? Bobbin Threadbare: So it is a different VM, but I think kind of the overall goal is I would say similar is just the route to that goal is for example, what Jordi and for Miden is different. I think at this point in time, there are quite a few projects out there that are building different types of zero knowledge virtual machines. There is you mentioned Hermez and Jordi. There is StarkWare with Cairo. There is zkSync with I think they call it ZK EVM or something like that. And I think there is two or three other projects that are trying to build virtual machines that are automatically generating zero knowledge proofs. It seems like this is the way, at least in, in all of people's minds forward in terms how you can support very organically zero knowledge proofs you know, in the blockchain world. So this virtual machines all make different tradeoffs and different, different design choices. And I think there's plus 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 that correct or maybe appropriate for a given use case. So, you know, to, to compare with Jordi's approach that you mentioned. So Jordi is building a very close to EVM replication of the VM. Anna Rose: Exactly. We talked about it like op codes 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 you, you take a STARK-like construction and then you Snarkify that, and then you write it on chain. So there's actually this combo. Bobbin Threadbare: Yep. I mean, those are very valid design choices. There is a reason why you would want to do that. Let's say support EVM at the op code level because you know, it will make it much easier for people to migrate smart contracts. Miden VM takes slightly different approach. So there is a VM that is different from EVM. There is gonna be its own 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 smart contract, you know, basically at the byte code level, but you can migrate it at the Solidity level. So there is, it may be a bit more involved in terms of migration. 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 Miden. And 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. Anna Rose: Interesting. What do you kind of imagine, like if the two projects and I, I feel like it's not the only one for 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? Bobbin Threadbare: I think It's, it's possible. I think it's too early to tell how exactly the architecture will work out just because 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 I think the way we work on this is actually very collaborative within Polygon. We have 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 Hermez. 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 this conversations and basically share ideas on how, like I'm trying to solve something and, you know, somebody might have already solved it. And then if I will, you know, have some solution that somebody is trying to figure out. So 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 you know, I worked together with at Facebook and I wasn't sure what it was gonna be Polygon like, but I think so far I can say that experience have 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 you know, on weekly basis. And we kind of discuss all of those things. And so this has been a very good outcome in my mind. Anna Rose: 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. Now you're in a crypto company, I guess we'll call it web3 company. Do you feel like, is the 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? Bobbin Threadbare: I think so there are two aspects of it. There is the aspect of like working with directly with your colleagues, which I think in 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't speak for a larger company because, you know, I've only been exposed to like the crypto research organization within 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 experiments and figure out what Anna Rose: You get to be real. Yeah. You get to do kind of like the fun stuff. Bobbin Threadbare: Yeah. The other aspect of it is where you need to interact with the outside world and we need to go through kind of all the, 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 an outside interview requires a lot of approvals even trying to publish. Anna Rose: I know, I remember trying to get someone on from Winterfell, was just told like, nah, you're gonna have to go through tons of stuff. So I was like, okay, fine. Bobbin Threadbare: I, I think like one example just to contrast again, a larger organization like Facebook versus a smaller kind of more nimble, I would say 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. 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 were, we wrote the blog with a week basically, and it got published. 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 you know, those are the, the facts. Anna Rose: Totally. Yeah. I mean, it, 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 wanna 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? Bobbin Threadbare: Well, first of all, to talk about like open source STARKs, I think there's been implementations already. So like even starting with like, as early as my, well, even before then, the genSTARK was a kind of an open source implementation of STARKs. I think there were other implementations, I think, you had Ramco at some point, they also worked on a open source, STARK prover and then Winterfell, for all practical purposes, it is an open source STARK prover even right now you can use it now. You know, some of the aspects, you know, it's an evolving project. 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 in production. If you wanted to have this 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 under it operates and how you need to write AIRs, for example it does make it much more simple. I, I do think like one of the, I don't wanna 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 AIR sophisticated programs out there and 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 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 ETH STARK. It is that they were extremely complicated to use without kind of, they didn't have their own DSLs that were simple enough, or it basically required you to spend all of time on this, like scaling this learning curve before you can do anything useful with them. But now as we have, you know, StarkWare has Cairo and we're working on Miden 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. Anna Rose: 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? SNARK-tober, I think was the name 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 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. Bobbin Threadbare: I, I think for one, I see more people or more projects kind of making use of different STARK components, such as FRI, for example, like there is other projects out there that are trying to rely on FRI and kind of, like Jordi is seeking, you know, planning to use them, there are other ones out there that I'm aware of. So I, I do feel like the understanding from kind of people who are very deep in ZK tech of what STARKs are and how they can be used. And you know, how different components of STARKs can be married with different components SNARKs is increasing 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, what proving system I am using or, you know, Anna Rose: True. Bobbin Threadbare: They don't even need to know that the underlying proving system of Miden VM is STARKs or something like that, they just know that there's zero knowledge proofs generated. And then this is the properties that it has. Anna Rose: Totally. So going forward, I mean, we just, you mentioned before that right now Miden is basically Distaff with the Winterfell prover architecture, but like, what is the future of Miden on the technical level? What do you already see on your roadmap to change? Bobbin Threadbare: So there are quite a few improvements that we have in mind for Miden specifically. So as I mentioned earlier, one of the things that Distaff liking is random access memory. So this is something that we're bringing in that will make Miden VM fully feature complete, but there are two other things that we're trying to, or kind of working toward with Miden 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 Miden VM versus like some other like VM that is not necessarily tailored towards zero knowledge proofs and getting a little bit into technology right now. So most of the VMs that I'm aware of that are out there, they, it 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 the input integers that the VM understands and that's what the VM kind of natively supports then if you other the 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 the core of the VM. You can support kind of privacy in the future. So, as an example, most rollups right now, they're used for scalability purposes. They're not used for privacy purposes. I think there are some rollups like from Aztec, for example, that do work for privacy purposes as well, but you know, most rollups in their current shape are used for scalability. And this is, is what kind of the original, not original, but the immediate goal of Miden project is about, but we do wanna make sure that you can, there is a roadmap or clear roadmap of how you can get to, let's say something as complex as privacy, preserving smart contracts, where it's not only that your transfer is private, like, you know, even on other networks or in kind of privacy preserving systems, you can provide privacy for simple transactions. But what we wanna achieve is privacy at the smart contract level, where if you wanna hide the code and you know, you don't wanna reveal the code of your smart contract. You can still do that. And, you know, the VM is being designed such a way, which naturally should lead to something like that. I mean, there is still a lot of questions to answer in terms of how this will work, how this will work and still be interoperable with Ethereum and all of that stuff. And this is something that will 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. And still generates the proof for the entire program, for example. Anna Rose: 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 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? Bobbin Threadbare: No. No. The idea would be to use STARKs as well. We will need to have the recursive STARKs to do this efficiently. So this is something also to work on, but I think with the VM model, once you have the VM, a recursive STARK is definitely possible and you know, should be fairly efficient. So the idea is that once we have recursive STARKs 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. Anna Rose: Wow. That's really exciting. I wanna kinda 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 come completely a new path? Like the underlying builds the kind of cryptography, the things you're using are different enough that you, you don't need to, or you can't borrow from the SNARK world? Bobbin Threadbare: There is some borrowing going on already. I think, for example, the changes to Miden VM that I'm working on right now, they flow directly from some something that PLONK was doing earlier, this you know, permutation based checks. And this is a very powerful technique that in the original version of Distaff VM, it wasn't even used because I wasn't aware of how to use them. But now that these techniques permeation base checks are being used widely in the community. I mean, I don't wanna say because I'm, I'm not sure I know a full history of how it started out, but you know, PLONK was one of the systems that popularized it. And I think you know, StarkWare is using 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 cross pollination is going on. And then I think you know, things from STARK is I mentioned PLONK's arithmetization is somewhat, I, it's not the same as AIR, but it has a lot of similar ideas in it. So they're not two separate ecosystems, as I wanna 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 accented. Anna Rose: 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 we'll ever be able to like mash up the acronym SNA_SARKs, oh God, I'm not allowed to name things. Bobbin Threadbare: I think there is enough invested into different namings right now that probably is not gonna change that much. Well we'll see... Anna Rose: 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, Miden good luck with it. Bobbin Threadbare: Thank you so much. Thank you for having me. Anna Rose: I wanna say thank you to the podcast producer, Tanya, the podcast editor Henrik, and to our listeners. Thanks for listening.