Where RiscZero Fits in The Modular Thesis

Transcript

welcome to the rollup today's episode is with Jeremy from risk zero project that has built a general purpose ZK VM based on the risk five algorithm now before we get into the podcast it's important that you have at least a basic understanding of ZK and ZK proofs ZK stands for zero knowledge and a zero knowledge proof is this innovation in mathematics that allows someone to prove that something is true without giving up any of the details about why it's true you can think of this like I can go to a bar I can prove that I'm of age to drink at that bar but I don't need to give away my actual birthday or any of the other information on my driver's license or ID this is basically a ZK proof and it has

far-reaching applications to lots of instances in blockchain as well as technology in general and risk zero has built this general purpose zero knowledge virtual machine to enable ZK proofs on several applications spanning ethereum as well as other blockchains that have traditionally not been able to get access to some of this software like Bitcoin we're going to be talking all about risk 5 and risk Zero's general purpose ZK VM in today's podcast but before we do here's a word from our sponsors that help make all of this possible enjoy navigating multiple blockchains can be complex and conversome let's say you want to deposit into a lending Market on polygon because

they have the best rates but you only have funds on optimism so you bridge your funds to polygon only to realize that you need madic to pay for gas maybe use a centralized exchange or you ask your friend to pay for the gas but only then can you finish your transaction in a chain abstracted future powered by connects this is not the situation you can connect your wallet to any dap from any chain with all the complexities of swapping bridging and depositing all completely abstracted behind the scenes head over to connect. network that connect. Network to learn more about connect chain abstraction toolkit welcome back to the rollup today

we are talking about ZK with our friend Jeremy here from risk zero really we think ZK will eat modularity in a way and that's been an article from these guys from equilibrium and from julot and we are are excited about ZK making a big entrance into the modular stack um BR zero is working on ZK VM so we're going to dive into that as well as some of the higher level concepts of ZK um and just talk about the Imp implementation and kind of get a catch up as to where we are on the development of ZK and the Practical use cases in today's world uh of course here with Rob um good morning Rob um how you doing man GM like it says on your

shirt yeah yeah it's another another beautiful day in Florida out here and uh excited to catch up on ZK because um a little while ago we had done like a very general highlevel overview of of what ZK is um Z I mean the space in general moves so fast that um it's come a long way um and and now we have like like you said modularity ZK we've kind of like here and there spotted and and kind of like spotted progressions in ZK technology um and so uh risk zero is coming out very very soon with their like 1.0 ZK VM which we'll get into in a minute I'm very excited for how that is going to push forward ZK uh in general

so Jeremy welcome uh it's a pleasure to have you on the rollup and uh very excited to learn more about ZK and uh especially the state of ZK as of recent uh from you and your your stance at risk zero awesome great thanks for thanks for having me uh yeah you know um you know at risk zero we've been working on on ZK quite a while so excited to you know have a conversation about uh sort of where the state of things is and where it's going so beautiful awesome cool so I think like we know ZK as like there's a couple things like don't trust verify and also like you can know something without having to know the contents of what this thing is or you can know that that

something is is legitimate without having to know what it is there's a lot of terms thrown around like verifiable computation why don't we kind of start here I I know this something that that you guys champion at risk zero what does verifiable computation mean to you in the terms of of crypto and in in the lens of ZK yeah absolutely so I mean I think one of the most powerful impacts of ZK has to do with the fact that it allows you to show that someone ran a computation correctly uh in a time that is much faster than the time it takes them to do the computation so I can run a very complex computation and then I can show I did it right uh and what's interesting is no matter how much Computing I do the amount of time

it takes to verify it is always the same and this is really important for any sort of decentralization because it allows different people to work on different parts of the computation and then cross verify in a way that scales much differently right you know uh if you look at the sort of Prez sort of blockchain approaches uh the only way to tell whether someone did something right is to redo it yourself and as a result there's a massive amount of redundant Computing that gets done uh you know to verify the the transactions on a given chain uh with ZK um you know you can have some people working on some set of transactions some other people working on some other set of transactions and

