Episode 296 - Zeth, Bonsai and RISC Zero with Brian and Jeremy

Transcript

[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 this week Nico and I chat with Brian and Jeremy from risk zero we catch up on the state of the project and map out the pieces of the stack from the risk zero zkv M which utilizes the risk 5 instruction set architecture the Bonsai proving service and the type Zer

ZK evm zth we chat about how they made some of their design choices how all these pieces work together and what we can expect in the future now before we kick off I want to share a message from one of our top sponsors of the recent ZK Summit 10 alo alo is a new layer one blockchain based on zero knowledge technology they are offering more than a million dollars in Grants that you can apply for over at al.org Grants before we start I also want to highlight our upcoming ZK hack Istanbul event this IRL hackathon is happening from November 10th through 12th be sure to get your application in and if you are accepted please RSVP only those who RSVP will be admitted I've added a link to this and the alog grants in our show notes now

Tanya will share a little bit about this week's sponsor [Music] launching soon namada is a proof of stake L1 blockchain focused on multi-chain asset agnostic privacy via a unified set namada is natively interoperable with fast finality chains via IBC and with ethereum using a trust minimized Bridge any compatible assets from these ecosystems whether fungible or non-fungible can join nada's unified shielded set effectively erasing the fragmentation of privacy sets that has limited multi-chain privacy guarantees in the past by remaining within the shielded set users can utilize shielded actions to engage privately with applications on various chains including ethereum osmosis and Celestia that are not natively private nada's unique

incentivization is embodied in a shielded set rewards these rewards function as a bootstrapping tool rewarding multi-chain users who enhance the overall privacy of namada participants follow namada on Twitter @ namada for more information and join the community on Discord discord.gg NADA and now here's our episode today Nico and I are here with Brian and Jeremy from risk zero welcome back thanks excited to be here very nice to be here again cool hey Nico hey Anna hey Brian hey Jeremy hey so one quick disclosure before we start in on this one ZK validator and I personally are investors in Risk zero and Nico's team

over at geometry is also an investor and we are really excited to jump in and get an update um you were on the show almost exactly one year ago so if anyone is curious sort of about your back stories we're going to add a link to that in the show notes and last time we had you on to me you were just going public with what you were building at the time in that episode we discussed kind of how you were constructing your architecture I'm going to try to paraphrase what risk zero is and then I want to hear if this is still how you explain it but in that episode we talked about how what you're doing is you're basically taking risk five a processor architecture and sticking that into a ZK circuit and that

would mean that you could write L like you could write programs in C++ or rust and then compile it down into something that it understands already in a circuit is that still how you explain risk zero to people definitely yeah I mean the core technology hasn't changed uh at all I would say it's gotten more mature and the set of packages and libraries and programs that you can run without modification has increased a lot we support 1300 of the top 1500 rust crates or something like that oh wow did you still Focus though on like C++ and rust or have you expanded to any other languages I think we've mostly focused on Rust at this point because um it seems to be a very good language for um

writing things in that is familiar to the sort of um you know crypto space although we' we've definitely discussed expanding our support to other languages um one of our sort of goals is to have really excellent support for anything we support So before we take on something you know uh we want to make sure that we have the resources to do a really good job of it um so yeah we could get it more into that as well in terms of like which use cases which different languages are are more suited for I think and you know inside crypto certainly when you're thinking about applications with a lot of tvl behind them people seem to be gravitating towards rust for for really good reasons um but then if you start to think outside of web 3 you start to see uh increasing interest in a iety of

languages what do we mean by support here is it that there are some things in the Ia that are missing to support other languages no but it's it's more like for example on Rust some packages have assembly code in them and the assembly code only runs on x86 for example or um you know certain uh things expect certain kinds of Hardware accelerators to exist that don't actually exist or or things like that so so by and large most things um just compile and work automatically uh but there are some special cases that still do require additional work right but then on a per language basis you also have to think about like designing memory allocators that are that are most well suited for the zkm but most importantly it's just

trying to get the tool chain into a situation where it's really accessible by your sort of average C plus plus Dev which you know cargo's cargo is amazing in a lot of ways and C++ and the sort of programmer build ecosystem there is not not so great so it's like a support challenge you just mentioned that you would like you've brought in a lot of the crates is this something you have to do no but we do test them all so so uh basically we don't need to do anything on a per crate basis but we do run big sweeps of crates to see which crates tests pass inside the zkv m and which ones do not and the ones that don't we look into why and usually it's some kind

of like uh you know thing that assumes it's on a certain type of platform or something particular about some lowle detail yeah happens to use random numbers or um things like this which are obviously complex to to get right in a ZK context um but some some packages you do need to modify a little bit here and there I use the term um just in that definition before process or architecture as describing risk five is that correct or is it a VM this is what I'm trying to figure out so the risk five spec lays out the rules that have to be followed between the risk 5 software and what is the hardware like the the basically the the the way the

software talks the hardware um and that's you know called it Isa typically but we actually Implement a VM but the VM follows that set of rules and so it looks like a risk five processor to all the software is basically the short version so it's kind of both it's kind of both like when you think of a actual like Hardware architecture you're probably talking about a very specific revision like a 8486 like uh rev 7 or something like that that's the actual like where all the gates are whereas this is just the instruction set architecture which defines the op codes you know in ethereum heartlands that you need to to actually interact with the machine so we we look from a from an application perspective exactly like a risk five chip but obviously there's

there's no Hardware there cool so um listening back to your episode a year ago I noticed that you guys mentioned numbers of like the speed of this virtual processor like how many cycles can you prove in how many seconds of real time and the numbers back then were like 30 khz uh on an M1 CPU and like 10 mehz on a GPU cluster is this still relevant today have things evolved can you tell us a bit more yeah we we've actually made some performance improvements uh since that point uh and in terms of the sort of GPU cluster kind of use case uh Bonsai actually um you know we can sort of get that to go uh quite fast uh you know I think I think you know so we're probably at the 30

mahz sort of level for some use cases and we're continuing to work on uh performance improvements and we expect a number of additional performance improvements um over the course of the next uh couple of months um but I think one thing that's interesting is is I think in terms of the one big huge performance Delta I think between now and then is the fact that at the time you could only run smallish programs h um and I think that with the creation of continuations uh one of the huge things now is that you can run any program no matter how large um and you know you could prove entire eth blocks or run

very complex logic and I think that that has opened up the door to a lot of use cases and what's interesting is that we find that most of the times that a lot of the things that people are working on the performance doesn't really make that much difference because the ability to run these use cases is so transformative that the um you know exact people are not people are not that concerned with the exact number of clock Cycles because it makes something go from not doable to doable and one of the cool things about the way continuations works is that um we don't require some massive machine with a huge amount of memory and ever increasing sort of uh computing power as you uh run larger programs we simply

distribute the work wider across a more GPU nodes or whatever right so it's a lot more tunable in that regard what is it that you call continuations like I starter proof I start my program in one proof and then I resume it in the next proof uh yeah so it's basically a way to take a very long serial execution and to break the process of proving it into multiple small segments um and then each segment is proven and then we combine the proofs of each segment with recursion um so so yes in some sense you're proving the pro prog over multiple smaller pieces but that's all transparent to the user so the user just says run this huge program and then we to sort of take care of that yeah there

is a mechanism in place for users to be able to explicitly choose when they want to pause if they do and then to resume from that later so if you do want to pursue like more complex parallelization strategies and things like this there are some mechanisms to allow that um but yeah is it a little bit similar to like batching proofs though or is it is this a different Paradigm like actually I don't think we've ever heard that continuation yeah it's sort of a a a unique thing um as far as we know but I think so it is similar to batching in the sense that batching allows you to run lots of small proofs but in this case you're running one large it's sort of the opposite in some sense right in batching you're taking a number of small proofs and running them inside of a

larger proof to improve performance and in this case you're taking a very large proof and breaking it down into smaller proofs in order to um allow you to run larger um operations basically yeah this sort of process was the thing that really let uh this sort of zth project actually succeed uh and that that we announced recently and have let you know people start to experiment with running full eth blocks based on code that um you know we didn't write it just utilizes revm and W and a couple other crates um to to prove full E blocks so we had to make some very minor modifications but that proof is about 4 billion cycles and we sort of use continuations to split it up into 4,000 um 1 million cycle chunks and then prove

those all in parallel and use Rec cursion to join them together is the continuations in any way like specific to risk 5 or have other teams in the space used this kind of technique I mean I think anything that has sort of a VM based structure um you know should in theory be able to to do this same type of thing and I think some of the people looking at folding are doing similar ideas exactly so from a theory perspective continuations is very close to IVC if anyone remembers like the Nova episode mhm so incrementally verifiable computation and this is something we've seen the lurk people do um for their VM as well but I think there are obviously some differences and from what I understand yours is very paralyzable yes

so one of the things is um and I think that some of the folding schemes could be modified to support this but most of them currently sort of prove one segment at a time um and so so you know you're you add up all the time for doing all the proofs whereas our mechanism is to basically do a very fast normal emulation so not doing proving just emulating a risk 5 like you would run in a normal emulator determine all of the events that occur during the course of the whole programs execution and then split out those pieces um to a wide number of machines that all can run simultaneously um and then we use a binary tree to do recursion so that the amount of time the wall clock time required for the recursion is small

because we can also do those recursive um combinations also in parallel so it's very um focused from a design perspective on trying to reduce the wall clock time and increase parallelism um and and also I think one of the other goals is to be able to utilize consumer grade Hardware so um you know none of the proving processes involved in like the even the sort of zth you know Pro an entire you know eth block really used more than 18 GB of GPU Ram or you know what have you I think we we could actually have brought that down that just was a nice number for the machines that were on um AWS so by doing that we we basically reduced the cost of the

computation by being able to run on Lower performance machines as well as making it yeah more appealing and and um useful for future decentralization use cases Andor you can imagine running parts of proof on the client side and then having other parts that don't involve private information running on servers and so forth It's funny just going back to the folding idea I actually I didn't even bring it up because I just assumed it was different and actually I want to do a quick check because like in folding doesn't each chunk need to be the same no okay uh so so so because we're using general recursion we could actually verify roofs from different circuits um So currently we pretty much only use the

risk 5 circuit for the majority of things and the risk 5 circuit includes a couple of accelerators in it but in terms of some of the cryptographic accelerators we're considering building separate circuits for some of the accelerators running those the the accelerator operations in a different circuit and then using recursion to combine that with the risk 5 uh circuit so that will actually allow some very interesting use cases in the future cool so you know one of the questions is like it's been a year what are you what have you focused on what have you explored and maybe we should say like what have you released CU there's actually like products and things that people have been able to play with so let's start with the what have you explored over the last year yeah so over the last year I

mean we explored uh specifically apis and trying to get continuations right and just really the overall developer experience as well as um sort of the very early versions of bonsai which um basically Implement sort of a co-processor architecture um based on this relayer contract yeah we talked about this at eth Denver even we built a sort of clob internally that if you place orders on chain you can then do the order matching offchain and and then settle the settle the orders on chain and you're seeing actually some other people start to adapt adopt these approaches with the ZK Unis swap that that Diego um put out this is the ZK amm yes exactly okay that's on Bonsai then

that was built on Bonsai it's built I mean I think just built it locally using ZK VM but if you wanted to to actually productionize something like that you'd probably want to use SP okay but is it a full-fledged co-processor on mainnet today I always thought of it more like a test environment somehow sorry it's been a test environment for the for the past while but yeah the um people use it right now in a through a rest API so it looks like a lot like a cloud SAS service right now but it will be on chain um coming up pretty soon so um yeah we're basically going to launch a very simple test net that actually dials back some of the co-processor sort of features that we had put into it and really just makes it a simple request

appr proof on chain and this sort of a a permission service that rero is operating or is this meant to be decentralized and have people contribute yeah so the very first version will be um will be permission list in the sense that it runs on chain however the sort of people fulfilling the proofs initially will just be us but it's very much Our intention to start expanding that Set uh as soon as as soon as we can yeah yeah so I think I think you know this last year um a lot of our goals have been to get continuations was a huge a huge feature and uh I think also just trying to get to sort of a 1 with the ZK VM um we've been developing really rapidly in terms of improving the

apis and making changes but we really want to get to the place where we can present a very consistent you know reliable thing going forward that people can start to build on and know that it's not going to change out from under them so trying to get all the necessary work to get to that 1 um I think we're very close to that um and then yes I think that yeah obviously um this sort of bonsai sort of service which allows you to run large proofs on chain uh and you know we'll eventually be decentralized as sort of the next big um step forward we hope to you know get something out rather soon uh in terms of being able to let people use that yeah I think going participating in hackathons you know the the Delta between we went to eth Denver participated in eth global and you know

somebody W using rero for the proof of exploit um but something we learned from there is that you know the developer experience was really uh an obstacle for a ton of teams and I think you know we saw between there in ZK hack uh we made a ton of changes and really noticed uh some really positive upticks in in the kinds of applications people were able to make and so we continue to invest in all that as well that was DK heck Lisbon where we I think you're bound B you had a lot of bounties and you actually had a lot of submissions people talked about how it was kind of easy well easier than other tools to use risk zero I think that was one of our key takeaways when we did like the retrospective on Z hack like wow man risk zero like people are

really latching onto it because it's so easy to like write stuff yeah I mean in some ways our our goal as a company has always been to sort of democratize the the DK development to make it possible for you know ordinary Developers to be able to write ZK systems that's cool you mentioned you were dialing back some of the co-processor features I kind of want to just talk about the co-processor space like there's a lot of teams that are kind of offering new like a nuanced version of a co-processor they don't all call it that and actually there was this period of time where I was also kind of bringing risk zero into that field when I'd list them but it sounds like yeah I'm just really curious like how are you

dialing it back why are you dialing it back back yeah what was your findings doing that I think that our findings are mostly it's sort of one of focus we're trying to we're trying to build an infrastructure that's as useful as possible for as as many use cases and what we found after we sort of released this clob demo and the sort of relayer associated with that is that people actually do want to do things that look like co-processing like a sort of ZKA amm case uh we've actually done some governance examples where the voting power is computed uh of in a co-processor model but effectively the way in which we were sort of relaying the state between between Bonsai and the onchain application everybody wanted to do it differently so I think we're

really trying to focus on this base very simple you want a proof we'll get it on chain for you in a way you can reason about it and and we want to kind of let the market uh help explore and discover what the right interaction modalities are rather than trying to come up with a highly opinionated solution now so I see Bonsai more as a a way to build co-processors and libraries and and things that can um reason about on chain State and yeah we might come up with a more opinionated take in the future so I wouldn't say that we won't um almost certainly will but there's there's a lot of exploration left to do I think I mean is that not what a co-processor is anyway just offchain execution being proven onchain yeah sort of but I think I think different people like there's an

interesting question of where the state lives which state is attested to is it a up is all of the state necessary on chain who has to agree that the state is valid so I think I think in regard to a lot of those questions I think that we want to allow people to be fairly flexible in what the answers to those are we want to be able to support you know roll up kinds of use cases or things where all the state really is on chain and it's purely just doing processing um and so I think that our sort of goal is to figure out what is the minimum API that by by which someone can generate a proof and get it on chain um and I think there's really sort of two use cases where the proof is

initially requested on chain and then run and then um returns and then there's which is sort of more of the co-processor kind of use case um and then there's actually we also want to be able to support for example people requesting proofs off chain and having those land on chain as well um so you know if someone just wants to talk to the web to API and get ask for a proof to be generated right so I think we're our goal is it's also sort of a minimal viable product kind of a uh mechanism we would like to get something that is usable for real applications you know on mainnet as soon as we can and I think in terms of we've been also spending a fair amount of time uh on security uh We've you know engaged like three different

auditing firms we're hoping to be through uh a lot of that soon um we're sort of dotting our eyes crossing our te's sort of getting ready to have something that we feel we can stand behind in terms of being used for real applications with actual locked value behind them um so I think that that's we're trying to get to that place um as rapidly as possible uh and I think to some extent we're trying to keep the feature set minimal so that people who have different ways of they want to interact with it can all make use of it um and sort of see what the market actually wants was Bonsai then a little bit like a a showcase of what's possible to some extent but really the intention

is that it's going to be this decentralized network that's useful for for proving things at scale that's the long-term vision for it um okay initially you know when we in the East Denver time frame um the intention was to like get it out into the market I think much quicker but you know uh I think reality intervened and there's a lot more work we had to do on user friendliness and and all of this so Bonsai test Net Zero will be on chain this um yeah this year and people will be able to write um you know production apps if they're if they decide that the that the risk tolerance is in line with their application I guess let's move on to another kind of announcement release more recently zth or zth I don't know

how do I say it zth yeah I mean we say it zth like gu because in our mind it's basically a it's like an eth client but lots of people say it Z as well so you know I think you can say it however however you want Z did you just say that we'll allow it zth that's cool yeah so an interesting thing about how zth came about is it maybe listeners know this maybe they don't but optimism Foundation actually released an RFP for helping ZK ify the optimism stack us and 0 Labs were both uh selected for that and team yeah the um the approach that uh you know that the Foundation sort of

asked for and is pretty similar to the one that me team's exploring is basically ZK ifying the sort of existing fraud proof system we proposed a different architecture where we actually um take the sort of rust clients for optimism and then go about producing validity proofs and potentially then using that to build a fraud proof system or even just use that to build pure validity proofs so as part of this the first step was really to be able to prove eth blocks we we we actually started some of that work in advance because the idea of proving an eth block is just an obvious interesting thing to do once you have a general purpose ZK uh proving system but then with the you

know optimism RFP that sort of accelerated our work on that but but it turned out it was actually a significantly less complex project that we had anticipated and we had some amazing work um by our team on that uh but but but it was uh not a huge engineering project inside of our company um and and so there was sort of we decided it's in some ways I I personally think of it a little bit as like a a showcase for the power of general purpose uh ZK and how you can take some very complicated thing that would take a very long time uh to write a full circuit for a you know uh type one evm and we could just Rec mostly

just recompile code there were some like slight um changes to the way we had to get Merkel proofs in and things like that for efficiency but but it largely it was the vast majority of that project is existing code yeah so I think it took two Engineers three weeks or something like that to get to get zth then um slightly different scale of effort relative to other ZK EVMS I know that when we last spoke you didn't have ghost support but now I'm curious how did you get the like it sounds like a GU fork and our evm so we actually go still go still doesn't work um and that's that's largely due to like the fact that we use risk

32 uh it's a subset of the risk 5 uh or a different flavor of risk 5 risk 5 has many flavors um and go only supports some of them I think one thing that is notable is that with regard to the uh sort of next version of the circuit um one of the things that we intend to do is support uh a wider sort of set of skews uh if you will of risk 5 processors including um a skew that will uh run go which will I think be an interesting and unlocking feature although I think there's also still some amount of work that's going to be required from a language support perspective to make that as easy of a process as it is currently um with the

existing rust uh versions of things but yep it goes particularly hard to support you've seen a couple other projects you sort of tried to do general purpose with like ZK llvm and so forth and it turns out like go doesn't really use LM so that's actually not even a viable path there but I think there has recently been uh some progress towards getting GE to work inside um wam which is actually also a potentially viable route that that one could run on top of Riso yeah my bad I just I kind of missed W I didn't think about it but it's like this is going to sound so naive it's a full operational client being used what do we know the percentage like it's it took over I guess from like what

parody ethereum used to be long long ago and then open ethereum I think they still consider it like you shouldn't be running I think it's still considered like in beta but it doesn't stop people from brave brave people from running nodes anyway huh so then you had an already rest like already written in Rust client you could Fork that add this validity but I guess like if someone wanted to run zth like can they already run it and get the ZK property yes okay but it's just validity it's not privacy uh I mean you could get privacy out of it if you wanted to build a if you wanted to create a private evm proof off chain you could totally do that yeah yeah no no no

of course evm isn't really doesn't have specific considerations for privacy since it's meant to be all run in the public so I think there's like but but in terms of of the actual it it is does have the full ZK support so I could prove to you for example actually there are privacy use cases particularly for Block Builders like I could for example prove to you that I have I can build a block that has you know such and such number of transactions with you know this much M or whatever the whatever the thing you're interested in um is now now I don't think that that's likely to be economically reasonable in the near term just given the uh sort of the latency requirements for Block building as an

industry but um it is an interesting conceptual idea some teams out there are using actually ethereum blockchains for various um internal sort of corporate Supply Chain management but you could imagine using something like zeth to prove something about the state of a private ethereum chain uh elsewhere so if somebody did want to invest in you know building a some form of private uh infrastructure on top of e and and ZK a test to State about it you can absolutely use the this kind of uh zth architecture and crates to do that how long does it take to prove like one block yeah well it depends on how many gpus you use okay yeah um but yeah I think 15 minutes is the fastest we've

seen um expect to expect to make that quite a bit faster here in the future I think the other thing that's that's interesting about uh the feasibility of using uh zth in the real world is also that right now the cost to produce a block is about $10 uh of compute I think in terms of speed wall clock time we do want to bring that down but I think that a lot of the thing these systems the economic viability of doing this for example on let's say all of ethereum all the time is really determined by the sort of cost of doing this sort of ZK uh validity proof um right so I think that that that we're also very much focusing on bringing that cost down as well as the sort of

performance in the wall clock h both of these products Bonsai and zth zth I'm just sort of curious how these interface with the risk five base like I don't like to me they sound like separate they're really not so this is like you take if you look at the zth code base it's really just a fork of um of rvm and re I think with uh a couple other packages and you really just basically take the evm block pass it in and say produce approv that this is correct and and also what's the new state after this so it actually computes all the state transitions tells you what the new state is and provides the ZK proof that it was done correctly

on risk five that's right ah see this is the part I'm mix I'm missing like the rust compiler takes the the zth code compiles it to risk 5 and then we have this sort of host guest abstraction the host loads this guest binary and risk 5 passes it the state and says hey run this program which is the evm on this state which is the state of the last block and all of the transactions that people want to you know put into the next block okay go run this and then that runs on the risk zero uh Z KVM in Risk 5 simulated and produces this proof that it says okay here's the new state of your next block okay but like the amount of glue you have to do there is like 10 lines of code and and what's also in terms of the way that Bonsai

relates Bonsai is simply a service for running things in Risk zero it's simply a service for running these emulated risk 5 machines but much faster via parallelism okay basically yeah and then I think Bonsai also has some additional features in terms of um well it has the sort of recursion element to roll things up and then it has this Stark to snark mechanism so you can actually verify the proofs on chain because normally our proofs are Starks they're quite large you could verify them on chain but it's very expensive so we have this other separate mechanism and these are that we'll be opening up as well as soon as we're done with uh security audits we didn't want people to get too too

carried away there with the ability to prove arbitrarily large things on chain so actually that's when you talk about what happened the last year one of the important things that happened in this last year is this sort of proof wrapping mechanism that allows it to be economically feasible to verify our proofs on ethereum and I think that that was also a pretty large engineering task uh that was a big enabler going forward is that where you were using the fry based with this with the Groth 16 wrapper is that what you're talking about yes okay so one of your colleagues Paul gave a talk at CK Summit 10 We'll add the link to that in the show notes that was actually a topic I thought we

could chat a little bit about this is a new creation since we spoke last I guess that's right so we basically if you look at it one of the wonderful things about uh Starks and Fry is that they they're very efficient especially for VM like systems you could produce them quite quickly they're GPU accelerat there's a lot of good things about them um however the proof sizes are significantly larger at verifying a stark or a fry based system at all uh on ethereum is very expensive uh and in fact almost not feasible uh you can in fact do it like in you for example starkware uh managed to make it work um

but the engineering required was pretty extensive and also they there was a lot of decisions about the how many bits of security and sort of things like that that were actually uh with their proof system that were driven by this like how hard it is to engineer this verifier for um PR base systems on chain so what we ended up doing is taking another proof system that we knew to be you know quite efficient on chain which is grth 16 um and we basically built a verifier for our Stark proofs that ran inside of grth 16 and so rather than directly verify the Stark proof onchain instead we

verify it in another proof system and then verify that proof on chain so it adds one extra layer of wrapping but it basically uh massively reduces both the size of the proof and the cost of verifying onchain on the other hand like fries and Starks were completely untrusted in terms of setup and now we've introduced this potential sort of trusted setup component with grth 16 I will say that it's we didn't actually it's not like we wrote it to use grth 16 Jeremy can talk more about this we actually take our verifier circuit and our compiler produces circom as an output which we then use the circom itself to produce the grass 16 circuit um so we actually tried F flan and would

prefer to sort of move in that direction but uh there were some uh some engineering challenges there we expect to see the sort of onchain verification mechanism uh support many different kinds of snarks in the future it's just like gr 16 was the most mature and so it kind of worked faster and at this point we're just trying to get our proofs on chain as quickly as we can so people can start learning how to use these things in an interesting onchain context like we're starting to see I know that other teams are using the same technique are people rewriting the same Stark verification circuit or is there like some kind of General effort to get things together as far as I know everyone's doing their own version of things in our particular case we were

lucky in some sense because we have a lot of internal compiler technology which we also hope to um open source at some point but but the one of the key things is that because we use recursion we had to describe our verifier in a somewhat circuit friendly way for the use in recursion and we had a bunch of compiler work that actually translated our verifier into um something that we could verify uh inside of one of these systems already and so we were able to retarget that to circom without a huge amount of well I mean was a fair amount of effort but not an insane amount of effort so so so in that

sense from our perspective that was a technically easier route and I think that different people are taking taking sort of different um sort of mechanisms for for this um you know one thing that we're also interested in doing is we're starting to look into running other verifiers inside of the risk 5 VM so that we can actually uh be a place to compose a lot of different kinds of other proof systems like for example one of the things that uh just in terms of a funny application there some people interested in using um Ezekiel which is like a basically Zer knowledge proof system for ml um but one of the problems is if I want to prove for example that some JPEG that has a certain hash is a picture of a cat well the process of

converting the raw pixel values into the is aat is pretty well handled by the sort of existing ml um you zkl systems but the process of turning the jpeg into pixels is actually rather difficult to encode in a circuit but it's very easy to write to to just import some Rust library and then do it and so sort of this this idea that okay well we can we could we could use the existing zkl thing to prove the second half then we could verify that as well as do the jpig decoding in a program in our system and then we can either do the Stark to snark on it and then get a very small single proof that's verifiable in Shain that this jpeg is in fact a cap right you know so lots of fun applications you

know people use tensorflow or pytorch to interact with ML systems and you have to build a lot of the sort of ancillary um logic around your ml pipeline in people prefer to do that in higher level languages and utilize libraries but then obviously when you go to actually run the nuts and bolts of the ml algorithm you obviously you're using a very specialized execution environment although we will have some really fun um uh ml stuff coming out on top of on top of RIS zero that's more like decision trees and things people use to build risk models which I think are very fascinating in the ZK uh context so I guess this like R plus Ezekiel thing is kind of like a CPU plus another chip specifically for RL right yes exactly exactly and we we actually anticipate

you know with this General recursion based mechanism that we're using we actually are will likely start to see not only different skews of um processors uh you know since we're going to probably somewhat generalize uh like our risk five support but we'll also see other kinds of interesting specialized circuits or accelerators uh you know that that that will all be sort of able to be part of a single ecosystem via the use of recursion um so I think that that's actually a a super exciting Direction over the next you know period of time you sort of you know you're talking about having the fry based recursion wrapped in the gr 16 wrapper

do you actually Envision sticking with that you sort of said like you do it because of circom because that's what circom produces or that's where it's what it's built on but like is that the final version that you go live with it's more like like cir supports a number of proof back ends so you can take a circum circuit and you can have that be verified in gr 16 or flan or I don't even know all the the different um modalities that it supports but effectively a ton of work was done on the Groth 16 back end uh by other people to make it support these giant circuits because it's a quite large circuit so ffan just broke so I think our intention Our intention is very much to get to a trustless uh verification it's just um it's a matter of time and backlog do you

I think this is like a I'm curious Jeremy can go ahead but then I'm also curious to get your take on how important this is to the ecosystem I've seen a lot of people uh talking about uh trusted setup wos recently but I don't really know the context yeah I was just going to add one small thing which was that you know our goal the reason for doing this is to make something that is ethereum friendly and I think aside from a new pre-compile in ethereum you know fry based systems will never be friendly to verify directly so there'll always be a wrapping between a fry based system and something that's verified on ethereum in particular for other chains not necessarily wasm based Chains It's actually very straightforward to verify FR based things for example you which exact proof system and whether it's

graph 16 indefinitely I think that's probably unlikely uh it'll probably be something different but yeah and on the trusted setup point that you were just asking I mean I think it's always been the thing that teams have to do but don't really want to do but they have to do it and then they you know there's been crazy develop Kobe my sometimes co-host Nico's colleague has developed like all these really cool techniques to do trusted setups better but even when I ask him like well you know is this going to end up in like textbooks and he's like no we want to make this obsolete actually like I'm creating it but hopefully we don't have to use it too long so my take is like it depends who

your adversary is yeah if you're fine with this one out of many participants assumption then you're okay if you start like being extremely paranoid and thinking like oh I can't even trust a single person if you move to something like a Pon commitment you still need to trust that the curve you're using is not back doored if you're using fry you need to assume that your hash function is Collision resistant so if you're going as for saying I don't trust one of these participants like trust no one why do you then trust the curve why do you then trust like the hash function like this is maybe I'm being a bit Paranoid by this but like if you're really trying to say in the ground scheme of things like there is a ground truth and I don't need to trust anyone about it none of these

schemes give you that none of cryptograph is going to give you that just cash underneath your mattress at that point really yeah could you use an existing trusted setup SRS that's already been created like maybe the ethereum one like or do you have to manually run a trusted setup yourself so uh some of the systems have a have a a multi- circuit trusted setup so a trusted setup that could be used for different circuits uh Gro 6t at least the way we're using it right now uh does have some circuit specific components uh and so while we can use for example the the powers of TOA part of it we don't need to run our own trust and setup because that's already been done and there's like you know ones that are well uh established the the there are some

parts that are unfortunately circuit specific um so so so but luckily I think we'll eventually get to a proof system where that is not the case so okay do you think you'll launch with this though yes like main net test Net Zero will be the gr 16 version and um if people don't want to use it because of that I guess that will be interesting Market data um but but yeah the intention is to get to get um somewhere else before then I see I we might get lucky I mean I think at this point um you know we're sort of the it is still possible that the difference between uh what we have and what we need for some alternative proof system system is small because there's still a lot of Investigation work to be done but my the

sort of plan of record if you will is to go forward with gr 16 for now since we're on the topic of proof systems this is no longer broad recursion but I want to bring up like the new claims about VMS and look up Singularity right these lasso and papers um so this new approach or this approach that has been theorizing now is supposedly practical which is I just have one big lookup table and that's going to be my process is this something that you've looked at is this something that is I don't know the next Evolution for VMS so we we've looked at it quite a bit um at you know I read the paper and we've done a fair amount of analysis and the truth is is it's not exactly clear what the

performance Delta will be at a practical level because some of the components are still unimplemented and um I have tried on a number of occasions to do good back of the envelope numbers but you know the reality is is that um performance in the real world is actually quite complicated and even getting the back of the envelopes I just uh never got to the bottom of that um so the short version is that our interest as a company is we are fundamentally most concerned with bringing ZK to people in a very usable form um and we really strongly believe that the sort of using an existing Isa is a good way to do that and if it turns out that uh you know when these things start to get built that it looks like

it's a better way to go than our current proof system um we will very likely adopt them and we are going to continue to uh experiment with those things internally and be in a place where we're prepared to um make those changes if need be but as as it sits right now um you know we have a very carefully engineered very functional works today sort of system um and so if you ask me what will it look like 3 years out um it's very possible that uh the proof system will change dramatically over that time frame um I mean there's still new mathematics to be developed and new ideas to be had um so I I do I am definitely uh interested and uh at least

somewhat bullish on these new techniques but I think it there's still a little bit of a time and real Benchmark data will tell you had sort of mentioned wum as interesting how would that interface with what you have so there are a couple ways so we've actually uh the the most naive way and we've actually done this is just to take a wasm interpreter like the wasmi crate and then you can just take a wasm binary it's pretty convoluted if you're taking a wasm binary running it through an interpreter which is compiled through risk 5 which is then a VM which is then creating a proof of the it's basically creating a proof of the interpretation of a wasm binary it's like you know the inception mean of like we must go deeper must go deeper exactly so you got to run an

interpreter just find something like run gu on top of wum on top of rero and then you will have completed the thing and your proof will never complete but the the abstraction Loop will have completed um anyway Jeremy can talk about like some other approaches to running awesome though yeah yeah so we're actually we're actually um one of our sort of with the new circuit work we are sort of separating out a lot of the sort of core like oh here's a 32-bit multiplier unit and uh it was sort of sort of diving up the circuit so it's less monolithic uh with the intent that one could put for example a different sort of instruction decoder front end onto what is roughly similar reusable components for the um

sort of circuit and thus get different kinds of VMS uh you know I think initially we're largely focusing on going a little bit wider in terms of the types of risk uh five variations we support uh that said though I do think that that same mechanism will probably eventually get to things like wasm support there's also some sort of trans compilation techniques we've looked at on some of that as well um the one thing that's slightly trickier on wasm is it does have a sort of a higher bar in terms of the minimum sort of operations that are required like for example floating Point support or things like that um whereas uh right now all of that in Risk 5 is done through software emulation so that's a very nice feature

for us so we've already mentioned a couple use cases uh and sort of categories of use cases so like ZK ml um the ZK amm experiment but yeah I just was wondering if there's any other experiments or use cases that you're already seeing emerging and also I think Brian you had mentioned that like something in the architecture was sort of use case dependent so maybe we can bring that back I mean I don't know how much um the architecture is use case dependent I think I was talking about um moving sort of moving away from this relayer contract we had built in the sort of ZK co-processor model and basically letting teams um designed that to be what they want so we we've seen

people experiment with sort of onchain with governance co-processors and they had very specific um mechanisms they wanted uh for their particular use case and then if you look at the sort of zkm with it's like pool locking and all this like it's quite a sophisticated mechanism there and um it's like not really what we had I mean if you think about this you start to realize yes obviously you need some way to lock a pool if you're going to be using a synchronous um transactions over over a you know formerly single threaded completely uh lock in lock step kind of blockchain so yeah the goal with Bonsai and what we're doing now is to is to minimize what we're offering to let

people kind of design these mechanisms on their own because they do seem to vary based on based on the kinds of what actual computation going on right in the unop case if you looked at the debate that happened sort of after that on the co-processor uh telegram people are like asking you know specifically what's the sort of lockup interval for these when you lock a pool and then you have to wonder how that interacts with me and all kinds of other uh considerations whereas in a voting example you might not care about that at all you might care more about um maintaining privacy or knowing the totals until some later date or something like this and and of course there's also uses for fraud proofs or rollups which are also sort of

applications I think there's a lot of interest in adding ZK to uh existing fraud proof systems or moving toward validity proofs for different uh optimistic chains which we're also looking into in terms of use cases and we actually also have a couple of additional showcase sort of use cases that we're working on internally um sort of similar to zth that we will intend to uh put out over the next couple of weeks I think zth was really made people aware of the power of sort of what you can do with the general purpose ZK system and I think one of our goals in terms of use case is to try to continue to build sort of not necessarily products but but in sort of like starting points or or one

might say reference applications for for people uh that make use of the different power of of ZK so right we were seeing a lot of people try to build these kind of hybrid zk/ fraud prooof systems and Engineering that in a way where that that such that the sort of fraud proving engine is actually capable of Performing the sort of fraud proofs that you wanted to be able to um you know there's a lot of thought that needs to sort of go into that to get it right um so we'll we'll be like building some reference imputations and helping teams get the these kind of architectures correct the other thing I guess I did mention earlier is that the the poly based team put out some really cool benchmark that we've been um working on you can see them at ZK bench. deev and a sort of

interesting aspect there if you look at uh at the RIS zero benchmarks you'll realize that pretty much every Benchmark takes uh 6 seconds plus a tiny tiny bit of additional time uh in almost every case and it's basically the continuations mechanism and the way it currently is designed has to do this sort of build up like a Merkel tree of various uh memory page tables and stuff so verifying all this adds a certain amount of overhead so we basically can't do small proofs faster than 6 seconds right now it's like the smallest proof takes 6 seconds no matter what so it's kind of funny you can get anything you want proven in six seconds so we've sort of biased the current architecture towards there's lots of stuff we could

do to improve that kind of runtime but right now we're very focused on you know how do you prove things the size of zth which are like 4,000 1 million cycle blocks um so it's just like a completely different scale but there is some overhead uh that you incur when you start to build a system with the sort of continuations feature in mind that you know optimizing that out for smaller um spot proofs and stuff will will take quite a while I think and I suspect you know with the uh the sort of next revision of the circuit will have sort of this sort of optional features like well this is the with continuations or without continuations version so we can remove a lot of that overhead but I think our Focus has very much been on the very large applications um where I

think it's just almost impossible to do with any other system and for those kinds of use cases cool is there any other use cases that are sort of on your mind maybe more like tangible end user use cases that you've seen at hackathons yes but I don't know that I can necessarily talk about some of them yet um but I will say that uh there are some really interesting maybe more consumer use cases where an interesting kind of dynamic that we're seeing is that so when we finally got Bonsai done um and people are able to use it the sort of effective throughput of the system did go up by you know for an end user by about like 20x or so so that in of itself sort of brought a whole new set of uh potential computations into a into

sort of a feasibility realm where you know 2 minutes is too slow but about 20 seconds is okay or 10 seconds is okay so I do think every time you sort of see a new leap improv system kind of speed and um capability new sets of of use cases do start to to open up and hopefully we'll be able to talk more about some of those in the future or we see some of them built at CK hack Istanbul which is coming up yeah hopefully yeah exactly I guess now we can talk a little bit about what's next and what's coming down the line I do have one question though before we jump into that which is is risk zero going to be an L1 or is risk zero going to be an L2 is this

decided I mean I mean well LTS don't exist anymore last or co-processor I guess or a coprocessor or utility chain sometimes I think of it as more of like a utility chain maybe it'll have state of its own which makes it start to look like an L1 but the primary purpose of it is to augment other ecosystems and help help make them more capable which is sort of like a co-processor narrative then then in that context it's a co-processor but then if you did build an application just on top of it then I guess it would be an L1 so um I I don't think it's going to be an L2 that said we expect it ideally to be useful for all these l2s and um and on ethereum itself so the answer essentially is all of the above

right we we have a very modular way of looking at these things I think uh in the sense that what we would like to do is find a way to make a it possible for people to generate proofs in a decentralized manner and for the economics of that to make sense for people and that is the entire goal and I think that uh there are lots of ways that that ends up happening in the existing systems but I think that we're not really married to a particular sort of existing uh sort of designed for that sort of decentralization process some of the features we've uh we'd like to bring to Market that you know hope we can talk

about in the next year sometime um you know might rely on some amount of State being stored somewhere uh which you know could be in other da layers it could be directly on a chain that we control and we'll see how all that evolves so there's still a lot of exploration to to figure out what the right final form is but for now it's going to be more the the thing we're going to launch is basically going to be this sort of stateless co-processor type model cool all right so what's next what's coming up what can people look out for ZK VM 1.0 not too long after that uh a new version of some of the circuits um most importantly though I think is going to be be able to get uh proofs and proving using risk zero on to main net is ZK VM

different from zth then it's not a ZK evm so ZK VM is the risk five is the risk five ZK proving engine got it so if you run W on top of the ZK VM you now have a ZK VM got it okay so so the one the work to sort of get to 10 has been basically exploring a bunch of different AP options getting the sort of continuations figured out figuring out what the actual abstractions and everything we want to exist there are and then actually orienting the system so it's maintainable in the long term so it's auditable so people can understand the audits all of this is basically been the the bulk of the sort of fit and finish work that's required in our minds to actually call something 1 whereby

once that's out we intend to support that sort of API for a long time going forward so people should be able to build yeah their systems with confidence on top of this that's main net well so that's that's basically the predecessor to main so by building the ckvm sort of 1 that gives the sort of foundational stability that you can then use to have that were then comfortable with sort of launching Bonsai onto Main net on top of that along with the release of the sort of Stark to snark uh system and the recursive system to open source people will be able to if they want to run with zero proofs at home on their own machines whatever you know basically post those um completely

permissionless to chains so there's the one maturity is basically getting to the point where everybody can use the system and can put it on chain Mission if they want to simultaneously we'll be launching this Bonsai test at zero which will be an actual supported um still kind of Tes is read like done this but um based on uh really confident sort of foundation so if people want to deploy real apps on it we expect um we expect people to be able to do that but we're not necessarily promising that we figured out the pricing model or the right mechanisms or anything it's basically the simplest thing we can get so we can so you can get feedback from people uh and figure out what the right

long-term solution is because when you start thinking about how do you bring a proving system that's that's really this kind of co-processor utility chain or proving Market or any of these things uh you start to it's really easy to just spend way too much time thinking about what the right thing to do is without In Absentia of of real data so do you expect other Bonsai to emerge not from your team living on the VM probably at some point people will certainly be able to do that in the future ideally people just participate in sort of bonsai itself and there'll be ways for other people to do that coming up in the future so Bonsai will get more and more open in terms of the sets of people that can participate in it in a meaningful way that said you know I think anytime there's anything of value it'll probably

be forked you know maybe you don't want this comparison but essentially like Bonsai it's sort of also what starnet is doing with their like shared prover starting with like their own sort of proving infrastructure and like slowly opening it up so I don't know if it's a useful model for people to think about or if you don't want to be boxed into that yeah I don't think we really want to be boxed into that because I think we're going to move from where we're at to other people being able to contribute uh muchly they but that is it is it is a reasonable um yes people have done similar things before and yes dark knut is one of them all right well I want to say a big thank you Brian and Jeremy for coming back on the show and sharing with us this update and also like letting me

and ni ask all the questions we always wanted to know and we're too afraid to ask so yeah I really appreciate it anytime and looking forward to the secrets clientside use cases that you can't mention yet thanks Nico for co-hosting this one too thanks for having me on an I want to say a big thank you to the podcast team Rachel Henrik and Tanya and to our listeners thanks for [Music] listening