ZKPodcast: The Arkworks SNARK libraries with Pratyush Mishra

Transcript

[Music] welcome to xero knowledge i'm your host anna rose in this podcast we will be exploring the latest in zero knowledge research and the decentralized web as well as new paradigms that promise to change the way we interact and transact online this week guest host robert habermeyer and i chat with pratush mishra about arcworks an ecosystem for developing snarks and developing on top of snarks but first i want to remind all of you to subscribe to the zk mesh newsletter

it's a monthly newsletter that looks at the latest in decentralized privacy preserving tech privacy protocol development and xero knowledge systems research it's put together by myself and mccarra be sure to subscribe to get this delivered directly to your inbox at the beginning of every month the next one comes out in a couple days i've added the link to this in the show notes i also want to thank this week's sponsor leased authority leased authority is a security consulting and product development company known for pushing the limits on how to build privacy respecting solutions they are a team of security researchers open source developers privacy advocates and cryptographers they are firm believers in the protection of people's privacy but they also believe that privacy tech should be easy for people to use

leased authority has developed an end-to-end encryption cloud storage product that minimizes the collection of any data related to its users this is called private storage private storage implements privacy and security by design not by policy it's based on tahoe laughs an open source distributed file store the product is launching in the second half of this year please visit privatestorage.io to learn more and to sign up to be notified about its release so thank you again leased authority now here's our episode all about arc works [Music] so today guest host robert habermeyer and i are going to be chatting with pretoge all about arc works so first off welcome

back to the show rob thank you anna glad to be here and welcome prateuge it's also your second time on here yeah thank you so much anna yeah it's great to be here and uh yeah looking forward to the podcast with the two of you cool so rob you've actually been on you're you're a two type guest but this is the first time you're gonna be co-hosting with me there are episodes that i can link to where you talk more about the work you do but i think it's worth it for our audience for a quick intro to you who are you what are you doing well my name is robert a lot of people call me rob i am the co-founder of polka dot network i've been working in rust building blockchain software for the for almost five years now um yeah that's all the important parts cool

what you just described as some of your bio kind of explains why you're the co-host on this particular episode because arc works is a collection of rust libraries and i thought it would be really great to have an expert here with me in talking to you pratice now pratush you've been the last time you were on the show you were actually on the show for a whole conversation about the sexy construction and we talked kind of in detail into that we've also since then we've done study clubs with you you spoke at the summit this past online summit in the fall but i was thinking maybe you could tell us a little bit about where we left you with the sexy curves to now what what have you worked on and what is arc works what's kind of come out of

that yeah last time i was on the show i was i guess still a second or third year phd student so still quite fresh but yeah so my main project of the time was sexy which is a system for doing private competition uh in decentralized ledgers and as part of that paper we developed an implementation for our construction and that implementation required us to you know do all kinds of uh snot related uh implementation so we had to implement the lowest level the elliptic curves and the finite fields and then on top of that we had to develop the actual stocks themselves and then write constraint systems for these snacks and then finally you know implement this xe construction so we this code we

we started developing it using an initial fork of sean bowe's bellman library so howard who and i we forked that code base for to you know expose a few more knobs that we could fine-tune for our construction and that sort of code base has eventually over the course of the next few uh i guess the past few years uh evolved into uh the artworks ecosystem and so now artworks is an ecosystem for developing snacks and developing on top of snacks developing applications that use snarks and it has seen a lot of contributions not only by me and howard but since then a lot of contributions by students at berkeley who've done excellent job like implementing new protocols and

implementing new applications um inside the artworks ecosystem as well as from outside contributors in from zcash folks from cello folks as well as alien folks or like a lot of different people in industry have contributed to the artworks ecosystem i just remember we've done like study clubs on the xc paper originally this was basically an academic paper as i understood it and there was a sort of there was an implementation but it wasn't necessarily the focus of the work like it was sort of something that could be implemented but now since then it like are you saying that you've shifted most of your focus just towards the engineering side of this to build out those libraries so that it's an implementation that could be used or is

that something that was already there with sexy that's just evolved yeah so the i guess the zexty specific component of that original code base was i guess not not even like the the largest part of that code base it was mostly just as i said like the elliptic curves and the snarks and maybe the constraint systems on top of that and then finally we put together all of these you know modular components and we got sexy and the part that the past that were reusable for other research projects were these lower level components the curves and the snarks and the constraint systems and those are the parts that we have since developed further i i don't spend all of my time on it but like a significant amount of time me as well as a lot of other students

at berkeley as well as external contributors have spent in improving the code base and yeah now it's used not only in our research projects but also by other projects in industry so i think cello is using the curves that we have implemented there as well as i believe mina has they're using a fork of our code base so it's exciting that the work that we started you know just to basically show that our idea in sexy was feasible and you know not just theoretical that has sort of evolved into something that a lot of people contribute to and is now useful for a lot of people so coming back to that point that you just raised about like the the practical versus theoretical