then you can just verify those right so I think it had the long-term impact on scalability can't be overstated in my opinion um you know and the other thing that is interesting is this sort of privacy property that you pointed out about ZK which is that uh when I am doing doing that com computation I only have to reveal the parts of it that I want to reveal um you know I think that has a lot of use cases as well but I think just the you know the verifiable part of it is the one of the more near-term impacts right especially for things like l2s Etc when we think about risk zero um like and and like you said ZK proofs in general have kind of these two properties they have the the Privacy property where we don't have to reveal

all of the necessary components about like the state transitions or the transactions we can just verify that that they were computed correctly that's kind of the Privacy element and and then we have the succinctness property um which is that that verification is much much simpler to do than like actually doing the computation yourself um at risk zero do you guys focus on one of these properties or or the other a little bit more or is it really kind of like both uh that you guys are are trying like what what is the general mission of risk zero and how does it kind of pertain to each of these properties I mean I would say that the general mission of risk zero is to make the full power of ZK accessible to

everyone and not only in terms of the you know being able to run ZK proofs but being able to develop uh ZK proofs being able to you know encode the whatever rules you want you know um run whatever program you would like inside of a ZK system um and I think that you know most of these these properties do become critically important and so I think to some extent it's hard to build a full system without all of the properties right uh succinctness is absolutely critical for verification on blockchain um you know the verifiable nature of the Computing is critical for almost all the use cases there are some use cases that don't require the Privacy aspect but you know that I think that there are enough that do that it's worth really trying to

make that part of a a product offering I mean I think that what you know our initial thesis uh you know the sort of reason we started the company was this idea that in order to make a ZK proof I I mean once I became aware of ZK technology and I've been following it for about six years it sort of blew my mind the fact that this is even possible that it's possible to verify the correctness of a computation faster than it is produce it um but you know I tried to convince a lot of my friends that ZK was the future and when they asked me how do you write a you know ZK program I was like well you know you just Implement a some polinomial constraints over some finite field elements and they're like that's not you know

programming right this is a this is a very very complex difficult thing to do development in historically right when people were writing their own custom circuits and you see these project take you know months or years to get something done even simple things right and so our fundamental thesis was if you can make it so that people can write ordinary programs inside of a ZK system uh that that would sort of revolutionize the use of ZK and so that sort of was our our basic idea and you know we're you know I think that there initially there was concerns that people had that oh the performance of these General systems would be too slow or uh you know that it wasn't possible to do this uh

and I think now that though you know now I think uh the whole industry with regard to ZK much of it is moving toward this sort of General per Pur uh you know uh sort of Direction um so I think that our hypothesis has been pretty well validated at this point so we're very excited to get the stuff into production as well so yeah definitely there was a little bit of uh non-english in there for us who have little ZK understanding but we're just going to bear with us on this pod as we've done quite a bit of research but there there's still a little bit of uh what I call ZK magic language which is a a language that is exclusive for just a small subset the world's population so I um applaud you for being a part of that

population sir yeah well I think our goal is to make it so that to use ZK one doesn't need to know any of these things right um and I apologize if uh having built these systems I uh unfortunately uh do sometimes speak of bidding code um but yeah I think that the you know if I mean I think a lot I really believe that ZK is going to have a wide ranging impact both you know obviously in the the entire blockchain industry but I think Beyond on that as well um but I think that the our goal as a company is to make the sort of technical complexity of ZK vanish right um you know you think about um you know public key cryptography and things like that you know there was a time on the internet when um Communications between any two

parties could be seen by everyone along the way right and no one wanted to you know put their credit cards into a website because uh it just was being transmitted in clear and then you know there was all this work to build the pki infrastructure and uh you know the encryption infrastructure that we sort of take for granted today and now the only difference between an unencrypted and encrypted one is you know htttp versus https right it's basically invisible infrastructure and uh you know our goal is to make writing ZK so easy that it's just like oh do I want to run the program or in the ordinary no regular Computing or do I want to do it verifiably and I'm just going to flip that switch and then you know it takes me a little bit more effort to do the

Computing um but but but it's as easy as I writing a normal program yeah part of what's being an entrepreneur is almost having a little bit of a crystal ball and trying to see the future in some capacity right you can't predict the whole future but you can place your Bets with your energy time and capital to kind of like see where the future kind of goes and we had a podcast with uh Sam from or jeem from Sovereign Labs um and he talked about their entire design being around taking a bet on not just being there being just one on Z KVM or just effectively there being a lot of development in this space and it kind of seems like you also had a similar hypothesis a couple years back as you

