ZKVMs vs. ZK Circuits: A Spicy Debate

Transcript

I have a feeling this one is going to be another one where I'm kind of just staying out of the way Uma and donish are going at it when you get $1 worth of GPU compute you're actually doing a lot more compute than like on a CPU that is how long zkm will be rolling so ZK VMS will always be rolling I hope that once Von Rishi comes out of stealth with what she's been building that you guys can collaborate as well GM what's up guys welcome to another episode of the rollup today we have a debate this was a fun episode it was a very friendly debate we had a fun episode with Uma from cin and vanishri from FMA FMA has recently come out of stealth and they are working on custom ZK circuits Uma takes the side of generalizable ZK VMS this is a question

of convenience versus customizability there's lots of parallels that we draw during this debate ultimately this one is a really really good Deep dive into ZK and a couple of nuances versus tradeoff of building a generalized environment or a very custom environment purpose built for specific use case hope you guys enjoyed today's episode before we get into it a word from our sponsors welcome aboard on our journey into the singularity this is the endgame road map for frax and fractal the new L2 out of the fra ecosystem that is totally based on fractal scaling fra still is a modular L2 blockchain built by fra with modular

and fractal scaling in mind fractal scaling is based on the mandal BR set of fractal images and it explains how l2s become l3s and the entire app chain life cycle goes through its Evolution the frax ecosystem is made of some of the top builders in the space and has stemmed from its OG days of the frax stable coin it is now in the LST space the LRT space and this frax L2 joins the existing Suite of fra products including fra Swap and frax lend you can see frax fairy the bridge to go from any chain

arbitrum optimism or main net into the fraxel main net Bridge your tokens and bring your FRA assets into the fractal ecosystem join today to get the best out of fraxel you are still early join today take part in our Expedition into the [Music] singularity cartey is your home for app specific rollups at the Forefront of developing new tools and platforms that enhance the capabilities of blockchain Technology carty 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 welcome back to the rollup guys uh today's episode we're going to be discussing the tradeoffs of ZK VMS versus ZK circuits kind of this idea of generalizable ZK VMS versus more specialized ZK circuits kind of inspired by a tweet from visher here a couple weeks ago um and almost like a secondary followup to our recent episode with Uma and Brendan about succin impact on polygon's agler so yeah tons to talk

about excited um Rob good to see you I feel like I've been kind of AFK from these episodes for a couple days so good to be back and um yeah start get you back on uh real quick here uh I again have a feeling this one is going to be another one where I'm kind of just staying out of the way and Uma and vanishri are going at it um and yeah we'll uh we'll get it started here but again I think uh the idea here is is like Andy said ZK VMS and ZK circuits um what are the trade-offs why should we use one or the other um and talking about the designs uh of both so yeah I think first we'll get it started with

some intros um VRI you're new to the channel welcome and uh yeah why don't you start thank you so much Robbie and Andy it's great to be here um quick intro about myself is I'm the founder of Firma FMA is a universal proof generation layer that is designed to generate proofs for any proof system in a cheap performant and reliable Manner and uh a little bit about my personal background is that I'm a cryptographer um I um I got introduced to zeron proofs long ago Robbie and Andy I told you the story of while ago uh little quick stories that uh I um learned about Zer proce when I was an

undergrad kid in India in a remote town and uh just was blown away who wouldn't get blown away right the ability to convince somebody um of the Verity of a statement without even telling them any information whatsoever about the reasons why it should be true it just uh sound so uh impossible at its face value and how how can there be so much of research and so much of advancements and look look at where we are um and very soon I realized this is what I wanted to work on I think for for a long long time um probably for the rest of my life and and uh um since then everything that I've done is in line with

my goals of uh uh staying goals of working on Zer knowledge proofs uh doing my PhD at UCL La um uh in cryptography and working at the various projects including Mina uh the Mina blockchain um on consensus protocol the ZK circuits there Etc and then um Firma um yeah that's a little bit of background about myself thank you awesome um hello I'm Uma I think I've been on the podcast before um I'm one of the co-founders of sync we're building a ZK VM called sp1 so basically what sp1 lets

people do is it lets any developer just write normal rust and then use ZK uh so you don't kind of have to write ZK circuits anymore and then we're also building a decentralized pro Network around sp1 to make it easy for anyone using sp1 to use one API call to get their proofs generated um and not have to set up their own infrastructure sweet okay guys welcome on uh thank you for taking the time um I think to take us off going to pull up on the screen here uh the tweet from Bon street I'm gonna read it out loud for those who aren't watching on YouTube or on our website um so Von's readed on July 28th here is here's a controversial take on the

