zkVMs vs zkDSLs

Transcript

I'm Alice from H ZK really excited to moderate this debate between Uma from succinct and also Zach from Aztec um our goal today is to really try to flesh out the advantages and then also the limitations between these two approaches ZK VMS and ZK dsls and really help uh members of our audience uh navigate through these kinds of trade-offs um and see which one is more suitable for your needs depending on what you're trying to build s sorry to be interrupting don't think I don't think the microphones are on oh um yeah no worries

sure I could also hold it is okay okay yeah okay sounds great all right so I'm wondering if we can first start off with maybe some of the advantages that come with both approaches so if Uma if you want to speak of some of the advantages that come with ckvm and then um Zach if you want to speak of some of the advantages that come with ckds cs um and then also address some of the limitations that come with each approach um yeah I can start so for a zkm what is a zkm um basically what we're building it's a think is a zkm called sp1 where you can just take normal code like rust it gets compiled to risk 5 which is a pretty standard instruction set and then we can prove

the execution of any risk 5 program so I think the biggest benefit is that the developer experience is like as it similar or the exact same as normal programming like there's two million developers that know rust um there's probably like hundreds of people that know like esoteric ZK languages and stuff like that so it's just like orders of magnitude um better developer experience and then another benefit is that there's so many libraries and tooling built out in Rust already so for example the Json Library the thir a library uh even like node implementations like ref and Revan or even light client implementations like tender that are all written in Rust and now you can get all of that tooling and library for free basically um and that's

what I see is like the reason why I think ZK BMS are just going to like dominate all of ZK for the next you know or for for like basically the rest of time yeah hey so um yeah uh I guess I I'll I'll represent the DSL side now um so azik DSL is one where you have a um a bespoke programming language domain specific language that compiles down into aziki circuit and the big difference between that and a VM is for a Zeki V VM you have one basically one circuit one proof system which will um which will simulate a virtual machine um and verify program Trace whereas with a DSL you can directly compile your program into like the most optimal um

constraints for your um for your proving system uh the reason why we went down this approach with Noir is because um with privacy with a focus on privacy it's important to be able to prove um your statements locally on very limited Hardware so you know phones old laptops and there you have some severe resource constraints you have resource constraints particularly with regards to memory as well as computation and so the the efficiency that you can leverage from directly transpiling your program statements into constraints without going through the VM exraction for us is extremely useful um the way I think about it is uh well for to say that I'll go I'll go

with some of the some of the downsides which is I think what um is kind of mentioned all the coroller to which is that with Noir you don't well what it's it's pretty easy to program and it's rust like it's not rust you don't have access to this existing ecosystem of um of software and libraries and so the question about whether that's acceptable I think it's very much depends on where on the tradeoff space you are um because and again I think what's quite telling is um uh with sp1 and with Aztec like they're quite we're quite we have quite different focuses where sp1 correct me if I'm mistaken the the main focus is on computational compression basically can

you take a very very complicated statement um and um prove it a construct a proof that can you can verify very very efficiently so that you can you know do things like scale blockchain or um you can have a very you can have an untrusted um prover um with with a lot of resources they used to prove a statement that you then verify on a with a trusted entity that has very few resources um which is a blockchain basically uh for privacy things have the things are very different because if you're building a private transaction layer like Network like uh Aztec the um the programming Paradigm is is very

is quite radically different you have you're working with encrypted State models specifically and the having to manipulate an update private State it's quite challenging you know you have nullifiers you have utxos and we wanted to create a DSO where you can provide semantics that abstract away that complexity have that kind of that ability to fine-tune that um and similarly like I think um what we're doing with Aztec very much mirrors what's happening happened in the web 3 ecosystem where solidity for example wasn't a par wasn't much of a barrier to ABD Doctrine to blockchain for um if anything quite the opposite uh historically blockchains with programming languages that are exactly

the the same as existing ones like rust don't seem to have a huge amount of uh like um value ad compared to ones we have to learn in new domain language like solidity because basically there's already so much to learn if you're writing a smart contract coming from a programming background the actual overhead of actually of learning a new language is relatively minor um because you know if you if you um if if you have a bug in a solid smart contract you know you lose you can luse millions billions of dollars it just it's a very different model to regular programming so anyway that's a very long-winded explanation but the the Crux of it is um resource limited if you have resource constraint and you need to maximize all available performance compiling directly