uh where do you see arc works fitting into that is it more something that you see people using later on uh when they're implementing protocols that have already been described or do you also view it as a playground for work on the research phase right so i think um i guess the nice thing for uh like when you're working in the zero knowledge space is that these lines are often blurred so for example this is not my personal story but what i believe i think sean beau said when they were working uh started working on the halo paper was that he started implementing the bulletproof protocol and then he noticed some curiosity about its structure and that that led to the whole halo approach which has since spawned a lot of research papers so i think like this you know research

by tinkering with code is definitely something that is possible in the zoo knowledge space and i think our goal with artworks is to not only support i guess production-ish use cases like towards the end of your research pipeline but also during uh research itself and i think we do take this approach like within our research projects we try to accompany them with like when we're writing out the constructions we try to you know have a map of how this would look in implementation land if you know it's implementable and often that translates you know straightforwardly when you're actually implementing code so like one of the goals of our code base is to make sure that you know when you start off with

a description in a in a you know science paper going from that description which is high level to go to code it shouldn't like require too much thought on the part of the implementer it should be easier to get like secure and performant code so yes i think we i guess to answer your question yeah we do aim to support both kinds of use cases because it did originate as a research code base you sort of mentioned that it's not the only thing that you actually work on what else are you working on right now as part of your studies right so i guess since the since a sexy paper like what really that spawned was that what i found interesting was that it left two sort of open questions and the first was that in sexy like for

the sexy model to really work out you need two efficient components uh one is that you need to be able to do proof recursion you know efficiently because one of the key i guess components or ideas in sexy is to recursively check some proofs of computations within a within a particular transaction and the other one was you know we are making snarks for specific computations you don't want to do a trusted setup for and so you want to be able to do just one setup and reuse that so that sort of these two questions spawned i guess my research in the zoo knowledge base since on this you know updatable or reusable snark i worked on marlin with alessandro and uh you know a bunch of other great authors

and uh on the recursion front i've been working on some follow-ups to halo uh which are yeah we put up online last year and i think there's going to be a zika study club about that uh hopefully soon as well um no totally yeah and so like for both of these we did try to implement um our our protocols and we used the artworks ecosystem for that that actually that that's sort of a main question i have about arc works is what is it exactly like you're sort of saying now you've used it to implement some of the research that you're going you're doing going forward but like is it a language is it a i don't know is it in an environment

like is it just a collection of libraries this is this is a i mean we've had a few projects on the show where we actually like spoke to them about the work that they're doing if they have these languages and i still don't entirely understand where artworks fits in so maybe you can help me like maybe understand the landscape and where arc works lives yeah totally so artworks is basically a collection of truss libraries for implementing snarks and working with snarks so what that means is that you know snacks have a lot of underlying components as well as you know when you're building applications on top of snacks you need to build some infrastructure around that so the point that the goal of artworks is to make that infrastructure all modular and able to work with each other

so for example if you want to implement a snark you need to you know have implementations of elliptic curves maybe you have to have implementations of pairings you might need to have implementation of you know some finite field uh ffts and so on and what arc works aims to do uh maybe on this lower below the snark level is to make it so that these components you only implement them once and then you can reuse them across different snarks or different implementations of snacks so for example all of the algebra infrastructure which means elliptic curves finite fields ffts is shared across our implementations of the gross 16 snack the gross malar snack and the marlin snack so all of these share the same infrastructure so you don't have to implement it again and

again um and then like so once you you know have your snack you want to build applications on top of your snack and so on that front like above the snack in the stack above the snack we want to make programming applications with snarks easier so we have infrastructure for writing constraints and making that ergonomic so one of the things i'm not entirely clear on what arc works is i've i've sort of tried to understand it as like a collection of libraries but i wondered if it sort of falls into the category of a language i i think it would be really cool to hear from you how you place it in the landscape of the different projects that are trying to develop something similar so artworks is a collection of rust

libraries and the scope of artworks is somewhat broad but there's two primary i guess categories are two primary audiences one is folks who are implementing a very low level cryptographic protocols so you might think like you know a snark or a signature scheme or some other low-level primitive and the other audience is people who are implementing applications on top of snarks so you know people who are writing maybe circuits uh for you know dark forest or something so that's the uh like maybe the next audience the people who are not necessarily very intimately familiar with the low level workings of snarks so for the first audience the protocol implementers

what arcworks aims to provide is a collection of coherent libraries that can be reused across projects um so for example we have a very modular implementation of the algebraic components that you might encounter in protocols so for example elliptic curves finite fields fast fourier transforms these are all very core things for implementing snarks as well as you know some of these are useful for implementing signature schemes and so on right and the idea for arcbox is to make these things very reusable so you know you don't have to re-implement the same code again and again as an example our implementations of the growth 16 snack as well as the groth malar snack and the marlin snark all reuse the same

underlying uh elliptic curve and finite field infrastructure so there's no code duplication there okay so that's the first audience you know we aim to make their life easier for the second audience our goal is to allow people to program snarks in a way that's you know very close to programming just natively writing your application so for this we've developed this infrastructure for writing constraints which can be you know used to implement the the snark inside that's used for dark forest or for sapling or so on like whatever you know your cool snark application is and you can think of this portion as more like a sort of a domain specific uh language like a dsl