were kind of talking us through that so let's kind of talk about that evolution of these VMS and kind of how we got to where we are today would kind of I think our audience would greatly appreciate kind of a chronological understanding of like how risk zero came about today and kind of like this evolution of ZK to now uh you know being a couple weeks out from risk zero ZK VM 1.0 you know like I said I had been following the the sort of research for um many years before this um and but I think that the we really started with this idea of making ZK more accessible um I think that we've seen in terms of the ZK development process and how people have done ZK going through a couple of different

iterations the first sort of generation of ZK was uh this sort of custom circuit idea right where you write a bunch of mathematical constraints uh that that's supposed to you know represent your program um and you know we we actually saw real applications using that sort of approach right like sort of zcash you know and some of the very early ZK uh use cases did in fact make you know things that worked using that approach um and then you sort of see this sort of second generation um you know which you know is sort of in the you know Alo or some of the you know early stor Cyro stuff where there's a idea of well we need to make this more accessible to programmers so we're going to build sort of a custom

programming language uh so that it looks more like regular programming but it's still very ZK specific and I think that's you know brings it makes it much more accessible but it's still uh you know you have to learn a custom language and more importantly you can't make use of any existing code right you want to like maybe make a ZK thing that checks whether chess position is correct well you have to rewrite the rules of Chess yourself in the new language because there's no chess library because the language just came out right um I think that people often underestimate the complexity of developer tooling and like the the power of a big ecosystem right so our question was can we somehow make this you know VM you know match the structure of an existing VM that people

already use so that we can take advantage of all this existing code and I think there's actually sort of two approaches right the the sort of ZK evm approach where you try to build a VM that emulates the you know ethereum virtual machine um so that you can use the solidity code and you know that's a very you know sort of um you know lots of blockchain things that makes a lot of sense right um but the evm is a very complicated machine right um and what we decided to do was take a slightly different approach at the time um which was quite novel then and the idea was well what if we found like the most simple possible virtual machine that actually has

software that already exists for it and we settled on the risk five which is a which is a type of a a processor chip less common than you know Intel or you know um arm uh but but but something that does have enough traction that you know the rust you know compiler already supported that that chip and it's a very very low complexity and so our thought was we build a very low complexity very high per performance uh you know VM that can run arbitrary code um and then we you know use that um to to allow people to to run normal code inside of ZK and actually what's interesting what we

found is that once we did that you know we were able to actually make a ZK evm by just taking the normal uh you know like like w um and the sort of the the evm components of existing rust ecosystem and just run those uh inside of our Z KVM and and actually the performance uh you know while not you know as as uh quite as fast as you know the something that's custom built for that evm use case um you know we were able to do in weeks what other teams had been spending a year on right so I think that that uh sort of shows to the power of the sort of general purpose nature and the ReUse of existing code beautiful

yeah risk five chip here plays a pretty important role I'm curious like because we haven't talked about this so much when we talk about ZK proofs what is the relationship between the hardware component of of one of these chips with kind of like the software component of what you're doing in that Computing space yeah so we don't actually do anything with any specialized Hardware but the the idea is that it's designed to look to the programmer or to the really to the compiler right sort of like you're running on this particular ship right so um so so we really are running just a a a virtual machine uh but that virtual machine looks like a

well-known pre-existing standard well-defined piece of hardware and by by doing that by making our VM match an existing specification uh we get the we get the power of being able to reuse all of the compiler work all of the um you know this this that's been done uh that that existed before we started and so in some sense that's you know part of the the the approach right and I think that it's similar in that in regards to the evm approach which we use as the the well- defined nature of the evm although the evm is changing much more rapidly right um the other nice thing about risk five as a Target uh is that uh you know it's a very well specified and the

specifications are very long lasting and they change very slowly uh because in the world of Hardware you know doing another rev of Hardware is very expensive and so you know you want these these standards to be very stable um so that that provides us with additional sort of just makes things easier to do cool interesting um bear with us as we're just we we are just coming around to these ideas and just and just uh talking to you about our Curiosities and we were kind of talking about this idea uh prior to the recording uh with regards to kind of like the commoditization of rollups effectively by or the commoditization of ZK VMS and then it's the knock on effects of the complement