into constraints will create a faster proving will create a faster um PRS than running through a VM so as Zach you mentioned that ckds CS may be more advantageous if you have those kinds of limited resources and um Uma you mentioned that the developer experience is um going to a lot more simplified when using a ZK VM I wanted to dive a little bit more into the developer experience part I know that both of you both Aztec and succinct is focused on trying to abstract those cryptographic complexities away and having the developer really focus on the logic behind their application rather than just writing the circuits directly um but just wondering what is really needed for a developer to build their ZK application in both the short and long

term um how I personally see it is that ZK VMS can be particularly really useful when a project is about to um like when they're trying to bootstop um their product but then maybe later down the line uh when they're focused on optimizing for performance maybe zkd cells can come in so wondering about how the developer experience would be uh affected in both the short and long term and maybe some differences in terms of the um incentives that are offered on ZK VMS and then also on ZK dsls I guess I maybe kind of disagree that that um people are going to move off of ZK VMS even as their project becomes more mature and I think okay for example let's look to AI where today a

lot of people bootstrap their application by using like the gp4 open AI API but actually a lot of them don't end up moving off because it's actually hard to like train your own model to compete because the model itself it has so much going into it it has you know so much optimization has so much data that it actually you it's very hard to compete with that by doing something yourself and I actually think the ZK VM Paradigm is really similar so even earlier I was like talking to a team where they had built their own ZK evm from scratch like a circuit for it and my understanding from talking to him briefly is that their costs aren't even competitive with running ref and revm in sp1 um and that's actually like really

surprising for a lot of people cuz for sp1 it's like the developer experience is so good right you can just stick ref um a rust binary in sp1 prove it and it's the developer experience is amazing and it's also really cheap and fast so it kind of feels like you're getting free lunch in some sense because it's just better in like every Dimension um but I think the intuition behind that um once you like dig a little deeper into it makes sense basically with sp1 it has like such a good Paradigm for programming where it's this platform where because it can support any rust code uh it compounds like a lot more than hand writing circuits for a bunch of different applications and like doing custom optimizations for a bunch of

different applications and in particular there's something in our approach called pre-compiled where we actually get kind of like the 8020 of optimizations uh with with this approach which I'll go into a little bit I believe Noir also kind of has like these pre-compiled circuits in a certain sense like for your big RSA stuff uh we have some custom Gates I wouldn't really call those pre-compiled though um but slightly different ways of expressing constraints oh I see um I I think I remember that I saw some Twitter post that you we have a VM which could be considered a pre-compile but it's not really part of the the Noir um cryptography engine basically if you want to do recursion fold and Aztec then

we defer we delegate expensive operations um to the very end of your transaction um like life cycle where we then prove those with a custom uh virtual machine which could be considered a form of pre compile oh yeah it sounds maybe somewhat similar to what we do but basically for our case like let's take a really illustrative example so for an ethereum block if you just run it in like normal risk 5 it's around like two billion risk five Cycles which is quite a lot but we have these like specialized circuits for ketak uh for sep 256 K1 signature verification for Shaw 2 and a bunch of other things and if you use these custom circuits with sp1 and we have this architecture that lets you kind of inter leave like normal instructions with these custom circuits

you get down to like 200 to 300 million Cycles so that's basically a 10x reduction in the amount of net prover work and I'm being a little imprecise here but you can roughly think of it as an order magnitude reduction and you can see that like from this approach we kind of get the biggest benefits of custom circuits while still being able to maintain this like developer flexibility and I think that's kind of the intuition why it's actually really hard for another team to compete with that because if they did a bunch of custom circuits well first of all they'd have to recreate all our custom circuit for KET and sha and all that stuff but imagine you did that uh then if you want to custom circuit all the other parts it's you're only getting like a small fraction of the gains because we already

got most of the gains from like our pre-compiled that are the most commonly used so I think that provides an intuition for why I actually think projects aren't going to move off of ZK VMS and instead they're going to always continue using zkm um because our team's also always focused on making our zkm better and it's really hard for another project to like keep up with those advancements um in general could I could I touch on that cuz I feel like I want to push back some against some points there because what you describe that process of like the other team building in ckvm and not being able to compete against sp1 where I see what I see there is just you have a what you're describing is your moot against other zbm which I think is slightly difference to um like