which is for writing constraints specifically but in that case would you equate that with something like circom is it comparable or do they work together yeah so our dsl for writing constraints is still i guess you're still writing rust it's just that you know we make heavy use of some nice rust features like traits and generics to make it so that you know you're still getting a very good quality constraint systems out so that you know they don't have uh like unnecessary or inefficient constraints in there but you have like all of the whatever rust offers you you can still take advantage of that um and we as i said like heavily leverage generics and rust traits as well as rust macros to try to make this

ergonomic and like you know as low effort as possible but i think it sort of still sits at a maybe a level below projects like sircom or leo or zinc or you know these other sort of socrates basically these languages which are high level and are like very just targeted at stock constraint generation so yeah we i think we sit a little level like a level below that so if i understand correctly you're trying to do two things so one is uh for application developers who want to write something that uses snarks many snarks are just going to use the same types of constraint systems and they'll just be able to write uh rust code that you know for some constraint system for

some snark it's it's it's gonna to execute the the circuit that's that's uh desired and then on the other side you create tools for people to build new uh snark protocols that those two sides of things can be plugged together and you try to reach those both use cases uh with with the same set of libraries exactly yeah and yeah it's a good point about the modularity so one thing i didn't mention was that yeah our goal is to make it so that you know you write a constrained systems once but they're not like specific to a particular kind of snark so you know i write my constraint system and then i can use it with the gross 16 snark or with a marlin snack or with a you know halo snack or

you know whatever the latest snack is it should be easily you know portable to uh like yeah the consumer system shouldn't have to concern itself about you know what what is underneath it in terms of the snark so when you write something at the higher level when you write higher level code in rust that uses these constraint systems and then you plug in a snark system like graph 16 or or one of the other ones what is the actual output is it the the rust compiler is going to take your code that's been fitted with this modular component actually produce a binary that is executing the circuit or is there some other output of the of the process uh that happens later on or earlier on

in the in this uh the cycle right so everything in in artworks is implemented as a library uh and it's as a generic library so what that means is that for example the gross 16 snark will have a you know a type parameter where you can say this is the kind of constraint this is you know please plug in your constraint system here and then i'll take over and i'll just you know call the leverage the interface of the constraint system uh to get out the constraints and then like to for an end user you do have to compile it down to a binary right um and at that point you will instantiate all of these components so you'll instantiate what elliptic curve is used underneath your gross 16 snark what constraint system is being plugged into your raw 16 snack and so basically that's when it's all

instantiated and then you get a final concrete system i see so and that can just be embedded into uh larger binaries but is is there a goal of creating sort of self-standing proving binaries or is that something that happens outside of the artworks ecosystem i think uh i goggles implement the libraries but i believe that uh you know cello as well as mina what they've done is they've taken these libraries and they've compiled them down within and stuck them like within their specific binary so that you can uh like within their larger application context and then they just call uh these library i mean whatever binaries we do implement in the

ecosystem have been mostly just for our own experimentation and benchmarking purposes but there's nothing stopping you know somebody from writing a one page even rust binary but just calls these methods on growth 16. it's very straightforward once you have your components this is like probably less than 50 lines to take in some user input and then spit out a proof on the command line i want to understand a little bit about what people would have done before there was something like arc works like there are existing projects i kind of mentioned surcom you mentioned leo you mentioned some of these other like uh socrates what were they doing if you wanted to use what they have what would you have had to do as a

like an engineer as an implementer here that's different than what you can do now with arc works right so yeah i guess it depends on your audience so so i think like socrates and zinc and leo and all of these languages their aim is to sort of provide a you know a fixed package to the end application developer so the the application developer shouldn't have to worry about oh you know what kind of proof system am i using and how is this going to be how efficient is going to be they just give you like a compiler and at the end i mean you plug in your input program and it'll spit out your final proof or your parameters or whatever right so that's i guess uh these end-to-end

systems and their goal is to provide a very high level api to users who are not necessarily like technically proficient they might be you know programmers but not necessarily cryptographically trained and then there's like a separate set of libraries and tool chains which aim to target i guess more like snark developers and protocol developers and in this category you'll find libsnark you'll find the bellman ecosystem you'll find as well as mina's i think snarky ecosystem forgive me if i you know anybody out there if i'm not naming your project but yeah so these libraries they um i guess lipsnack was the first one and it offered a c plus interface um and i guess that's the problem with c

plus is that when you try to get this high level of generic and modular code working together it can become a bit hairy with the template meta programming and template instantiation errors so since then i guess people and also because of memory safety so people have moved on to memory safe languages such as rust or ocam or go where you can't get you can still like maybe leverage i guess modern programming idioms without having to worry about memory safety and those kinds of bugs so i guess yeah bellman i guess was the precursor like the ancestor to the zexi code base and we forked it off from there just because we needed to add some more flexibility for our research purposes and since then

