 So Zcash is a commercially deployed cryptocurrency with real-world usage that provides strong privacy. It's the culmination of several years of academic research, including my PhD thesis. And you're no doubt familiar with cryptocurrency, so you probably know that they're digital payments and that they use a blockchain. What you may not know is that they don't offer any privacy. In fact, quite to the contrary, most of them expose all of your spending details to everybody, to the entire public. And of course, privacy problems with digital payments are not a new thing. It dates back until at least the 1980s when cryptographers started looking at eCash, building electronic payment systems that had the same privacy as paper cash. And cryptographers and computer security researchers have been working on this for a number of years. There's been a lot of interest in progress, but we never really have gotten it deployed. And the reason for that is that if you spin up one of these things, you basically have to get people to trust your new cryptographic bank. And that's sort of a non-starter. So if you think about an ideal eCash scheme, you want it to be secure. This is sort of the same quote non. We want it to be private because we don't want to build a surveillance system that anyone can use to forget what's going on. But it turns out you need it to be decentralized. And this is where cryptocurrencies come in, because Bitcoin provides exactly this, because it has a blockchain that has no single trusted party. But the problem with the blockchain, as Andrew alluded to, is that everything on it is public. And in fact, it's been well known in academia for a while that you can in fact recover what is going on in one of these and figure out what transactions are and who people are paying. And this is not just a problem in theory, it's a problem in practice. There are actually companies in the business of doing this kind of analysis out there today. And so rather than thinking of Bitcoin or cryptocurrencies as private, which is a tempting thing and people have said this in the past, you might want to think of Bitcoin as Twitter for your bank account and that it actually broadcasts everything you do to everybody. And this is not just a problem for personal privacy, it's a problem for businesses. You can't have your competitors seeing what you're doing either. And so this is the thing that needs to be fixed. And this is where eCash comes in. So this talk is going to focus on the past, present, and future of eCash. So in terms of the past, I'm going to give you a little overview of Zerocash, which is the underlying academic work this came out of. It actually was presented at Real World Crypto for the first time anywhere publicly in 2014. Then I'm going to move on to talk about the present, which is the deployed version of the system called Zcash and some interesting lessons and funny anecdotes that came out from that. And then finally, I'm going to talk briefly about what the future looks like both in the near term and potentially in the long term. So Zcash came out of Zerocash. This is a work that was published at Oakland in 2014. And it aimed to provide privacy for a blockchain. And to do this, you need a couple of tools. Obviously, you need a blockchain, but you also need cryptographic commitments. You can think of these as opaque envelopes. And you need, of course, zero knowledge proofs. Particularly, Zerocash uses ZK Snarks. And these are somewhat notorious amongst at least the cryptocurrency people on the internet as being a little difficult to understand. But if you think about them in the right way, they're fairly simple. A ZK Snark is sort of a proof that some computation was done correctly. And the way you do this is you compile that computation down to what is called a quadratic arithmetic program. And you can think of this as like an architecture like x86 or ARM, or really more so something closer to like an FPGA. And then once you have this representation of what you did, you need to prove that it's correct. And you do this using some very complicated cryptography that thankfully for me and for you, I do not need to go into. But there was one interesting caveat, which is that you need to have some parameters that are generated to build these. And this is typical of a lot of research in academia. But as we will see when I get to the actual present of deploying this, you really do have to figure out how to do that. So if you have these tools, right, how do you do payments? Well, in Bitcoin, right, if Alice has $50 and she wants to pay Bob Kane and get back $40 and change, she actually has to identify everything that's going on because you need to enforce some basic constraints on the system, right? You need to ensure that the money exists, that it actually belongs to Alice, and that it hasn't already been spent and that money is not being invented out of anywhere, right? And because this needs to be done, in Bitcoin, everything's public, right? You actually identify all of this information, anybody can look at it and verify it. This is the power of Bitcoin and cryptocurrencies in general, but it means there's no privacy. So to get privacy, the first thing you do is you use commitments, right? You replace these cryptographic checks with a commitment to the exact same information, who the money belongs to and who it's going and the amount. But you still need to get security. And the problem is we can't do the standard style checks that Bitcoin has because we can't just point to what transaction we have, right? That would break privacy. So instead, you generate a merkle tree over the history of all payments starting from T0 all the way up until now. And you say that you have a coin in that merkle tree, right? And then you prove the usual things about it, that it actually belongs to you, right? And then the transaction that is spending it doesn't invent money out of nowhere, right? And finally, right, you have to do one thing that's a little special. Because we only have this indirect reference to what is going on in the blockchain, we can't make sure that the money that we're spending hasn't already been spent, that it hasn't been consumed already. And so we have to, in fact, actually produce a nonce, sort of to prevent replays, and that's a serial number. The cool thing is we do all this, but via the magic of zero-knowledge proofs, all this is hidden. All the ways in which we prove this aren't visible to anybody. But the network is still guaranteed that the transaction is correct, right? And this applies not just to what's on the blockchain, but to anyone who is observing the transaction or even who you're paying. They learn nothing other than that they got a legitimate payment for $10. And so this is zero-cash, right? It is secure, it's private, and it's decentralized. So this is the protocol that we came up with. It is commercially deployed in the present as a thing called Zcash. And this went live in October 2016. Transactions in it for the privacy-preserving ones take about 40 seconds. As a result of this and a couple of other reasons involving legacy interactions with exchanges, it has both private and non-private transactions. About 19% of those transactions are private. It's about 8% by volume. I'd love to give you more usage statistics, but since this is the privacy-preserving system, some of those kind of things are actually hard to come by. But it has more than $15,000 transactions a day. So this is out there. You really can download and use it. But in order to get there, we had to do a couple of things. So remember when I said that ZK Snarks need secure parameter generation? This is a problem because someone has to generate these. And if that person is malicious, they can forge proofs, and therefore they can invent a bunch of money. And there is a fair amount of money you could steal using that technique. You can't break privacy, you can't de-anonymize people, but nonetheless you need to do this. And so what we did was we had a multi-party computation in which there were six people who participated to jointly generate the parameters and then destroy their secrets, and in some cases physically destroy their computers in the process, which is what you see in the picture. And as long as one person is honest, that process works out. So the interesting thing is multi-party computations, the thing you and I are probably quite familiar with, but part of doing this ceremony wasn't an exercise in doing a secure computation and actually generating this thing. It was an exercise in getting people to trust it. It was sort of almost a kind of theater, so you had to film the thing and make sure to make clear to everybody that it worked out because you really wanted people to buy in to trust. So this was done, it was done shortly before Zcash launched, and Zcash actually went live. And this has led to numerous funny things. One of them, incidentally, is one of my co-authors, Ron Turmer, actually got a photo credit in the New York Times, which is not a thing that I particularly expect. That's not even the strangest thing. But I'd like to take a moment here to sort of address the elephant in the room, which is, Zcash provides strong privacy. This is actually a thing that's quite important because a lot of the other technologies that are out there provide privacy that breaks into a lot of cases of real-world usage of things. But when you start talking about strong privacy, one of the things that comes up is sort of criminal usage. And it is true, of course, that you will get things, criminals will use any technology. They use cars to commit crimes, they use cash to do things. But no one talks about banning cars or banning cash. And privacy is important. Individuals need privacy. Businesses need privacy. And in fact, when you sit down and explain to regulators that Bitcoin or cryptocurrencies expose all of your payments to everybody, they sort of understand that you need, by this kind of privacy. And moreover, that the tools we have for dealing with cash, which after all is anonymous, can actually be used to deal with cryptocurrencies, right? The same rules for reporting that apply to banks can apply at exchanges. But it is the case that when you wrote all these things, you will get one or two uses that are in fact criminal. And Zcash actually hasn't had that many of them, but I do just want to mention one of them because it is a funny anecdote. Probably the strangest thing that happened in the course of doing this, which is the shadow brokers who were at one point selling, I think still are, their early access to the, they're stolen in SA exploits. And they were doing this with Bitcoin originally because as I said, criminals will use whatever tools they have available at them, anyone who's doing this use what they have. But at one point, they switched over to using Zcash, right? And in the process of doing this, they had to write an FAQ explaining how to do it. And the shadow brokers, if you read anything they have, write this wonderfully sarcastic, cheesily bad English. And so the description of Zcash included this lovely gem. When asked if Zcash is safe, the response is, expert of no. Zcash is having connections to USG, DARPA, DOD, Johns Hopkins, and Israel. Why is USG sponsoring privacy version of Bitcoin? Who the, knows. Or is knowing, excuse me. Little hard to get that right. And so this is a long way of getting to the following point. Apparently someone actually does read grant acknowledgments because buried in the bottom of the Zcash paper were details on this. So yeah, that's probably the strangest thing that happened. So that's Zcash deployed today. It has real world, it's out there, you can really use it. So where does the future go? Right? Well, the immediate future is a thing that's being called sapling, which is the upgrade from what the protocol is currently out there. This should be deployed in the summer hoping nothing goes wrong. And sapling is primarily a set of performance improvements. It takes the time to generate a transaction from nearly 40 seconds down to four seconds and from nearly three gigs of memory down to 40 megabytes. So this is something you could potentially practically run on a phone. And so how do we get there? Well, the first thing to get there is to understand why it's so expensive in the first place. So under the hood, Zcash is in fact actually quite complex. You don't need to understand the details on this diagram, but everything you see in orange is a hash function call. And it turns out that when you're compiling down your computation for a proof to this, you know, the stock thing that a snark works on, you end up with inefficiencies. And hash functions are well suited for doing this, but they're still slow. And so this is where you get this problem from because you have to do a large number of hash invocations to get Zcash to work. So this is where a thing called jub jub comes in. And jub jub is an elliptic curve whose operations can be efficiently done inside an arithmetic circuit, efficiently done inside a Zcash snark. As a result, you can actually get less than five constraints for this kind of multiplication. You can think of this as sort of a measure of how fast it is. And this, of course, in and of itself, it's not clear what you do with this. But it turns out you can actually build a hash function out of using elliptic curves. And this is a Peterson hash function, similar to a Peterson commitment. And this thing is way faster than standard hash like SHA256 when you're doing it in this funny quap style architecture. So to hash 32 bytes, instead of taking something like 26,000 constraints, and so this is how you get from having proving times in the order of 40 seconds down to like four seconds. So this is very important because this will actually help get real-world usage and end up making people have default transactions that are actually private. So the second thing that has to happen is since we have changed the circuit, we have to regenerate the parameters. Because you have a new thing, you have to rerun this parameter setup process. And we could just rerun the original one, but the original one had some funny limitations. For provable cryptographic security, everyone needed to pre-commit to what they were doing before you started the protocol. And then they needed to keep that commitment around for the entire duration of what's going on. In this myth, you had to pick everyone in advance. You had to pick who was going to run in it. And you had to vet them because if they went offline or they aborted, you'd have to restart the protocol and in particular, because they have to keep their system secure for the entire time that it's running, this caused some interesting problems. The protocol took a little more than a day. And at some point in the day, you're going to have to sleep. So one of the participants actually made what they jokingly called a ninja alarm, which was just posting a chair against the door to see if someone broke into the hotel. This is actually a fascinating story because most of the computation they actually were driving around were all of Canada. Everyone could follow them. Make sure everyone is absolutely sure that there's nothing going wrong. This is, honestly, that someone referred to as desert crypto bus. So this was a nice thing. It was sort of fun to see it happen. But ideally, we wouldn't want to make anyone go through doing this. And so this is where a new protocol comes in, which we are calling powers of power. And this is an improved multi-party computation. It has no pre-commitment phase. In fact, you don't have to pick people in advance. Anyone can participate. In fact, you can participate after the protocol is running. You can join it and come in and do your computation, and then leave. And importantly, because of the way this works, you don't have to keep your system secure while the entire protocol is running. Once you've done your part, you're done. So this makes things way easier. More significantly, parts of this computation can be reused. Not just as a process for generating parameters just for Zcash, the first part of it, it runs in two phases. The first part of it is actually usable across anyone who wants to do a circuit. So this is usable for other blockchain applications such as Ethereum or anything else. And this is significant. This is an important thing to allow people to actually do these and make these things practical. Because again, the entire point of blockchain is to make things trustless. And the wider you have participation in setting up the better the sort of trustless assumption is. Most significantly, this is actually running now. So if you want to participate, you should talk to me after the talk or see this link, which will be repeated again at the end. So that's the current future of Zcash, the present stuff that's going to be coming out recently. What happens in the distant future? There are a couple of different options. Eleban Sasan and Alessandro Chiesa and some other people are working on radically improved zero-knowledge proofs called Z-Case Starks, which don't have this trusted setup. There are other optimizations going on about faster hash functions that might even be faster than jub-jub that other people are doing research on. These are lattice-based or potentially like low-gate count systems. But one thing I want to talk about is a thing that we are tentatively calling zero-knowledge execution. So Zcash enforces a very basic constraint. That the money coming into the system is conserved. That if you have a payment coming in, which is value C, the money going out is not greater than that. So this is a very simple thing to do, but you can envision your zero-knowledge proof enforcing some other arbitrary constraint, a function F. And this is an idea that multiple people have had and has been proposed for smart contracts. So you'd have a function F, you'd have a function G. And you could make these things a standalone process. You could make it such that each one of these things is their own little domain with their own little privacy set. But that ends up being actually quite complicated and problematic in some cases. For example, if F is an auction and you are supposed to bid in it, if you know that no one else has ever submitted a bid, you probably don't want to bid that high. You could deal with just submitting a $1 bid. But on the other hand, the moment you know that someone else has ran this auction code and has participated in your auction, you know you should bid something higher than $1. Maybe your actual value of the asset, I'm not sure. I'm a cartographer, not an economist, but it becomes a problem. So what you really want to do is you want to hide what the function that is executing. And this becomes a challenge because these two functions might interfere with each other. One of them might want to pretend to be the other. One of them might actually be malicious and be intended to actually break the other one. So you still need to somehow keep them isolated while at the same time maintaining privacy. And so this is sort of like moving from a mainframe system in which you have one function that is executing, one program, which owns everything, and moving all the way to a sandbox model for applications, something like an iPhone, where you have a bunch of different mutually distressing processes and you're trying to keep them isolated. But in this case, you also need to maintain privacy from everybody. So this is interesting. I'm quite excited for it, but it is a ways out if it even... It is a ways out. So lastly, I'd like to note that none of this would have been possible without the work of numerous numbers of people, my co-authors on the various papers, this engineers at the company, in fact, I'd specifically like to call them out because in the course of research, people often forget that actually getting this thing from theory to practice is a huge amount of work and involves a huge amount of optimizations. And yeah, you know, everyone had a major part in this and it wouldn't have been possible without them. So in conclusion, I'd like to say that this is real world crypto, right? For all punny definitions of crypto, cryptocurrency or cryptography, right? This is eCash sort of from an academic paper to real world usage in less than three years. I had to double check the math on this from the first presentation in 2014 until when Zcash went live, really seemed to me like it was a lot more time having been involved in that, but turns out it actually took less than we expected. So that's it. Again, I'd like to say if you would like to participate in Paris or Tower, here is the QR code in the link. This will be up for the rest of the Q&A. And thank you. All right, and we do have time for questions, so please go ahead. Dmitry Korotovich, thank you for your talk, Ein. Could you maybe elaborate a bit on the selection of the Pedersen hash? I know that there were some other proposals like dedicated hash functions like MIMC, and maybe you could just give a bit more detail so I'm light why you exactly chose Pedersen. Right, so the Pedersen hash is sort of the conservative choice. So there are a bunch of things that offer more aggressive performance and are quite interesting, but they're reasonably new, and they haven't been subject to a bunch of analysis. So if I were writing just another paper and I wanted to present faster results, I would definitely use those. But if you know you're going to deploy this and you're worried about the extra security with lots of money at stake, you want to be conservative. And so since elliptic curves are well understood and it's a simple matter of sort of optimizing that circuit to compute them, right, it's a little better off for making this the current choice. It's already less than three years, so... Sorry, what? Well, the entire, almost the entire scheme is less than three years old, and it cannot be very conservative after all. Right, so there are some minimal things you have to do to get privacy, and we sort of don't want to try to push the envelope any further. And so this is, four seconds is good enough for what we want to do now, and this doesn't preclude using more advanced functions when they come out. When they've been around for a while longer and we better understand them and understand the choices we have to make for parameters. And four seconds is for two to the 64 points? No, so one of the other interesting things that happened in the course of getting this deployed was the tree depth got cut from 64 to 29, and that is currently still tentatively, tentatively as the emphasis, the tree depth that will be in the new version that's deployed in sapling. Hi, Ian. Hi, Ian. So we just saw two talks. So can you compare the privacy properties offered by Zcash to NimbleWimble? Right, so NimbleWimble is, in general, a bit of a moving target, and it's not a very good idea to do that. But the main thing that NimbleWimble provides is confidential transactions, and those hide the value of a transaction. They do not entirely hide, they do not hide at all who you're paying or who the money is coming from. Now, if you compress the blockchain as you do in NimbleWimble, that data is not necessarily on the blockchain itself. But if you are an observer of the network, you can still see the transactions before they're compressed and build up roughly the exact same picture in Bitcoin, but you have to have been around at the time to do that. So NimbleWimble potentially gets you privacy after the fact when archaeologists just uncovered the blockchain itself 50 years down the road, but it doesn't necessarily get you privacy in the situation we're in now where people are actively observing transactions as they pass through the peer-to-peer network before they get included in a block. Okay, so to be fair, the only thing I know about NimbleWimble is what I saw 20 minutes ago. But I thought there were no identifiers at all. There are no public keys. There are no public keys, but the observation of NimbleWimble is as follows. If you have this compact blockchain, you have to actually eliminate old data. That means at some point there is some leakage on what has been spent. You can't just say, oh, here's the thing and there's no other stuff coming out. There are patterns actually in what's going on. It's very different. Okay, good, thanks. Last question. Yes, go ahead. I didn't hear you mention anything about protecting against network adversaries watching your blockchain. Right, so this is in fact a point that... I guess that wasn't a question. Yeah, so as a note, if you actually use Zcash and you're worried about network adversaries and for some threat models you should be, you need to use Zcash through Tor. And in fact, improving that in terms of the real world protocol is one of the things that people are working on because right now you have to set up Tor as a separate system and connect to it and it's sort of roll your own thing and that's not ideal from a usability standpoint. All right, and with this we'll thank Ian again.