the like compe competing against the ZK DSL approach um and I think it's also it's quite difficult to to what I'm going to talk about is quite abstract because right now today I feel like the the space the ZK space is still extremely immature and underdeveloped compared to what it's going to be so um what I'm going to talk about doesn't exist today but I want to project a few years into the future maybe 10 years where um I feel like the pre-compile approach kind of is going to be my prediction slightly problematic because uh basically the the The Brute Force risk 5 approach um when you want to do when you want to run Pro complicated

programs right like it it there there it's it's not optimal um this is why the pre- compiles exist um and but the pre-ms you talked about they exist for ethereum right so if you want to verify an ethereum block using sp1 great you have promil what if you want to do something else you know what if I want to verify a machine learning algorithm what if I want what if I got some like really complicated a trade matching engine that uses some like weird uh like weird algebra what if I you know um uh I don't know what if I want to run like the like if I want to verify that uh my nuclear reactor software is like is is is is running properly basically the more the larger the industry gets the more complexity you're going to get the more diversity of applications you're

going to get and the harder it's going to be to maintain pre-compiled to make sure that the VM will always remain state of the artart um you know I would have a lot more confidence that VMS will dominate if the VMS didn't need pre-compiled and there's a there's a question there's an open question about will that ever be the case um quite possibly uh you know like the way the space is moving quite possibly but I think it's a little too early to say um here's what I want to like like discuss or think about like um what we're seeing in the space is you know it's growing there's a lot more like capability to handle complexity right now the limiting factor generally if you're trying to do

something in this space is like the is developer time because you know good developers they are six figure salaries easy six figures right and so you want to you need to minimize the amount of time you're spending executing and so VM abstraction is fantastic for that you know you build your V your your your virtual machine that can handle any program and then you can focus your limited developer resources on optimizing that VM and then um companies Downstream from you they can just use your VM uh and I think that similarly this is kind of why I think um the dynamic for why like um VMS proliferated in the in the real world right because if I want to um uh you know who who writes web apps in C++ um or even rust right because just the the different

compilation targets for all the different devices that you're executing it on it's an absolute nightmare it's much easier just to say Okay Chrome Safari you handle it you write a JavaScript virtual machine I'm just going to code on JavaScript um but uh what's going to happen longer term as effectively the more people come into the space the the contentious resource stops becoming developer time right because the products are more uh like the products have larger audiences they they generate more Revenue the value you gain in extra performance outstrips the resources that you're willing to that that that will cost to pump into it to get that performance um I do think there's going to be an inflection point somewhere where

basically uh like what if you had arbit if one had arbit resources right you wanted to make a maximally efficient CK system what would you do well you would take uh a language like rust um and you would write your own compiler right you would replicate all of the like work the 20 30 years of work that's gone into clang um and lvm and you do it all again from scratch and you would write a compiler which compiles down into an intermediate language which is optimized for ZK circuits and then that compiles directly into optimal constraints now that approach if one could build that it would blow the zkv out of the water uh but obviously what I'm talking about is um requires a lot of developer resources that no no no sane person is willing to

to to invest now because it's just not not worth it but I would wager that the if if we succeed like the Happy path is if this industry succeeds and ZK becomes like eats the world then that is exactly what's going to happen yeah I I guess I'm pretty in agreement there that maybe one day there will be like a compiler layer um um that gets written uh but I think and it sounds like maybe we are even in agreement that the general purpose like front end that's like normal code well is here to stay um but I guess I don't see why like we can't even write the compiler like once we're once we have like more usage and then we're like oh yeah now the next part of the stack to optimize is the compiler layer um yeah

you could but it wouldn't be a zkm then um uh yeah yeah like I guess I got very technical level um totally but then it has like the property that most people care about as zvm which is like oh I can just write Russ yeah so so you're talking about like natural languages of ssds SLS there which I think I do wonder I think it depends on what it's used for for for for if you if you if you're doing com computation compress absolutely like nobody wants to learn a new language what's the point I do feel like for if you're caring about privacy right you want to like see you're building some application where you you know you have a client you have

a server and that and you're and you're hiding you're hold and the client is holding back information from the server and sending proofs of knowledge instead then things get a lot trickier because existing progam languages don't don't really have semantics or heris that kind of like make that easy right like no one's no one's like designed it like that and okay sure maybe you could write libraries to do that but well I mean you definitely could write libraries to do that but the more your programming uh like environment depends on those libraries and that and that and the interface in the API a the more commerson things become and be the more the less your program looks like a rust program the more it looks like something else entirely um and I think for for Aztec because we our focus is very much

