Joe Petrowski: 00:02 Welcome to Relay Chain, a podcast produced by Parity Technologies where we discuss all things Substrate, Polkadot, and Web3. Joe Petrowski: 00:22 Today we have Anna and Deirdre from the Zcash Foundation. Welcome. Anna Kaplan: 00:27 Hi. Deirdre Connolly: 00:27 Hi. Joe Petrowski: 00:28 What brought both of you to the Zcash Foundation in the first place? Anna Kaplan: 00:31 So, I might start. Actually, I'm doing an internship for the Zcash Foundation. And it was actually last year at Zcon where I was talking to the Zcash Foundation and I was like, "Oh, I'm really interested and your work is great. And maybe." And so, this is how I ended up at the Zcash Foundation. And I'm happy that I'm doing this internship actually. Joe Petrowski: 00:53 Okay, so what brought you to Zcon last year? Anna Kaplan: 00:56 Actually, it was I think originally a meetup and then my cryptography stuff that I was doing at my Master's thesis that I was doing. And I was like, "I need to talk to these people." Actually, I was a scholarship attendee last year and I was happy that the Zcash Foundation has scholarships available for people like me, or other people interested. That's really awesome. Deirdre Connolly: 01:19 For myself, I was interested in specifically post-quantum cryptography for the past few years. Basically as a hobby because I was getting more and more into security for my real day job. But, my real day job was not related to cryptography at all and via that I kept going to conferences like Real World Crypto, and Devcon, Crypto Village and making friends on the internet who worked in cryptography. One of them told me the Zcash foundation was looking for their first core engineer hire who would be responsible for taking over a Rust implementation of the Zcash protocol. It was a confluence of interests all in one job and I went for it, and they hired me. Anna Kaplan: 02:03 Yay! Deirdre Connolly: 02:03 And I started for weeks ago. This is my first Zcon. Joe Petrowski: 02:08 Anna, you just helped make the first, or the second Zcash implementation? The first one outside of the Zcash company or Electric Coin Company and Deirdre, you're taking it over. What's the benefit to having multiple clients in the first place? Deirdre Connolly: 02:22 For any independent protocol, you want to make sure that if any multiple parties are trying to operate over this protocol, if you have a single implementation, it's prone to be a single point of failure. One, you want to make sure you don't have a single code base that everyone will be susceptible to a bug, or a wrong implementation of the protocol. But two, if we want diversity over what running that protocol means, in a more general sense, not just a security implementation sense, having more than one implementation is a very good idea. Deirdre Connolly: 02:56 For example, the deployment of TOS across the web ecosystems, to secure anything over web traffic, or internet traffic in general, there used to be ... I don't know if it's still true ... but, a lot of implementations were consolidated around a very few number of implementations of TOS. Such as, open SSL and when a bug happened in open SSL, everyone got bit. Such as, not everyone, but anyone who was using it that was susceptible to the bug, such as something like Heartbleed. So it behooves us as protocol maintainers, as protocol enthusiasts of Zcash, the protocol to have more than one implementation, so that we can distribute our risk as well as we have multiple avenues to develop the protocol as a community so that it's not just one implementation and one version of the protocol getting pushed forward that everyone has to rely on. Anna Kaplan: 03:52 Just in general, like decentralization, with only one protocol, is kind of ironic. That's what we try to not do ... decentralization with decentralized protocol limitations is what we want to achieve. Joe Petrowski: 04:08 You guys gave a talk yesterday and you talked about getting the community involved in the project. Then, we had these breakout sessions in the afternoon and we were in different ones, but in mine ... some people from the Zcash Foundation weren't even aware that the Zebra client was open-source throughout its development. So they weren't watching it and so, naturally my next question was like, if the people in the Zcash Foundation didn't even know about it, or follow it, like they knew it existed, but they didn't know it was open source yet ... what are your plans to get the community engaged? Deirdre Connolly: 04:36 For me, I think that the reason that was true was because we didn't have any engineers or technical people at the foundation who were ready to take over a project like this when it was done. We have given grants to other engineers and other developers who would either continue maintaining those projects after they were done, air quotes 'done'. But this is, I think, one of the first situations with the Foundation, where a project was done and handed over directly to the Foundation. Deirdre Connolly: 05:05 For the future, I'm basically on Twitter all the time. I will be soliciting people to try out new versions, try out new implementations of zips as we upgrade to the new network, upgrade pipelines at least for the immediate future. We will be explicitly advocating to people to go to our open-source repo on GitHub, download the code, try to build it and then eventually we will be distributing packages and binaries and things like that and try them out for us because we are still a small team and we are trying to serve a large community. So we need the help of the community to help us make sure that we are adequately serving them with this implementation. Deirdre Connolly: 05:47 Now that we have a full-time person, whose job it is to do Zebra and push it into the future, I will basically be explicitly asking for help in many different avenues including Zcon, on the internet, on GitHub and so on. Joe Petrowski: 06:02 Okay, so follow Deirdre on Twitter. Deirdre Connolly: 06:04 Yes. I am @durumcrustulum. I have an avatar of a chicken wearing a helmet. Anna Kaplan: 06:12 Which is actually amazing. It's like in all the platforms you have the same avatar. It's nice. We also have the Rocket Chat, which is also nice for everybody who's actually contributing at some point, and is contributing to this open-source project, they can ask us questions in the rocket chat, which is the channels called Zebra Dev and actually it's nice because there's also the Zcash wizards. Also there you ... there's also a lot of questions, just in general about Zcash and there will be questions about Zebra and yeah. I think there you also have the avatar of the chicken with the hat. Deirdre Connolly: 06:45 Yes. Anna Kaplan: 06:46 The helmet is also there. Joe Petrowski: 06:48 Okay. We'll make sure to put links to all these things in the notes. Deirdre Connolly: 06:51 Thanks. Anna Kaplan: 06:52 Thanks. Joe Petrowski: 06:54 Now that we've handed over the client from Parity to a Zcash foundation, what's the state of it? Like, what can it do and what can it not do yet? Deirdre Connolly: 07:01 Technically, it is alpha software because we the foundation just took ownership of a large pile of Rust. Joe Petrowski: 07:08 I think most blockchain software, like Bitcoin and Ethereum, it's all alpha software. Deirdre Connolly: 07:12 Just to make it explicit, this is alpha software. We're still making it ready for us the Foundation to explicitly tell the world "Okay, go run this on main net, put money into it" ... and that sort of thing. For my first four weeks with the Foundation we were prepping for us to take ownership of it and rename some stuff and basically turn it into Zebra. At least from a branding and kind of community standpoint. But also, sending a lot of continuous integration deployment and analysis infrastructure. Deirdre Connolly: 07:40 Currently we are using a GitHub actions pipeline, but we ... that's still not available to us as a GitHub org so I'm still waiting to see whether we can do that in the future. But we're also trying to make these builds faster and trying to get a better fuzzer test suite so that we can do randomized analysis and testing of the software and that will take a little bit of time for us to generate tests that will touch a bunch of code. Deirdre Connolly: 08:08 But, we also are trying to finalize an audit from my end and an audit from one of our research scientists at the Foundation, Henry de Valence , to make sure that we the foundation know exactly what this code is doing and what we want to keep and what we want to clean up before we turn it into mainnet. Right now, what it does, is it runs on mainnet and it runs on test net, but we don't recommend you run it on mainnet yet. But, it works. We don't have ... it's operational up through Sapling. We support Sprout and we support Sapling. We are targeting to get implementation done for the Blossom network upgrade by October when it's supposed to turn on. But, we haven't started that work yet. Deirdre Connolly: 08:50 We plan to go to release 1.0 before Blossom is implemented, but that's a tentative plan. Anna Kaplan: 08:59 Yes. Also, plans on RPC things, maybe like the whole structure's going to be like, we think about how to improve in general RPC things and for now you can do Bitcoin-based RPC and we're thinking to extend and to change that. This is also, I mean ... for example, a cold wallet, all that a developer has to do is talk to us about RPC. So, if you tuned in and you do something where you need RPC stuff, let us know. Anna Kaplan: 09:28 This is something we are thinking about and going to do. Joe Petrowski: 09:32 When you say run, cause obviously sync blocks, but can you send transactions? Transference? Can you do everything? Deirdre Connolly: 09:39 Yes. As far as I know, you can do everything. But, we're not recommending you do that, except on testnet, for the time being. Deirdre Connolly: 09:50 We don't have viewing keys, yet. But neither does Zcash D to my knowledge. Yeah. Joe Petrowski: 09:55 Viewing keys, for what? Deirdre Connolly: 09:57 They're for Sapling. Anna Kaplan: 09:58 For shielded. Deirdre Connolly: 09:59 Yeah, for shielded transactions on Sapling. Joe Petrowski: 10:01 It's been awhile since I ran zcashd. It was before Sapling. Deirdre Connolly: 10:05 Okay. Joe Petrowski: 10:05 But I know I was in the viewing keys and stuff. Deirdre Connolly: 10:08 Oh, okay. Joe Petrowski: 10:10 But, I haven't tried post-Sapling. I'm out of the loop. Anna Kaplan: 10:16 But it’s basically also nice syncing, seeing how you actually see what's happening and also, knowing that there is second node implementation. Deirdre Connolly: 10:27 Our RPC is currently not as extensive as the one in zcashd. It's matching up with the basic Bitcoin operations over the RPC. We don't have a separate compiled CLI the way that zcashd does. You usually use Curl or something like WGet, to hit the RPC locally, or remotely. Part of our goal is to work with, especially wallet developers and see what they need from RPC, but not necessarily add every single little thing that people might think might be useful sometime down the road. Deirdre Connolly: 10:57 We want to keep it useful, but also terse, because the more methods that you support, the more complexity in the parsing layer of your RPC and the less that we have to maintain the better from a security and complexity perspective. We want to be useful, but not a kitchen sink of an RPC. Anna Kaplan: 11:19 Yeah. Also, I think one of the main points is just to have a good secure implementation. So that's why Deirdre's talking so much about, not too much, but very good much and about fuzzing and the build infrastructure. This is just in general, no need to have overhead in RPC as well. Joe Petrowski: 11:38 Yeah, you're getting ahead of me. That was my next question, because in your talk, you mentioned this build-test-deploy benchmark pipeline. Do you have experience with that in other software? Can you talk about what each step of that means? Deirdre Connolly: 11:52 Yes. The way that our pipeline is currently set up, is we run all of our unit tests. We have multiple packages, thanks to the Parity folks, they structured it nice and cleanly, which is very nice. We have multiple Rust packages at the top layer of our repository and we run the tests for all of those. And then the Zebra daemon, the main binary, if all those tests pass, we do a release build of the whole package. If that works and you're on our master branch, we will package that up as a Rust container image, ship that, tag it, ship that over to Google container registry and in parallel, we build our Rust fuzzer binaries. Deirdre Connolly: 12:30 When those binaries are built, those are separate tests from the unit tests. We ship those over to a Google cloud bucket where it gets picked up by our cluster fuzz continuous testing, continuous fuzzing infrastructure app, which is an open source app which Google released a couple of months ago. And you can set it up on your own cloud and it will pick up these binaries and put them into a job and the way that you've defined your fuzzer, it shoves random data into these runners of pieces of your code to see what happens when you just shove random bits into them and executes them. Joe Petrowski: 13:06 We're still in the test phase of this, right? Deirdre Connolly: 13:08 Yes. This is ... we have very few fuzzers at the moment. We want to expand that a great deal because that will basically help us, in theory, automate the generation of tests in a way that manually writing unit tests and having a human think up how to unit-test a piece of code or an API. Things that they wouldn't just think up on their own. They're gonna continue to supplement our existing unit test suite, but in concert with fuzzing. All of those steps basically let us continuously test for every single change on a branch and to master whether all the tests pass, whether the build succeeds for the release profile, and then we use that exact same piece of code to ship it to our container registry and it eventually will be auto-deployed to our testnet clusters. Deirdre Connolly: 14:02 We plan to have testnet clusters of nodes running Zebra in North America, Europe, and Asia, at the very least. When we have our specifically released 1.0 or major releases that we actually tag and say this is 1.0 or 2.0 or the release of Blossom support or something like that, we will automatically be deploying those to run on main net as well and have clusters, hopefully, all over the world to help supplement the network. Joe Petrowski: 14:29 Do you test with testnets of zcashd and Zebra at the same time? Deirdre Connolly: 14:33 Not yet. This is a goal. Anna Kaplan: 14:35 Goals are like, integration testing and also comparing those is a goal we need to achieve at some point. But also, I wanted to add, are we going to then have clusters of Zebras which are going to be Zeals? Deirdre Connolly: 14:50 Yes. We're going to have Zeal North America and Zeal Europe and Zeal Japan and stuff.. Anna Kaplan: 14:57 So if anybody's listening and does not get the joke about the Zeal ... that's the mascot of the Zcash foundation. Our mascot is a zeal, which is a group of zebras. There we are, with clusters of zebras. Joe Petrowski: 15:11 Welcome to Zcon. When you get to the benchmarking phase, what are good benchmarks for a client? Also, an individual build, like on single machine? Versus a benchmark for clients connected to each other. Deirdre Connolly: 15:26 For our builds, it's a little bit of, what your actual runtime restrictions are. For us, in doing everything in Rust, I just rhymed ... our builds by themselves with everything cashed locally are a lot faster than say, the zcashd builds. Because a lot of their code is C and C++ and a little bit of Rust cryptography in there. That is thankfully due to Rust and Cargo being quite excellent. And then on top of it, it's how you are distributing your packages. How are you deploying it? How are you building it for release, and things like that. Deirdre Connolly: 16:04 For us, we're doing it right now, all in docker images and containers and the fact that the resulting builds, the artifacts, and the binaries that we actually release are quite large. They're three to four to five gigabytes of just stuff that we build to actually spit out our Zebra binary. Moving that around between clouds over the internet pipes can take awhile. Deirdre Connolly: 16:26 I was able to get our builds down from 40 to 50 minutes in a kind of smart cached travel CI build, changing nothing else about how we cargo test and cargo build release to 25 minutes on a branch change with a small change. That was very nice and a lot of that is shipping bits around on the internet. There's probably 10 to 15 minutes of that we can shave off if we didn't have to move gigabytes of data around on the internet. Deirdre Connolly: 16:58 Then, in terms of benchmarking, you would like to see how fast it takes for you to validate proofs, to validate generating of your keys, to validate as much as you can that is independent of changing blockchain or public data that comes into your implementation. For example, you would like to test with constantly held parameters, I guess, into these benchmarks. If you are always benchmarking your implementation against a constantly changing blockchain, your benchmarks are gonna vary because there's activity that you can't control happening on the blockchains. Deirdre Connolly: 17:38 People might be shoving tons and tons of data into certain transactions in certain blocks. One time you run your benchmarks and they're really fast and then the next block gets mined and you're just like, what happened to my benchmarks? As much as you can, you want to structure them independent of the blockchain changing. You might snapshot the blockchain if you need to bench like processing of blocks and not necessarily running proofs on them. Then, you run your benchmarks and then, if you decide to upgrade to a future snapshot in the future, you will have to adjust your benchmarks to take account for that. Deirdre Connolly: 18:12 And just be like, "oh, we can't compare our results from the past to what we have now." Because you've completely changed your set of assumptions of what you're testing. Joe Petrowski: 18:21 This would be like two different builds of the clients? Or two different versions? So, you could say, how do these two compare if we have this state and then we just fill the meme pool with all these transactions, how fast do they delete with it? Deirdre Connolly: 18:34 Yeah. Yeah. Joe Petrowski: 18:34 Okay. And the entire network ... how do you test that? Deirdre Connolly: 18:41 I don't have a good answer for that, yet because I'm a little bit new into benching a multi-networked protocol implementation. I have a little bit more experience of a single peer to a single peer to a single peer for TOS or something like that. We'll see. I have a feeling we're going to be running experiments of a cluster of Zebras, a Zeal, and try to have a stand alone experiment of them just trying to overload each other and see when they fall over. And see if we can auto-generate blocks or transactions of maximum size or something like that, and just saturating the peer-to-peer pipes and see what happens. That's less of a benchmark, it's more of a load test of what Zebra can do. If we kinda have benches, or I guess, standards of what we expect Zebra to behave we might set up an integrated test environment of Zebras and zcashd instances and see if we're trying to do this behavior with zcashd, does zcashd fall over? Or are we the bottleneck? Deirdre Connolly: 19:45 Is zcashd better than us? We'll see. That's one way to test that. Anna Kaplan: 19:50 Very much. Also, we can, at some point, have a look at the zcashd testings and timings. They have a whole website up with green, red, orange structures. I don't think we need, like we will see how necessary that is and how helpful that is from a development perspective. I think very much helpful, but maybe users won't check every day. Not sure like a live website, could be fun. Joe Petrowski: 20:20 I think it depends on who you're talking about when you say user. Most of the clients offer the user as another developer or a company, it's not so many ... we're all nerds here, so we use it ... but, most people don't. Deirdre Connolly: 20:38 Not the end user who's trying to just pay with Zcash or accept Zcash. We mean people who are going to take Zebra and integrate it into their own software, or try to deploy it themselves. Joe Petrowski: 20:49 Which is hopefully a lot. Deirdre Connolly: 20:50 Yes. Anna Kaplan: 20:51 Hopefully. Joe Petrowski: 20:53 On the road map, Blossom is next? Deirdre Connolly: 20:55 Yes. Joe Petrowski: 20:56 And can one of you talk about what are the main features, and upgrades? Deirdre Connolly: 21:01 There is a single zip in Blossom and as opposed to Sapling, which was a major overhaul of the proving system and of so many efficiencies and new curves and all sorts of stuff. Blossom has a single zip. There were a lot of other things, if I recall that were originally slated to be part of Blossom and they had to be dropped on the floor because there just wasn't enough bandwidth to implement them in time. Deirdre Connolly: 21:26 I forget what the zip is in Blossom, but I'm pretty sure it's actually quite small in comparison to, for example, Sapling. That's why we are fairly confident in getting a 1.0 release out before Blossom and then also releasing another version that includes the Blossom upgrade. Joe Petrowski: 21:47 What's the name of a baby zebra? Deirdre Connolly: 21:50 Oh god. I don't know. Anna Kaplan: 21:51 Yeah, we don't ... no clue. Joe Petrowski: 21:52 That's what you should call it until 1.0. Anna Kaplan: 21:54 Yeah. Joe Petrowski: 21:54 Until 1.0 Anna Kaplan: 21:56 That would've been a good idea. Like a child zebra would have been also good. Deirdre Connolly: 21:59 A zebrette. Anna Kaplan: 21:59 Yeah. Joe Petrowski: 22:03 Okay we'll take this a little bit less technical now. Anna, you're also studying politics in society? Anna Kaplan: 22:08 Yes. Politics and technology, but I mean that's like kinda- Joe Petrowski: 22:12 Politics and technology. Anna Kaplan: 22:13 Society is technology- Joe Petrowski: 22:17 What do you think will be the political changes due to this technology? Anna Kaplan: 22:23 You mean, technology in the sense of cryptocurrencies in general? Or technology in the sense of preserving technology, like general cryptography for example? Joe Petrowski: 22:30 I was thinking more general cryptography but take your pick. Anna Kaplan: 22:37 Yes, so actually I think that we will be needing to have a lot of cryptography and efficient cryptography in our lives. You can just see how even Facebook and Google start saying privacy is the most important feature for us and are talking about anti-encryption for everything. We see that, okay, apparently we do need a lot of cryptography. The reason for that is ... in my studies we learned about precautionary principal, which I think is very important. In chemistry for example, if you look at a new drug or new pharmaceutical component, you would not deploy that unless you know the risks. Anna Kaplan: 23:18 This is a very easy principle, but has scientists, people explain it in different settings. Actually, this is what EU does for pharmaceutical problems. They would not put that on the market until researchers say, we have these risks. We know what the risks are and we can see the risks. And the problem is, that we just deployed, let's say a lot of technological tools without assessing the risks. I'm not saying that we have to minimize, minimizing the risks is the next step, but just assessing the risks is very important. Anna Kaplan: 23:56 I think this is where we are now and there are people trying to access the risks. When they assess them, they also think about how to increase or decrease the risks. This is where we are going to need a lot of cryptography. And what I'm very excited about is actually the cryptocurrency sphere is talking a lot about Zero Knowledge proofs because of Zcash. Anna Kaplan: 24:20 A lot of people who were doing Ethereum things for example, are like interested in zkSNARKS and starks and what's the difference to bullet proofs and do we want a trusted setup. I think this is so great, but what I also think is there's so much cryptography next to zkSNARKS and zero-knowledge proofs. I would love to see a tech community focusing on a lot of cryptography and trying to put that in real world products. Anna Kaplan: 24:47 Homomorphic encryption, for example, and cool new signatures and multi signatures and all the post quantum things happening, and we need to deploy that into more tech products to get society to not like suffer under the precaution principle which we don't hold up to. Joe Petrowski: 25:09 I think even if the cryptocurrency thing completely goes away there's going to be a huge net positive just because of the money that's been thrown at like, cryptographic research. Anna Kaplan: 25:19 Yeah. Absolutely. Deirdre Connolly: 25:20 That's one of the things that the foundation is, well part of their mission is that one, we are supporting Zcash the protocol, and the Zcash community, but also privacy technology research in general. Carrie, one of our research scientists is doing a lot of research in secure implementations of elliptic curve groups, prime order groups. And that technology can be used way beyond anything related to cryptocurrencies or privacy. It could be used in any usage of a prime-order group in cryptography that doesn't even have to be one that was originally designed for elliptic curves or something like that. Deirdre Connolly: 25:57 I completely agree. If cryptocurrencies come and go, I think there will be a massive trickling out of influence about applying high efficiency technology both pseudonymity from other cryptocurrencies and real private zero knowledge proof-based technology and lessons learned about how to make these things efficient, deployable, usable by real people, and how to make sure that they stay secure in many different situations. Because Zcash uses zero knowledge proofs and zk-SNARKS in a certain way, but that's a different way than the way that Monero tries to stay secure and private. Deirdre Connolly: 26:39 I think it's going to have an influence for a very long time and hopefully for the good. Even hopefully not good if our cryptocurrencies don't live forever and ever. Anna Kaplan: 26:47 That would be very sad, but also, what I was thinking when you were asking question of how society should perceive or not perceive cryptography ... and how cryptography influences. Society, I was thinking that, actually recently I was talking to a professor and there's not that much research in cryptography, but just in general, privacy. She then mentioned that privacy ... different people have a very different definition of privacy. Anna Kaplan: 27:14 When she said it, I was like, "yes. True." I perceive privacy as absolute confidentiality and data minimization. If some part of my data is leaked, I'm like, "oh no, that's so bad." And I think how to minimize the data. She mentioned that a lot of people perceive privacy as control over the data. They're fine with sharing data as long as they have control or they know what's happening- Deirdre Connolly: 27:37 For example, their medical information. They have to share it, but they really want control of to whom and when they actually share it. Anna Kaplan: 27:47 Exactly. And cryptography, enhancing, the first definition of privacy is confidentiality. Whereas, I think we can use tons of cryptography to help everybody who's thinking privacy is control and who thinks it's fine for me putting this picture up on a social network, and I want to help those people. Anna Kaplan: 28:05 We could help those people I think- Joe Petrowski: 28:08 Yeah, I talked about this earlier, with Amber and Patrick from Clover, that there needs to be a lot more privacy by default. You can still give people the option of ... if you don't care about privacy or you don't want it, you can undo it but right now it's like, if you want privacy, you can actually achieve a reasonable level, but you have to have a lot of technical skills. Anna Kaplan: 28:30 Yeah. Joe Petrowski: 28:30 Making that the default on applications is really important. Deirdre Connolly: 28:33 Even if it's not about technical skill, it's not the default, and so a lot of people don't even know about it. Period. Or they won't use it because they just do the golden path, the first thing that they're presented, and that's what they get used to. Deirdre Connolly: 28:45 For example, Venmo payments. You can have them all private and no one knows about it except you and the person you're transacting with. It's not end-to-end encrypted, personal knowledge, or anything like that, but it's just not out there in public for all of your connections to see. People don't realize that they are public by default. They don't realize there's an option to make them private at all. Deirdre Connolly: 29:06 Similar, Facebook Messenger has end-to-end encrypted with the Signal protocol, private conversations. I have a feeling that a lot of people don't know that that exists. You can use that from your mobile device to your mobile device. You can't use it on the web browser implementation of Facebook Messenger, but it exists. It's very secure. They even have excellent cryptographic features to let users report abuse via end-to-end encrypted messages to Facebook and Facebook can't ... you basically unwrap a message to prove that it came from the person that you're reporting against. Deirdre Connolly: 29:42 It's called message franking, that I don't think I've seen in any other end-to-end encrypted messenger. I have a feeling it's not as well known that you can do this on Facebook Messenger and Facebook Messenger's huge. Anna Kaplan: 29:53 Also, I think that's exactly that solution is something that is sometimes overlooked by the community or communities who look at privacy and security. Because a lot of people are like, "oh, you know what, like don't use the social network, don't share this photo," which is absolutely right. I mean, yes, if you really care about this thing you should not. Deirdre Connolly: 30:15 If you don't wanna have a social life. Anna Kaplan: 30:18 And I think that they're like, oh, just use very complicated, this complicated sub tool or something. I think that's very elitist because people have not ... they don't have the skills. They don't have the time and they have a lot of different things they are thinking in their lives and I think it's very important for us to concentrate, to make something usable. That's something the Z Foundation cares about, to have it usable, good cryptocurrency. We're on the path to that. Yeah, it might be a bumpy road, but that's a goal. Joe Petrowski: 30:50 Yeah, I have the impression the Zcash community foundation, in general, puts a lot of thought into stuff like the precautionary principle and stuff like that. I know, I've never worked in application startups before, but before I was in satellite launch, it was like the same thing. Once it's out there, there's not really anything you can do to fix it, and so we kind of have to think the same way with these protocols. Once you put it out there and it's broken, then a lot of people could be fucked. Deirdre Connolly: 31:19 And same with the software. Not even just the protocol. It's like a meme at this point with cryptocurrency stuff is like, this is untrustworthy software. It's a prototype. Do not use this if you care about your money or whatever and then someone forks it and they're like, this is our new cryptocurrency and it's live right now and people put their money into it. Deirdre Connolly: 31:38 That's one of the reasons the software has been in the open since Parity started on it for Zebra, but we want to do our best to say the software from the foundation, we want to make sure that we trust in it before we say, "People, put your money in it," and call it 1.0 and say it's live. It's official. Joe Petrowski: 32:01 Yeah, with this governance stuff and I know they talk about cryptocurrency maybe dying, but- Deirdre Connolly: 32:07 I don't think it's actually dying. I think we're just in a little bit of our own little world. We're always afraid our cool thing is gonna die or something. Joe Petrowski: 32:17 But one of the last things is, I know we talked about TOS earlier, and the bug that affects everybody is that cryptocurrency can actually provide an incentive for people to work on it, which these other open source protocols, you're just counting on some guy doing it on the weekend. Deirdre Connolly: 32:32 Yeah, and for the case of open SSL, the project, it had one or two people working part-time as the people who were maintaining it, even though, major corporations all over the world were extremely relying on it for years. And only when Heartbleed hit did people realize that they were undermanned even though they were a critical part of internet infrastructure. Now, open SSL is a project. It's a completely different beast. They have so much more money, so much more staff, full-time staff, who maintain it, and they've completely cleaned up their code, their documentation. There's still stuff to fix in Open SSL because it's a large complex seed code base, but it's worlds different than what it was when Heartbleed happened. Deirdre Connolly: 33:14 Luckily, in cryptocurrencies, we have all these different structures to finance both the projects and to incentivize people to work on them, and to keep them safe, and make sure that they're secure, and also to make sure that they're fast. Because otherwise people won't use them, and so on, and so on. Joe Petrowski: 33:33 Yeah, so quantum security—one of your passions, Deirdre. Deirdre Connolly: 33:40 Typography is my passion, also, post-quantum cryptography. Joe Petrowski: 33:45 What is the threat of quantum computing because most people think you break the private key and that's it? But what is the real threat model? Deirdre Connolly: 33:52 The real threat model of a sufficiently large efficient quantum computer coming online, mostly, is people logging traffic or other encrypted or protected by asymmetric cryptography in some way, logging a bunch of your data over time, right now. You can just sit on the internet backbone, for example, and just slurp up a bunch of secure ... well, I guess for blockchain, you keep the blockchain history forever and ever. But in the case of, for example, TLS, your connection is secured, established by doing a asymmetric cryptography handshake, such as elliptic curve diffie hellman. And then, from that you derive a symmetric key, and you use that to encrypt all of the messages that you exchange over that channel. Deirdre Connolly: 34:41 Then, you break the connection and all of that data should be, poof. Everything that went over the wire should just be thrown away in the bin, right? But if you're sitting on the wire and just recording all of the encrypted traffic, including all the handshake messages, you can just stick them in your very large database, in your data center in Utah that is being funded by the federal government, and just save that for years until you bring your very large efficient quantum computer online. Deirdre Connolly: 35:05 When you do that, there are multiple quantum attack algorithms for elliptic curve diffie hellman and other pieces of classical cryptography where classical cryptography is everything that we're using now in the real world. Including pairings. Including any kind of diffie hellman, except for supersingular isogeny diffie hellman and there are attacks against symmetric cryptography, such as AES, but they're far less powerful. Deirdre Connolly: 35:30 The threat model is: anyone who can afford to buy or build a sufficiently large quantum computer to efficiently run these algorithms, who has something to attack, such as a store of protected data, like TLS connections, or public data like a blockchain. And then they train their quantum computer to run this algorithm against a key exchange specifically to break the private key of an elliptic curve of a public private key pair or other kinds of diffie hellman or a signature. Or something like that. And then they're like, oh cool, I can decrypt all of that traffic that was encrypted underneath this key exchange, or oh, I can break any part ... so if there are parts of the Sapling private transactions that rely on doing an elliptic curve diffie hellman key exchange. Not a key exchange, but they do a handshake. If they can break that part, and they can break the pairing part, and they can break all these other parts, then they can decrypt your encrypted notes and things like that. Deirdre Connolly: 36:33 They're not gonna become efficient enough to buy one and put it in your house for a very long time, but the way that the research is going amongst the many physicists, and computer architects, and scientists, and theoreticians who are working on this across the world, who are getting a lot of money invested into this, such as IBM and Google, and other companies like D-Wave is someone who has a target, a collection of data, that is possibly high value. Either it's a bunch of TLS connections, or a blockchain, or something similar. Or, if they have a single high value target who they intercepted their hard drive, or their phone, or something like that. Deirdre Connolly: 37:17 They can train their computer on that. The way things are going ... there's a meme among quantum computing that quantum computers have been 10 to 20 years away for 10 to 20 years and they're not quite there yet, but they're never stalling. There's never a lull in the progress between we can break, we can factor a 15, we can factor a composite of two primes, except that composite is 15, then we factor into 3 and 5, like ooh. But, we've got 50 to 100 physical cubit quantum computers now, not D-Wave quantum annealing computers, but real cubit computers now and the progress keeps increasing. Deirdre Connolly: 38:00 It's not Moore's Law increasing, but it's kind of getting there instead of the number of cubits doubling on a processor every 18 months, which is about what Moore's law used to be. I think it's about every 2 years at this rate. So that is the threat from quantum computers. I would say don't rewrite everything and throw it out the window and hide under your bed now. But, don't keep your eye off the ball for the next 10, 20, 30 years. Joe Petrowski: 38:32 And don't put your private data, just encrypted, and put it in a public place? Because you have to assume that will be broken. Deirdre Connolly: 38:39 Yeah. One of the things that people are trying to work on, when trying to develop quantum, new, quantum resistant cryptographic systems is we actually have a lot of theoretically quantum secure systems, like 1 million bit RSA. That is quantum resistant. You are not gonna train your quantum computer against 1 million bit RSA, but no one will use 1 million bit RSA. Not in a blockchain, a private blockchain implementation, not for TLS. Deirdre Connolly: 39:14 Maybe, if you really really need to keep something secure right now, and encrypt it, and put it in a vault or something like that, you could use 1 million bit RSA and that would be fine. It's a one time computation and maybe a one time decryption far in the future and you would probably be safe. We need to figure out, and there's a lot of vigorous work going on in this area, efficient, time-efficient and space-efficient quantum resistant algorithms that can be used to drop in to the applications that we use cryptography in now. Deirdre Connolly: 39:46 There's a lot of interest in replacing key exchanges and signatures. There are many avenues that people are approaching with pluses and minuses. Sometimes they are very fast, but there are huge bytes on the wire, or vice versa. But there still needs to be a lot of work done to find quantum resistant zero knowledge proof systems that are fast and succinct. Joe Petrowski: 40:09 My understanding before was if quantum computers come in and change things, and they can crack these say 256 bit keys, then you just make a bigger key ... but I think you're saying the algorithms are fundamentally different. Like you need to design a new way to make a signature. Deirdre Connolly: 40:25 You can make a bigger key for AES, another symmetric primited. So for hashes, for block ciphers like AES and ChaCha and things like that, you could just basically double the key size. So, for AES 128 you double it to 256 and you're good to go because the best known quantum attack algorithms against those sort of crypto primitives are far less efficient than the ones we have against asymmetric primitives. So the ones that we have for symmetric are called Grover's algorithm and basically it's like a square root speed up against just trying every single permutation you've got. That's why it doubles from 128 to 256 because you have to account for a square root speed up. Deirdre Connolly: 41:06 For asymmetric algorithms, for anything that depends on the discreet log problem or factoring, which includes RSA, diffie hellman elliptic curve stuff, algorithm and variance of it are the biggest threat. They basically, it's not a square root speed up. I forget what it is, but it's much worse. It's like, if you double it, that's not gonna take into account. I think it reduces it by a factor of 10 or something like that. It's ridiculous that I don't have the numbers off the top of my brain. You need a fundamentally different primitive math problem to base your asymmetric cryptography on to be resistant. Deirdre Connolly: 41:48 For example, the leading candidates for asymmetric key exchange includes lattice based cryptography, things like LWE and other variants. There is isogeny based cryptography. There's also systems, other post-quantum systems, based on hashes and codes, and I think there's one more ... multi-variant. Multi-variant is the other one. But the big ones for key exchange right now are basically lattices and isogenies. Lattice is because they're extremely fast. Isogeny based because the keys that you actually put on the wire are extremely small. Deirdre Connolly: 42:23 Those are based on fundamentally different mathematical assumptions that are assumed to be difficult for quantum computers to attack. And by difficult, I mean, we have not discovered a quantum algorithm, that we run on the quantum computer, that is efficient against trying to break these cryptographic systems. So that's not to say that we will never find an algorithm that runs on a quantum computer, or a classical computer to attack these new possibly quantum resistant problems, but for lattices and for isogenies, but there's been a minimum of 20 years of research to see if we can find something to break them and so far we haven't. Anna Kaplan: 42:59 I really like that you say quantum-resistant because there's these algorithms and these primitives are ... a lot of people in cryptography call them post-quantum, which I always found weird because the ideas that we use current day classical computers to use these algorithms, to secure our data now with these problems that Deirdre's mentioned, like lattice-based or isogeny-based things. This is called post-quantum because it's secure in a post-quantum world against quantum computers. But I think quantum-resistant is a much better term. Anna Kaplan: 43:31 Quantum algorithms though, are actually algorithms for quantum computers to secure data- Deirdre Connolly: 43:37 And people are working on quantum computing, not just to break all the cryptography we use today. Quantum computing, theoretically, will be very useful for simulating complex processes such as protein folding, which can be very useful for medicine and pharmaceuticals, for fluid dynamic simulation, and for weather simulations, and nuclear physics simulations. Things that we throw lots and lots of data-centered compute at now and do okay. But, if we can get a quantum computer who has this fundamental quantum physical interactions which are more closely related to the systems that they're trying to model and process, that's a bigger reason that people are trying to develop these computers. Not just because they ha ha, they're stealing all your data and stockpiling it and trying to decrypt it later. They're not trying to attack all the cryptocurrencies and steal all your data. Deirdre Connolly: 44:29 That is not a wise investment. Like we're just gonna invest in quantum computing and break all the blockchains. There may be certain parties that have three letter acronyms that are trying, that have this sort of purpose in the back of their brain, but that is not generally where most of the investment in the broader community, business community seems to be. It seems to be for these other more generic purposes. Anna Kaplan: 44:50 Should we turn the Zcash Foundation to a quantum organization? Deirdre Connolly: 44:55 I don't think we have that much money or expertise. Anna Kaplan: 44:59 As you see, the Zcash Foundation itself, everyone's very keen on any kind of cryptography and we're interested in what's happening. So don't worry, we're not going to do quantum computer stuff. We're just interested. It's really cool. Deirdre Connolly: 45:14 And mostly, for example, we had a speaker here at the end of the morning session here at Zcon 1 where he was accessing a new result about a different construction of snark that is based completely on symmetric primitives. So it's all hashes and other random oracle stuff. So that means theoretically it is completely quantum-resistant to all known attacks. We have other snarks and starks ... not starks. We have other snarks, but they're all based on classical asymmetric assumptions at the moment. Things like pairings that are used in Sapling and stuff like that. Deirdre Connolly: 45:50 There are starks, which are not used in Zcash, that are also theoretically quantum-resistant because they're also completely based on symmetric primitives. But to have another one with a good security proof behind it is very exciting. Part of my interest at the foundation is to keep an eye on the evolution of zero knowledge proofs that may be quantum-resistant and see how they may be applicable in Zcash as we evolve the protocol itself, or in a similar kind of Zcash adjacent application. Either in a cryptocurrency or the privacy technology. If they prove to be efficient and useful, now. Because if they are similarly fast, similarly succinct, as what we're using now that's all classical based, I see no reason to experiment with that adoption of a possibly quantum-resistant primitive. Deirdre Connolly: 46:46 We'll see. We'll see how it goes. Joe Petrowski: 46:49 Is there anything else that you guys wanna talk about? Anna Kaplan: 46:52 Actually, how is it at Parity now? Is there a huge duel between two podcasts, Joe? Joe Petrowski: 47:02 I don't think so because this was Fred's idea. Joe Petrowski: 47:06 Zero Knowledge started like 2 years ago, and Fred was like, we should have a Parity podcast, and everybody ignored him. He and Anna were just like we're gonna start it ourselves, and then 2 years later, I think Fred said again, we should have a Parity podcast and we said okay. And we're actually using Fred's personal microphones and recording equipment, so— Deirdre Connolly: 47:30 Thanks Fred. Joe Petrowski: 47:31 Yeah, thanks Fred. I don't think there's too much of a duel here. Otherwise he would not have given them to me. Deirdre Connolly: 47:36 I just wanna say, thank you Parity for giving us Parity Zcash, now that we're calling it Zebra. Without you we wouldn't be where we are. Anna Kaplan: 47:45 Big thanks. Joe Petrowski: 47:46 Thanks to you guys for coming on and for Zcon. It's really fun. It's an exercise for the listener to go look up the name of a baby zebra. Anna Kaplan: 47:56 And tell us, later. Joe Petrowski: 47:58 Send us back, yes. Deirdre Connolly: 47:59 Thank you very much. Joe Petrowski: 48:03 Thanks for listening to Relay Chain. We'd love to keep in touch. Follow us on Twitter @RelayChain or email podcast@parity.io Joe Petrowski: 48:11 Our team at Parity includes some of the leading peer-to-peer networking developers, consensus algorithm inventors, blockchain innovators and Rust developers. If you want to learn more about our work or want to work with us, visit our website at parity.io and sign up for our newsletter at parity.io/newsletter.