of of zkm which is effectively rollups and you're talking about how you can build generalized ZK VMS rather than just custom circuits which was kind of like the previous iteration of ZK VMS and you know you know we've kind of learned that this becomes possible by running a state transition function of a rollup in Rust through risk zero now there are a bit of like trade-offs here if I'm understanding correctly between a generalizable zkm versus running like a full rust or a full like a full circuit for for your ZK maybe we can talk about this like this commoditization of zkv M's of the complement being rollups and kind of like how how you're thinking about the trade-offs between uh a ZK VM

versus like a a more optimized full circuit uh machine yeah well I think I think this is really interesting because what it does is it makes it I mean I think historically if you look at some of the early you know um Pioneers that were working on specific use cases involving ZK a huge amount of the value of those companies was in these sort of custom circuits uh right you know um like so there's like uh you know with with like zcat for example like that there's a very complicated a lot of huge amone of effort went into building the circuit even though what it was doing was quite simple mostly just sort of a Merkel tree lookup and nowadays one can write very similar things using these

sort of you know generalized general purpose ckvm much much more quickly like day you know right to to do this type of thing and uh like you know in terms of people building rollups or l2s it just opens up the possibilities so much right um you know you don't have to hire a huge number of devs that are going to be focused on all these ZK details you can just focus on sort of your application I think that not only will we see this lead to a lot more sort of ZK l2s or other you know things along those lines but I also think there's this sort of emerging uh ZK co-processing mechanism right uh wherein you can move compute that's app

specific compute offchain uh so if you want to do you know sort of a d you know a defi use case right where you you're doing a big complicated order processing thing rather than pay for the gas for doing all of that you can do all that compute in a general purpose ZK VM and then just verify it on chain um and so I think as we sort of look forward to the future where it becomes uh very straightforward and inexpensive to verify these ZK proofs on chains and in very inexpensive to get them generated right as we bring down improving costs you're going to see a lot of these things where you move significant P portions of the computation off chain for scalability um and not only you know will of course this lead to more sort of

l2s but I think there'll also be this other kind of like um you know L 1.5 I don't know what you would want to call it a sort of case where you have an application that maybe runs on the L1 but that does much of its computation offchain but in a very app specific way rather than having to you know sort of move your liquidity into some L2 keep all your liquidity liquidity on the L1 you just do your compute off of the uh L1 right so I think that that both those things are going to continue to become easier and people who've spent a lot of time and energy building their ZK systems in the prior generation to to do these types of things uh a lot of that value is going

to you know be reduced as it becomes easier and easier to do these things more quickly makes total sense um and then as a result of doing things of building ZK in the current ERA with with ZK VMS there's a bit more like flexibility and functionality um in terms of being able to plug into to like other sdks and other kind of ecosystems of rollups and kind of offer like a a proving layer uh or a a last or a a fallback kind of mechanism and again referencing to Sovereign because we talked quite a bit about risk zero in that pod you know we spoke about how uh rollups within sovereign's ecosystem effectively uh are able to to Outsource proof verification

to a a kind of host of ZK VMS and there's some sort of like auction process in in which these proofs are given to a winner and then they are are verified and kind have returned back to the rollups them themselves let's talk more about some of these like practical applications of risk zero zvm as we get closer to the uh official launch of 1.0 kind of what other practical expectations are or applications are you kind of looking at in implementation that you see or that you have lined up already yeah absolutely we we have a number of different partners that we are working with uh both for sort of on the you know sort of L2 side as well as on the sort of more application specific side um you know and I think that you

you spoke earlier to this idea of making it easier to integrate with things you know one of the other things that we've been working on is uh you know within this sort of ecosystem it's very easy to for example interact with rust code because rust code compiles down to uh you know our zkm but we also it's also really important to be able to access like existing state that's on chain right so for example uh you know running uh we just recently uh put out a library called steel which basically allows uh the programmer to call evm view calls uh and inside of the DK VM um so that they can run computations on the existing chain onchain State uh and you know so