on programmable private smart contracts because the smart contract programming domain is so weird and unique the execution environment of a of a of a of a blockchain is so unique um we felt that you know if we did say you could write if we like imagine we wouldn't we couldn't do this just because the performance wouldn't be good enough for client side but let say we could let's say we say okay right you can write your rust code and we'll turn that into a proof that you can prove locally the amount of like Library additions and and weird extra extensions that you would need to to actually to to to handle contract semantics to handle private state to handle storage would be so high that really like that would be the majority of your code at that point and so it wouldn't really be rust anymore um

I guess doesn't like so Solana has like a rust front end that then compiles to ebpf and then they have their own libraries of like their own six canonical smart contracts that they expect people to use so I guess why do you feel like and clearly they're like pretty successful so I mean they're successful yeah but I also think that like programming son was not really like programming rust I mean so yeah totally I wouldn't say it's a deal breaker it's just that it's not you lose the value ad if I think about salana I don't think Solana's value prop is I can write my smart contracts and rust the value prop is it's FAS and it's and low latency is cheap um yeah but I guess at the same time you still get nice like the cargo package manager like you you still like

you your ID like you you know recognizes you know chose rust analyzer and stuff like that so but I do agree with you that that's definitely not Solana's main value prop is oh you can just write rust um because it is a really different Antics in Paradigm and you have to understand so much stuff but there is I think some non-trivial benefit to all of the tooling that you can get like cargo is pretty nice you know crates iio is pretty nice like all that stuff is pretty nice yeah you're you're right about that and there is a there is a tradeoff there and you know like it is very hard to build a good package manag like cargo it's very hard to build like good formats good language servers uh but AI like but but that can I finish but like you know not team is

pretty stacked cuz we have all of that and we got profilers and we got uh like Nago is um I keep okay sorry I'm Shilling here I'm going to sh up a little bit I'm always Blown Away by Nago and it's and like just how easy it is to um uh to just to to update to the latest version to modify versions basically like to to pull pull down libraries other people have written um yeah I know I'm Shilling but you know I wasn't involved in that part of uh you know I'm like I operate at a high level of a stack these days so just when I was writing Mar code last week and going hm I how do I like update to the latest pre-released to get certain weird supports it was really easy I was I was expecting about like 2 hours of work

installing weird libraries um so yeah tuning is a big deal and it is a pain in the ass to recreate it all from scratch I guess also the AIS these days have been trained on like mountains of rust code and stuff but but maybe you know you can uh get them to train on mountains of Noir code too yeah it's surprisingly good actually um with with with the rock code um but also I hate to be like a a cynic or like a kagin but I also feel like when it comes to Smart contract programming um I would worry about AI you know if you're like write me a solidity smart contract like to do a DEX you know like that's uh you're going to be getting an digital knock on the door door from North Korea I

think but I mean you to push back on that a little bit you can also have like the AI Auditors like audit my decks too and like for example they've seen like so many validity hacks and um bugs that actually we I was trying out 01 Pro recently even on like some of our own stuff and it it was pretty pretty good yeah um at detecting things yeah I agree with that um but also like if that was something to we we could optimize for we probably choose solidity as a taret language not rust because because of the the training data on like all the hacks that cost lots of money are on ins solidity um so I this is a big Tang I find it like just beautifully ironic right that like um

solidity as a language is very very insecure um is then if you were going to design a smart contract program language from scratch knowing what we know now like Gavin would did a great job back in 2014 knowing what he knew knew but no would know now you wouldn't dream of doing it nevertheless if you're going to write a smart contract today like the safest language to do it in is solidity just because of the sheer amount of knowledge that we've attained about best security practices that have and that knowledge has been paid for in uh in in in in in cach uh through through all the hacks that have happened um but yeah I just find it finally that city is kind of the safest language to write smart contracts in is yeah so we talked you guys both talked a bit about performance