we've leveraged that additional flexibility to make the ecosystem more generic but yeah i mean the bellman ecosystem is still a great source of libraries uh for developing our own applications is that we took a few different trade-offs there um and oh camel and the go ecosystems i think they maybe deserve a different niche i just like programming and rust so but with the i'm curious about that connection to bellman like did you take a lot of those initial libraries and bring them in did you write everything from scratch yeah so a lot of our um especially the algebraic infrastructure so the elliptic curves and finite fields it started off as a fork of the equivalent libraries inside the bellman ecosystem basically at that point

i believe like bellman was less than a year old so there was still you know a lot of the interfaces were not maybe as fully baked as they are now since then there's been a lot of work and now they're very nice interfaces but i guess at that time we needed a little bit more flexibility and you know some more knobs to tune inside their interfaces which they didn't provide so we took their code base and an excellent code base and uh added those knobs that we could tune for our initial requirements in the xc paper but since then they've proven useful as i said i think for other projects as well but yeah a large part of the code is of this core like the algebra code is shed from development infrastructure touching on um the algebra

portion of things uh it seems like a lot of people have tried over time to create interfaces and programming language objects that encapsulate those same mathematical objects how have you found uh the process of trying to encode those things in in the rust language are there edge cases does it work cleanly so i i don't have a lot of experience perhaps with other approaches but in my experience in rust it allows you to very easily compose a lot of different objects so for example a very fundamental object is elliptic curves right these elliptic curves um

they come associated with i guess two fields or two finite fields uh one is the base field and one is the scalar field right and they have some associated uh arithmetic you know there's some formulas which go into you know add points on elliptic curves so what you ideally want to do is you want to write your arithmetic just once right the elliptical arithmetic just once no matter what kind of curve it is um so as long as you know it's a short wise rash curve i only want to implement the point addition and point doubling just once and i shouldn't have to care what the un kind of underlying field is at all right for the base field and what rust allows you to do is to just easily add a generic parameter

which can say you know so this elliptic curve is generic over any kind of field i don't care what the field is as long as it implements some basic addition and multiplication and inverse operations and rust allows you to express these constraints very easily via rust traits and so what this means is that now when you want to implement a new curve in inside arc works you can take this existing like you know one-time implementation of the curve arithmetic and you can take the existing templates for your field arithmetic and just combine these and so what it ends up being is that implementing a new curve takes just maybe he and 100 lines of code and compare this to perhaps you know

hand coding your implementation it probably you have to re-implement all of these components again and again and that would probably span over like 1000 2000 lines of code with potential for bugs and so on have you found that for the example of elliptic curves uh the people are taking libraries for elliptic curves that are written outside of the arc works ecosystem and wrapping those and then bringing them in to that same trait wrapper um so not yet i think that might be become an option in the future there are some a few paper cuts involved in that our trades do require you to you know implement a lot of sub trades so it's a

little bit of an overhead to actually implement our field and curve traits but what we do enable is that we already have uh implementations of you know some generic finite fields and generic elliptic curves so that when you do want to implement your new curve inside arc works it's yeah you don't you don't have to really worry about the efficiency or worry about redoing arithmetic but it is a goal of ours in the future to enable people to easily you know take arithmetic implemented in i don't know like the dalek libraries or maybe in the bellman libraries even and easily use those implementations with existing artworks infrastructure so that's a goal uh we haven't yet found time to

devote to that but that certainly on our radar do you give tools for people to uh punch through the abstractions if they need to if they want to rely on a particular property of a field or of a curve that that they use for optimization in a protocol right so that yeah there's always uh it's a good one there's always a trade-off between you know abstraction and often efficiency right oftentimes if you specialize to a particular kind of field or modulus or curve then you can get uh efficiency improvements right so that that option is certainly available in inside arc works so if i don't care about abstraction then i can just say okay just give me for example the

you know bls12381 curve and i'll just use that that's what i'll use my protocol so i'll optimize my protocol around that and so we i guess do allow you to do that that being said our existing implementations of like you know the snarks for example are all generic so they can't quite directly leverage those properties of special properties of elliptic curves but what we do allow is that when you're implementing the curve itself if you have a you know elliptic curve which has some special properties so for example if you your elliptic curve has very efficient kinds of scalar multiplication so there's one method called glb multiplication which allows you to speed up scalar multiplication which is a core operation um in a lot of protocols it allows you

to speed that up that operation up by quite a bit right so there's some implementation effort by contributors from cello which uh allows you to like generically sort of specialize the scalar multiplication code for uh curves which support this glv optimization so that you know when the at the higher protocol level you don't have to worry about oh does my club support glv mod optimization or not it just transparently gives you that efficiency boost so we do uh we're always saying i think our goal is to allow at each level of the stack allow people to apply the optimizations that make sense within the stack in a transparent manner so that you know at the high level of the stack