one of the one of the cool things is because we can sort of emulate the evm just for a small section of computing we can sort of allow the sort of way in which you can access onchain state to be a lot easier um you know and I think that that's going to be highly valuable for a lot of these type of sort of applications um yeah the other okay cool and the other uh applicable use case that we've heard about is is this idea of like a global State layer where you have all these different rollups and you kind of have to pull their each individual State at a certain Epoch and kind of bring it all into one Global State layer perhaps this is more like more of like an interoperability or like

a proof aggregation use case but is this something that you guys are thinking about as well absolutely I mean I think I think that that there's actually one of the things that people so the the sort of immediate obvious use case of ZK is to sort of prove the correctness of a state transition um but what that means is that that also is allows for sort of cross state messaging to be provably correct right so if you want to look at you know um moving uh you messaging across uh across chains um or between rollups for example um you know ZK allows you to prove these sort of State transitions on the on the on the far rollup to the one you're interested in

sending a message to and and as a result they mean that you can sort of have this interchain messaging happening um without having to wait for you know windows for optimistic you know delays or these kinds of things right so you can get a much faster much more interaction between different sort of um Computing environments different you know uh different chains fuel achieves Higher throughput by utilizing a novel utxo based approach that allows for parallelized execution this design significantly accelerates transaction processing which enables fuel to handle vastly more transactions than nonp parallelized systems thanks to advancements introduced by Fuel ethereum

rollups are set to be more powerful than ever before and fuel is not just enhancing ethereum rollups it's redefining them making them faster more scalable and more adaptable to meet the needs of modern applications and developers go to fuel. network that's fuel. Network to learn how to build on the rollup of OS so I think and the second thing is really regarding sort of aggregation and one of the really cool things about ZK once you have recursion um which you know is a absolutely key critical feature for a mod ZK system is that it allows you to prove two things and then prove that both those verify and then

verify that resulting things so you're able to aggregate a large number of proofs into a single proof uh and that is super critical uh for a number of reasons one it allows you to talk about a very large number of State Transitions and verify them very quickly even if the state transitions are being produced independently by different parties uh you know so you can you can sort of have a lot more uh interp party complicated sort of interactions um which I think we'll see a lot of moving forward I think that that that's sort of we're just sort of on the beginning of what that's all going to result in um and then I think the other really important part is just in terms of reducing the cost of things like verification right so if you look at verifying these proofs on chain to verify a single proof

on Chain by itself is on the order of sort of 300,000 uh gas right which is quite expensive um still cheaper than doing some in some cases the computation is big enough it's still cheaper to do it offchain and verify it but if you look at how you can use aggregation you know we're working on um mechanisms that will allow you to have a amateurz cost for verifying proofs that's more on the order of 20,000 gas for verifying approv and so the ability to do an arbitrarily large amount of compute offchain and then only pay 20K gas for it I think is going to have open up a lot of really interesting possibilities yeah as you kind of described that it it brought to mind this this idea of like exponential exponential succinctness yes because as

a result of that recursion you're you're able to save quite a bit of resources and and preserve the succinctness property actually apply that to multiple different like well would have been individual ZK proofs but through aggregation a single succinct proof yeah it's really crazy like one of the amazing things about ZK is really you can you can verify effectively and you know arbitrarily large amount of computing with a a single you know quick succinct check and actually you know in some ways like you know um you know Mina um really sort of pioneered this in that their entire history of their blockchain is really verifiable by like a light client right and and I think that this uh you know we will start to see the scalability when you think about sort of

wanting to scale the existing systems to uh an unbounded rate right you know we've seen a lot of work on people scaling the the raw transaction throughput of a blockchain but really the the sort of long-term goal in my opinion of these decentralized systems is to make it so that as you add more nodes to the system as you add more Computing capacity that the transaction rate scales up with the the number of computers every additional computer you add gives you more transaction rate gives you more throughput right and I think on the Computing side ZK already has all the necessary components to make that happen and then I think on the data availability side there's additional scaling challenges but I think that the

you know that's I think largely solved at a theoretical level um I think that the it'll still be a while before we see practical sort of truly horizontally scaling um decentralized systems but I think that the question of whether it is possible is no longer an open question in my mind uh which you know I think even a year ago it was right so um I'm really really excited about what the future holds with that you know so it sounds so intuitive to to to think about that concept of yeah add another computer get more scalability but when you when you take it on this verifiable and the verifiable nature of it it means