about tooling about the developer experience um I'm very curious to hear more about the security side so in adding more of these um abstraction layers on top of circuit building does this potentially introduce any kinds of new security vulnerabilities or does adding these abstraction layers maybe reduce the number of bugs that a developer May unintentionally write I think with both Noir and a zvm it actually helps the security situation quite substantially because instead of having random developers apin whatever circuits that they came up with that month and like shipping you're you basically have a standardized interface and then uh the security critical code is all in one repo it's all in one place

it's maintained by like uh highly competent team it's reviewed and audited many times the security compounds over time so I actually think both ZK VMS and ZK dsls are like a huge huge huge Improvement than developers rolling their own um ZK yeah yeah writing your own ZK circuits is is uh someone who's done it it's um you can do it but it's it's uh you're going to have more bugs than if you use an abstraction layer um you know um as much as I'm I'm supposed to be repping my side I do hear think here the ZK VMS actually they are easier to secure uh because the the attack surface of part bugs is is quite is the is smaller um take a z DK ZK DSL like uh

you have unconstrained functions right where because often um performing a computation is more expensive like well proving a computation is more expensive than um verifying the computation like the classic example is if you want to like validate the one xal y divisions are expensive right so what you do instead is you check that x * yal 1 um uh and and that basically means that in in in no you can you can use unconstrained functions to generate Witnesses and then constrained functions to um to prove that the the output is correct um which basically means you can you can you you you exposed to the underconstrained class of bugs which you don't get in a VM um and that class of bugs is quite large uh so again I think

it's one of these things where you want you want to squeeze out performance there's a trade-off space the more performance you get like the the the less the abstraction layer is going to hold your hand and the more um you can shoot yourself on the foot so I feel like there's a kind of like hierarchy where if you're writing your in circuits you know you're you you're you're playing with a a loaded shotgun with a hair trigger in a safety um and uh you know zsl a lot more secure um you know you as as said you know the coal one place you know you just verify your Noir code um you trust that the the the actual like no compiler and the back ends are all being like audited by the best people in the industry um like the surface that that that where things

can go wrong is much smaller but I do think zkm as as well as uh it's probably a little easier um to validate your code got it and in terms of some of the future use cases that were anticipating like um a lot of projects in ZK space were anticipating near realtime proving sometime in the future there's a lot of talks about stying ethereum um and then I know both succinct and Aztec is really in terms of use cases really excited about for example private voting um now empowering these kinds of use cases um for the future is there an approach that you both personally believe may be more preferable over the other or do you anticipate maybe a combination of these approaches being used depending on the

type of use cases we're thinking about I guess I think in the next like year or two there's actually a really clean um place where you should use ZK m versus a ZK DSL so for example I think if you're doing client side proving in the browser or in your phone like I will be the first to admit Noir probably crushes us um because like sp1 performance is really like we run it we get a lot of great performance from like gpus but like your browser doesn't really I mean they don't really have that they have like web GPU but it's not really there or like your phone if you have an Android phone like it's just a really hard situation for sp1 to perform well so I think there's a really clean divide it's like if you want it on a mobile device or for your browser use

Noir if you want anything else I think sp1 is really great and I I feel like all the use cases you guys are targeted are actually like oriented around those um like those uh environments for proving so it's actually I feel like in some ways we actually like don't even disagree um on where the people should use one or the other I think for example for Real Time ethereum improving I mean that's like one of our biggest use cases that we personally at our company even care about and so we're really focus on optimizing for it from our pre- compiles to even like optimizing the rust code that lives on top to even optimizing like the parallelized proof generation across a bunch of Hardware um so I think that will be a clear winner for that use

case just cuz like we're so focused on it and so focus on that and roll up workloads um whereas I I don't imagine that you guys are thinking about or that focus on that kind of stuff on real time proing yeah no no I hear all the cheddar about it on online and I and I just get very jealous and bitter because uh basic yeah um you know what you were saying like with with when you when you're doing computation compression right like you can you can just you can hit the scale button right like you you you know you focus on making your code as paralyzable as possible crushing down arm's law and then you just scale scale scale scale scale um where client side proving you can't scale maybe you could get the user to like to like prove on their iPad and their phone at the same

time but uh um and so it's it's a much tougher challenge um certainly like realtime proving client side isn't happening anytime soon um uh that being said you know it's the the end goal for something like azc is to get we the end goal is to get to web to style of user experience where things just do happen um but I do suspect um in the me medium term that's going to require uh computation delegation so basically like you get a third party um to prove for you so either a trusted execution environment or an empc set up like tat SEO um uh cuz yeah real time on the client side isn't isn't happening anytime soon unless you just want to

