Episode 251: Exploring Risc0 with Brian Retford and Jeremy Bruestle

Transcript

foreign [Music] 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 [Music] this week Guillermo and I chat with Brian Redford and Jeremy brustel from risk zero we talk about their previous working cloud and how ZK offered unique solutions to long-standing scaling problems we cover topics like Risk 5 building VMS and talk about how risk zero aims to build a system that could

support a robust decentralized public cloud but before we start in if you haven't yet be sure to check out the ZK whiteboard sessions it's produced by CK hack and powered by polygon this is a series of educational videos that will help you get onboarded into the concepts and terms that we talk about all the time on the ZK front it's a great place to start learning about CK Tech we also have a study group going right now focused on the ZK whiteboard sessions so be sure to check that out over on the ZK hack Discord also keep your eye out for the upcoming ZK hack 3. we are returning with our virtual multi-week event once again on November 22nd there will be workshops and puzzle hacking competitions keep an eye out on Twitter and in Discord for

more information now Tanya will share a little bit about this week's sponsor today's episode is sponsored by Mina protocol if you're a developer looking to get hands-on experience building zero knowledge applications then you should apply for mina ZK app beta testers leaderboard participants will get access to test challenges where you can learn to build ZK apps on Mina for a chance to rank on the leaderboard against other participants and the top participants will have the opportunity to be considered for a grant Mina ZK apps are written in typescript so developers can easily get started without learning a custom programming language like other ZK protocols learn more about the ZK app beta testers leaderboard and how you can start building ZK apps by heading to minaprotocol.com forward slash ZK

podcast that's minaprotocol.com forward slash ZK podcast so thanks again Mina protocol now here's Anna and Guillermo's interview with risk zero foreign Guillermo and I are here with the guys from risk zero welcome to the show Brian Redford and Jeremy brustel thanks super glad to be here yeah it's wonderful to do this uh conversation cool a quick note uh zkv and myself personally are investors in Risk zero and I guess being Capital crypto is as well yeah obviously we are never giving Financial advice on these shows it goes without saying but uh we thought we'd just let you know that before we kick

off so to start this off I think it would be great to meet Brian and Jeremy tell us a little bit about your journey to working in VK in blockchain in general blockchain is fairly new for me um my interest in CK originally uh comes from the sort of more mathematical side my background has been in I mean I've been interested in computer security and cryptography for as far back as it goes probably the first notable thing I did was I wrote air snark which is a program that uh broke web encryption uh many many moons ago if anyone still remembers WEP it was the old uh Wi-Fi protocol

thing um and I'm really fundamentally um interested in sort of following new mathematics and sort of emerging research and trying to figure out where you could potentially commercialize that most of my startups historically have all been in that sort of Arena where there's some sort of new theoretically interesting thing and then you figure out how to apply it I've been following ZK for about um seven or eight years since I first discovered the PCP theorem about probabilistically checkable proofs and when I realized that it was possible to check correct execution of programs in constant time regardless of how long

they ran I was like wait a second this like completely changes the landscape in terms of scalability of distributed computing and all of these things right but at the time it was not a practically useful technology right everything was just way too slow so I continued to follow the research on it and the way that I do that because I love math but I'm not a mathematician I'm not really great at writing proofs you know I'm not an academic and as a result of the way that I I read math is I read the papers and then I try to implement the code and so I had been you know sort of in my you know copious spare time between startups and you know other things you know taking a little bit of time to implement

some of these ideas from the various papers I was reading um and then you know at some point realized that it was we were now at the point where this stuff was about to become practically useful at which point um you know I think I started to try to pitch everyone that I knew about this this you know oncoming future of uh you know sort of zero knowledge proofs and how they would change the world so I think that's when I started to try to talk Brian's ear off about it as well so cool what era is this exactly what time frame well so I think the the the when did I start talking to you Redford two years ago I think this is two years ago we were on this like road trip to to

Oregon um wait you were on a road trip to Oregon yeah well Intel's offices are down there oh got it got it got it so there's this pattern where Jeremy gets uh gets involved in or interested in things and uh then starts talking people's ears off about them and that's actually you know how we we started our first startup 20 years ago which was doing decentralized Wireless Mesh networking over 802.11a and B it was and eventually G that kind of worked um that company eventually sold to Nokia long after we uh we ditched it um and then I went off and worked at Google for seven years where I was building out the Google Cloud platforms

pricing building and metering systems um which actually feeds into my interest in this space so uh yeah what's the connection there the connection is that um inside Google you would see a lot of projects and products and product managers all trying to figure out features for their Cloud products and seeing features ship or not ship and the gating Factor was like can we make 95 margins on it or not and so I think there's this huge barrier to innovation in this space that really comes from the sort of centralized control over what cloud products actually ship and which ones don't and so um you know after Jeremy convinced me that we could use zkata to really you

know achieve Cloud scale decentralized Computing like it's hard to look away wow well I want to get into that I want to get into that Vision um is there anything else sort of in the lead up to forming risk zero that you think like you sort of mentioned some companies some startups so one thing that's worth noting is me and Redford have known each other for a long long time we met through the Seattle sort of hacking scene as well as some of the other folks I'm in the company and we've we've done multiple startups together prior to you know this we worked at a company called vertex AI which basically built um uh a tensor compiler that allowed you to accelerate various AI workflows

especially on different custom chips which is why we ended up getting acquired by Intel um so I think that the the thing to note is that we've we've done multiple companies together we've known each other for a long long time and the you know but that we're sort of new to this particular um realm although I've also been following to be honest we've been following you know the state of um cryptocurrencies for a long time I mean I read satoshi's paper when it came out and my my thought was wow what a brilliant solution to the distributed consensus problem but it's only going to do four transactions per second ever because it doesn't scale so who would ever use this thing which was clearly not correct um but you know