future of ZK ready in short for any given project ZK VMS will fade and custom ZK will take over here's why ZK VMS have been crucial for WID widespread adoption by significant ific L reducing time to Market however this this comes at the cost of high resource demand for proof generation while this cost is decreasing custom ZK is likely to be more performant consider an application's evolution it starts with ZK VM finds product Market fit achieves success and then aims to improve its performance transitioning from ZK VM to custom ZK becomes an obvious choice as time to Market is no longer an issue now to be clear this doesn't dis this

doesn't diminish the value addition of zkm at all I think they will be forever essential but as a bootstrap mechanism for any new project feel free to challenge it and Uma kind of came back with a challenge um which I'll pull up on the screen shortly but first I think uh to explain your point of view further for the listeners uh would be great to kind of hear more from your side there so before I talk about the exact uh tweet I want to start by acknowledging the amount of impact that zkm had has zkm have had on our space I think Z kvms have have catapulted the adoption of ZK they have reduced significantly reduced

the barrier to entry reducing um by reducing the time to Market and Engineering costs there is zero taking away from that right um I think like I said in the tweet I think they are forever to they they are here forever to stay the bounds of my argument are the following when a project reaches a level of maturity when when when these bootstrap constraints go away the bootstop constraints of time to Market and the bootstop constraints of engineering costs go away and when performance takes Center Stage then the question that needs to be asked is will ckvm still be the right

choice for them or will will it make sense for those projects to consider custom ZK circuits and my thesis as as I mentioned in this Tre is is that zkm Z kvms are a great Gateway mechanism for those projects and uh custom circuits can increase performance I think uh they will have a custom custom custom CK circuits will have a space um yeah that's the that's the high level structure of my high level high level uh gist of uh my thesis cool now I'm going to pull up UMAS and then we'll kind of take the

tweets down and just have a more kind of fluid conversation um so Uma you went in and responded um which unfortunately I mean unless you want to hear me do another monologue I think that we'll just pass on that one but maybe you could also kind of summarize your key points here um and then we can kind of Kick this off yeah for sure so I think uh for some background it's maybe helpful to even talk about my personal experience with ZK circuits versus ZK VMS so you know for around two years ago like I was writing a lot of custom circuits I was using languages like circom like Pony 2 um which is more of a framework than a

language and writing custom circuits for in particular a lot of like client use cases like a ZK tender like client and we wrote a lot of circuits it took a really long time um it took like many months to write them it took the many Engineers it was very difficult to audit and in the end we were pretty happy with the performance of our circuits I think it was like you know the proof generation time took like 10 minutes or something like that um and so that was our journey with ZK circus then we built sp1 and with sp1 I think like our intern or something wrote the tunderman like client it took an afternoon it was like 50 lines of code um the proof time was actually really really fast it was

several minutes instead of tens of minutes and then the proof cost was also a lot cheaper instead of being several dollars per proof it was like a few cents per proof and so I think my personal experience with the ZK VM is that it's been better than custom circuits in literally every single Dimension like the developer experience is like 100x faster the proofs are cheaper um the proof generation time is faster um and overall like the maintainability the auditability the customizability is like unparalleled so I think a lot of my thinking around why ZK BMS will totally dominate ZK circuits even in the long run um is born out of

this personal experience um and yeah maybe I can talk later about you know why I think that Trend will continue for a long time um but yeah I think that's like kind of the well that's like one data point I guess um that you know I think is really illustrative of like a real world example with these two different Technologies I mean basically like let let's open up the floor so vonish if you'd like to respond and then maybe we can go back and forth a little bit on yeah these two competing thesis I think the amount of like I like I said the amount of advancement we have had in ZK space

it was even Unthinkable uh even before uh all sp1 R zero uh do Nexus um ZM all all these projects started I I am even guilty of the of of the fact that uh of the fact that uh I thought that it may not even be possible to build a lium so I actually am very um stunned by the amount of uh amount of uh advancements that these teams including um's team has done um again I think the the the the there are bounds of my statement right my statement

doesn't even uh cont doesn't even contest any of this my statement actually goes to a specific situation where the the the engineering time is so small the um the uh the results you can get by by uh the the results are improving time uh you can get by uh applying ZK VMS now uh in comparison with the ZK circuits that have been built in the past um might be a lot better here here all this completely acknowledged

still my point remains that as a project grow so big so big that it touches the life touches lives of billions of people at that [Music] time at the time and and also at a and also for a project where performance is critical right there can be projects where performance is critical there there are there are too there are very whenever you touch the entire right people are working with limited resources phones even Nokia phones old phones not able to generate proofs on them um not having enough me memory to even complete the proof let alone how however long it takes these are all the

