Intro (00:05):
Welcome to Zero Knowledge. I'm your host, Anna Rose. In this podcast, we will be exploring the latest in zero knowledge research and the decentralized web, as well as new paradigms that promise to change the way we interact and transact online. This week, guest host Robert Habermeier and I chat with Pratyush Mishra about Arkworks. An ecosystem for developing SNARKs and developing on top of SNARKs. But first I want to remind all of you to subscribe to the zkMesh newsletter. It's a monthly newsletter that looks at the latest in decentralized privacy-preserving tech, privacy protocol development, and zero-knowledge systems research. It's put together by myself and Mikerah. 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 of days. I've added the link to this in the show notes. I also want to thank this week's sponsor, Least Authority. Least Authority is a security consulting in product development company, known for pushing the limits on how to build privacy-respecting solutions.

Anna (01:14):
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. Least 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-LAFS, 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, Least Authority. Now here's our episode all about Arkworks. So today guest host, Robert Habermeier and I are going to be chatting with Pratyush, all about Arkworks. So first off, welcome back to the show, Rob.

Robert (02:10):
Thank you Anna, glad to be here.

Anna (02:12):
And welcome Pratyush, it's also your second time on here.

Pratyush (02:17):
Yeah. Thank you so much Anna, it's great to be here. And yeah, looking forward to the podcast with the two of you.

Anna (02:21):
Cool. So Rob, you've actually been a two-time guest, but this is the first time you're going to 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?

Robert (02:39):
Well, my name is Robert. A lot of people call me Rob. I am the co-founder of Polkadot Network. I've been working in Rust, building blockchain software for almost five years now. Yeah, that's all the important parts.

Anna (02:55):
Cool. What you just described as some of your bio kind of explains why you're the co-host on this particular episode because Arkworks is a collection of Rust libraries and I thought it would be really great to have an expert here with me in talking to Pratyush. Now Pratyush, the last time you were on the show, you were actually on the show for a whole conversation about the Zexe construction, and we talked kind of in detail into that. We've also, since then 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 Zexe curves to now. What have you worked on and what is Arkworks? What's kind of come out of that.

Pratyush (03:37):
Yeah, the last time I was on the show, I was still a second or third year PhD student. So it was still quite fresh, but yeah, so the main project at the time was Zexe, which is a system for doing private competition in de-centralized 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 SNARK-related implementation. So we had to implement the lowest level elliptic curves and the finite fields. And then on top of that, we had to develop the actual SNARKs themselves and then write constraint systems for these SNARKs. And then finally, you know, implement the Zexe construction. And so this code, we started developing it, using an initial fork of Sean Bowe's Bellman library. So Howard Wu and I reforked that code base to, you know, expose a few more knobs that we could fine tune for our construction.

Pratyush (04:30):
And that sort of code base has eventually over the course of the past few years evolved into the Arkworks ecosystem. And so now Arkworks is an ecosystem for developing SNARKs and developing on top of SNARKs, 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 inside the Arkworks ecosystem as well as from outside contributors in Zcash forks, from Celo forks, as well as Aleo forks. So like a lot of different people in industry have contributed to the Arkworks ecosystem.

Anna (05:16):
I just remember we've done like study clubs on the Zexe paper originally. This was basically an academic paper, as I understood it. And 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, 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 Zexe that's just evolved.

Pratyush (05:48):
Yeah. So I guess the Zexe's specific component of that original codebase was, I guess not even like the largest part of that code base, it was mostly just, as I said, 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 Zexe. And the parts 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've since developed further, 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 Celo 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, that's exciting that the work that we started, you know, just to basically show that our idea in Zexe 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.

Robert (06:59):
So coming back to that point that you just raised about like the practical versus theoretical where do you see Arkworks fitting into that? Is it more something that you see people using later on 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?

Pratyush (07:19):
Right. So I think I guess the nice thing for 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 Bowe said then they were looking started looking at the Halo paper was that he started implementing the Bulletproof protocol and then noticed some curiosity about its structure and that led to the whole Halo approach, which has since spawned a lot of research papers. So I think like this, you know, the research by tinkering with code is definitely something that is possible then the zero knowledge space. And I think our goal with Arkworks is to not only support, I guess, production issues, cases like towards the end of your research problem, but also during 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.