that all of these computers are going to have to verify the same thing and and so when you add another computer it means that there's more redundancy and so a lot of times we've seen that not like adding more nodes in the system actually slows down the scalability it may it adds it may add some security because you know it's another computer that is also doing the same computations but it but because there's another computer that's has to do the same computations flows things down the light node architecture just breaks this and and it means that we're we're actually able to kind of like divide and conquer a little bit all of these all of these nodes are able to verify the work of the other nodes but because we have this succinct property it means that they don't have to do the exact we don't have to compute

the exact same computations we can just verify that those computations were correct and then each of the nodes are able to kind of like specialize on their own little piece of that of that entire computation yeah and if you do it right and you roll the whole thing up from like a a big in a big tree sort of form you can get it down so that the all the correct execution of all the nodes on the system are all verifiable by a single very small thing that can be rebroadcast to everyone right so I think I think you're you know there's uh I think that long term this is definitely the direction that that uh things will move in there's a a lot of different ways to do it like there's interesting question of whether it's a bunch of different sort of sovereign things that

interact whether it's a single giant uh you know scalable thing that has uh the same execution model everywhere I think there a lot of opens but I think that the with the combination of ZK and some of the new things like data availability sampling and some of the other da work that's been going on about making the scalable distribution of data happen as well because that's obviously the other sort of part of it is the compute and the state um I think that the um yeah I think these problems are very much soluble in the long term the ZK endgame not only for interoperability but for verifiability as well when we get single slate single slot finality improve aggregation for cross chain transactions

Jeremy will be in mikos partying and a big smile on his face yeah I mean it's been the dream right like I think that um you know if if you look at it I think that there are so many applications for which uh you know blockchain uh would be a great choice but just is not technologically uh feasible to to do right now and largely this ends up coming down to costs right like um you know you know think that uh you know why not replace Twitter with like a truly decentralized blockchain version well it really just comes down to you know no one's going to pay you know uh you know five dollar of gas fees to you know click the like button right um and I

think that that that that that cost that $5 of gas fees really comes from the sort of scaling limits which are induced by this uh you know um redundant computation right and so as you look forward to a world where we can actually really have this horizontal scaling I think a huge wide range of new possibilities start to open up right um so I'm very excited about where that where that's going ZK VMS uh have been called these F like a funnel for Prov networks yes how does the risk zero zkv M kind of work together with Prov networks and and could you kind of just unbundle that and and talk about kind of the interplay between these different components yeah because to be honest

guys I thought ZK VM sorry Jeremy I thought ZK VMS were like like the alt VM thesis like you've got like move VM and like uh svm Salon VM but but it's not really the same is it so no it's well it's largely uh you know sort of especially from our perspective rvm is designed to be very um sort of unopinionated and to allow you to run these other kinds of VMS inside of it right uh because it's very much works like a normal ordinary processor and a normal ordinary computer and so actually you know we uh for example uh have uh some prototypes where we can actually run you know the move you know move VM you know code inside of our VM but we

and obviously we of course support running evm things in our VM um so it's really sort of meant at a to be a lower level more of like a more like a piece of Hardware in that regard um but yeah I think uh to to go back to the sort of question about Prov networks I mean I think that you know on the Network side that we're starting to see the emergence of a number of different projects to do sort of um Pro networks to allow people who need zero knowledge proofs to be produced to be able to get someone with the right Hardware to do the Zer knowledge proof to to do it um you know and I think that uh you know we're you know currently working on our own

particular take on the sort of Prov Network um as well right now and we're we're sort of finalizing the some of the design on that but I think that you know I think that was it's the economics of it are still not in my mind fully worked out in terms of the sort of making sure that the supply and the demand match up and I think there's also sort of an interesting um separation uh on the marketplace it's actually a little more complicated than just sort of a two-ended Marketplace because there's actually multiple parts to the process uh in my mind you can almost sort of separate this question of what I would called ZK settlement which is the idea that I will pay X if I get a proof of the of Y that the process of actually