constraints right when these becomes become the constraints and when a project grows to that level of maturity the focus becomes comp competing there there won't be typically one project there will be multiple projects and they will compete uh people will say 1 minute against 95 seconds uh one one minute against uh 55 seconds and it even milliseconds even one bite of data uh difference can become the uh the the the coarseness in which people um Pro projects can compete so when that becomes um uh a Center Stage for projects there if it is the case

that custom circuits can perform better than ZK VMS I don't see projects holding back from putting together a cryptography team of let's say 10 uh amazing cryptography Engineers working on ZK circuits for one year that won't be a problem because cost isn't a problem at that stage time to Market isn't a problem at that stage because this these projects have already got around this problem through the use of ZM um and uh and there there are uh Uma rightly mentioned some important advantages of zbm such as auditability such as uh reusability of the code uh here are some here are some important points uh related to that

right one about auditability um when we are audit so I I'm actually very skeptical about I'm actually very um cynical about the way audits currently are looked at uh in the ZK industry specifically and for for the following reason right what when when you audit what is the you need to get some level of assurance after the audit right and that level of assurance should align with your main goals the main goals for a project for for example some somebody's is is building an application to transfer money from one party to another party and they're using ZK they they

want to make sure that nobody's uh nobody that this money doesn't get lost for example or people are not not going to uh not going to Mint extra tokens out of thin a without getting detected these are these are the concerns of that project the audit the results of the audit should directly transform somehow easily in be inferable um the results of of of the audit should somehow connect with the goals of the project and um so contrast that with the current state of ZK the current state of ZK is that we are going at a break neck speed we um we are going at a Breakneck speed

that at such a speed that we we uh rightfully don't have the time to peer revie all the security results of of security analysis of every ZK um advancement that happens and how those security properties relate to the security properties needed by the application and these are not just theoretical right take for example what happened in zcash in zcash because of the bug that that there existed what um what it implied is that anybody could um mint fake cach out of thin air and nobody could notice right these are

real issues right um and uh and and that is coming from an amazingly strong cryptography team I think I think that's one of the most amazing cryptography engineering teams there exist um and still there was a bug and uh and I think we have a long way to go in terms of audits making um audits uh being being of a great uh of of of significant value to applications that are using CK systems um so there is that point I'll I'll put I'll leave it there um right I I think uh to summarize my points are that there are various there

are various advantages of ZK VMS but when it comes to the bounds of my argument I think whenever custom circuits do make sense um the advantages of zkm the extrudability Etc will become minimal and the ability of projects to to expand on areas where where the bootstop constraints don't matter will uh will make sense interesting point on the auditability um I don't know if you if you want to comment on that specifically um because I think that's it's a it's a it's it's kind of an interesting uh thought with regards to how how these audits are being are taking place and also just like the

discoverability errors um um which which I think is interesting and then um if you don't have any comments on that I'd like to ask you uh specifically about uh some components of of your post as well um so let us know if you have any comments there yeah regarding the auditability it sounded like your point well I guess I'm not I guess I'm not like 100% sure about the point but I guess my view on this is like auditing and easy Cas systems super complex and so if you hire you know a team of cryptographers to make a bisoke ZK circuit um I think it becomes much harder to audit than for example an

application built on top of a zkm uh for example with our zkm sp1 we've gotten many audits for it at this point we've gotten we've had a public code competition for it um we've spent getting audits is extremely expensive and then the auditing compounds over time right so like as you know we use it more um and then we design upgrades to the protocol there's more and more pairs of eyes looking at the code base and I think the security and auditability story just gets better over time if you're making a custom ZK circuit for your use case often you have actually a very similar amount of complexity um to for example a ZK VM uh even for for example if you're trying to verify

signatures or something like that there's a lot of complex logic that goes into you know making non-native field arithmetic work in a ZK circuit or all these things and you know it obviously you're not going to spend as much money auditing one circuit versus one ZK BM that a lot more people use obviously you're not going to have the same number of Auditors or the same pair of devis on the code for a custom ZK circuit for that is just much more limited in scope versus a zkm that a lot of people use across a lot of different applications um I think the beauty of a zkm is that it is a really General platform where it can benefit a a bunch of different applications right so who can use sp1 I mean basically anything in crypto like

rollups can use it Bridges can use it and then basically any use case can use sp1 and so every day we're really motivated to wake up go into the office and make sp1 like 10% better and we know that when we make it better everyone benefits and similar similar to that like for our Auditors they know that when they're auditing sp1 that's an audit that benefits the entire ecosystem and all the people using sp1 and that means we can invest more in audits we can invest more in security more people can look at the code more people have an interest in looking at the code as well um like there's a lot of different teams that have you know taken sp1 forked it like in a friendly way added their own pre compiles um you know tried to do