Pratyush (08:21):
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, you know, science paper going from that description, just high level to go to code shouldn't like require too much thought on the part of the implementer. It should be easy to get like secure and performant code. And 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 originally as a research code base.

Anna (08:56):
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?

Pratyush (09:01):
Right. So I guess since the Zexe paper, like what really that spawned was that, or what I found interesting was that it left to sort of open questions and the first was that in Zexe or for the Zexe model to really work out, you need two efficient components. 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 Zexe is to recursively check some proofs of computations 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 set up for a computation. And so you want to be able to do just one set up and reuse that. So that sort of these two questions spawned, I guess, my research in the zero knowledge space since on this, you know, updatable or reusable SNARK,I worked on Marlin with Alessandro and a bunch of other great authors and on the recursion front I've been working on some follow-ups to Halo,which are, yeah, we put up online last year and I think there's going to be a zk study cover about that,hopefully soon as well. Uno, totally. Yeah. And so like for both of these, we did try to implement our protocols and we used the eclipse ecosystem for that.

Anna (10:17):
That actually, that that's sort of a main question I have about Arkworks is what is it exactly like, you're saying now you've used it to implement some of the research that 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? 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 as soon as they have these languages and I still don't entirely understand where Arkworks fits in. So maybe you can help me, like maybe understand the landscape and where Arkworks lives.

Pratyush (10:54):
Yeah, totally. So Arkworks is basically a collection of Rust libraries for implementing SNARKs and working with SNARKs. So what that means is that, you know, SNARKs have a lot of underlying components, as well as, when you're building applications on top of SNARKs, you need to build some infrastructure around that. So the goal of Arkworks 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 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 FFTs and so on. And what Arkworks aims to do, maybe on this lower, below the SNARK level, is to make it so that these components, you only implement them once.

Pratyush (11:41):
And then you can reuse them across different SNARKs or different implementations of SNARKs. So for exampleall of the algebra infrastructure, which means elliptic curves, finite fields, FFTs is shared across our implementations of the Groth16 SNARK, the Groth-Maller SNARK and the Marlin SNARK. So all of these share the same infrastructure, so you don't have to implement it again and again. And then like, so once you have your SNARK, you want to build applications on top of your SNARK. And so on that front, like above the SNARK in the stack, above the SNARK, we want to make programming applications with SNARKs easier. So we have infrastructure for writing constraints and making that ergonomic.

Anna (12:20):
So one of the things I'm not entirely clear on what Arkworks is, 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 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.

Pratyush (12:40):
So Arkworks is a collection of Rust libraries and the scope of Arkworks is somewhat broad. But that's two primary, I guess, categories or two primary audiences. One is folks who are implementing a very low level cryptographic protocols. 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 for, you know, Dark Forest or something. So that's the, like maybe the next audience of people who are not necessarily very intimately familiar with the low-level workings of SNARKs. So for the first audiencethe protocol implementers, what Arkworks aims to provide is a collection of coherent libraries that can be reused across projects. So for example, we have a very modular implementation of the algebra components that you might encounter in protocols.

Pratyush (13:37):
So for example elliptic curves, finite fields, Fast Fourier transforms. These are all very core things for implementing SNARKs as well as some of these are useful for implementing signature schemes and so on. And the idea for Arkworks is to make these things very reusable. So, you know, you don't have to reimplement the same code again and again, as an example our implementations of the Groth16 SNARK, as well as the Groth-Maller SNARK and the Merlin SNARK all reuse the same underlying elliptic curves 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 very close to natively writing your application. So for this, we've developed this infrastructure for writing constraints, which can be used to implement 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 domain-specific language, DSL, which is for writing constraints specifically.

Anna (14:49):
But in that case, would you equate that with something like Circom? Is it comparable or did they work together?

Pratyush (14:55):
Yeah, so our DSL for writing constraints — I guess you're still writing Rust, it's just that we make heavy use of some nice Rust features like traits and generics to make it so that, you know, you're still getting in a very good quality constraint systems out. So that they don't have unnecessary or inefficient constraints in there, but whatever Rust offers, you can still take advantage of that. As I said, we 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 maybe a level below projects like Circom or Leo or Zinc, ZoKrates — basically these languages, which are high level and are like very, just targeted at SNARK constraint generation. So, yeah, I think we sit like a level below that.