prove a Fibonacci Sequence um but yeah I think I do think that the the distinction is is fairly clear clearcut like you know um like you can see in the difference about cryptography um engines right like we don't focus on gpus it's purely CPU cuz there's no there's not much Point um eventually we'll get around to webg but G web GPU is yeah it's it's it's a bit underbaked um needs needs a bit more time in the oven uh and um uh yeah if you know if you if you don't need privacy if you don't need the like handle private State semantics um and you don't want to improve client side then um you know uh Noir won't be the fastest solution for you um if you

have gpus at your at your disposal to proof um um so yeah I do think the distinction is fairly clear for now I do think that there are some interesting alternative like interesting future paths I do I do think that the direct compilation path is going to eventually become dominant but it might take a lot of time because it requires so much effort to basically build compilers from scratch um uh I also think another big advantage of DLS is uh the fact that it creates an intermediate representation means that it's a little easier to decouple the execution environment from the proving system because the proving systems are like cryp like it like everything is the the pace of changing

in cryptography research is so fast that everything obviously in six months um you know I would love to like completely revamp azc cryptog is a state-of-the-art but you know that would add like I don't know like 18 months 24 months to our road map to release so we're not going to do it um but the the power of things like nor is that because it compiles down to an intermediate representation you can swap in different cryptography um proving backends uh which means it's it's possible to to kind of like Outsource keeping up with state of the art uh to the entire Community you know like we have there's um worldcoin for example that building a backend fenir um using some like crazy Prime field stuff um um so there is that Advantage um uh I do think that once there's a bit of

maturity in the ecosystem right let's say we have zvm that deployed they're AED mature they're being used in production by a lot of systems then there's going to be a problem where um you know you skip forward two years and now that zkv improving technology is like 5x 10x slower than the new stuff and completely revamping a zvm um to use new cryptography is going to be a harder thing to do than um than using building a new cryptography library and then proving um an intermediate representation um although both are very hard so yeah and just as a kind of like a last question before we close um I'm wondering for both approaches uh what sort of new Innovations are needed to

enable for uh both ZK dsls and ZK VMS to be uh more performant in Industries even those Beyond web 3 and then also if you have any um kinds of advice you'd like to give to anyone in the audience who is trying to uh navigate these different trade-offs I think there's still a 10x to be squeezed out of the stock from proving system improvements better C engineering across the stack and just overall optimizations um so and it's it's not like I mean yes it's difficult but it's not like rocket science like I think all these things will happen and that's like what we're focused on so I think if you combine all these things like a 10x is you have to do a 2X like between three

and four times and there are 2xs everywhere uh you have to remember that even with sp1 we launched it like one year ago and so even in the past year we've improved its performance by like 20 30X um and we're still learning new things um every day from like op profiling performance and optimizing so yeah I think 10x is very easily still on the table I think the next 10x after that will definitely be like harder um but we'll cross that bridge when it comes I guess um in terms of advice I think ZK especially with ZK VMS I really think ZK is like now moving out of like the research phase into more of the adoption phase and I think a lot of the ZK builders that I see they love like

doing stuff that's hard and and maybe you even see this with the Noir where they're like oh I want to work on the circuits like oh I want to move work on the proving system um and that's really cool but I think ultimately to build a product there's so many other parts of the stack that are really really difficult for example like go to market or like making a great product or like think getting users and Stu like that um and so I always encourage Builders who are like excited about building with ZK being like okay now that for example ZK VM or Noir have like made ZK easy you should take that as a plus and focus your like huge amount of IQ points on like all the other hard problem that might not be as like sexy but are actually like the key points of Leverage

in like building a product and a business cuz like ultimately that's what that's like the phase crypto is more actively moving into and I think to take ZK mainstream like that's really what we need is like people who are very very focused on product and adoption and now that ZK is easy we have the tools in our toolbox to make it happen so yeah that's kind of like my advice to builders yeah I mean I agree with that completely uh you know aex roots are are in um a startup called credit M that's what I originally started it was trying to do tradire on ethereum but we couldn't because we needed privacy we wanted to build a product that we we knew had like um there was a market for that that where where where we could

