# Democratizing zk-SNARKs: Improved setup, performance and security

- Channel: [Devcon](https://streameth.org/devcon)
- Date: 2018-10-07
- Duration: 14:50
- Watch: https://streameth.org/watch/yt-7BxoyEw6LUY
- YouTube: https://www.youtube.com/watch?v=7BxoyEw6LUY

## Description

Speaker: Sean Bowe

An overview of the next generation of zk-SNARKs, including a new multi-party computation protocol, new elliptic curves, and the tools for bringing zk-SNARKs into production software.

The Devcon3 ZK breakout sessions are sponsored by the Zcash Company.

## Transcript

[Music] hi so yeah my name is Sean Bo I'm an engineer at the Z cache company Christian just did a really great job explaining how zero knowledge proof smirk and how was the case narcs work my the focus of this talk is gonna be on making ZK snart's work in production software so obviously at Z cash we bride's ek starts into production last year and it was very expensive to do that and that's why we're probably the only people that have done that since then and you know part of that is because it took a lot of engineering resources to do it and it also took a lot of auditing a lot of things can go wrong and the trusted set up obviously is the biggest thing that I think holds back ZK snart's from being deployed in more software broadly so what are the challenges of bringing ZK snarks into production so I think there's four things that that people really kind of stress are the reasons why they can't use the case nartz in production it usually has to do with curve security performance the trusted set up and I guess circuit design as well so curve security I'll go into so there's an elliptic curve obviously this pairing friendly elliptic curve that was implemented in ZK it was designed by our scientists at C cache and it was just implemented in aetherium and it's a pairing friendly elliptic curve that originally targeted 128-bit security however due to some optimizations to the number field sieve algorithm this has weakened a little bit it's about 110 bits now so we're designing a new curve which is targeting closer to 128-bit security we're gonna move to this and in the next version of Z cache it's designed to target the security level without really losing the performance that we had before as much as we possibly could so this new curve is very rigid compared to the old curve it's been reviewed a lot it's been optimized a lot it's been implemented twice I implemented it in rust and a library called paring and it's pretty stable implementation Diego Arana is also implemented it in relic so this curve is being impairing friendly curve is what we build ZK starts on top of so now and now the performance improvements so there are three different things that we're doing at Z cache to improve ZK start performance so one of them is using a different proving scheme so the one that Christian was just talking about which uses eight group elements there's newer ones that use less group elements than that so we want to consider those also there's these techniques and optimizations one of them which I won't go into in too much detail is called streamed proving where the common reference string or the public parameters of the ZK snart's are loaded from disk as the as the computation is being performed when you're constructing a proof so that that has led to like a hundred times less memory usage during proving so it's one of the things that ZK starts their reputation for using a bunch of memory and taking forever we're hoping to to eliminate that the last thing that improves on performance is this new Jubjub curve which I'll go into in a second so as far as proving systems are concerned there are the best one is probably yen's growths new 2016 pairing based snark and this this has three group elements and after this snark was published in last year it a couple papers followed subversion resistant snark so this is where the common reference string is is uh you know modified by the by the person who created it to violate zero knowledge and also snarky signatures which are simulation extractable non malleable ZK start proofs so what we're gonna do in Z cache and kind of the path we're taking forward is we're gonna look at the original graph construction but obviously we want to prevent malleability and we want to reduce these reduce the assumptions so we have a clear path forward for that and arielle gammas onions growth and and Mary Mallard are actually working on that right now so cross original scheme is really efficient so that's kind of why we want to embrace that so this Jubjub curve weird name but it's a twisted edwards curve it's a special curve that's designed specifically to work for BOS 12 381 it's optimized we've come up with all sorts of tricks and optimizations that make it really efficient to reason about this curve inside of zk stark or zk snark arithmetic circuits and so we've reviewed it and optimized it and and and everything it's quite nice curve the reason why you would need an embedded elliptic curve inside of your arithmetic circuits is because you can build a lot of you know efficient cryptographic primitives collision resistant hash a--'s and commitment schemes and signature systems and all sorts of things like that so that allows us to replace the you know we currently use inside of Z cache we use sha-256 for everything and you can use it for quite a few different things but it's not very efficient to do inside of arithmetic circuits being a purely boolean function so these these new cryptographic primitives that are based on these elliptic curves that are embedded inside the ZK snark arithmetic circuit are a lot more efficient because they're entirely algebraic primitives so this this new curve we've implemented in prototype did in and it building software like Z cache and buildings arithmetic circuits like z cache we end up with significantly better performance almost 5 to 10 times better and there's more optimizations that I'd like to talk about but I can't because they're part of ongoing papers so now the the biggest thing that gets people to not really be interested in CK snarks is the trusted set up so when you you know we have Starks on the horizon which are trustless and quantum resistant and so on but for now the proofs are still going to be quite large and not easy to compose together and so we're gonna have to deal with snarks probably for a long time or at least until you know quantum computers destroy everything so z cache is going to have to do more of these trusted set ups and other projects in the community anyone who wants to use ZK snart's is going to have to do their own trusted set up because for any given statement you need to reduce it into this common reference string so we have a new paper that makes this trusted set up a lot easier which I'll talk about soon so you can create the public parameters or the the common reference string for Z K start schemes with a multi-party computation and this is what we did last year for Z cache we performed a multi-party computation where we had six people that got together and the property of this MPC is that only one of the participants needs to be honest so you'd have to compromise every single one of the participants to compromise the final parameters what is compromising the final parameters mean well it means that you can probably construct false proofs you can't necessarily violate zero knowledge as long as you verify the transcript and so on but it's definitely something that we don't want because in Z cache for example that would allow someone to counterfeit unlimited amounts of money so this is something that really bugs people obviously so now you can imagine that if you add more participants than six then in maybe like a hundred or a thousand it would be way harder to compromise everyone it would be way harder for them all to be colluding in secret but of course in the Z cache ceremony we didn't do that we had six people and there's a reason why so it's very expensive to perform this multi-party computation as you add more participants both logistically and also cryptographically so this is how the old MPC worked we had six people and there's this server in the middle that the coordinator this coordinator is kind of on a beefy beefy server and it has to perform some computations so what the coordinator does is we you know we start this NPC there's a commitment round so every single participant needs to commit to their what we call the toxic-waste but what is really just their randomness that they have to end up destroying at the end they commit to this in advance and then the protocol begins so we there's a this round-robin computation where the coordinator sends about a gigabyte file to Andrew in this case and then Andrew performs a computation that takes about 45 minutes or so and then sends back the result and then the result is you know another gigabyte and then this is sent back to Derek that's another gigabyte another 45 minutes and then you have to bridge air gaps and you have to do all these logistical synchronizations that are very difficult and this just continues on throughout the entire entirety of all the participants then there's a fast Fourier transform a very expensive fast fourier transform we had a really beefy server and it still took an hour to perform or two of them so once once that's done then you do this round-robin thing again and then you actually do it again so that becomes extremely difficult to to manage this as time goes on so the disadvantage is obviously it can't scale to a large number of participants a participant can't abort in this and if a participant aborts it breaks the whole protocol so you have to start over entirely as a result of the fact that you know you can't scale participants can't really take the risk to do you know their own countermeasures and their different operating systems different hardware things like that so they have to you know use the software we give them and so on so that kind of sucks as well coordinating all this is very difficult everyone has to have a ton of time you know planned out in advance we had did it over a weekend that everyone was free shortly before we launched the cache but it is unfortunate so we need to do something better than this and so we've designed this new multi-party computation protocol it's we just published it this week on ePrint it eliminates this commitment round and the point of that obviously is that you can have as many participants as you want and because participants obviously need to maintain custody their Hardware throughout the their participation in this ceremony this is a lot easier to do if they don't have to commit to it and then exist throughout the entire ceremony they can just jump in participate and then leave instantly so this massively reduces the this area of attacks and also helps scale the the protocol so what's really awesome is that per circuit computations for the multi-party computation are really really small and I can explain why so we have these two phases in our protocol there's this first phase called the powers of tau where there's this communal ceremony that takes place that's agnostic to the actual circuit that you're trying to construct the ZK snarks for so it works for all ZK start circuits so this is a communal ceremony that benefits everybody and it can be an extremely large one but it can scale to you know hundreds of thousands of participants it's much more expensive than the phase two but because it's agnostic we can perform at once and everyone can leverage the results then there's a phase two so in your concrete application so for example in Z cash but file coin or whatever other ZK snark application wants to or whatever other applications want to use ZK snart's they have to perform this phase two computation however if they leverage the result of the phase one their particular multi-party computation again can scale to hundreds or thousands of participants and and this is really awesome it's also very cheap you don't have to perform these expensive fast Fourier transforms and and so on and you know all the benefits that that come with this protocol include you know participants don't need to maintain custody or hardware throughout the entire ceremony so it's a lot simpler so there's powers of Tao ceremony we're planning to have the Z cash Foundation host or you know facilitate the execution of this of this ceremony the way it behaves basically everyone can publicly verify that everything took place just as we described it there's a public transcript that's verifiable we give out a tool and everyone can check to make sure it all work correctly so there's no central point of failure here so yeah again it benefits everyone because everyone's NPCs can be sped up significantly so as a summary yes most of the Z key snarks most of the problems with CKD snart's that people point out today are being addressed so performance we've made massive reductions in time and improving memory curb security were bumping security margins up without compromising performance very much and obviously this trusted set up I think that we can with this new multi-party computation protocol and with having so many participants again with you only need one participant to be honest so as this grows to hundreds and thousands of people there's no way that everyone could could have been compromised becomes unrealistic so that I think helps make the the the case that trusted setups are reliable at least for now so there are some things that people I've been working on this new library called bellman which is a Russ library for constructing ZK snarks it has an implementation of all this stuff like stream proving in the graphic protocol and so on it's kind of an alternative to Lib snark it uses the BLS 12:3 81 curve and we're actually gonna build Z cache on top of this bellman library however I really think that a lot of work needs to be done on ESL's for constructing arithmetic circuits right now I don't think anyone has really come up with a perfect mixture of high level and abstraction and so on but you know work by Jakob and other people is very exciting in that area so that's it I'm happy to entertain any questions thank you [Music]