Robert (15:55):
So if I understand correctly, you're trying to do two things. So one is for application developers who want to write something that uses SNARKs, many SNARKs are just going to use the same types of constraints systems. And they'll just be able to write Rust code that, you know, for some constraints system, for some SNARK it's gonna execute the circuit that's desired. And then on the other side, you create tools for people to build new SNARK protocols, that those two sides of things can be plugged together. And you have tried to reach those both use cases with the same set of libraries.

Pratyush (16:37):
Exactly, yeah. And yeah, it's a good point about modularity. So one thing I didn't mention was that our goal is to make it so that, you know, you write your constraint systems once, but they're not specific to a particular kind of SNARK. So, you know, I write my constraint system and then I can use it with the Groth16 SNARK or with the Marlin SNARK or with the Halo SNARK or whatever, the latest SNARK is. It should be easily portable — the constraint system shouldn't have to concern itself about what is underneath it in terms of the SNARK.

Robert (17:07):
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 Groth16, or one of the other ones, what is the actual output? Is the Rust compiler going to take your code, that's been fitted with this modular component and actually produce a binary that is executing the circuit, or is there some other output of the process that happens later on, or earlier on in the cycle.

Pratyush (17:38):
Right. So everything in Arkworks is implemented as a library and as a generic library. So what that means is that, bringing up the Groth16 SNARK, we'll have a type parameter where you can say, "This is the kind of constraint, he's plugging a constraint system here, and then I'll take over and I'll just call the, libraries that interface with the constraint system to get out the constraints. And then for an end user, you do have to compile it down to a binary, right. And at that point you will instantiate all of these components. So you instantiate what elliptic curve is used underneath your Groth16 SNARK, what constraint system is being plugged into your Groth16 SNARK. And so basically that's when it is all instantiated and then you get a final concrete system.

Robert (18:20):
I see. So, and that can just be embedded into a larger binary, but is there a goal of creating sort of self-standing proven binaries, or is that something that happens outside of the Arkworks ecosystem?

Pratyush (18:34):
I think I'll go implement the libraries, but I believe that you know, Celo as well as Mina, what they've done is they've taken these libraries and they've compiled them down and stuck them within their specific binaries — like, within the larger application context. And then they just call these libraries. 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 that just calls these methods on Groth16. It's very straightforward. Once you have your components, it's probably less than 50 lines to take in some user input and then spit out a proof on the command line.

Anna (19:23):
I want to understand a little bit about what people would have done before there was something like Arkworks. Like there are existing projects, I kind of mentioned Circom, you mentioned Leo, you mentioned some of these other like ZoKrates, what were they doing? If you wanted to use what they have, what would you have had to do as like an engineer, as an implementer here that's different than what you can do now with Arkworks.

Pratyush (19:47):
Right. So, yeah, I guess it depends on your audience. So, I think like ZoKrates and Zinc and Leo and all of these languages, their aim is to sort of provide a fixed package to the end application developers. So the application developers shouldn't have to worry about what kind of proof system am I using and how efficient is this going to be. They just give you like a compiler, and at the end you plug in your input program and it'll spit out your final proof of your parameters or whatever, right? So that's, I guess these end-to-end systems, and their goal is to provide a very high level API to users who are not necessarily technically proficient. They might be, you know, programmers, but not necessarily cryptographically trained.

Pratyush (20:34):
And then there's like a separate set of libraries and toolchains, 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, as well as Mina's Snarky ecosystem — forgive me, you know, anybody out there, if I'm not naming your project — But yeah, so these libraries, I guess libsnark was the first one and it offered a C++ interface. And I guess that's the problem with C++ 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 the memory safety, so people have moved on to memory safe languages, such as Rust or OCaml or Go where you can still leverage, I guess, modern programming idioms without having to worry about memory safety and those kinds of bugs.

Pratyush (21:31):
So I guess, yeah, Bellman was the precursor like the ancestor to the Zexe codebase and we forked 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 system more generic. But yeah, I mean the Bellman ecosystem is still a great source of libraries for developing our own applications. That's why we took a few different trade-offs there. And OCaml and the Go ecosystems, I think maybe they serve a different niche. I just like programming in Rust, so...

Robert (22:07):
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?

Pratyush (22:14):
Yeah, so a lot of our, especially like 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 codebase and it, you know, excellent codebase and added those knobs that we could tune for our initial requirements and the Zexe 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, of this core, like the algebra code is shared from the Bellman infrastructure.