you can take advantage of it without having to you know worry about whether it exists or not i hope that answers your question yeah it does it does well i want to talk a little bit about like the general cryptographic community and their use of rust because like when you're talking about this i keep thinking like what if some of these implementations have been done in a different language but they should be included does it mean that you need to re-implement the entire thing or is it something that could actually be like shared or do you just see that most of the crypt like crypto community right now are moving towards russ so maybe it won't be a problem yeah so in my mind i think sort of rust is the perfect language for implementing cryptographic protocols um but two reasons so one thing i mentioned

earlier was that unlike c and c plus plus rust has memory safety right so which means that if i have uh you know if i'm indexing an array incorrectly i won't accidentally access your secret key and reveal that to the network like you know what happened with since similar things happen with hard blade and so on so and this is like an essential property for cryptographic protocols right because these are often the most security sensitive portions of especially in like blockchain protocols um so that's one property uh and but like you know you might say there's a lot of other languages which are also memory safe but i think the nice thing about us is that it hits this the same performance profile that c and c plus

aim at so you get like the benefits of cnc plus plus namely the performance without the downsides of the lack of memory safety that you suffer there so in my mind i think the optimal approach would be to design your protocols and design your core primitives inside a rust based library could be you know artworks could be bellman there's other libraries as well and then if you want to interface with it from another language let's say your you know final application is developed and go i think the best way would be to just expose a simple interface to go off the high level protocol functions and then you can just call these methods from go so and go you're not implementing your

you know heavy cryptographic machinery which can be difficult to optimize uh predictably right but then at the application level you're still benefiting from you know whatever benefits go provides you name the ease of deployment and so on but in this case you're talking more like from the low level being in rust going upwards like to the application level but what i was actually thinking was like older implementations that weren't done in rust what does it mean for them to be included in artworks like is there a way to do that or is it like something where you should not be bringing in kind of different languages at that low level it should all be in rust in the arc works setting yeah basically i guess uh the older implementations would

probably be in c and c plus plus and i guess the nice thing about russ is that it has a very good story about interfacing with c libraries so and there and by extension c plus so the idea there would be if you wanted to reuse some existing component let's let's say you implemented your state of the art snark in c plus and you didn't want to rewrite it in rest what you could easily do is provide a c wrapper around your c plus plus library and then you know link to that c c wrapper from your rust code inside arcmix and then reuse artworks for the for the rest of your application development if you wanted so that's certainly possible i don't think i mean i would not recommend that i think for example one of the original approaches that sean investigated while writing developing

bellman was to write a wrapper around lip snack i think yeah it just gets a bit hairy especially when you're working with c plus it gets a bit hairy so he opted for the pure rust approach in the end is there a lot of code that goes into writing uh snarks or the algebra or is it mostly like thinking work that then turns into 100 or 200 lines of code um so i think i think for the snark world in particular if you're developing snack protocols i think most of it is in the research phase in like the math and computer science phase and then implementation i wouldn't say it's trivial at all though it's that you know going from your like what is

optimal for presenting you know in a paper is different from what's a you know efficient inside an implementation right so oftentimes what you'll see is that you'll say something in the paper and then when you're implementing it you're like well for for the purpose of the implementation you have to optimize it so there's like a lot of effort which goes into the code but i would say that those 100 200 lines of code have a lot of cryptographic thinking behind them and then implementation you have optimizations at the protocol level that also appear there so that code would become really really dense yeah so yeah i guess maybe compared to some other you know domains a lot of protocol like snark protocol code is there's a lot of information within each line i i guess i would say that what kind of experience do you try to

create for developers who are working with uh artworks i guess i get the there's two audiences right so the protocol developers and the constrained and the application developers above the snark level so for the protocol developers i think yeah our aim is to make it so that you can go from the paper to code in you know without worrying about oh did i do this step correctly or is this step secure to basically provide secure defaults that your protocol developer can come in and just use them while still ensuring that you know security without losing efficiency so you're not by choosing artworks you're not you know you might get security but you're not you don't want to sacrifice performance

and that's sort of we try to balance both of these aims at the higher level um you know the application developer level our aim is to make sure that even if you're maybe not a snark expert you can still write constrained systems and then applications atop those in a way that's even if you're not a cryptographically trained it should not be like you know you're spending all of your time just wondering is this secure basically provide you with efficient defaults and i guess at both both levels we want to provide efficient and secure defaults that folks can use but obviously like you know what we assume of users is slightly different at each level like earlier on in the conversation you actually defined what groups you were targeting but can you just repeat what those are so you sort of mentioned

for protocol devs but art like are you actually like would you picture like an application developer using arc works directly or that are they going to have to go through something to interact with it right so the yeah the two audiences that i mentioned earlier were people who are developing cryptographic protocols directly so maybe you know implementing snacks or implementing um you know your new signature scheme or some other primitive of the sort right so that's group one and the other group is people who are not you know developing cryptographic primitives with other applications using stocks so for example you know if i'm implementing dark forest i might not know oh what is the exact security property of this snark and