beat the incumbents on price but we couldn't we didn't have the technology so that's what we basically we spent the last seven years building that technology so that you can you can do um you can like web 3 can compete with web 2 it can compete with fire can provide the same kind of guarantees that people expect so um yes uh uh you know I would love it if people in this room like use that technology to try and build compelling valuable products um Noir S1 they are means to an end it's all that's all they are they are means to ends um you know I hope like if we succeed our Technologies both of them are going to become commoditized and not considered very important in the same way like we don't consider clang to be very

important but if you got rid of clang right like and GCC and all the all the compilers right like you know we're all we all can't work um but uh it's just you know it's it's Bas level infrastructure um uh so yeah you know I think I think right like 2025 is the year for ZK is the year for privacy where you can actually where the design space of a smart contract is now being exploded you can you can meaningfully um prove things about yourself on chain that you that that you couldn't before know things about like your identity like Z passport you can do payments like with the open banking API you can even have private shared state with tat SEO um and and they're NPC Prov uh you can you know you can do you can do defi

where you can have some kind of basic compliance regimes if you need them you can touch real world assets and hold them on chain without revealing that to people without revealing the the the the the ID checks you have to go through um you know you can do you can broadcast anonymously on social media the design space of what you can do in web 3 has shifted fundamentally and it's still today very very hard to build products using this new technology because it's still absolutely bleeding Ed Aztec isn't even testing it yet we're soon we're soon really soon but like um you know and like Noir is is going to be audited you know this year but it's not yet been so you know it is still early stage but but the the tech is here you can use it and actually build today and that's that's

something which I have desperately wanted for seven years um so yeah uh um yeah ZK good no good and in the spirit of the you you know um being a good host sp1 is also good no it is a very impressive piece of technology really impressive yeah absolutely so it's really exciting that we're as what you mentioned Uma um transitioning from that research stage to more production ready uh systems we're able to build real applications and what you mentioned Zach kind of seeing a shift within that design space and now we're see more of these uh privacy preserving applications being built so we're indeed in a very exciting

time um appreciate both of you for um joining us on this debate and hope everyone in the audience um took away something in terms of like navigating through these trade-offs between ZK dsls and ZK BMS definitely a lot of opportunity in both spaces so thank you so much both of you thank you thanks for having all right amazing so we have time for just one or two questions if there's any questions in the audience please raise your hand I'll bring the microphone and and then if you could please keep it brief because we're on a on a schedule um and thank you so much for our panelists and our moderator um so any questions for Zach or uma yeah okay hey guys great panel um my question is around what you were just saying kind

of how ZK 2025 is the year of ZK building applications on ZK but you also said you know the technology obsoletes every six months how do you kind of make it so that people can feel comfortable Building Technology on top of of what you've built in that environment hello is a very good question two things is like that's the beauty of having these abstraction layers right like it's Aztec's job well nor job um to to like to to keep up to date with the state of the art right like you don't like you don't need to change nor the language to integrate with a latest and greatest Tech in ZK so the idea is if you write your programs at Noir like like a now isn't going away

anytime soon right like we are we are committed to making this kind of Technology mainstream which means making sure that we're always up to date with state of the art um well you know as up to dat is can be whilst actually releasing stuff um which means that yeah you you write our programs today in two years time they'll be faster uh because they'll be because we have integrated the the best cryptography and the same same is true I would wager with VMS um uh oh no there was something else to that what was your question um yeah I guess you could think of it maybe in terms of like if A6 are important and how do you you know integrate things like that when they need something that's not changing but the space is changing so fast well I mean for us it it's a little bit more

straightforward because like our focus is on programmable private transactions right blockchains um which means proving client side and I don't think A6 are coming into consumer Hardware anytime soon so yeah well like at least the Aztec Foundation is probably not going to be like spearheading a drive to prove n A6 it might happen you know it's it's an open standard somebody else might need that uh but generally I think if you're building if you're building an application or product right like your execution environment should be relatively like static as in we wouldn't ask any of our any people using okay now you need to buy A6 to proove um you know uh we're always of the mind that like you should be able to prove no in a

CPU yeah I think the exact same thing applies with sp1 like now Builders can you can just write normal rust code um if I don't know the thing goes away tomorrow um well there's a lot of other ZK VMS out there that you can use and they will probably get better so there's actually basically zero platform risk okay thank you so much I know I said maybe two questions but we are out of time so uh please join me in thanking our panelist and moderator thank you guys so much