Robert (23:10):
Touching on the algebra portion of things. 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 the process of trying to encode those things in the Rust language. Are there edge cases? Does it work cleanly?

Pratyush (23:37):
So 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? And these elliptic curves they come associated with I guess two fields or two finite fields. One is a base field and one is a scalar field, right? And they have some associated arithmetic, you know, there's some formulas which go into, you know, add points on elliptic curves. Ideally what you want to do is you want to write your arithmetic just once, right? The elliptic curve arithmetic just once no matter what kind of curve it is. So as long as, you know, it's a short Weierstrass curve, I only want to implement the point addition and point doubling just once.

Pratyush (24:28):
I shouldn't have to care what the 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 inside Arkworks, you can take this existing 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 a hundred lines of code. And compare this to perhaps, you know, hand-coding your implementation, probably you'd have to re-implement all of these components again and again, and that would probably spend over like 1000-2000 lines of code with potential for bugs and so on.

Robert (25:33):
Have you found that, for the example of elliptic curves, that people are taking libraries for elliptic curves that are written outside of the Arkworks ecosystem and wrapping those and then bringing them into that same trait wrapper?

Pratyush (25:51):
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 crates do require you to implement a lot of sub-traits. 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 implementations of, you know, some generic finite fields and generic elliptic curves, so that when you do want to implement a new curve inside Arkworks, 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 take arithmetic implemented in, I don't know, the Dalek libraries, or maybe the Bellman libraries even, and easily use those implementations with existing Arkworks infrastructure. So that's a goal. We haven't yet found time to devote to that, but that's certainly on our radar.

Robert (26:50):
Do you give tools for people to punch through the abstractions if they need to, if they want to rely on a particular property of a field or a curve that they use for optimization in a protocol?

Pratyush (27:05):
It's a good point. There's always this 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 efficiency improvements, right? So that option is certainly available inside Arkworks. So if I don't care about abstraction, then I can just say, "okay, just give me for example the BLS 12-381 curve and I'll just use that. That's what I use in my protocol, so I'll optimize my protocol around that." And so we do allow you to do that. That being said, our existing implementations of the SNARKs, for example, are all generic. So they can't quite directly leverage those special properties of elliptic curves. But what we do allow is that when you're implementing the curve itself, if you have an elliptic curve, which has some special properties,

Pratyush (27:58):
So for example, if your elliptic curve has very efficient kinds of scalar multiplication — so there's one method called GLV multiplication, which allows you to speed up a scalar multiplication, which is a core operation in a lot of protocols — it allows you to speed that operation up by quite a bit, right? So there's some implementation effort by contributors from Celo, which allows you to generically sort of specialize the scalar multiplication code forcurves which support this GLV optimization. So that, you know, at the higher protocol level, you don't have to worry about, "Oh, does my curve support GLV optimization or not?" It just transparently gives you that efficiency boost. So we do we're all the same. 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 worry about whether it exists or not. I hope that answers your question.

Robert (29:00):
Yeah, it does, it does well.

Anna (29:03):
I want to talk a little bit about like the general cryptographic community and their use of Rust. Because 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 crypto community right now are moving towards Rust, so maybe it won't be a problem.

Pratyush (29:28):
Yes, so in my mind, I think Rust is the perfect language for implementing cryptographic protocols, for two reasons. So one thing I mentioned earlier was that unlike C and C++, Rust has memory safety, which means that if I'm indexing an array incorrectly, I won't accidentally access your secret key and reveal that to the network, like, you know, similar things happened with Heartbleed and so on. And this is like an essential property for cryptographic protocols, right? Because these are often the most security sensitive portions of, especially in blockchain protocols. So that's one property, 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 Rust is that it hits the same performance profile that C and C++ aim at.

Pratyush (30:18):
So you get the benefits of C and C++, 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 Rustbased library, could be Arkworks, could be Bellmen, there's other libraries as well. And then if you want to interface with it from another language, let's say your final application is developed in 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, in Go you're not, implementing your, you know, heavy cryptographic machinery, which can be difficult to optimize predictably. But then at the application level, you're still benefiting from whatever benefits Go provides you, namely ease of deployment and so on.

Anna (31:13):
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 Arkworks? Like, is there a way to do that or is it something where you should not be bringing in different languages at that low level? It should all be in Rust in the Arkworks setting.