you know what kind of efficiency efficiency it guarantees me i just want to like write my constraint system and then use that within my like people who want to use snarks as a tool not as you know something interesting enough themselves so then we target both of these folks and i guess like your question about you know can somebody just pick up artworks and use it within their application that is more relevant to the second group of people the application developers and i think our our aim is to cater to those folks also obviously because you know our interface is a little bit lower level than something like circom or leo or zinc or any of these languages right it's a bit a bit more starting cost but we do

by having that initial starting cost it does allow you for more avenues for optimization so uh for example i think in socrates there is not a way to one common trick in snarks is to instead of you know if you have some expensive computation all you need to do is check the computation instead of doing it let's say i have a factorization right it's very easy to check that the factorization of a number is correct right you just multiply the factors together and you get out you check that it's equal to the final number right but actually computing the factorization is very expensive right and i want to prove to you that another factorization of some number let's say uh my rsa key right all i need to do inside the snark is multiply the numbers together i don't need to

you know you know factorize them for you because you don't need to factor them either right so the snack the competition has knock is much cheaper now what arcbox allows you to do is to express these kinds of optimizations that are you know specific to snarks at a at the low level while maybe high level frameworks don't necessarily expose that uh ability to folks so yeah that's if you're an application developer aiming to use artworks you are working maybe maybe at like a slightly lower level of abstraction but it does allow you to get more efficiency out of for your final program do you mean in the sense that it allows uh application developers to think more clearly about the

proving and the proof checking side of their protocols yeah it gives them maybe a clearer insight into like how the what the code they write i mean what that will translate into in terms of number of constraints and how to optimize the the size of the resulting constraint system i want to go back to one of the things uh you said earlier about making it really easy to translate from mathematical papers into code that sounds really striking to me because you know the notation that that you have in in mathematical or cryptographic papers is very different from the code that people would usually write i'd imagine it's a large source of of errors could you elaborate a bit more on like on how you achieve that or you know where it

really works well so one example is that a lot of especially the snark etc a lot of the protocols are written in terms of an abstraction called a prime order group a primordial group is just you know some object which has where you can add things and subtract things and there's a concept of zero right so something plus zero is equal to something right so a lot of group a lot of protocols are defined abstractly in terms of this group abstraction and what we implement in artworks is a trait which basically captures this group abstraction so it implements addition it implements subtraction and it implements some notion of a zero right so when you're actually writing a protocol from the high level uh pseudocode to code you don't have to worry about oh

how am i going to translate this group abstraction you just use this group trait and then you invoke this addition and subtraction methods on it as appropriate so that that's one place where for example um we allow you to not have to worry about how am i going to translate my pseudo code to code there are other fact other places as well like we have abstractions for ffts and polynomial multiplication like your protocol might say multiply two polynomials right and you you you don't want to worry about how i'm going to do this small polynomial multiplication because there's lots of ways to do it efficiently lots of ways to do it inefficiently what you just want to do is use the efficient default so we have abstractions which just you know say

take polymer and one polynomial to multiply them yeah so it matches the high level description again exactly you actually mentioned a couple projects that are working are using arc work so you mentioned uh that it's being used within like cello's sort of larger structure potentially with mina as well but where else like who who are your the users today right so i guess there's two categories of users again so one is like industrial users uh who are taking snack protocols and deploying them in practice and within this category i think uh cielo and mina already fall i think other folks are looking into it but i i'm not i'm not i think maybe al grant is looking into it as well but i'm

not entirely sure helio also they're using a fork of the sort of a prior version of the artworks code base and they're also using it um i guess i mean uh alia was a zexty implementation so it makes sense to use the same infrastructure totally i can say that web3 foundation is using it for bls aggregation awesome yeah so yeah there's a lot of i mean it's kind of difficult to know who's using your code uh we don't have that telemetry infrastructure i don't think i want to add it either but yeah i think it's like some nice industrial adoption um at i guess all levels of the stack the protocol implementers as well as i think cello there cello and

alio there they have constraint system implementations um so yeah it's at a couple of different levels of the stack and then there's the research users who uh are using it for their you know when they develop a new protocol to experiment it and experiment uh with their efficiency and figure out what the performance is um so i know you know a few groups both within obviously within berkeley uh with another sunrise group but also outside who have used the arc works code base for uh implementing the protocols cool so you're you're at berkeley you're in the academic community have you found artworks to be a useful teaching tool or do you think that it could be used to teach teach students about zero knowledge

proofs um i think certainly it can be useful to okay so i guess of teaching the requirements are kind of slightly different right you don't really care about performance you just you know want to make sure that it's very simple for users for the students to develop because they're only learning a lot of new things so the artwork there's like certainly like a slight learning curve to workbooks even along with you know learning trust um so for teaching i am i'm not sure it's perhaps yet the best tool that being said i did in a past course that i co-taught you use artworks to showcase you know some simple constraint writing tutorials and so on but i think i think it needs a little bit more work before

