 Hi, so yeah, my name's Sean Bo. I'm an engineer at the Zcash company. Christian just did a really great job explaining how zero knowledge proofs work and how ZK Snarks work. My, the focus of this talk is gonna be on making ZK Snarks work in production software. So obviously at Zcash, we brought ZK Snarks 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 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 setup, obviously, is the biggest thing that I think holds back ZK Snarks 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 people really kind of stress are the reasons why they can't use ZK Snarks in production. Usually has to do with curve security, performance, the trusted setup 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 Zcash. It was designed by our scientists at Zcash and it was just implemented in Ethereum and it's a pairing friendly elliptic curve that originally targeted 128 bit security. However, due to some optimizations to the number field C 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 in the next version of Zcash. 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 in a library called pairing and it's pretty stable implementation. Diego Arana has also implemented it in relic. So this curve is being pairing friendly curve is what we build ZK Snarks on top of. So now the performance improvements. So there are three different things that we're doing at Zcash to improve ZK Snark 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. Which I won't go into in too much detail. It's called streamed proving where the common reference string or the public parameters of the ZK Snarks are loaded from disk as the computation is being performed when you're constructing a proof. So that has led to like 100 times last memory usage during proving. So it's one of the things that ZK Snarks their reputation for using a bunch of memory and taking forever. We're hoping to eliminate that. The last thing that improves on performance is this new jub-jub curve which I'll go into in a second. So as far as proving systems are concerned there are the best one is probably Yens Groth's new 2016 pairing based snark. And 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 modified by the person who created it to violate zero knowledge. And also snarky signatures which are simulation extractable non malleable ZK Snark proofs. So what we're gonna do in Zcash and kind of the path we're taking forward is we're gonna look at the original Groth construction. But obviously we want to prevent malleability and we want to reduce the assumptions. So we have a clear path forward for that and Ariel Gabazon, Yens Groth and Mary Mallard are actually working on that right now. So Groth's original scheme is really efficient so that's kind of why we want to embrace that. So this jub-jub curve, weird name but it's a twisted Edwards curve. It's a special curve that's designed specifically to work for BLS-12381. 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 Snark arithmetic circuits. And so we've reviewed it and optimized it and everything, it's quite a 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 efficient cryptographic primitives, collision-resistant hashes and commitment schemes and signature systems and all sorts of things like that. So that allows us to replace the... We currently use inside of Zcash, 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 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 new curve we've implemented and prototyped it and building software like Zcash and building arithmetic circuits like Zcash, we end up with significantly better performance. Almost five 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 biggest thing that gets people to not really be interested in ZK Snarks is the trusted setup. So when you, we have Starks on the horizon which are trustless and quantum resistant and so on but for now the proofs are still gonna 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 quantum computers destroy everything. So Zcash is going to have to do more of these trusted setups and other projects in the community. Anyone who wants to use ZK Snarks is going to have to do their own trusted setup 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 setup a lot easier which I'll talk about soon. So you can create the public parameters or the common reference string for ZK Snarks schemes with a multi-party computation and this is what we did last year for Zcash. 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 does 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 Zcash, 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 maybe like a hundred or a thousand, it would be way harder to compromise everyone or it would be way harder for them all to be colluding in secret. But of course in the Zcash 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 server and it has to perform some computations. So what the coordinator does is we start this MPC, there's a commitment round. 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 there's 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 another gigabyte and then this is sent back to Derek, that's another gigabyte, another 45 minutes and 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 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 that's done, then you do this round robin thing again and then you actually do it again so it becomes extremely difficult 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 it can't scale, participants can't really take the risk to do their own countermeasures and different operating systems, different hardware, things like that. So they have to 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 planned out in advance. We did it over a weekend that everyone was free shortly before we launched Zcash but it is unfortunate. So we need to do something better than this and so we've designed this new multi-party computation protocol. We just published it this week on E-Print. 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 of their hardware throughout their participation in the 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 surface area of attacks and also helps scale 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 Tao where there's this communal ceremony that takes place that's agnostic to the actual circuit that you're trying to construct ZK Snarks for. So it works for all ZK Snarks circuits. So this is a communal ceremony that benefits everybody and it can be an extremely large one but it can scale to hundreds of thousands of participants. It's much more expensive than the phase two but because it's agnostic we can perform it once and everyone can leverage the results. Then there's a phase two. So in your concrete application, so for example in Zcash but Filecoin or whatever other ZK Snark application wants to, or whatever other applications want to use ZK Snarks 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 this is really awesome. It's also very cheap. You don't have to perform these expensive fast Fourier transforms and so on. And all the benefits that come with this protocol include participants don't need to maintain custody or hardware throughout the entire ceremony. So it's a lot simpler. So this powers of Tau ceremony, we're planning to have the Zcash Foundation host or facilitate the execution of this ceremony. The way it behaves basically everyone can publicly verify that everything took place just as we describe it. There's a public transcript that's verifiable. We give out a tool and everyone can check to make sure it all worked 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 ZK Snarks, most of the problems with ZK Snarks that people point out today are being addressed. So performance, we've made massive reductions in proving time and improving memory. Curve security, we're bumping security margins up without compromising performance very much and obviously this trusted setup. I think that with this new multi-party computation protocol and with having so many participants, again, 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 have been compromised. It becomes unrealistic. So that I think helps make 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 Belman, which is a Rust library for constructing ZK Snarks. It has an implementation of all this stuff, like stream proving and the growth protocol and so on. It's kind of an alternative to LibSnark. It uses the BLS-12381 curve and we're actually gonna build ZCache on top of this Belman library. However, I really think that a lot of work needs to be done on DSLs for constructing arithmetic circuits. Right now I don't think anyone's really come up with a perfect mixture of high level and abstraction and so on, but work by Jacob and other people is very exciting in that area. So that's it. I'm happy to entertain any questions. Thank you.