Pratyush (31:38):
Yeah, basically I guess the older implementations would probably be in C and C++, and I guess the nice thing about Rust, is that it has a very good story about interfacing with C libraries, and by extension C++. So the idea there would be, if you wanted to reuse some existing component, let's say you implemented your state-of-the-art SNARK in C++, and you didn't want to rewrite it in Rust. What you could easily do is provide a C wrapper around your C++ library, and then, you know, link to that C wrapper from your Rust code inside Arkworks, and then use Arkworks 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 developing Bellman was to write a wrapper around libsnark. I think it gets a bit hairy, especially when you're working with C++ it gets a bit hairy. So he opted for the pure Rust approach in the end.

Robert (32:40):
Is there a lot of code that goes into writing SNARKs or the algebra, or is it mostly like thinking work that then turns into 100 or 200 lines of code?

Pratyush (32:50):
So I think for the SNARK world in particular and developing SNARK protocols, I think most of it is in the research phase and like the math and computer science phase. And then implementation, I wouldn't say it's trivial at all though. It's that going from what is optimal for presenting in a paper is different from what's 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, for the purpose of the implementation, you have to optimize it. So it was 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.

Robert (33:34):
So that code would become really, really dense.

Pratyush (33:37):
Yeah, I guess maybe compared to some other domains, a lot of protocol like SNARK protocol code... There's a lot of information within each line. I guess I would say that.

Robert (33:49):
What kind of experience do you try to create for developers who are working with Arkworks?

Pratyush (33:58):
I guess there's two audiences, right? So the protocol developers, and the constraint and 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 without worrying about, "Oh, did I do this step correctly? Or is this step secure?" To basically provide secure defaults that a protocol developer can come in and just use them, while still ensuring security without losing efficiency. So by choosing Arkworks, you might get security, but you don't want to sacrifice performance, and we try to balance both of these aims. At the higher level, at the application developer level, our aim is to make sure that even if you are maybe not a SNARK expert, you can still write constraints systems and then applications on top of those in a way that's, even if you're not cryptographically trained, it should not be like you're spending all of your time, just wondering "Is this secure?" Basically provide you with efficient defaults.

Pratyush (34:55):
And I guess at both levels, we want to provide efficient and secure defaults that folks can use, but obviously you know, what we assume of users is slightly different at each level.

Anna (35:06):
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 would you picture like an application developer using Arkworks directly or are they going to have to go through something to interact with it?

Pratyush (35:25):
Right. So the two audiences that I mentioned earlier were people who are developing cryptographic protocols directly, so maybe, you know, implementing SNARKs or implementing you know, a new signature scheme or some other primitive of the SART. So that's group one, and the other group is people who are not developing cryptographic primitives, but other applications using SNARKs. So for example, if I'm implementing Dark Forest, I might not know what is the exact security property of this SNARK and you know, what kind of efficiency it guarantees me. I just want to write my constraint system and then use that within my — like, people who want to use SNARKs as a tool, not as something interesting in and of themselves. So we target both of these folks, and I guess like your question about, you know, "Can somebody just pick up Arkworks and use it within their application?" That is more relevant to the second group of people, the application developers.

Pratyush (36:20):
And I think our aim is to cater to those folks also. Obviously, because our interface a little bit lower level than something like Circom or Leo or Zinc or any of these languages, it's a bit more starting cost, but by having that initial starting cost, it does allow you for more avenues for optimization. So, for example, I think in ZoKrates, there is not a way have one common trick in SNARKs is to, instead of, if you have some expensive computation, all you need to do is check the computation instead of doing it. But let's say I have a factorization, right? It's very easy to check that the factorization of a number is correct. You just multiply the factors together and you get out and you check that as equal to the final number.

Pratyush (37:05):
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 my RSA key, right? All I need to do inside the snark is multiply the numbers together. I don't need to factorize them for you. You don't need to factorize them either. So the SNARK, the computation of a SNARK is much cheaper. Now, what Arkworks allows you to do is to express these kinds of optimizations that are specific to SNARKs at a low level, while maybe high level frameworks don't necessarily expose that ability to folks. So, yeah, if you're an application developer aiming to use Arkworks, you are working maybe at a slightly lower level of abstraction, but it does allow you to get more efficiency for your final program.

Robert (37:54):
Do you mean in the sense that it allows application developers to think more clearly about the proving and the proof checking side of their protocols?