their own optimizations and I think through that they're also looking at the code as well and so overall I think the security and audibility story for zbm because it's such a general platform is like a lot better than anything that's bu custom almost I would say definitionally um perhaps like if you're building an extremely simple circuit that's like you know you know tens of con maybe not tens of constraints but like tens of thousands of constraints or like very very few lines of code built on an existing um circuit framework that's been used for a long time so for example circom then maybe I would say you could like audit that securely like for example I think the tornado cach

circuits are extremely simple and something that um are by at this point given you know how much money has been in stake at tornado cash um something that is very reliable very secure and we can all feel very good about but I think for any other application that's like more complex um the zkb security story looks a lot better I have a few um points of response to that thanks sua so one is I think I wanted to explain my point a little bit better about about auditability so the the core aspect I meant is connected to the various levels of SEC security

approv system can have right there is no secure not secure kind of a situation there are levels of security right something can be only secure to an extent that there can be application that is fine with that uh but there can be application where you're worried about bigger kind of attacks that you need higher levels of security specifically in in in in if if you look at uh if you look at analysis written analysis of security uh of proof systems for example gr 16 right gr 16 is not um it doesn't have the highest level of security it has uh no the so-called

knowledge soundness and the highest level of security is simulation extractability there they're just I think they're named very badly they don't tell us very much but but let me try to explain very uh in in an interal manner what what exactly these two levels of security mean the lower level of security pretty much uh captures the notion of soundness that you you you you try to convince a person of the wory of a statement you're not able to convince that person of a wrong statement uh that is the basic level of security right the higher level of security is non- malleability that let's say Andy gives me uh a proof then in a man in the middle attack when I'm

when I'm playing some when I'm talking to um I shouldn't be able to transform the proof from Andy and fake it to come from my way I don't have the witness I'm not able to generate that proof but Andy gave me the proof so I have something to begin with I can transform it mul it and give it to Uma this is the non-malleability attack this is the this is like the man- in the- Middle attack the https security all they are all related right they so summarizing there are multiple levels of security um and and even grad 16 for example doesn't have that higher degree of security and there are applications where it makes sense where it is

important that you have that non-ability um uh where you can actually create Havoc if you're able to mul somebody else's truth as yours and when uh when that level of security is required when my my point is that my point is that our audits are our our c spases is going at such a pace that we we rightfully I think this is the right way to go still I I'll I'll say I I'll explain why but but I think the way the the pace at which we are going doesn't allow us the time required to analyze the of security of these proof systems and also for the for on on

the application side for the applications to think about what is the right level of security that they want because they're because it's just the state of it's just the it's just the world we are living in right applications they're not ZK experts that is why um and and other um's teams and other teams are helping these teams to embrace ZK without knowing ZK without having to think about this uh this ZK in in depth without having to think about the security aspects in depth it's very natural these all all projects are not thinking about uh the security aspects as a result my question is what what what does these um so what what do these audits really tell us what do

these audits uh give Assurance to these applications on imagine an application that needs higher level of security but a but a ZK has doesn't have that ZK proof system doesn't have that level of security then what does this audit give us what what does the result of these audits give us that that was my uh main uh Point uh let me make a couple of other quick points that um while it remains true that the the uh amount of brain power the amount the number of eyes that a zkm can get can compoundly affect a large number of people it uh a mirrored

argument holds true for tools that can be built to make custom circuits easier to build if more people and more people and more people are building uh are are advancing the area the area of tools to build custom circuits it Remains the Same so um just the way we didn't Ju Just the way we learned our lesson from not questioning uh our ability to build something as beautiful as Z kvms I think we shouldn't question the ability of our industry to build amazing tools that can help us easily build efficient custom ziki

circuits and uh and one last point is that just the way again there is a mirrored uh argument just the way ZK VMS can impact the entire world in the entire world of projects that are trying to embrace CK tools that can that can be used to build custom ZK circuits can be can impact this this project that can so recall that we are talking about these projects that have reached higher level of maturity right they have they have impacted a significant number of people now anything that has anything that helps them impacts again a large number of people anything uh these Uh custom

tools that can help you build custom ZK circuits that thereby helps these really Advanced projects which are impacting an entire world can help this entire world so I think um there there are mirrored arguments in summary um I think uh ZK VMS are highly impactful custom ZK circuits can be highly impactful but but just in different two different ways Welcome to the ignition Mantle's newest campaign to liberate the growth power of Bitcoin fbtc ignition has officially beun with a total token supply of over 2,000 fbtc with a tvl of over 150