making sure that proof gets landed and verified where it needs to be verified for the use of the app and the payment movement that's sort of like settlement from sort of this question of you know matching which is trying to figure out you know which um person who needs appr proof goes with which person who can produce the proof um versus you know any sort of also um you know sort of reward mechanisms or to you know ways of uh encouraging provs or you know as well as all kinds of things like things like if you have a party like an L2 that wants to have ZK proofs produced reliably over an extended period of time what they really want is actually like an SLA and

sort of how do you make a Marketplace for things like slas um you know is there a slashing mechanism right there's a number of these interesting things because like you know many some case some use cases really want um I want to just pay for proof right now and I'll pay whatever I need to pay and some people want to know that the price is going to be stable for a while and that the proofs are going to get done and that their L2 isn't going to grind to a halt because of a price spike in the Prov market right um so I actually think that the market mechanics um you know and and also the other thing is that Z zkps aren't necessarily completely fungible right like you might need a particular type of proof or you might need a large proof versus a small proof

and different machines have different capacities for these things so um I I think that the the market mechanics of this are actually going to be um quite uh interesting and I actually think there's a there some value from a design perspective to separating out the questions of like the settlement part of it from the sort of uh you know um matchmaking part of it because I think there's there's room for a lot more Innovation on the matchmaking side the settlement process is really about how to get the thing on the Chain the most efficient way so anyway we have we we uh we're currently working on a number of these sort of problems um you know currently the zkm 10 you know if you want to run the verifier you run it yourself but I think and if you want to

generate a proof you generate it yourself or you know we have a web two service Bonsai that you can use to do it um but I think that long term uh there's going to be a lot of interesting things in terms of the the status appr Market cartey is your home for app specific rollups at the Forefront of developing new tools and platforms that enhance the capabilities of blockchain Technology ctei enables applications that are flexible and built to scale build on a full Linux environment and use traditional software libraries but in blockchain development go to

cy. that's cy. to learn more about building your own app chain today the first the settlement part of like putting that proof on chain that part in like facilitating the money movement and the payment for that proof that's just another state transition and it largely right yeah and I think that it's actually it's actually interesting because it really you know only requires you to know that the two parties agreed to the the that there and that the proof matches whatever requirement that the the client or you user had um so I think that uh that's definitely you know uh a can be looked at as a separate problem

from the question of how do you figure out who's going to run what proof and how do you figure out the sort of price uh and and sort of that whole Market side of it um but anyway I do think that there's a definitely we're we're just sort of seeing the beginnings of these kinds of things emerge and I think that um uh but I think that this is going to become increasingly important because um you know there's obviously whenever there's a demand for something and there's a supply you know making a an effective Market that works well for all the parties is a critical part of you know making the technology applicable Yep this is uh this is all getting to the to the like the scalable nature of of trying to bring down the proving cost

enough so that someone who who pushes the like but like button on Twitter doesn't have to pay five dollars like to press it I think we've already I think the the thing is is that we've already passed the point where the your the cost of proving has gone down enough that it is now cheaper to prove many computations on chain than is to pay the onchain gas for that but I actually think that you know there's been uh a lot of work on the sort of performance side um from all the parties in this industry and there's a lot of room uh for continued Improvement um you know I think that we in the last uh you know few months the next release of our software is going to have like you know

some almost like 3x Improvement in the for performance um and I think that you know we still see a lot of you know fairly loow hanging fruit in terms of additional engineering work to bring the performance down even further I think that we're actually getting very close you know I sort of look at this question of we you know it I think we are only you know months uh away from being able to for example verify an entire ethereum block um you know just using normal rust you know like RM or whatever uh in for some something like sub right and I think that as those cost numbers go down the

sort of things you can do just go up there's certain applications that are cost limited right the Twitter like button being an example but also just like there's there's there's this wide range of things and and and right now ZK is applicable in cases where it's an important enough transaction it's worse the extra cost but as these performance things sort of continued to improve we're going to see a much and much wider set of applications become economically sensible to do and and what are the limitations like I've asked this question before and someone actually said that we're already like operating at bare metal so is is is it just a matter of like adding more provs to the network or or like adding more nodes to to these Pro Network are like kind of