Pratyush (38:02):
Yeah. It gives them maybe a clear insight into how the code they write, what that'll translate into in terms of number of constraints, and how to optimize the size of the resulting constraint system.

Robert (38:14):
I want to go back to one of the things 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 that's large source of errors. Could you elaborate a bit more on how you achieve that or, you know, where it really works well?

Pratyush (38:43):
One example is that, especially in the SNARK literature, a lot of the protocols are written in terms of an abstraction called a primordial group. A primordial group is just some object, where you can add things and subtract things, and there's a concept of a zero, right? So something plus zero is equal to something. So a lot of protocols are defined abstractly in terms of this group abstraction, and what we implemented in Arkworks is a trait which basically captures this group abstraction. So it implements addition, it implements subtraction, and it implements some notion of zero, right? So when you're actually writing a protocol from the high level 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 these addition and subtraction methods on it as appropriate.

Pratyush (39:30):
So that that's one place where, for example, we allow you to not have to worry about how am I going to translate my pseudocode to code. There's are other places as well, like we have abstractions for FFTs and polynomial multiplication. Your protocol might say, "multiply two polynomials." And you don't want to worry about how I'm going to do this 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 take polynomial one, polynomial two, multiply them. So it matches the high level description, again, exactly.

Anna (40:11):
You actually mentioned a couple projects that are using Arkworks. So you mentioned that it's being used within, like Celo's sort of larger structure, potentially with Mina as well, but where else, like who are the users today?

Pratyush (40:26):
Right. So I guess there's two categories of users, again. So one is like industrial users, who are taking SNARK protocols and deploying them in practice. And within this category, I think Celo and Mina already fall. I think other folks are looking into it, I think maybe Algorand is looking into it as well, but I'm not entirely sure. Aleo also, they're using a fork of a prior version of the Arkworks codebase and they're also using it. I guess Aleo is a Zexe implementation, so it makes sense that they use the same infrastructure.

Robert (41:03):
I can say that Web3 Foundation is using it for BLS aggregation.

Pratyush (41:08):
Awesome. Yeah, I mean, it's kind of difficult to know who is using your code. We don't have that telemetry infrastructure and I don't think I want to add it either. But yeah, I think there's some nice industrial adoption, I guess at all levels of the stack, the protocol implementers, as well as I think Celo and Aleo, they have constraint system implementations. So that's a couple of different levels of the stack. And then there's the research users who are using it when they develop a new protocol to experiment with their efficiency and figure out what the performance is. So I know a few groups both within, obviously within Berkeley within Alessandro's group, but also outside, who have used the Arkworks codebase for implementing the protocols.

Robert (42:00):
So you're at Berkeley, you're in the academic community. Have you found Arkworks to be a useful teaching tool or do you think that it could be used to teach students about zero knowledge proofs?

Pratyush (42:14):
I think certainly it can be useful. I guess with teaching the requirements are kind of slightly different, right? You don't really care about performance. You just want to make sure that it's very simple for users, for the students to develop, cause they'll be learning a lot of new things. So there's certainly like a slight learning curve to Arkworks, even along with, you know, learning Rust. So for teaching I'm not sure it's perhaps yet the best tool. That being said I did in a past course that I co-taught use Arkworks to showcase some simple constraint writing tutorials and so on. But I think it needs a little bit more work before it's appropriate for use inside an educational context.

Robert (42:59):
I see. You'd rather have something that was just really easy to use, but didn't focus on a lot of those other aspects, like performance and allowing people to optimize and swap out components.

Pratyush (43:11):
Yeah. I guess that if you're an undergraduate or even at a graduate level, like early graduate level, there's a lot of background that you need to pick up like for SNARKs before you can start using them. So maybe adding Arkworks and Rust on top of that can be you know, difficult. Also because in an educational context, I think, you know, you can expect most students to already know Python or maybe C or C++. But I think Rust is still getting there in terms of popularity, so it's like an additional stepping stone for people to pick that up along with Arkworks.

Anna (43:45):
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 it's not a company, I guess, and I'm wondering what is the strategy for actually keeping this going after, say, you step away from it. I'm not saying you will, maybe you never will, but like, you know what I mean?

Pratyush (44:11):
No, no, that's certainly a very good question. And I think one that we haven't yet had to think about, and probably we will have to think about it, also because I'm going to be graduating soon. I think I want to keep contributing to it, in my off-time, whatever I do after graduation. But yeah, it's a good question, we haven't yet thought of it. If there's ongoing industrial adoption, then I might have to flesh out some ideas on maintenance and funding and so on, but we haven't had those conversations yet.