um when Jeremy you know talked me into doing this company he's like really we're gonna do a blockchain company I mean I think cryptocurrency is cool you know I've used it for various things you know in the past but um uh was this Prime this is like bear Market a little bit it was like 2020 is this what we're talking about maybe it was Bear Market I mean at the time yes but I think by the time we really started talking about making a company it was it was the hate the full Market okay coming up did you but did you guys have this sense of like crypto as like did you have any concerns about like the scams and the things that had made headlines I mean I don't I think I did only from uh is this a sustainable business model is this space going to you know is this

going to eventually be something that doesn't dominate those sort of headlines in that way but I also think you know I bought lots of nfts prior to this my friend one of my close friends was actually one of the pioneers of air and and was an early sort of nft person on tazos so I always saw the value and I kind of ignored a bit of the hype around or or like mainstream media dunking on crypto constantly I mean it's some kind of an easy target yeah um so yeah I was a little worried about it but I think the more I dug into it the more I realized that you know I think a lot of the most interesting things in computer science are going on in this space right now did you think was it really the ZK part that dragged you in though because

like you had known like you said Jeremy you've known about blockchain for a long time like what was it what's the switch there so so for me like I've always loved distributed systems and I've always believed in decentralization um and you know I mean our first company was really a wireless Mesh networking company and it used a lot of it was a very heavily focused on decentralizing routing and Communications right um and I always is wanted to really love you know sort of cryptocurrencies and not so much the currency side but some of the more interesting things like smart contracts and what you could do with ethereum but like to me there was obviously this issue which is like if I wanted to build Reddit on top of you know one of these systems

it was never feasible right because there's always this idea that the because they don't scale if you have a lot of transactions the cost per transaction just goes up and you know no one's going to pay 50 of gas to upvote on Reddit right it's just not reasonable and so I like the idea and concept but it wasn't until sort of this realization that zero knowledge could help pave the way to you know I think one of the things we like to say is transactions too cheap to meter right this idea that we could actually build really you know sort of cloud scale distributed systems on top of these that I got really excited about the space um so I'd always been interested in it from an intellectual standpoint but you know at that level and I think ZK once

we started digging into it so you know I think between sort of that road trip and and Jeremy like I mean I didn't even believe this was possible and he's telling about it my mind is just blown for like a month like somebody's gonna figure out something with the math but then once you dig into the math you're like no this seems like it's not that hard to understand like at a conceptual level and it does seem like lots of computer science would be broken if this is broken so what was the starting point CK was like what was the paper or like project that first dragged you in do you remember so so for me I mean I think it was well so originally it was just discovering that the the sort of PCP theorem was in fact true although not necessarily useful but then I think the

one that really got me excited initially was the cycles of elliptic curves which was a sort of first recursion in zero knowledge proof systems because to me recursion is one of the key components that make scaling possible so I actually implemented that whole thing um but the recursion time was like like I don't know a minute and a half or something on the implementation I had and I was like too slow right um and uh and the implementation was pretty efficient as well so I I I basically continued to follow it in a until the deep fried paper was the first one where I was like okay this is starting to get to the point where it's really doable and I started working on implementations of that um and uh yeah I think I think it was what I got to I got a working recursion

for a simpler system than the current proof system we have right now that was down to 15 seconds and I could see how I could get it down below one second and then I was like okay this is this is super cool right this is actually when Jeremy started talking to people about it he kind of like didn't mention he was doing any of this until he he's like like explains the whole thing he's like and also you can verify proofs inside another proof but like so when you think about it and you're like oh okay this has insane implications it's just truly insane so here's a quick question for you right because like you know now let's shift maybe a little bit more towards zero but I'm actually curious It's like a it's like a wild idea right like to me like when you guys first

talked to us like when you mention it it's like the obvious thing to do it's like hey we have we have we can build circuits right what is a thing that is very cool to build with circuits but the whole concept is wild right like you have these circuits now you can like build things with them you can prove things with them and this is like very interesting kind of theoretically speaking because like sure I can like make a thing that you want to convince me of and like fine like you can convince me of it in like this very nice short proof okay but the jump from that to being like hey what is a cool thing we can build the circuits that isn't just like you know a calculator or something it's a processor right and then be like oh wait we can

like efficiently verify the entire exist like you know an entire program trace on a specific processor by just like you know instead of building the processor on like an fpga or like a real circuit you build it in this like zero knowledge circuit like where the hell did that idea come from because like at the time you know ZK VMS are kind of maybe starting to be a thing but people who haven't really talked about it and like it was known you could do this but it's kind of a logical leap so yeah so I started it was it was it was basically because what I tried to explain how one would go about writing a program no one could understand what the earth I was talking like it was it basically it was like oh an arithmetic circuit okay

wait so it's like a circuit but it's in a finite field right you know I have a lot of friends who are very smart programmer hacker types right and I I as I tried to explain oh it's turning complete you can do you know everyone was like that thing sounds impossible to program yeah and I think the the initial versions too we were because our background at like vertex Ai and the company that Intel acquired was building out dsls for machine learning so we're like we'll just build a DSL and use myr to compile these circuits because this is a pattern we know and understand and I don't know we hacked on you hacked on that for a while but at some point I think it was I think it might have been Redford who came up with the idea he's like what if we just use an existing

like Isa I can't remember because we were all hanging out together I think it was Redford that actually was the one who came up with that and then and then basically once that idea popped into our heads the real question then was is that actually feasible and if so what would be the architecture to use right so we looked at like webassembly we looked at mips we looked at all kinds of different things and within with the the sort of question of how small of a circuit can you build and still run something that's an existing processor because you know we did a lot of compiler work our previous company was a compiler company we know how hard compiler tool chains are and how hard language adoption is and so this idea that you know you would just build an entire functional compiler tool chain and a new language and the

