 speaker for tonight is Sven Halberg and he's going to talk about Zcash anonymous cryptocurrency. The subtitle of this talk is zero-knowledge succinct non-interactive arguments of knowledge for laypeople. If there are laypeople who could memorize that and can repeat, you get karma points. Sven is a mathematician, a coder, a cryptographer. He also does functional programming in C, which probably makes him the person you might want to listen to. Please, a round of applause for Sven. Thank you. Thanks for the introduction. Yeah, thank you all for coming. So the short version of the subtitle is ZK Snarks for the interested layperson. Quick check. Has anybody from the audience heard the term ZK Snark before? Oh, that's more than I expected. Okay. So at the end of this talk, hopefully, you will know how these things can be used to build a cryptocurrency, which is kind of like Bitcoin, but has better privacy and anonymity properties. Little disclaimer, I won't be able to explain to you how the ZK Snarks work. So please don't be too disappointed by that. That will be another talk for next year, maybe. All right. So let's start right. Zcash is, like I said, it's a cryptocurrency, magic internet money. Kind of like Bitcoin is, in fact, based on the Bitcoin code base. So it's kind of like an altcoin that you may know. But other than a lot of other coins, it actually adds a substantial new feature to the protocol. And that is mainly a new type of transaction that is capable of shielding the sender, the receiver, and the amount of money being transferred. Now, this type of transaction lives next to the regular Bitcoin type transaction. So you actually have two types of addresses. One is it's called a transparent address. It starts with a T and a new type of address that starts with a Z or Z, which gets used by the new type of transactions. And yes, like I already said, it uses these so-called Zcash Snarks, which are relatively recent kind of mathematical magic, as I like to say. I think the earliest 2010 is the earliest citation from the Zcash spec. Yeah. For a little bit of history, Zcash is an evolution, basically, of two academic proposals. One called zero coin, which was still pretty different from Zcash. And the other is called zero cash. And that is already almost like Zcash. So you could consider Zcash an implementation of zero cash with some refinements and improvements. Now, the number of the inventors of zero cash and a number of other people have formed a company in order to actually get this system off the ground as its own altcoin. And I'm told they are also in the process of forming a nonprofit foundation to govern the future development or something. A little disclaimer, I am not affiliated with any of these entities. I'm just interested bystander who happens to think he can explain this stuff a little bit. So because we don't have so much time, this talk is going to focus entirely on the technical aspect. There are also other interesting questions, but I just want to explain how does the system work in the abstract? What do the transactions look like? What exactly is being hidden? What isn't hidden maybe? And how can you verify even the validity of a transaction if you know almost nothing about it? And lastly, it will then become clear where the ZK Snarks come in. So if you know Bitcoin, this is just a recap. This is a Bitcoin transaction. Sorry. So imagine Bitcoin. I don't want to go into blockchain or any of that here because we don't need to. Please imagine Bitcoin just as a long list of transactions that is publicly verified, that is entirely enough for this talk. Because the Bitcoin system is basically transferred over for the transparent world, we can just focus on an individual transaction. So this is one single Bitcoin transaction of which you have a long list in the world. And each transaction takes a number of input amounts from previous transactions and then declares a number of output amounts to some receiver addresses. And in order for this transaction to be valid, you need most of all, well, these two things, you need to show that you actually have authority to spend the inputs and you need to make sure that, well, the input amounts balance with the output amounts, right? Now, like I've already alluded to with Zcash, the picture looks almost exactly the same, except there's a new block at the end of the transaction that adds some things called joint splits. And yeah, what these are and how you can verify and prove their validity is the main topic. So let's jump right in. What does a joint split look like? So as a major difference from Bitcoin, value in these new Zcash transactions is actually transferred in the form of virtual coins. That's kind of ironic because Bitcoin, despite the name, doesn't actually contain any sort of coin concept anywhere. Here we have that. And you can see from the picture that each joint split takes two coins as inputs and it generates two coins as outputs. So the input coins are consumed and no longer valid at the end and two new coins come into existence. So why two? Just really quickly, that's because that is general enough for anything. If you just want to consume one coin, you set the other to zero. If you just want to produce one, you set the other to zero. And if you want to consume more or create more, you just combine multiple of these joint splits in the same transaction. Okay. And now the important part, each such virtual coin has what's called a plain text that is basically a tuple of values that contains the information about that coin, namely its owner, its value, and some technical values that we'll get back to. And this stuff is kept secret. It is known by the owner of the coin, but nobody else. The only things that are published actually in the blockchain, as part of the joint split statement, are these so-called nullifiers on the left here and commitments on the right. Don't worry so much about what those are for the moment, but these are just numbers that are uniquely derived from the coin, from the coin plain text. And yeah, the nullifiers are always used when spending the coin, and the commitments are always used to create the, to bring the coin into existence. So since these numbers are different, and they are actually derived in such a way that they cannot be matched to each other, you can't immediately trace a transaction, right? And this is called a nullifier simply because it nullifies, it is a value that essentially nullifies the coin, right? It gets consumed after that, it is no longer a valid coin. And the way this works is really simple. I can explain this on this picture. Each node in the network simply keeps a list of all the nullifiers it has ever seen, and it keeps a list of all the commitments it has ever seen. And when a new joint split comes in, it simply checks the nullifiers against the list it has already seen, and only if it is nowhere in there, this is a coin that's still valid. So that's really simple. This is double spending protection, very important obviously, but that doesn't require any magic yet. And what requires magic is, well, checking that I don't pull these numbers out of thin air, that they actually correspond to actual coins and that everything balances out, the values need to balance, I actually need to be the owner of the coins and so on, and explaining how that works is the rest of the talk. So this is what the joint split looks like in less of a picturesque form, more of a formal form, this is actually from the paper, with slight adaptations for readability. You can see there are a number of values we're not interested in most of them, but you can see the two nullifiers here for the input coins, and you see the commitments for the output coins, and then you see a value called RT. That is a number that uniquely identifies the set of commitments in existence at that moment, so it establishes the context for the nullifiers, for instance. If you know what a merkle tree is, this is actually the root of a merkle hash tree. If you don't know what a merkle tree is, don't worry, simply think of it as a number that uniquely identifies the set of coins in existence. And then lastly, the interesting and most important part, away at the end here, that little pi is a so-called proof of validity, and that is just a simple number that somehow with some process is supposed to convince us that this transaction is valid and conforms to all the conditions we expect from a valid transaction. To kind of motivate how that could work without going into too much detail right now, imagine if I could convince somebody that I simply know the note plain texts for four notes, the two input notes, and the two output notes. If I can convince somebody that I have these plain texts and that these two nullifier values do correspond to the two input coins, and these two commitments do correspond to the two output coins, and the values balance out, and the two input coins actually exist in this merkle tree here, then this is right, this is already intuitively, yeah, this is convincing of some sort. And that is basically the game plan for us. And to make that more precise, yeah, will be our job. Now really quickly, the titular ZK Snarks, it's already been introduced, what it stands for, it's a zero-knowledge succinct, non-interactive argument of knowledge, so this black box lets us do what I just alluded to, perform that proof that we know these note plain texts, and that they also satisfy our requirements. And this is the abstract API really simplified of a ZK Snark system. Maybe a little caveat, there are multiple constructions of ZK Snarks, not a single one, but so we're talking about the one that is used in ZK, Zcash. So at first there's a one-time setup procedure, this is by the way a concept of some interest, but we also don't have time for that one. This was actually done a week prior to the launch of Zcash, this setup procedure, and it's a very interesting story. If you want to read it, there are several people involved in there and they have written accounts on how it all went, so that's really interesting, but we have to skip it unfortunately. And then we have this proof procedure that we give some inputs, in our case the note plain texts, and it generates this little Pi value that we can put into the verify procedure, notably without the input, and if that returns true, we should be convinced that the prover knows this input such that it satisfies the statement that we set the whole thing up for. And then you just put into a Lipsnark, it is literally on GitHub, and your system works, hopefully. All right. So to make this all concrete, the so-called joint split statement, this is the collection of conditions for validity of a transaction. So it is basically what I already said, the prover knows four notes that satisfy these things. Each note consists of four values, that is the address of the owner, the value of the note, a pseudo random number called row, another random number called r, these are of technical interest, we'll kind of gloss over that, and these should satisfy the statement that the input notes appear somewhere in our Merkel tree of existing notes. The nullifiers correspond to the inputs, the commitments correspond to the outputs, the values balance, and we also have spend authority for the inputs, and then non-malleability and uniqueness of row are more technical. Non-malleability means that this joint split, this proof is uniquely tied to this particular joint split, and uniqueness of row is similar for the pseudo random number that has to be actually pseudo random. All right. So, sorry, let's go back for one second. How do we encode this in a form that the ZK snark system can actually make sense of it? So if there are any programmers in the audience, you know how to encode lots of things in some sorts of code, and this picture on the next slide probably look familiar to many. This is a Boolean logic or a circuit diagram of a Boolean circuit that computes some logical function. This is just a stupid toy example, of course, that takes some inputs on the left, and then these Boolean values run along these wires are combined by these gates here, and you get some output value to the right. Now, you know this is enough to do all the things in your computer, so this could be intuitive as a way of encoding things. However, it turns out Booleans are mathematically not that nice because everything immediately collapses to zero or one. So what the ZK snarks and Zcash actually uses a variant called an arithmetic circuit, where the values along the wires are actual full-blown numbers, and the gates perform the arithmetic basic operations of addition or multiplication. So this is another toy example as a circuit for adding two numbers and squaring them and then multiplying by a third number. And as it turns out, we can use these arithmetic circuits also to represent Boolean operations. This is multiplication, and if you consider the inputs restricted simply to the set of values zero or one, the output is also zero or one, and it is one if and only if both inputs are one. So that's Boolean AND. Here's Boolean NOT, that's the function one minus X, that is zero if X is one, and it's one if X is zero. So we can do a lot with these circuits. We can encode all kinds of, well, expressions or functions in them, but what we have in our joint split statement are actually conditions, right? Things like this value has to equal that value or the sum of that value or so. So how do we get there? For that we need to introduce the concept of satisfiability. So again, this arithmetic circuit, we call it satisfiable if we can find an assignment for the input values here such that the output becomes zero. Why zero? Because that immediately leads us to satisfiability of equations. So consider maybe this equation at the top here. If we want to know whether this is satisfiable by some assignment to X, Y, and Z, well, do your high school math. Instead of talking about equality about the two sides being equal, talk about the difference between the two sides being zero. So just transform it like this, build an arithmetic circuit to represent the left side, and then talk about satisfiability of that circuit so that this left-hand side becomes zero and then you know that these values satisfy that equation. And ZK Snarks not just allow you to prove well, satisfiability itself and that is existence of any assignment that satisfies it, but it allows us to prove knowledge of the actual assignment. So our note play texts. So this is kind of our game plan. You probably have a picture now. Our plan is to encode the joint split statement that you've seen in formal equations and such, then turn all those into an arithmetic circuit, plug that into our Lipsnark and use it to prove knowledge of the notes such that the circuit is satisfied. Now, if we want to think back, what is it actually that we have to encode in the joint split? What are the ingredients? I said something about a hash tree, these commitments involved, and I mentioned a pseudo-random function. Finally, for the balance, we need regular arithmetic. So the first three of these are actually all instantiated with a hash function that you know, SHA256. So we basically just need to build an arithmetic circuit for SHA256 and then the rest is variations of that. SHA256, if you've ever seen a description of it, contains lots of binary operations or arithmetic on binary numbers. And so the Zcash implementation or zero cache actually chooses the route of representing all the numbers natively as binary. So if you have, say, a 32-bit number, you take 32 wires, each of them carrying only a zero or one. And only if you need the actual direct representation, let's say for your balance arithmetic, you convert that with an arithmetic circuit that simply computes the value of the binary representation with the regular formula there. And you can also go back with a little trick that I don't want to get into, so it's not too confused. And you can also do a thing like, well, bit shifting or other permutations of the bits simply by, well, permuting the wiring in the correct way. So this will be a bit shift by two. You get the values in at the bottom and then, yeah, reroute everything two places to the right. And so this should already give you a good idea of what to do. You just need to look up SHA256, take all the pieces, transform them all into these arithmetic circuits, just combine everything together. And when you're done, it looks something like this. So this is from the zero cache paper. They have this wonderful salad in there, which is basically just, you know, boil it all down. So at the age here that SHA256, you see that a lot, but actually not that much more. There's this concatenation, right? This bar, there are some constants and there's regular arithmetic numbers. So this down here is the balancing and some values plus some other values have to equal some values. Here's a check for overflow. That's also easy to represent. If you think about it, here is the condition that the commitments are formed correctly. Here's the nullifier being formed correctly. The only thing that's missing from this picture is the Merkle tree lookup, because that didn't fit on a single line, so they don't have it in the paper. Too bad. Yeah. But that's basically it. So I think we have like seven minutes for questions. We'll do a short Q&A right now. Please come up to the microphones. Number four. Assuming that there is a bug and that someone can, I mean, create money out of Finnair using this is there a way that the community can at some point see that there is much more Z-coin than then there should be. So not immediately, and this is actually one of the big dangers. So it's a very good question. One thing that you can see, if you remember the slide with the joint split statement, you can see when coins are created and you can see when they are spent. So at any time the system has a picture of how many coins have been created so far and how many coins have already been spent. But it's not that, of course, doesn't give you exactly what you want. And there has actually been talk about extending the system in the future to include a sort of regular account where every node is required to regularly transfer all their money into the transparent world and then at their leisure transfer them back. So it wouldn't actually hurt your anonymity, but that's not in there yet. Thank you. One question from the internet. Is a split of the chain in Zcash possible? A fork, you mean? Yes. That would work exactly as in Bitcoin. So yeah, all the conditions and everything are enforced by the same sort of consensus mechanism as in Bitcoin. And the last one, microphone number eight. Yes. I was wondering if you've kind of looked at the funding aspect and the ethical aspect and the algorithm of Zcash. And I was wondering what you think about those because when I looked at how they're funded and how the algorithm is collecting money for the developers and for the investors, I found that in the first four years, 20% of all the coins will go to the developers and the investors. And after that, it stops and the total amount that will ever be made of coins, 10% of those will then be for the developers and the investors. What do you think ethically about the choice they make there because they are kind of algorithmically programming the inequality there? Well, okay. So I can of course only speak from my own interpretation of this and I will admit I didn't look at it too closely because I was mostly interested in the technical side. But the way I interpret it is that I think they did this way that in order to have an alternative that's better than a pre-mine. I think they didn't want to do the pre-mining thing that some currencies do where the initial developers just generate a bunch of coins that then they own. And they also have the slow start mining, which I couldn't mention. That means that the first few blocks, I don't know how many, the mining reward is lower and it slowly ramps up. And I think they did those things in order to avoid a situation where the developers have a lot of power concentrated in the beginning. And I think this founder's reward that you mentioned where it is put into the algorithm that for the first four years they get a percentage of all the mined coins is basically to just balance that out, to do that in a fashion that's transparent. I think that's the intention. Apart from that, you said about basically algorithmically making this choice. So how do I interpret that ethically? I would say, well, it is put by them into the algorithm, but it's still the network consensus that confirms it. So there's absolutely nothing stopping the network to democratically decide we want only half the share for the founders or no share at all. And there's an alternative Zcash, I don't know if it took off or not, that just simply rips out the founders reward. And there's also another one that simply that replaces it with something else entirely. So there's a big discussion to be had about that. And I think it's pretty interesting, but that's basically my interpretation. Thank you. One more question, Mike Seven. Yes, you already went into this a little bit, but I wonder what alternative zero cash solutions you have looked into, because for example, there exists Monero, which is based on a different hashing algorithm, I guess, but I don't really know the differences. Yeah, I have to admit, I am not familiar with Monero. I know only that Monero uses something called ring signatures. So there's some math magic in there as well, but I haven't looked at the differences to that. I'm guessing that the privacy guarantees that they can make are less strong than the ones in Zcash, but I don't know the details. And this is it for tonight. Please, the round of applause for our last talk.