Anna (44:48):
Because actually this sort of brings up a bigger topic, which is like, when you don't have — in this case, Arkworks is 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's good, kind of goes back to the general open source development question 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.

Pratyush (45:27):
Yeah. Certainly like I think it's a very difficult question in the open-source space and that a lot of projects outside cryptocurrencies, within cryptocurrencies, are facing.You know, when you're maintaining this open-source 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've been taking over more and more responsibility of maintaining different parts of the ecosystem and, you know, helping with fixing bugs, adding new features cleaning up code. So there is like certainly ongoing supply of maintenance from Berkeley students. That's a good question on how to fund these open-source utilities, you know, which are common goods outside of the cryptocurrency space, especially within the cryptocurrency space. I think maybe, I don't know, foundation grants could be one option. I honestly 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.

Anna (46:25):
Well, 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 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 curious to hear how projects like this can be incubated and let out into the wild in a really healthy way.

Pratyush (46:45):
Yeah. So I think in terms of other coalitions, within the SNARK ecosystem, obviously there's like libsnark, right? It started off as a codebase that Alessandro and Madars and Cole were working on when they were grad students at MIT. And since then it was initially used in the first deployment in Zcash. It was used, I think back when Mina was starting up, and still it's used as a backend in ZoKrates and such. But I think what's happened there is that different projects haveas maybe some of the maintenance of libsnark, all effort put into updating or keeping libsnark up-to-date with the newest developments has slowed down a bit. I think other projects have forked libsnark for their use cases and added whatever things they wanted in there. I think there's value in avoiding that for Arkworks, just trying to make sure that all of the different editions all work together and are sort of in the same ecosystem instead of forked ecosystems.

Pratyush (47:46):
But I guess in terms of other projects, I think all the other projects, as far as I knowlike Bellman is funded by Zcash and worked on by Zcash folks. The Go Gnark libraries, I think they're worked on by ConsenSys folks. I think usually there's a big company backing these, big or small company. 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 one is the Dalek libraries. I don't know how they handle maintenance and funding. But they're also a primarily open-source project, which doesn't seem to be fundamentally tied to just one company or cryptocurrency.

Robert (48:33):
Well, maybe this is a call to action for somebody who's loving the crypto bull market to help support all of the open-source technology that's maintained by one guy in Montana that supports the entire internet. I think it's interesting that as an ecosystem you're targeting like these two sides. So one is 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. Here's a way we can make a proof, what are we proving? Let's figure that out later." But I think that now we're going to want to see a shift to people actually using zero-knowledge proofs and seeing that change in direction. How do you view that transition? Is that undergoing, what stage are we at?

Pratyush (49:30):
Yeah, certainly I think we're moving from SNARKs as a tool for specialized groups within, you know, SNARK focused companies like Zcash, they were sort of the pioneers of the SNARKs industry. But Zcash, with the specific circuits for payment, I guess Celo has SNARKs for their aggregating of signatures, Mina has their SNARKs for [unintelligible]. I think the, sort of, SNARK 1.0 era was a very application-specific SNARKs. 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 this latest proliferation of SNARK languages like Circom, like Zinc, like Leo, where the aim is to bring in the average developer into the SNARK world. And I think that's where the next exciting frontier is to democratize SNARKs and programming with SNARKs.

Pratyush (50:33):
And I mean, that's not to say that the research side is going to stagnate. I feel like definitely within the last year and post-Halo there's been a lot of exciting developments on various properties of SNARKs with recursive composition. But I think what eventually will happen over maybe the next three, four years is that the research side will settle down a bit, we'll find some good SNARKs and performance SNARKs that sort of fit our use cases. And I think the next step, the really exciting step, will be making the average person able to use SNARKs. That's definitely what excites me. You know when you are in academia, you're always like, "Okay, this is a cool idea." And then you wonder if it's ever going to be useful for anybody. But I think SNARKs have jumped this academia-industry barrier, and now we're going to be seeing, I hope a lot more adoption. Does that answer your question?

Robert (51:23):
Oh, definitely. Now I just have more, more things to ask, you know, exactly that point that you said about democratizing access to SNARKs and bringing it to the average developer. Do you think that's going to happen on blockchains, on smart contracts? Or do you think of other places where SNARKs are going to be really useful?