whole nine yards and get adoption that's like a huge amount of engineering on the other hand if you can build a circuit that is able to run something that already exists then all that upper part of the stack you get for free right I say not just the upper part of the stack too but the entire ecosystem of libraries and existing work that all the other developers in the world have done over the you know course of time I was gonna say we were just talking recently about you know um this this sort of example of using doing image cropping using uh you know is your knowledge proofs and um from you know danbone and one of the one of the thoughts was well actually inside the your risk you know zero ZK VM we could decode a gif and then crop an image and

then re-encode it to a JPEG or whatever because I could just import the you know libraries for doing that um you know directly because it's an already existing language right right I remember like a year ago like you came up to us and you were like hey what if we just like did risk five you know like one of the restricted isas sorry and say what did I say means like an instruction set uh instruction set what does a stand for architecture it is architecture okay um you know as like what if it just like did this and then like had all of risk five in other words all of lvm which is like this thing that you can that everything compiles to including like rust C C plus plus anything you want um so you can compile everything down to

lvm and then compile lvm down to like you know this like micro like micro architecture I guess it's like Risk architecture right uh and then just be like oh yeah cool like now we just like can use everything you want on this thing but also it's zero knowledge because like that's that's like a thing you can just build in zero knowledge it's just like yet another circuit right um and I was like wait why the hell did no one think of this this is like insane well Ellie actually yeah there was a tweet where Ellie um who's amazing and you know we're obviously huge fans of Ellie's um I'll leave on Tucson then the inventor starts um you know somebody asked him like why did you invent Cairo why didn't you just you know um use mips or something he's like oh well that's not gonna be possible for at

least five years or something so I think that there's just when you if you there's this sort of like you know if you start building something in a in a nation's space it's pretty easy to kind of get stuck in thought holes so I think we just you know effectively just had a second we were advantage and we just kind of already primed to think about the world this way one of the questions I did have I wanted to ask was about the name risk zero so Guillermo you just mentioned risk five usually spelled risk v um I'm guessing it's risk zero knowledge is that where that comes from yeah yeah very nice you know I've got like one thing in life and it's making up really stupid things like that this is a great name though this is like honestly like

probably one of the best like like just it's just like such a good titles reference yeah yeah it's just it's really good it's like it's perfect and like people are like quite polarizing it's quite polarizing really no way the one of the earliest people I pitched on it was our product manager from Intel and he was like that is the stupidest name [Music] okay and wait You just defined risk V risk five but I actually don't know anything about this so can we actually say what that is actually talk about why we chose it Jimmy Yeah Yeah so basically risk stands for reduced instruction set Computing and this is this idea um you know uh early microprocessors uh there was a question of should you make

the instructions for the processor complex and do lots of things or should you try to boil them down to the smallest possible set of instructions the most simple way to represent a program you end up having to run more instructions but the processor becomes much simpler to build you can run it at higher clock speeds and your compiler has to be smarter right so so it's basically that that's risk five is a very modern um new risk instruction set that's learned from all of the previous ones and so it's like super minimal and very capable and well designed and so when we looked at it it was definitely by far the sort of easiest of the existing instruction sets or VMS out there that we could Implement right you know yeah

and it also has no IP encumbrances so x86 is the most notorious cisk or complicated or complex I'm not even sure what the C stands for anymore so you know implementing x86 would probably be harder than building a ZK evm um maybe maybe not Jeremy would know but um uh you know then if you're if you're not doing that you're basically looking at you know arm or mips uh and there's a whole bunch of other ones that maybe you could think about but um arm arm is arm has IP encumbrance and mips used to until very recently but also is a bit more complex but risk 5 also comes with a bunch of bonus features um in addition to being open source it has complete battery of conformance tests so we know that our processor

implements risk the risk 5 specification because well at least in so far as the tests capture that but on top of that they actually have a formally a formal model for for what the risk five ships look like so in the kind of formal methods work we're doing at some point we'll be able to you know really speak very confidently about the nature of the system that we're building what exactly now are you building then like are you building a ZK VM where you can run something like Risk on it I don't know if that's how you're supposed to say that at all or is it is that that's exactly what happens yeah okay so like if you if a programmer writes you know like uh Sudoku game or uh uh Mao the card game I know some people trying to

do that in in rust or something and just compiles it then it runs on top of this VM just like a zkevm might run solidity byte code this runs risk 5 code so any so we support C plus plus and rust the compiler compiles this down into risk the risk five Isa and then this runs um inside this VM it's really like having a little like Arduino or microcontroller that's like attached and living inside your system but it's virtual and it can't lie about what it does yeah and also you don't it still has the same kind of ZK properties where you can hide inputs and so forth as well as hide the program you can know you can just commit to this functional commitment idea you can commit to knowing the hash of a program that produces uh or acts in a

certain way yeah you just you've sort of flipped as you're describing it you flipped a little bit between the ZK VM zkevm this is a ZK VM right this is not for solidity all those languages you mentioned are not solidity so do you still see yourself a little bit in the camp of the zkevm ZK VM teams because there's a lot of groups that are trying to do something like this so there are two ways you could think about obviously you know the ethereum ecosystem and developer Community especially since I've gotten involved the space just blows me away the the the events and and all the people uh just building in the space so you know we're by no means uh trying to detract

from that ecosystem and I think there's a lot of ways in which you know risk there was Zero actually uh can contribute to that ecosystem so it is possible to compile solidity code to llvm we haven't played with that very much just because you know um time but another thing you can do is run the evm on top of risk zero oh so you can actually compile well you can't do compile a Geth yet because our go supports like well the go support will be fully functional in a bit but um you know one thing at a time but there's also rust implementations of the evm and that you can compile and you can actually you can run ethereum programs on a evm running on top of risk five so you