it's appropriate for use inside uh insider educational context i see you you'd rather have something that was just really easy to use but didn't focus on a lot of those other aspects like uh like performance and allowing people to to optimize and swap out components yeah i guess the uh if you're an undergraduate or even at a graduate level like early graduate level there's only a lot of background they need to pick up like for snarks before you you know can start using them so maybe adding artworks and rust on top of that can be a you know quite difficult also because like in an educational context i think you know you can expect more students to already know python or maybe c or c plus plus but i think rust is

still sort of getting there in terms of popularity so it's like an additional stepping stone for people to pick that up along with artworks i actually i had a question a little bit about how you picture this being maintained going forward because you mentioned earlier on that this is a project coming out of your work at berkeley but is that is it it's not a company i guess and i'm wondering kind of like what is the strategy for actually keeping this going after i don't know say you step away from it i'm not saying you will maybe you never will but like you know what i mean no no that's certainly a very good question and i think one that we haven't yet had to think about probably we will have to think about it also because i'm going to be graduating

uh soon so certainly something that i think i want to like keep contributing to it in even in my off time whatever i do after graduation um but yeah it's a good question we haven't yet thought of it you flip it out fully probably we might you know if there's ongoing industrial adoption then you might have to flesh out some ideas on maintenance and uh funding and so on but we haven't had those conversations yet because actually this sort of brings up a bigger topic which is like when you don't have in this case like arc works is a it's sort of a i mean it's a collection of libraries it's something that's going to be used by projects that do have value on in their

tokens or maybe they're going to be there's going to be businesses that are potentially going to use this it kind of goes back to the general open source development question exactly of what where do these things end up living and who maintains them and who's going to take care of them if they are actually key to something especially when you can't necessarily monetize these like these won't have a token although they may be underlying tokens yeah certainly like i think a very difficult question in the open source space and that a lot of projects outside cryptocurrencies within cryptocurrencies are facing just you know when you're maintaining this open source uh common good then how is it funded i mean i would say that there's a lot of

even beyond me there's a lot of excellent students at berkeley who have been you know taking over more and more responsibility of maintaining different parts of the ecosystem and you know helping with fixing bugs adding new features uh cleaning up code so there is like certainly you know ongoing supply of maintenance from berkeley uh students that it's a good question on how to fund these open source utilities you know which are common goods uh outside of the cryptocurrency space especially within the cryptocurrency space i think maybe i don't know foundation grants could be one option or i i honestly i haven't looked into the space too much i haven't thought about it too much i don't know what the state of the art is so i'm wondering if you know of any other projects that come

from like a more academic context who have made that transition it's okay if you haven't but i i think there's also just a general call to the listeners like if maybe they've heard of something like that because i'd be i'd be curious to hear how projects like this can be incubated and let out into the wild in a really like healthy way yeah so i think um in terms of other code bases within the snark ecosystem obviously there's like the lib snark right it started off as a code base that alessandro and madders and co were working on when they were grad students at mit and since then it was initially used in the first deployment in ccash it was used i think back when mina was starting up and still like it's used as a back end in socrates and such

but i think what's happened there is that different projects have as maybe some of the maintenance of lip snack has or like the effort in put into updating or keeping lip stock up to date with the newest developments has you know slowed down a bit i think other projects have forked lip snark for their use cases um and you know added whatever things they wanted in there i think there is value in having uh avoiding that for artworks just you know trying to make sure that all of the different editions are all work together and all sort of in the same ecosystem instead of like forked ecosystems but yeah i guess in terms of other projects i think all the other projects so as i know um like bellman is you know funded by zcash uh uh a work

done by z cash folks they go garvey libraries i think they work on their consensus folks i think usually is like a you know big company backing these big or small companies some company backing these um i'm not aware of too many open source projects in the sort of foundational snark ecosystem i guess these foundational layers i mean maybe maybe i guess one is the dalek libraries i don't know how they handle maintenance and funding but they're they're also like a primarily open source project which doesn't seem to be you know like fundamentally tied to just one company or cryptocurrency maybe this is a call to action for everybody who's loving the crypto bull

market to help support all of the open source technology that's maintained by one guy in montana yeah internet good move i i think it's interesting that as an as an ecosystem you're you're targeting like these two sides so one is the the research side and one is more of the application side because what we've seen so far is mostly experimentation with snarks on i'd say the research side like okay okay here's a way we can make a proof what are we proving uh let's figure that out later um but i think the now we're we're going to want to see a shift to people actually using zero knowledge

proofs and seeing uh seeing that change in direction and how do you view that transition is that undergoing what what stage are we at yeah certainly i think uh we're moving from snarks as a tool for specialized groups within you know snark focused companies like zcash with the you know i mean they were the sort of pioneers of snarks in industry but zcash you know with its specific circuits for this just payment i guess cello has you know snacks for their aggregating of signatures mina has their snacks for uh request accomplishments i think like the sort of i guess snark 1.0 era was a very application-specific snorks i

think the next level will be snarks for general purpose computations and general purpose applications so i think we're seeing that already with sort of maybe this latest proliferation of snark languages like sircom like zinc like leo right where the aim is to bring in the average developer into the snark world and um i think that's where sort of then one of the next exciting frontiers is to sort of demo democratize snarks and programming with snarks and i mean i that's not to say that you know the research side is going to stagnate i feel like definitely within the last year and like posthalo has been like a lot of exciting developments on various properties of recursive composition