Pratyush (51:43):
I think this democratization, will start with cryptocurrencies. I mean, it's always started with cryptocurrencies because I feel like SNARKs — blockchains in general are the killer application for SNARKs. There you have a lot of nodes that need to verify a lot of computation. There's not like a single source of truth and that's why you need this sort of privacy and integrity properties that SNARKs offer. 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 I think that the next step lines would probably be in places where privacy is important. So maybe healthcare or finance or I guess standard finance, classical finance. But 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. These blockchains, their benefit is that that they're providing a lot of financial incentive for SNARKs to become a usable technology beyond just a research tool.

Robert (52:53):
Bringing it back to Rust. One of the things that I think a lot of people are really excited about with Rust is WebAssembly, so compiling Rust programs to WebAssembly where they can be used in the browser, or even in smart contracts or even as a cross-platform operating system execution tool. How do you think about the interaction between WebAssembly and Arkworks is something that you target or optimize for?

Pratyush (53:22):
Yes, certainly. So Rust, has a very nice story about compiling down to WebAssembly and we try to take advantage of that as much as possible. Our codebase is all no-standard friendly, which is technical speak for that it can compile down to WebAssembly without too many problems. So we are certainly WebAssembly friendly. I think some folks have done some tied projects using WebAssembly like Arkworks compiled down to WebAssembly. But yeah, I would be very excited to see somebody, you know, using Arkworks to do SNARKs in a browser or something.

Robert (53:57):
Have you done any research into the code sizes that are produced when compiling Arkwork-based applications?

Pratyush (54:05):
No I haven't. But I think the nice thing about our framework is that, because it's all generic, what that means is that when you do compile it down to like your final application, which uses a particular curve and a particular SNARK, 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 off the top of my head, I have no idea what their actual costs would be.

Robert (54:33):
Okay. You don't, you don't pay for what you use or what you don't use, even in the code size.

Pratyush (54:38):
Yeah.

Anna (54:39):
I have a question actually for you, Rob, and for you Pratyush, because when we talk about like Rust and Wasm, I mean, this just reminds me of a lot of conversations that I had with Frederick being on the show and kind of bringing it back to parachains and Polkadot. Since you're here, I have a quick question: Because it's written in Rust, I'm assuming it's like network-agnostic. It can be used in anything that touches Rust. If you can deal with Rust, then you can deal with Arkworks. I know that there's a few 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 parachain context?

Robert (55:21):
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 the no-standard library environment. I'm not sure if Arkworks requires the standard library. I imagine it uses the standard library more for things like memory allocation, which you don't necessarily actually need the standard library for. But barring that specific blocker, I think it could just be used by any kind of parachain project to implement whatever zero-knowledge system they want it to.

Pratyush (56:07):
Right. Yeah. So Arkworks is no-standard friendly. So as you say, most of the requirement is just in allocating memory, so yeah, you can just plug it in these environments.

Anna (56:17):
Interesting. Well, I figured since you're here, might as well mention it.

Robert (56:24):
I mean, I'm super excited, I didn't want to barge in — I'm the host here. There's definitely a lot of cool stuff you can do with this project.

Anna (56:31):
Cool. Well, listen, Pratyush, I want to say thank you so much for kind of walking us through Arkworks 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?

Pratyush (56:54):
Yeah, definitely. I think we're all just looking for contributors at like all levels of experience with cryptography, as well as with Rust. We've had to label our issues with, you know, which are beginner friendly and which are not. So yeah, if anybody's interested, just hop on over to our GitHub organization. So Arkworks.rs is where it's at. And ping me on Telegram or Twitter or wherever. And I'll be more than happy to have people get involved and start contributing.

Anna (57:27):
Cool. Do you have any sort of community chat or anywhere like a Telegram group?

Pratyush (57:32):
Yeah, we do have a Telegram chat we can put in the show links.

Robert (57:35):
I'll join.

Anna (57:36):
Sounds good. Cool. You've got a new member over here. Awesome. So thank you Rob for co-hosting.

Robert (57:48):
Thank you, Anna, for hosting.

Anna (57:50):
And for Pratyush, thanks so much for being on the show again.

Pratyush (57:53):
No, thank you guys so much for having me.

Anna (57:55):
And to our listeners, thanks for listening.