million right now you can go on the fbtc website to see all of the featured campaigns saking opportunities and liquidity pools where you can utilize fbtc on chain today for some of the best yields available on l2s the ignition Sparkle campaign can be found at fbtc ongoing okay Uma let's put this into kind of uh terms for like an example that we can understand I think your Tweet was a was an example that that like hopefully we can understand um there's there's a lot of this that is kind of uh I think still probably a little bit difficult for the broader community so I appreciate you guys kind of breaking this down for us today but

you you put out a a your kind of rebuttal with regards to this tendermint like client example and kind of talked about the proof time proof costs lines of code and Engineering efforts for a custom ZK circuit built with planky 2 versus a tendermint like client built with SP sp1 uh which is succin zkm so let's just kind of unpack the key factors um that allowed sp1 to outperform this custom ZK circuit in this example from the from those that I mentioned as well as just kind of like how the performance and development time compared and what your key takeaways were uh in in addition to kind of um the

broader conversation here yeah so I think a really good question so you know just to touch on what you said I in my tweet response I said we built the same fundamental like application ZK application tender like client using custom circuits with this Library PL 2 and we built the same thing with sp1 and basically the sp1 thing was just better in every single Dimension like it was way easier to build it took way less time there's way fewer Alliance of code I think it's much more secure um it had it was the proof costs were way cheaper the proof latency was way better and so overall it just seems a lot better and I think one very natural question to ask

is like it feels like we're kind of getting free lunch like we just improved upon our old stuff with the custom circuit World in every Dimension like um I think it'd be pretty believable if I said oh the tender like CL with usp1 the developer experience is a lot better you know it's 50 lines of code but it's a lot slower or something like that uh so there's like some tradeoff but the argument I like to make with zkm is actually there's no trade-off and I think it's really helpful to understand why that is the case so with sp1 because again and I'll go back to this like platform analogy sp1 is such a general platform and such General tool that can be used across every single vertical in crypto like every single company in crypto right like rollups Bridges like

any use case can use sp1 like if you want to use ZK you can use sp1 and because it's so Broad in general we can spend a lot of engineering effort really optimizing it so to give a really concrete example with sp1 we spent many engineering months almost probably a full engineering year making a GPU Prov for sp1 so we took out sp1 we hand we wrote a lot of like very complex difficult GPU code and then we run sp1 on gpus and with gpus the proof generation times are a lot faster because like gpus are you know good at that um it's also a lot cheaper because on a cost basis like when you get $1

worth of GPU compute you're actually doing a lot more compute than like on a CPU um and so for us the gpus ended up being a lot more cost Ive and also a lot faster um than proving sp1 on CPUs now there's no way we would have spent an engineering year um optimizing our plony 2 like client and putting it on GPU like that makes basically zero sense there's no engineering Roi there because it's just for one application it's just for one use case um it's just for our one team so we would have never done that that wouldn't have made sense but for us like it was definitely worth putting in engineering resources to optimize sp1 because not only did our tender like

client with sp1 get better all the other rollups who want to use sp1 those all got a lot better and so that's like a really concrete example of why having such a general technology that can benefit a bunch of different applications is so powerful because then you can go and optimize every single corner of it um in a way that doesn't make sense if you have like a particular specific application um kind of like an analogy I'd like to make is with machine learning like I well I live in San Francisco so that's all the rage here um but also in the broader world you had like machine learnings existed for a really long time right uh you've had all these like small models and you know you've had these llms actually for a long time when did it go mainstream it

went mainstream when GPT 4 and Chad GPT came out what is the beauty of Chad GPT it's a general purpose technology where you can just put in English and then it spits back out English and now anyone can use AI right like you can use AI by typing through your chat GPT app uh there's a lot of other AI powered applications where uh the developers building those applications they just call the open AI API they put in just whatever your emails like documents what like whatever else and then you know you put in like hey chat GPT can you tell me about X or can you find this information and then um you don't have to do any customization you don't have to do any fine tuning you don't have to do any of

this like complex AI stuff you just like use general purpose gp4 and it just works for a variety of use cases and that's when AI really went mainstream is when we had this general purpose technology and I think it's very similar in ZK like if I think that ZK is an extremely powerful technology and it will go mainstream when anyone can use it by just writing normal code like it used to be before that you had to like do all this custom circuit stuff you had to put in a bunch of engineering effort and if you're just building one one single application the ROI is not there to actually optimize it and like you know audit it and even spend the developer time and energy but then once you make a general purpose and you make