know you can a nice thing about having a general purpose processor architecture like this as your base ZK proving system so you can in fact run other VMS on top of it there's actually people and you know they haven't told me exactly why they're doing this but running an x86 emulator on top of risk 5 and then proving the results of Linux kernel boot on x86 it has something to do with gold bars um that's all I can say wait what is the point of this sorry I'm like that the person hasn't told us exactly it has something to do with like physical asset tracking and sensors associated with that edit logistic points and stuff like

that I see a lot of applications for this honestly but that's wait but I'm surprised like a lot of sensors just like fully just have Linux instead of using some like real-time operaticism I yeah he did not get into the specifically okay well that's fair five all right um do you like in the ZK part of the ZK VMS are you talking about privacy or are you mostly focused on the scaling quality we absolutely care about privacy um and uh I would say that both are very important to us um in terms so so we are we do fully support zero knowledge um and we support both zero knowledge of the um

execution of the program as well as we can even make it such that you can prove you ran the program you said you were going to run but without revealing the details of the program the use cases for that a little more obscure I mean I think if you look at the core technology it's a you know the idea that you can build systems with the risk with the zero VM that do so like enhance privacy and you know enhanced scaling I'd say as a company we're initially focused on the scaling aspects so when we were idating on what to do as the company we spent went into deep deep ZK identity kind of rabbit holes because I think this is the the use cases that most excite me about this space have to do with pseudonymous uh identity and the ability to ZK you

know basically do ZK out of stations and sort of reputation scores and all of this stuff but fundamentally I think if the infrastructure is not there it seems like these you know having an amazing ZK identity system when you can't really build uh you know sufficiently complicated application ecosystem seems kind of pointless so we're focused on scaling because I think that's sort of the where the um biggest need I think is at right now yeah I mean it's table Stakes basically right like I if I want a distributed Reddit that has DK I could do all kinds of cool things with the identity but if I can't actually build the system in the first place it's sort of not relevant so here's a quick question uh I think we

discussed this prior but um you know risk five or any architecture does not often have like a notion of here is private data and here is public data right and we're talking about privacy here so like how do you enforce like you know what data is public and what data like if you're just compiling a c program down right like the C program itself has no notion of here are my variables that I will not reveal to you right like it has the notion of like here are variables that you should not access but there there's no notion of like privacy in like C or rust or whatever right so so we model that via Library calls so effectively um the way that it works is the ZK VM

begins execution and there are sort of um calls you can make to request data from the so we call we call the VM the guest and we call the computer running the proof the host so um the guest can act ask the host for information which is always presumed to be private the guest can do any kind of computation it wants all that is presumed to be private there's a specific um API for writing to the public record and anything you you don't write to the public record is private so you know typically what you want to do is you you want your zkp to attest to some fact about something and so so whatever you want to attest to you write that to the the public record and that's the only

thing that's public everything else is private so that's kind of how whatever you commit to up front I guess yeah okay so and what does a program look like right so like usually in processors like a program is well in like real processor is not this like weird thing where we have a bunch of like virtual you know things with the kernel right you have like here's what happens you have like a chunk of memory that is a program right and that's like you compile it down you then like write it to memory and then you say processor start at 0x04000 go and then it starts like reading instructions from memory and going up but like you know what is like do you have a notion of memory like how

does it like maybe it's getting a little bit too into the weeds but I'm just like very curious about this specific thing it works exactly like that there is exactly um a processor there is a representation of ram we actually use a permutation argument a mechanism to do the emulation of the the random access memory um and yeah it looks exactly like a regular processor we actually so so when you compile the program down we actually compile it to an elf which is a type of uh it's a it's a loadable object file for um you know operating systems and basically we load the program into memory as at the dawn so so when the when the VM the ZK VM begins execution it the first thing it does is it loads the program code into memory

um and then it jumps to the start address and then it runs just like a normal program on a normal processor um and uh and then it when it terminates uh this is basically use that e-call which is like a low level instruction in Risk five to call to the operating system to represent the termination of the program and uh that's pretty much it so it actually it fully emulates all the things like you would expect and when you write a program you know it jumps into Main and there's some initial setup and all the sort of exact standard stuff I was gonna ask one more question which is um like what does here here's like and this is a question that a bunch of teams grapple with but you know how do you

abstract memory in like a ZK sense this is like it's a weird question right like what does it mean to like load a file into like this ZK circuits and then be like cool all right go so uh the current implementation you know we just represent memory as a bunch of 32-bit numbers that live at well-defined addresses um that's sort of the word size that the processor likes um uh and uh you know you can load a byte instead of a word if you want to but that's all just sort of handled by the VM um and the pr the initial program State we actually encode into sort of a Merkel representation from the elf file so

effectively the the initial memory image is determined by that sort of miracleized data structure uh so then there's a special mechanism for talking to the host using non-determinism so there's basically this mechanism by which the guest can request data from the host and point the host to a particular memory address at which point data just sort of magically appears in that memory which is allowable because one of the things we do with our memory semantics is we Define memory which has never been read or written to as being allowed to have arbitrary data and so as long as you tell the host to put it in some place in memory that you haven't ever

looked at before which we handle via the library calls and sort of the underlying sort of operating system level of the zkvm um then when you asked for the host to put something there you can it can it can appear of course you need to verify that it's right right so so on top of this we're basically building a set of you know mechanisms for allowing sort of um you know sort of merkelized access to data structures and we're looking at buildings sort of like an IDL around that to help make it easier for programmers to manage and stuff um I'm sorry this is a little bit of a I'm going into a couple of different things because the question is kind of broad so sorry I apologize but just like even thinking about it right like the idea that like you have a processor that

lives in you know inside of your processor fine let's say like ZK evm and ZK VMS in general have thought about this but what I've never seen before and this is like [ __ ] wild to me at least is like this idea that you could just like you know have undetermined data at the time you're executing except like the one time you're you know like you're executing this like very long complicated program right a bunch of stuff is happening and then you're like crap I need to go read like this thing but this thing is not defined while I am ex like at the time that I I'm going to like read it this thing is not defined so what do I do I can just like ask you know this is like the little computer living inside your big computer right