but i think what will eventually happen over maybe the next three four years is that the resets that side will settle down a bit we'll find some good snarks and performance knocks structures sort of fit our use cases and i think the next step will the really exciting step will be making the average person uh able to use snarks and i think yeah that's personally what excites me as you know like when you're in academia you're always like oh here's a cool idea and then you sort of you wonder if this will ever be useful for anybody but i think snacks have like jumped this academia industry barrier and now we're going to be seeing i hope a lot more adoption does that answer your question oh definitely now i just have more more things to to ask you know exactly that point that that you said about

democratizing uh access to snarks and bringing it to the average developer do you think that's gonna happen um on blockchains on smart contracts or do you think of other places where snarks are going to be really useful i think this democratization will start with cryptic i mean it's only started with cryptocurrencies because i feel like snacks are sort of you know blockchains in general like like the killer application for snacks right there you have you know a lot of nodes that need to verify a lot of computation is not like a single source of truth and that's why you need this sort of privacy and integrity properties that that snacks offer right so i think blockchains will perhaps pave the way forward for snarks to be used in industry i think

after that we will see more applications of snarks perhaps outside the blockchain space and maybe in any i think that the the next appliance will probably be in places where privacy is important um maybe healthcare or finance or i guess you know standard finance classical finance but that i think that is a bit more far off in the future just because you know those are established industries and perhaps they have more inertia to adopt new technologies yeah those blockchains are just uh they will like the benefit is that they're providing a lot of financial incentive for snacks to become a sort of usable technology beyond just a research tool cool bringing it back to to rust

one of the things that i think a lot of people are really excited about with with rust is web assembly so compiling rust programs to web assembly where they can be used in the browser or even in smart contracts or uh even you know as a cross-platform operating system uh execution tool um what how do you think about the interaction between web assembly and arc works is it something that you uh you target or optimize for uh yeah certainly so yeah so rust is a very nice story about compiling down to webassembly and we try to take advantage of that as much as possible our code base is all sort of no standard friendly which means you know it's technical speak for that it can compile down to webassembly without

too many problems um so yeah so we're certainly web assembly friendly i think some folks have done some toy projects with using webassembly like artworks compiled down to webassembly um but yeah i i would be very excited to see somebody you know using artworks to do snarks in a browser or something have you done any research into the code sizes that are produced when compiling artwork based applications um no i haven't but i think the nice thing about our framework is that because it's all generic right uh what that means is that when you do compile it down to like your final application which uses a particular curve and a

particular snack all of the things that you don't use are entirely stripped out so you don't pay for what you don't use so that should help with that but i got i on top of my head i have no idea how what their actual costs would be okay you don't you don't pay for what you use or what you don't use even in the the code size yeah i have a question for actually for you rob and for you pertussis because when we talk about like rust and wasm and i mean this just reminds me of a lot of conversations that i had with like frederick being on the show and kind of bringing it back to parachains and polka dot since you're here i have a quick question like like because it's written in rust i'm assuming it's like network agnostic it can be

like used in anything that touches rust if you can deal with rust then you can deal with arc works i know that there's a few uh privacy parachain projects coming out would they be able to use something like this as is or would they need to have something done for it to be used in a pair chain context my understanding is that they could just use it i think one of the difficulties is that we expect or at least the toolkits the sdk cumulus and substrate that we provide for writing parachains expects a no standard library environment i'm not sure if arc works requires the

the standard library i imagine it uses the standard library more for things like uh memory allocation which you don't necessarily actually need the standard library for um but you know barring that specific blocker i think it could just be used by by any kind of parachain project you know implement whatever zero knowledge system they wanted to right yeah so artworks is no standard friendly so as you say most of the requirement is just an allocating memory so yeah you can just plug it in in these environments interesting cool well i figured since you're here i might as well mention it i mean i'm super excited i didn't want

to barge in i'm a host here but it's definitely a lot of cool stuff you can do with this project cool well listen pratosh i want to say thank you so much for kind of walking us through arc works and helping us to understand what it is how it's already been used maybe how it can be used i do wonder is there any sort of call out to the audience you might have about contributors or like anything if people want to get involved some way for them to participate yeah definitely i think we're always looking for contributors at like all levels of experience with cryptography as well as with uh rust we have we try to label our issues with you know

which are beginner friendly and which are not um so yeah if anybody's interested just hop on over to our github organization so artworks.rs is um yeah where it's at and ping me on telegram or twitter or wherever and uh yeah i'll be more than happy to help people get involved and start contributing cool do you have any sort of community chat or anywhere like a telegram group yeah we do have a telegram which i think we can put in the show links sounds good cool you got you got a new member over here awesome already cool all right so thank you rob for co-hosting thank you anna for hosting and for touch

thanks so much for being on the show again yeah thank you guys so much for having me and to our listeners thanks for listening