it easy for everyone I think that's when it actually gets adopted so yeah I see a lot of parallels and just like from you know ZK circuits to ZK VMS being really similar to like the shift in AI being super general purpose as well um and so that's why I think maybe that analogy is like also pretty helpful um to kind of Reason about why I think ZK VMS are just like going to the Future yeah and Uma maybe you can um I have two things here for you and first is okay so with this generalizable idea we have um there's there's obviously you get rid of all these kind of trade-offs of the engineering effort which I'd like to kind of T touch on but first and

foremost would you agree that they by writing custom circuits and optimizing for specific tasks that if you do all engineering effort if you fund it all if you go through the entire what you're basically kind of alluding to as being a lot of work and somewhat of a headache do you agree that the outcome for a for certain specific tasks is more advantageous than using a zkv are there certain tasks that you think the outcome are more advantageous if you go through the entire process setting aside the process and the headaches involved or are you saying that regardless of of the outcome of of the specific t ask ZK VMS are better for you know the entire Spectrum that's a good question I think

for a certain use case for example okay let's take the tunder like client because that's our favorite example during this podcast if you maybe spent a few engineering years you spent like millions of dollars on engineering like um you know Engineers perhaps you could make a t a custom circuit for a tender like client that is better than the tender like client in1 I think that is possible now one thing I will say actually is like okay people like to talk about circuits um so let's kind of talk about what is the difference between a circuit and a VM so in a circuit world for example um a circuit means that you're taking your computation you want to prove and you're

writing it as like a fixed computational graph so you're basically writing it as this like you know series of gates and WI is it's like very fixed like to make it super concrete like you don't have like four loops and you don't have like Dynamic if statements and you don't have like branching logic it's all just done as a fixed graph in a VM with normal code we have like normal control flow logic like you can do Dynamic for Loops if statements like that so actually for example for tender there is this interesting phenomenon where in a like client you often don't actually have to verify all the signatures uh often times you only have to verify that 2third of the stake weight has signed off and in practice practice this can actually look like instead of having to verify you know 200 signatures you might only have to verify

20 because like the state weight the stake weight is super concentrated in the top like 20 validators um and that's actually true for many Cosmos chains so in a circuit one of the flaws is actually you can't do this Dynamic logic of or yeah it's very difficult to do this Dynamic logic of like oh I only verified the first 20 and then I early exit like you can't really do that in a circuit and so actually for certain computations um I think the lack of dynamic flexibility can actually make it worse than using a VM where you have this like more expressive environment where you you can like early exit and like terminate from your computations and so there are so I think it's really

hard to say even for tender actually thinking about it more I am like more on the fence given like some of these like tradeoffs um but certainly yeah there of course there are applications where it you spent the time and effort the custom circuit could potentially be like higher performance but I think that's true of anything right like for example there's like you know code running in your browser and like okay sure any developer maybe it could be more optimized or faster or things like that but the reality is like with any engineering task and if you've ever run a company or if you've ever done any work you know that you're always there's always way too much work to be done and you're always trying to figure out like okay where should I allocate my resources and

you're always operating under like a fixed resource model like it's not like engineering resources are ever infinite and there's always really real trade-offs um for example like if you have to spend a lot of time uh coding your ZK circuits maybe your product is worse because all your best Engineers have to like be writing these DK circuits and not like writing the front end or something like that so I think I do think there are perhaps cases where circuits can be better but then it's kind of this like I don't even know if that's like a super interesting question cuz that's not really a realistic scenario where you would be able to spend all this money on the business trade-offs it doesn't make sense but but I I just I I frankly I was just curious as to how far you may Jud

on on uh on which performance stack you know could kind of extend it I kind of want to pass it back to you uh van is and kind of ask you what how are you and and I'm sure that you have a ton of responses uh here as well but how how are you thinking about the engineering difference in between ZK VMS like succinct and custom circuits and how are you thinking about making this worth it like basically we just kind of came to or at least Uma came to the the consensus that perhaps there could be applications and use cases that are you know far better optimized but it's really just is it worth it and so kind of passing to you like how how are you thinking about the developer and Engineering lift to make this worth it

compared to kind of just uh using a general iable solution and then also kind of feel free to just chime in with your other thoughts on what Uma said vertex Edge is now live on say Network say users can now trade 50 plus spot and per markets with the unified order book liquidity of vertex Edge across arbitrum blast mantle and say the next 6 weeks 850,000 say tokens will be up for grab as trading rewards every single week exclusively on say join vertex on say Network now on vertex Edge

that's vertex protocol.com perfect my short answer is that it'll make sense putting that much effort on engineering can make a difference let's take an example Uber right Uber started off in LA in a few cities where they were trying to find product Market fit they were trying to get to Market and all they did in their product was to figure out how to get a person from A to B they even subsidized heavily uh I love the amount of uh money they would give away just to go from A to B and look at now uh the situation now the