the little computer is like I don't know what this thing is so please big computer you know your laptop or whatever tell me please what like should this thing be right I will pause execution until you're like tell me what this thing is and then you just like go and insert it and then it just continues happily as of like yeah everything was cool the entire time but it's like wild right yes although you're not guaranteed that like anything that happens on the host side is going to produce something a proof that's interesting reasonable to talk about of course which is why we get into this kind of work live data structures like if you know if you call out to the host and they just accesses a random URL and dumps data back from it then you can't really speak about what the characteristics of that are that's

right that's right that's right but it does allow you to do sort of the check and verify right if I want to do a square root I can always ask the host hey please put the square root of this number here and then inside the ZK VM I can take that number and I can square it and make sure it matches the thing I'm expecting it to be so with you know gkvm systems use this sort of non-deterministic trick a lot but in our case it's a particular easy like please fetch this the content addressable storage that hashes to X or whatever you know exactly and then you can verify that it actually hashes for that so that's right that's right so like you use this trick a lot like in ZK proofs but this is like a very nice and transparent way of doing it right like

when you create a secret proof of like a statement you have to know what the values of that statement are but like here it's like a very like transparent way of doing that right it's like oh no like I don't know what this is please like let me just like go fetch that from like the big computer that I existed and then like the big computer is like here you go you know it's like God handing you down and you're just like I will just check you just to be sure but that's okay exactly right it's interesting because in some ways it inverts the sort of notion of you know if you look at you're running some program in Linux and then you want to call into the operating system you fundamentally the operating system is more trusted than the you know sort of program running in this case it's kind

of like the opposite it's like there is an operating system you can call out to the operating system it'll hand you data but then you better check it because actually The Trusted part is the the program that's running um so it's kind of an interesting inversion in that regard so a lot of the ZK VMS that we've been learning about use Starks or they use fry and snarks somehow like they'll do like a recursion step using something that Starks actually uses as well but why are most of the ZK VMS using at the very least parts of starks or actually using full Starks under the hood so so largely it's because Starks are particularly efficient at proving circuits who have a repeated

structure and in this case the repeated structure is time so the idea is is that um you know a job of a VM is there's the state of the processor at time T and then it computes the next state at time t plus one and time t plus two it's basically executing the same function if you will over and over again stepping time forward and Starks are really well suited for that the air representation you know has this our built-in notion of um that and it's so it's a perfect match right for a sort of something that wants to look like a digital circuit running over time so this is the air features so this is different from r1cs and other kinds of snarks air arithmetic intermediate representation you gave me

that definition before I did not actually memorize it myself and I I sort of I have a visual of this that it's like time-based rounds kind of like it's going equal time but why do you need that exactly well so if you think about it it's interesting the the analogy between a you know actual digital processor and these sort of arithmetic circuits is really strong right um they both like you know if you look at a digital circuit you've got wires and then you have like Gates and in an arithmetic circuit you have numbers and you have these operations like multiplies for example and in a real digital circuit there's this idea of clock cycles and combinational logic so you've got this combination logic which is just like a

feed forward circuit some inputs come in and it processes through and then later some outputs come out but in a real processor you don't just use combination logic you also have these little memory cells that when a clock cycle comes in stuff goes from through that combination logic lands back in memory cells and then it gets stored there and then the next clock cycle comes in and that same process repeats and so the process that's happening inside of you know say your Intel processor or whatever is this basically this process where every clock cycle there's a current state and it then computes the new state and then the clock cycle ends and the next one comes around and that exact structure is the way that a stark is structured so if you're looking at something that wants to sort of execute steps over time it's

a really Perfect Analogy and in fact actually one could literally transliterate the design of an actual gate level risk 5 processor over into a stark if you were to do that in the naive way it would run horrifically slowly but the model is actually strong enough that you could almost lift the the direct implementation yeah I kind of wonder if that's why Ellie like invented them in the way he did I don't know I guess I've never asked and asked him that but you know it might have been very intentional on his part to build something that is more amenable to creating a VM you know given that Cairo was you know one of the first kind of VMS of this kind this is maybe a bit of a dumb question but like what you know we talked about

the ZK VM as the environment where you would then deploy risk five why does it need to be in a ZK VM why couldn't you do that straight on a nl1 like on ethereum I mean on ethereum maybe it's because it doesn't allow for certain op codes or I don't know but like could you could you not just have this as a standalone blockchain oh uh yeah you could and uh yeah that's what we're working on okay and actually you are so actually that's that's so funny another question then because like ZK VMS and zke VMS pretty much every time we talk about this it's always in the context of like them living on another blockchain as a roll-up kind of still using shared security but in your case

you don't need to I think the thing that's important to note is we are very much interested in the L1 space and making an L1 but part of the reason is the fundamental reason that these systems don't scale has to do with the way that consensus itself works right um and that if you re-look at and re-examine the question of how do you build a consensus system how do you build how do you build an L1 with the knowledge that ZK exists it changes the set of tools you can have so one of our goals as a company is to sort of say okay if you start over and you say what can you do what can you build in terms

of a consensus mechanism knowing that you have this capacity to do zero knowledge proofs where does that get you in fact one one real quick analogy so why do l1s not scale very well and it's very simple actually you know if someone wants to run a computation no one can believe that computation was right without running it themselves and as a result every machine in the network has to run every single transaction right um and with ZK that that assumption is different the the trust that can exist between two parties is fundamentally different so one person can run the code and someone else can check it and the process of checking is much smaller than the work of running it and you can use that as a building block to help make