like what what is the limitation and how are we able to unleash that so that we do drive down these costs even further for ZK proofs and then and then ultimately unlock some new use cases yeah I would I would say that the there's still been uh further sort of improvements in some of the underlying mathematics that underly these things that can be taken advantage of um you know I think there is definitely lots of room for better code just good old-fashioned engineering you know we for example Focus very heavily on doing really good GPU acceleration uh but GPU acceleration is complicated and there's room for us to improve there and there's room for I think in general the industry to really you sort of just turn the turn those numbers by just pushing on the

engineering side um and then eventually you do get to the point where you know sort of the next logical step is sort of hardware for you know doing ZK proving uh that's custom hardware as6 and so on um you know I think there's number of different um companies working in that direction you know we've been in discussions with a number of them to to sort of make sure our proof systems are going to be able to be to use some of this Hardware all that said I think you know there's still so has been enough mathematical Innovation that you know if you'd asked me a year ago whether it was really time to start building custom Hardware I'm like well you might end up discovering that the next Innovation improving systems renders your Hardware Obsolete and Hardware is a very long

life cycle but I think it is it is slowing down um but then I think the other issue is just yeah giving the right incentive structure to make proving worthwhile uh will just increase the level of Supply um you know if there's really some actual money to be had by running ZK proofs um you know and that Supply goes up it'll it'll provide you know more opportunities so I think I think there's there's lots of ways that the cost will continue to go down where the bottom of that is I don't know um you know like we may be nearly done with new mathematical breakthroughs uh but we might not be it's very hard to see that future right so yeah I think the kind of followup for this main point of lowering

costs to get more practical applications and to kind of get implementations happening is is kind of introducing ZK into this modular stack that we have now and I'm just curious from your perspective where do you see ZK like eating mod ity or what parts of like the modular stack if you think about you know all the way from just the the three layers like execution and data availability consensus and and settlement but like extrapolate that to like sequencing and proving and rpcs and interoperability and um you know there's kind of list can go on as long as you want I'm curious where you see ZK like really really making a Big Splash in the modular stack yes so I think in terms of execution I think long term nearly all

execution is going to move to to to ZK just because it does allow the you to parallelize the execution um uh you know I think uh there is lots of places Where Da and ZK um fit well together um if actually if you look at some of the the latest work on like data availability sampling they're using a lot of read Solomon codes which is a lot of the same sort of underlying mechanisms that are used in CK um and there's there's sort of a number of different ways in which they interplay uh in that regard um you know I think terms of you know interestingly um you know uh cross chain interactions the the ability for ZKA to allow you to verify something quickly is going to be highly critical on the on the consensus side I think the big value

that ZK will potentially provide there I think that one is more complicated I think that there is some value for for example signature aggregation um or being able to sort of um you know depends upon what types of consensus mechanisms you use though so I think that's a more nuanced and hard to give a a sound bite on um I think you know um there's also a lot of interesting things where ZK will have an effect you know sort of in terms of the ZK Identity or interactions with off with you know sort of existing web 2 stuff for example um you know we've done some work in terms of using ZK to validate sort of your log to existing

things like you know uh Google or other things like that so I think that there's going to be an interesting um sort of the ability to take some facts from sort of the web to world and make use of them in a trustless way that doesn't have any Central parties or you know uh involved uh I think is another huge huge opportunity so I actually think ZK is going to end up in a lot of different places but the one that's I think most incontrovertible is the sort of execution side uh where I think it will it will very much eat the world um so beautiful yeah Jeremy um any closing thoughts from you about steel and about kind of R zero uh v1.0 coming out uh what our community can be looking

forward to yeah I mean I think um you know we're very excited to you know help both the community in general and also our partners who are going to be launching with us uh you know uh with the one or shortly after to sort of um you know be able to make use of this sort of power of the general purpose uh ZK and uh I think with steel we're really looking to make that process very easier for ethereum devs and to enable sort of these um you know ZK co-processor applications um and you know we also I just wanted to just send a shout out and a thanks for all the people who are involved in our uh trusted setup ceremony which is going on

which is sort of one of the last uh phases of this process um and yeah I think that's that's that's pretty much it awesome Jeremy thank you for coming on uh it's been a pleasure to learn about ZK with you and uh glad we spoke some English today I do what I can thanks Jeremy yep