situation now is that they have found the product Market fit they have become so huge that they are operating in various countries many many countries they are the number of rights that they have served is phenomenally huge they they have impacted a huge part of the world and time to Market and um engineering costs aren't a problem at all two examples here uh one is that they were using Google Maps initially when they launched their product initially now they have have their own Maps they build their own Maps it isn't a small engineering feat but it could impact the entire world but the amount of the the little uh changes in user

experience of course it could be little i i instead of waiting for three minutes if I'm waiting If instead of waiting for let's say Let me let me uh give these numbers If instead of waiting for one minute if I'm waiting for 10 seconds it's a huge Improvement for me and you might argue that you know there are multiple uh other headaches for a company to figure out they all they should care about is to take a person from A to B but but when a company reached at the level that Uber has reached when they are competing competing with a with the with a company like lft and other uh companies in the rest of the world these numbers matter they will put put aside money that they have done they will put they will take

the time to build these things like they have done similarly in our space like we're talking about projects that reach the level of maturity and scale scale like uber has reached the the little benefits you get from move by moving from zkm to custom circuits the little tiny benefits that you get can impact that level of the world what when bootstrap constraints don't matter these companies put performance in center stage and take uh the decisions of choice of their stack where per commments matters uh this was in response to this question I have a couple of other responses but I can wait or I can I can

go with them I guess one thing though is for example rollups are probably the biggest category of ZK today and I think if you talk to any ZK rollup founder I mean certainly like we're working with optimism they're an extremely large rollup and rollup ecosystem they do impact the whole world they have very Global customer based they have a ton of like billions of dollarss and even for them they want to use the ZK VM to prove the optimism State transition function and maybe one day make optimism a ZK rollup for them having ZK circuits is just not even a consideration and if you talk to any ZK rollup founder like okay ignore the optimism and the arbitrum

that you talk to like scroll or ZK sync or all these people um or polygon even they all agree that ZK VMS are the the future of their ZK rollos um and they say like yes a risk five like or risk five based ZK VM where most of the Logics written in Rust and then you know you can have these custom pre-compiled and that's something I didn't touch upon sp1 actually has like it's kind of flexible it has this notional pre- compiles where basically you can have custom circuits for specific operations kind of interoperate with the main ckvm and so you can kind of get the best of both worlds because like for very very computationally intensive things you can make a custom circuit for it and we actually do this for hash functions and verifying

signatures that leads to like the order of magnitude speed up we've seen um that ends up being like a very effective tradeoff um and so I guess my question is RO rollups are the biggest ZK consumers consumers of ZK today and even all those teams think ZK BMS are the future so what's kind of the scale of an application that's needed to Warrant ZK circuits of the biggest applications of today are not don't think that CK circuits are right for them actually that's a great question two points one is that optimism when it is embracing Z think of them as starting on the Z Journey they're starting on the Z Journey where they're trying to find their their place in ZK by rightly

adopting ZK through ZK VMS and uh I think the futur is will tell when uh the ZK integrated version of optimism will mature and the other the the other question you asked is is um why are these rollups uh thinking that ZK VMS are the future I think for rollups ZK VMS forever forever will be the future because on rollups you have applications so zik rollups themselves are't applications they are a platform on which applications are built right zik rups are giving you the tech to build applications on top of

so the the the the tech they are giving the applications is zkm please come adopt ZK Embrace ZK uh build on top of us uh this is the right Gateway all their projects right there there they will always have ZK VMS um imagine an application on top of one of these rollups becoming so big that for them it might make sense right for them it might make sense but the role will will always continue to uh offer zvm because as long as so here is my core point right as long as um here is my core Point um all here has always been my core

Point uh that is for your argument not against your argument the the the the four part of my argument is that as long as there are projects that are starting to build that is how long zkm will be relevant so ZK VMS will always be relevant um when applications mature within a ZK within a ZK rollup ecosystem that is when uh it might make sense for them to reconsider what is the right application um an a point so so that is uh my response about uh how ZK circuits will Faire in the secure old ecosystem and uh one other uh point that I wanted to make

is that is about pre- compiles pre- compiles like Uma said rightly are that are that they are C they ZK circuits themselves right IM um if we are to talk about applications where where it might really make sense to think about custom uh ZK circuits are places where it's very slightly away from let's say a sha function you you let's say somebody is just proving that I have a pre-image to a hash function at that time ites it may not make sense for for us to use an entire ckvm we can just probably use the the pre-compile that sp1 has within it um this that specific custom circuit um here is another