systems scale I mean there are examples of that already in the wild like Mina is a recursive snark PS I'm an advisor to them so just declaring everything um but uh but yeah I I'm just wondering like I guess like in your consensus in the consensus part are there's is there ZK in there as well like are you using that recursive technique as well yes okay is that the part that is the ZK of the ZK VM or is there like double layers like there's a Zeke their ZK and consensus and then there's ZK somewhere else uh so there's we use the same zkvm both for consensus and for the execution environment for user programs and in

fact I guess the way things are shaping up in Germany could talk about this a bit more you know sort of ZK predicates are kind of a key part of how we actually like agree on the next state of the world so yeah I was gonna ask like um because this is like somewhat recursive right like what are you doing are you just like programming a verifier on top of like your risk 5 processor that then verifies like the computation so like you're just like using the it's like this feels like a bit of an oroboros like I am using my platform to both like do the computation no make us improve the computation and also mind you I'm also going to verify it on the secret like you know whatever the ckvm right as like part of the thing and then like now use that as like my like fully

succinct like small proof that I just like make sure everyone knows to start from Genesis to now or something is that the idea uh so so currently just to be clear the um the existing open source version that is already released already works you know you can run full zero knowledge proofs on real programs inside the ZK you know uh VM we're currently working on adding support for recursion I mean that's not currently released uh but that said we do have a sort of prototype working and literally our recursion actually runs our normal rust verifier inside the ZK VM to do the verification of the zero much proofs right what's the like abstraction that

you use for recursion because recursion is kind of a weird thing but like you don't really do on normal processors I mean it's very similar to mina you just you call you know in from inside uh the guest you call the verify function it's just like you would in like snarky JS you're like doing a proof and you have a proof as an input and you call verify on it and now you or if you call verify on two proofs you've now created one proof that verifies two proofs but like you also need this to be like incremental right you don't just like because you don't reprove the entire but but if you think about like one can verify the proof that the the Block in derives all the way from the Genesis block so I can verify the that proof that I got from somewhere else outside

and then I can add another transaction and that combination of those two things proving the the history till to Point N and then adding n to n plus one that new proof now proves zero to you know n plus one I I think you've sort of answered that earlier question too like why would a zkvm be a better environment than something like ethereum to deploy risk zero right because like what it sounds like is that that zero knowledge proving proof thing is it's all intertwined and you wouldn't necessarily be able to do that with like a vanilla yeah you could certainly like verify a risk zero proof on ethereum it'd probably be reasonably expensive I think we talked a bit about this certainly but um you could build an L2 a risk 0 L2 on ethereum I think it

just doesn't necessarily I don't think you're ever going to get then this kind of native scaling enhancement that we're really hoping to see yeah one of the one of the cool things is that if you are looking at it because of the fact that I can verify two proofs in one proof I can then do that two layers and I can do verify four proofs or eight proofs or 16 proofs and you know powers of two as a result our goal is to basically be able to literally process billions of transactions per second right our idea is to we we sort of have this idea like we're not kidding about being able to make transactions too cheap to meter the idea of being able to just really make

the scale of um you know sort of these consensus systems massively larger than it is I mean they'll still probably be metered but you know effectively unfortunately that idea I mean it's it's interesting to hear your story of like where you were coming from the problems you were working on and then seeing ZK is the solution to that you sort of mentioned this like infinitely scalable Cloud infrastructure maybe not infinite but like more than now are you still working on that as the vision is that the end goal or are there like other use cases that have sort of come up so I mean I think when when you're talking about building an L1 you know you obviously

want to support all of these sort of existing use cases for blockchains so you know defy gaming nfts token transfers all this kind of stuff but Additionally you know you want to support and you see a lot of people trying to do this in the evm ecosystem as well it's like building things that look like uh SQL databases and other kind of um you know developer tooling that actually makes it possible to write more complicated applications more quickly so we're still like the intent of this chain is to enable people to also build effectively cloud services and we'll actually be we're actually building one on top of rl1 that that will eventually release uh that basically lets you prove any arbitrarily complex computation very

quickly using massively parallel GPU acceleration proofs but we started to sometimes talk about ourselves as like instead of being web three we talk about it as Cloud 2.0 I mean I mean we really do absolutely want to construct and decentralized um you know um public Cloud you know write something that you can run real you could build like you could build a social media you know um system on or you could build you know real end user applications that are scale you know where Cloud usually you like relied on these like International database like databases kind of all over the world everything would be very very fast in this case are you like actually imagining every person's every like node

Runners machine or mine or validate or whatever it is they are the data center yes effectively okay so we're actually talking to a bunch of uh exothermia miners about utilizing their gpus because we have a GPU accelerated back end for this which is a key kind of key to achieving the sub multi-millisecond recursion times that will hopefully eventually get to which really is kind of the the you know linchpin or hinge for uh for for scaling so yeah we're talking to if you know anybody out there that's gpus you want to use them for something you know let us you're not proof of stake then you're going to remain proof of work or are you like a hybrid we still haven't fully decided um but our current notion is this thing

we call sort of proof of transaction which is a little bit like proof of necessary work but the the idea being that it will be proof of work like except that the work being done is literally yeah okay and so as you add more energy to the system you get more transaction rate so um the the idea being a way to make use of all of that work being done to actually help end users get what they want done although certainly we could absolutely build uh proof of stake mechanism as the sort of final decision about which blocks are considered correct as well from the so so from the security perspective we could choose

either but regardless there's going to be a fair amount of compute work being done just running the zkps themselves that's fascinating yeah and zkp's have this neat property for a system like that where you can determine longest chain not necessarily by number of transactions but by actual overall amount of computation represented in it so as you roll up all these DK proofs you know exactly how many cycles sort of went into every leaf or branch of your tree I actually we did years ago we did an episode a full episode on proof of necessary work with akikatus so I'll link to that if people want to understand a little bit more about the features characteristics of this proof of necessary work or proof of useful work the name has changed a couple times but yeah it's interesting on the topic

of um I guess scaling first things first is you know you're talking about a processor that lives inside of a real processor so you could talk about something weird like how many megahertz you're like does it you know does it actually run at like how many cycles per second how many instructions per second can it actually do and so here's so now this this is a very concrete thing that I can ask how many uh cycles per second does your current tiny processor run at inside of like a you know normal let's say a normal CPU I mean I heard you said you had a GPU previous I'm also curious about those numbers yeah so currently on my Mac um what what Mac is it uh I guess it's the news M1 So currently on my on my M1 Pro

um I get about 30 000 cycles per second um for execution now um sort of with the versions we're working on we anticipate that I I'll actually we actually support currently on our GPU acceleration which is not released we support metal which is uh Mac os's acceleration framework um as well as Cuda um and we're looking at more like on the one megahertz so about a million um wait metal actually does uh like large field arithmetic or do you have to do like some weird tricks feel the recipe check uh okay cool so what does note by the way is that our background our previous company was

almost entirely focused on yes um acceleration of ml workflows across multiple systems including you know gpus CPUs custom accelerate Traders right so we have a a large background in terms of how to make gpus um uh doing interesting and sing and dance if we want to we want to say it that way yeah okay and then so okay so fine that's that's uh Apple uh M1 Pro you know using accelerate uh framework or metal or whatever you'd like uh what about a you know a cool new hot off the press well actually not so hard to press anywhere but 30 90 or something like that like you know like a big GPU do you you have any ideas on those numbers probably an order of you know about 10 million instructions per second

although uh we haven't uh we don't have the full full numbers on that yet but um so we're like getting to like you know 1970s 1980s like that's like 90s well I guess I guess I guess see I mean you should be able to run doom on it is the key thing yeah yeah no I was that was exactly the question I was gonna go for is like what do you think we'll be able to run doom and ZK you know uh but well so an interesting point about all of this too is that um you know they're the ZK the workload split up into two parts one's like running the program forward and creating sort of tape that you then prove and the other parts proving it yeah and the proof the proving it part can actually be split up and done in parallel right I mean you're exploiting

this already like when you're doing it on the GPU right like that's effectively yes and and we we should be able to go wider So in theory one ought to be able to sort of run the sort of tape generation as uh Redford describes it um and then split the work out across a farm of gpus or what have you um and so you should in terms of latency to actually generate a proof of a fairly large computation we should be able to get it down I mean one of my goals with our work on recursion and acceleration is to be able to do things like running um you know a full version of a compiler like GCC or something inside of the proof system and be able to generate a

zero knowledge proof that in fact this source code compiles to this binary right like real there are a lot of real world use cases for this that's really good in terms of yeah absolutely securing supply chain stuff like you know making sure that binaries that exist and things that are running on systems being able to ask them to periodically prove that they're using uh you know binaries that were verifiably generated from source code that you uh audited so like how long it'll take those use cases to actually trickle down into the real world who knows but like couldn't I just like prove that about like a binary that I'm not currently using so there are there yeah things get complicated if you're not doing this for every single computation if the binary itself that you make is run inside of a

zkp system as well okay yeah sure fine yes exactly like recursively occasionally yes right if we say within the sandbox then you can of course always prove everything well but when people start talking about ZK Hardware you know and kind of like bearish on it in the short term but long term you know I think somebody's asking us you know could you use risk zero to make sure that like F-35 fighter jets are like running the software they're supposed to be or something like yes hypothetically not right now probably okay yeah well I'll ask the basic question then you can you can uh you can tell me the video so okay so fine you know now we have like fancy schmancy like 30 90s and and you can run it not just in 139 in fact like

arbitrarily wide because we know like ZK proving it's nice and maybe not arbitrarily but pretty damn close right it's pretty paralyzable so the next natural question is okay uh how about you know what are your thoughts on like maybe using it using fpgas or using like you know like very specific like ideally at some point in the future once everything is very standardized asex but you know what what are your ideas behind like Hardware acceleration of Seagate proving so I I currently think that the math is like unsettled enough and um and that Asics are uh hard to hard to make take a long time and it's also very hard to get access to the latest memory process node technology and so forth so I think it's going to be a long time for

Asics or competitive fpgas at least for Starks you know I don't know Jeremy probably can answer this like more precisely than me but I honestly think gpus are probably going to be um very Salient for quite a while oh interesting effectively a lot of this stuff is memory bandwidth um limited and you know it's really hard to beat the memory bandwidth of um a 3090 right um so I think that long term we may see more sort of acceleration but yes I agree I think that it's a little early or for like very specific snark kind of circuits if you see certain use cases evolve or people want certain things done very quickly maybe you'll start to see Asics for those but um yeah but I think another uh aspect of sort of acceleration and we talked about

accelerators there's like accelerating the proving system and then there's also um accelerating operations you're running on the proving system so when it comes to like doing recursion for instance like right now if you try to just run the verifier the pure rust verifier on top of our source code it takes a very very long time in fact on the open source version you run out of available Cycles before you can actually complete a recursion um but we also have an architecture for building accelerator circuits so if you think about like the a chip in your laptop you have a GPU but you also have like cryptography accelerators you have networking accelerators there's like really like about 100 different chips on a sort of modern microprocessor so we have an ability to also sort of build

these acceleration circuits and it's Jeremy kind of talking about which acceleration circuits we have in their role in recursion so so in our current in our current system for example um that's uh available we currently have an accelerator for sha 256 in particular because people need a good fast hashing function and yes absolutely you could write sha-256 on normal risk five um you know machine code and it would do all right but you can do much much faster if you write a specific circuit that does that specific thing so in the sort of next version of stuff we're going to have additionally a finite field accelerator which is particularly relevant for recursion we're also considering adding