example if you so the entire world is using https right um we have very simple math going on in HTTPS we have uh some lower value and there is an exponent and you all all the time you're recognized as a person who knows that exponent and and there and whenever you're building applications uh that uses that for for example TLS notary or um or anything that talks about anything any anything that is Bridging the web two to web 3 parts of the world there you'll probably have to prove something about what has happened in web

2 there computation is very simple like we were saying right there's something in the base something in the exponent you just proving something you're proving that you know the exponent there's a very very simple proof that exists the sigma protocol just three elements very simple very simple proof it's one of the first uh uh it it is one of the first proof systems that there existed extremely simple that is probably all that we need and um there can be many situations like this I think ZK rollups are are good examples where where where variety of applications come into place and ckvm are the right choice and maturity can open up space for

custom circuits but there are also applications where um where custom ZK circuits can readily make sense um Can can definitely make sense if not at the very beginning Uma I just want to kind of like have you like respond there and then I think probably going to wrap here um just want to be respectful of your guys' time Rob unless you have something else as as well I mean maybe I'll just throw in like a quick thought which is that I'm coming to this analogy of like the app chain thesis in with respect to ZK and so like right now projects start on General rollups until they graduate they find product Market fit and then they kind of like outgrow their ecosystem and then go build something

custom and it seems like we're always going to have General rollups because projects are always going to be building something new but then you know assumingly like projects are able to reach some level of scale they'll want to they'll want to internalize their me they're they're going to want some custom customizations and so I I just kind of and seeing this this analogy feel free to tear it apart um as much as you like no I think that's a great analogy like for example you have all all these chains making their own custom modifications to roll up stocks and whatever but I think actually that kind of even proves my point more which is when people make new rollups they're usually taking something like op stock and modifying a small piece of it so it

might be like Oh I'm modifying the sequencer to do like um you know some in protocol me recapture or okay let's look at blast they took op stack they forked it they made a thousand line diff to do this like uh rebasing yield native asset thing right but they didn't go build their own OB stack like that would be insane so I think I actually view ZK really similar where it's like you take sp1 um and then you use sp1 and then you're like oh my application's really big I want to do these like modifications make it more faster and more performance okay let me add a few pre- compiles but the core of the logic is still very much the same um and actually some teams have already done this so for example lur um Labs they're

like a very sophisticated ZK team they took sp1 they forked it they added own pre- compiles for making an ethereum like CLI in sp1 it was really awesome we merged those back Upstream um and now like everyone else benefits in the ecosystem so I think like I I'm very supportive of that kind of stuff and I think that makes a lot of sense where it's like you take sp1 and maybe there's like some new encryption algorithm that pops up or some new hash function that gets popular okay you know spon's fully open source you can customize it as you want and then one day maybe we'll merge it back upstream and you know then everyone can benefit or or maybe not um and maybe other people can just like take your fork and go from there um that's kind of how I see the future I

think in a similar way to how people do not try to build another op stack from scratch because that's just you know if you look at the op reboots like 20,000 commits the code base is really huge like that's just not going to be a fun time and you're honestly probably not going to build something better because they've like thought about it a lot and iterated a lot to get to that point I think in a very similar way like sp1 is extremely complex to build it's really really hard to build like we have spreadsheets and spreadsheets of data on like oh what are like the different bottlenecks let's optimize it um and We've ran run a lot of different workloads and a lot of different use cases to really like achieve all the things we've been able to and so I think it's just really going to be really

really difficult to build something from scratch that's like better or like even more competitive even for your particular use case because like there's just a lot of iteration that needs to happen but I think customizing like a core base makes a lot of sense and like I view op stack op chain op rollups on top of op stack or even like Cosmos SDK op chains like you're not building a new Cosmos SDK you're using the cosmos STK framework and then customizing it where you need to to build your chain and that also makes a ton of sense um but yeah building something from scratch I think is just going to be very very difficult um and so yeah I think actually Robbie your point around the op chain thesis um I think I I'm actually very much in

agreement with it and I think it like kind of supports my point that's how I see like the future of customized DK playing out cool makes a ton of sense well guys I think this is a good place to to wrap um this has been a really fun and uh I'm glad that we were able to uh talk about ZK with uh two people that are very well versed in the subject so thank you so much for coming on and uh sharing your thoughts this yeah I just want to add uh I hope that once uh Von Rishi comes out of stealth with what she's been building that you guys can collaborate as well I think there's going to be a ton of cool ideas that can come from from this um and it was a pleasure to have you guys on cool yeah thanks for having us yeah

this was fun thank you guys for having us um yeah