a bigint uh modulus multiply accelerator which should enable a large number of sort of elliptic curve kinds of use cases to be run efficiently and you know we're contained and some also some additional um you know hashing functions I mean effectively if you think about you know if you want to build something if you wanted to say run you know Geth on top of the risk 5 zkvm then you know much of it would actually run just fine but some of the you know heavy cryptographic components take a lot of cycles and so if we can if we can move those into accelerators um then that's a much better way to go I just want to make a quick clarification

because when you're talking about you because because we kind of circled into hardware and then out when you're saying accelerator circuits you're talking about virtual circuits still right like this is not very much so okay that's right what are they are they just like libraries what are they so so basically we have this risk five circuit uh which represents the computation of a normal risk 5 processor I mean we can just put sort of next to that in the arithmetic you know circuit representation another circuit that does say shot to 56 and then based on sort of what cycle we're running and what the risk five says we have this wave that for those two circuits to interact um in our current mechanism they actually interact through memory so the

you know risk 5 processor writes to certain regions of memory and then kicks off the shaw accelerator which then reads that memory and writes something else and then it goes back I mean the new system we're actually going to model it as calls out to the operating system like you would uh you know in a normal computer if you're running code you can call up to Linux to say right to a file so instead we're going to attach the accelerators in that sort of a method but yeah it's basically an extension to the core circuit itself interesting yeah that we yeah when we sort of build these in a circle it's not exactly like circum it's quite different but if we have our own sort of circuit description language that hopefully will release someday once it's a bit more mature that we use to kind of describe both the risk 5 circuit

as well as all these accelerators is this a proper DSL or is this like a different thing oh it will be okay and and like can you write so let's say I wanted to write like an accelerator for like I don't know Matrix multiplies because I think that's really cool and kind of know what I do can I just like go ahead and be like is it is it a standard call I guess it's a question like do I need to go and like actually change the you know the risk zero source code or can it you know can I just like call it as if it was like a cool little module or like a just like a generic right if you wanted to write like blast Library you'd probably have to like hook your blast you don't probably have to redo your blast back end or something like that to

call out to your accelerator sure sure let's say I can do that let's take I like hit you know I I like edited the blast libraries so like every time it does you know whatever any of the like last level one operations that calls my cute little chip and said can I just like well first things first so when I write this chip in like circom or like your DSL and like compile it down to like some like specific set of like whatever earthquake circuits which I can then use and then like hook into and I can just do this like anyone can just do this or is it just like well currently we haven't released the circuit compiler sure um but once that at some point it would be a reasonable use case now what's worth noting is that you need to compile it into the circuit

right so basically when you run a given program you're either running the program on the sort of stock you know risk five circuit that has you know say uh a risk five chip and accelerator A and B or you could run it on yours that has some additional accelerator so we at some point we imagine that people will want to run different programs on sort of different Hardware skus if you will uh the idea that like the proof system will support this idea and you'll be like oh well I I need the one I need this you know yeah exactly it's okay I like the idea of a hardware SKU for like a fake processor that is like a zero knowledge chip living inside your machine is just like it just all really comes back to like a very weird like

mental image that like doesn't really make any sense but I love like I just love it it's great you know in some ways one of our sort of goals is to make these systems approachable to programmers that previously knew nothing about zero knowledge proof systems and I think that this model of the zkvm as just uh you know a little VM a little virtual machine that works a lot like any other virtual machine you know you cross compile your code you run it in it it can talk to the host through some kind of communication Channel um you know really opens it up to I think a wider audience right and you don't have to learn a new language or even what an arithmetic circuit is right you just think that there's this little like it's kind of like a little you know Arduino sitting there inside your

computer I have one last sort of point I want to cover and that's so we talked about risk zero living as an L1 is it going to be connected to any other network or network cluster like I'm talking ecosystem ethereum polka dot Cosmos like anything like that almost certainly however the likely partners are going to do that so you know if you want to disclose things that aren't signed yet but we have a couple of partnership deals um yeah in the works and people are very much actively looking into doing that and we're going to actively support them doing that yeah so we see this technology is you know being broadly useful and and while we certainly have our take in what we think the L1 is going to you know provide and be useful for I think we also want you know this

technology to be available to other ecosystems yeah do you imagine the connection point just being Bridges or are you able to connect in a different way to these networks yeah that's like um also TBD or can't reveal and also also going to take a couple different forms you know this is how our L1 will talk to them and then also just how the technology will get used um by these other systems yeah I mean if you think about it there's there's sort of a multitude of different parts of integration like so if you just look at ethereum for example one could run an ethereum evm inside on top of our VM but one also could

have a verifier for our proof system that runs on existing ethereum there's a lot of different ways to bridge things and we anticipate there will be lots of different mechanisms used for different use cases so I wouldn't say there's a one-size-fits-all answer to that question certainly in terms of all the sort of ZK light client bridging stuff that everybody's doing these days I think there's a lot of interesting potential applications there naturally delved into the details myself last thing maybe you can give us a little bit of a sense for the timeline the roadmap when are you live can people already use this yeah where are you at right so as Jeremy said you know the current version is open source and the sort of next version we're working on will be open

source as soon as it's um since it's sort of you know more complete but we are when you talk about the sort of blockchain and this uh very fast GPU proving service we're working on a devnet and we're hoping to have um you know have that be public sometime uh like early next year late this year but we will have a sort of private sign up um and we'll we'll be you know sending that out uh uh over Twitter probably mostly and various other distribution channels so a couple people signed up and you know we're hoping hoping to get this into people's hands you know pretty soon nice well thank you so much Brian and Jeremy for coming on the show and sharing with us

all your work on risk zero as well as your journey to work in this field yeah thank you guys it was super fun actually sorry I devolved into some weird tangents but it was kind of interesting yeah all right thanks again Guillermo as well for coming on for this one all the way from Bogota big fan very excited to actually you know be on it when we started the companies like maybe someday we can be on this one today is your day nice all right thanks a lot guys I want to say a big thank you to the podcast team Henrik Rachel and Tanya and to our listeners thanks for listening [Music]