 Thanks everybody for joining. So in this talk, I'm going to talk about journalist proofs and getting practical when they're getting practical nowadays. So I am Avradip and over here with me, we have Mike who is also present in the session. So in this talk, we're going to cover the following. So we'll give a very high level introduction on what are journalists proofs. And we also see that there's a slight difference between proof of statement versus knowledge and the difference between interactive proofs and non-interactive proofs, how and how they can interactive ones can be converted to the non-interactive ones. Then we'll talk about different view knowledge frameworks and their adaptations in practice, such as snarks, grid proofs, tarps, plongs, et cetera. And lastly, we'll say talk about the state of the current journalist implementation in hyper leisure. So this is a classic example of journalist proofs is Alibaba Kiv. So we have the Peggy, who is the prover and she also proved to Victor who is the very fair that she knows a secret passphrase to open a magic door. But Peggy doesn't want to reveal any information about the passphrase. So here, we have the cave. So in the cave, so at first, the Peggy enters the cave. So in the cave, it's like the door isn't the end. And you can reach the door either through A or through path A or through path B. And initially, the very fair Victor stands outside and Peggy enters and she randomly chooses one of the paths. And once she reaches the door, at that time, the Victor enters the entrance of the cave. And from there, she tells Peggy to come back by taking one of the paths, either A or B and he chooses it randomly. And then if Peggy actually knows the passphrase, the door will open and then she can come back using A, the path A. So Peggy can also get lucky that Victor will say the path B and Peggy was here and in that case, she doesn't need to know the passphrase and she can come back. But this protocol can be repeated many times and if Peggy succeeds at every iteration, then Victor gets really convinced that Peggy actually knows the passphrase. And the Victor also doesn't really get to know the passphrase because he cannot hear what Peggy is saying. So the previous protocol was non-interactive. The previous protocol is actually interactive. But in the real-life scenario, if we can have a non-interactive drone as proof, that is much more helpful. In case of non-interactive proofs, there is no need of interaction between the prover and the verifier. The prover computes a proof and sends the proof to verifier. And verifier then verifies the proof and convinces itself about the prover's claim. And any interactive zero-knowledge protocol can be made non-interactive using Fiat-Shamilk heuristic that actually uses a hash function as a random record. And what it essentially does is whenever the prover, sorry, the verifier sends some random challenge, the prover can actually simulate those challenges using the random record. So now we have a little bit more mathematical formal definition of zero-knowledge. So here, suppose the LR is an NP language. That means for if there is an X in LR, then there exists some witness W such that XW belongs to the NP relation R. So if you recall the property of NP is given the language element X and the witness W, it is easy to verify whether the XW actually belongs to the relation. However, if it is, if you are given only the only X, then finding the witness becomes very difficult. And in this case, we want to, the prover wants to prove that the statement X is actually belongs to the language. And he knows the, he or she knows the witness W. And using this witness W, he can create the proof Pi X. And using the proof Pi X, the verifier can convince itself that X actually belongs to the language L. But the zero-knowledge property guarantees that this Pi doesn't leak any information about W. And to implement these zero-knowledge protocols, in many cases, we also have a common reference string, CRS, which are generated by some trusted entity. And there is also, so this is the regular zero-knowledge, and there is also proof of knowledge that is important in many applications. And in case of proof of knowledge, the verifier convinces itself that not only that X belongs to the relation, that prover also knows the witness W. And again, as usual, the verifier does not get any information about W. Now, the zero-knowledge protocols were, they just observed for all relations were invented long time back in early nineties. However, they become practical recently with the advent of Zika Snarks. So the Zika Snarks are zero-knowledge, a synced knowledge movement of the knowledge. And they are based on strong number theory of cryptographic assumption, which are non-falsifiable. And this is actually the first practical zero-knowledge for framework that can handle pretty much any arbitrary computation. However, as you can see on the left-hand follow charts, writing a Zika Snark, developing a Zika Snark for framework is not easy. It has, it goes through many steps. The first step, you have the competition circuit, the actual competition you want to perform. And from that, you need to create an algebraic circuit and that becomes, that gets converted to R1CS, which is rank one constraint system. And after that, you have that get converted to QAP, which are called quadratic arithmetic programs. And then you have linear PCPs or probabilistic TKL proofs and that becomes linear interactive proofs. And then finally, you can have the non-interactive Zika Snark. But we have the Zika Snark framework that can handle almost everything. For the end user, we don't need to know all the details. So Live Snark is the presented that is the defect to Zika Snark library. It is written in C++. And it is actually probably the most feature-complete journalist library available. And it supports many formats such as R1CS, BSCS, USCS, TBCS, et cetera. And you can also write arbitrary C code and that can be compiled to Tinyram format, which is supported by Live Snark. And it also helps the gadget libraries that helps building R1CS circuits. And there are also choice of different elliptic curves. And it implements the original Zika Snark paper as well as newer Rothstein paper, which is slightly faster, but requires stronger, stronger generic group assumptions. We also have the other Zika Snark libraries, such as Bellman, which is a popular Zika Snark implementation in Rust and it supports Rothsystem. And this is actually getting used in Zikash. And then there are Zocrets. So Zocrets is a Zika Snark toolbox on Ethereum blockchain. And it kind of gives a high-level, non-turing, complete language that simplifies the circuit specifications because if you're using Bellman or Live Snark, we pretty much have to deal with R1CS circuits. And this library is also written in Rusts and it supports Bellman and Live Snark as the backend. And there is also Ziknark, which is a first Zika Snark library written in Go. This also offers some very high-level APIs and there are also others, Ziknark, Snarky, et cetera. So before going into various in the other frameworks, just this slide explains how the journalist frameworks works at a high level. So they usually have two components. One is front-end and there is another as backend. So they are kind of the separate parts of the framework. So the front-end takes the high-level statement and it also takes the high-level witness. And there's a syntax of these things that depends on the actual front-end framework. And they also can use the gadgets to help the end user to specify the statements. And then in the backend, it takes very specific type of formats, either R1CS or arithmetic circuit or Boolean circuits. And this backend takes this low-level statement that witnesses and this actually has the actual core crypto and they generate the proof. And then in the verifier, it again takes the low-level statements and low-level statements as well as the proof. It doesn't take the witness. The witness is the private, that is used by the prover. And then it verifies the proof. So I don't go into the details on what exactly is the rank one constant system, but essentially they can be specified by some matrices and some, it is just ensure there exists a witness such that this condition holds. And what is important about the R1CS, this is an NP-complete language. So anything in almost anything that you're interested in doing can be represented in this R1CS format. Now in terms of the application, so Zcash is the, I guess most of you know about what is Zcash. This is the similar to Bitcoin. Cryptocurrency is similar to Bitcoin, but it enhances the privacy guarantees. And essentially it ensures that the wallet address can be shielded if the user wants and only visible info would be the transaction timestamp. However, there are heuristic attacks because of small number of shielded transactions, but in this talk we don't go into that. But first important that it has the option of selecting these flows for our voting purposes and previous version of Zcash used to leave Snack. And then I think from 2018 they moved to Bellman and now which support the Roth 16 proofing systems and implementation trust. And one thing that is kind of a drawback of Snack is that they require a trusted parameter generation at the set of phase. And to achieve the distributed trust, Zcash used the public parameters with NPCs. Well, that's mostly, right? Not all snorkels require trusted setups, but a lot of them do. Yes, exactly. And I mean, not all Juno's framework this requires this trusted setup, but the leave Snack like the Snack. So that there are other frameworks that do that do not, such as good proof and stocks. But Zcash is using this Snack from Bellman and it requires the trusted setup. And to achieve this trusted setup, they are doing this NPC ceremonies and it guarantee that as long as one of the participant is honest, the generated parameters can be trusted. And the first set of parameters were generated in 2016 and then they moved to growth 16 and it was Bellman and that required a new set of parameters and those parameters were generated in 2018. And both of them, both the cases they were performed through elaborate NPC ceremonies. And the next, the second one for the first one it was kind of restrictive because all the participants need to be online at the same time. However, for the second one, it was a more advanced protocol where anybody can join and leave the ceremony from whenever they want and it can be done in a sequential manner. The NPC. Yes, exactly. NPC is tough. But on the other hand, so one advantage for them was even though regular Snack, they require news like a setup whenever you want to prove a new statement but for Zcash what they did, they included something called a universal circuit. So for that, so what the advantage was that then once they are doing it, they can do it only once and then that would be good enough for a long time unless they're changing the protocol. However, we have now, we have a new advanced proof system called bullet proof and the main advantage of saying point of this one is it doesn't require the trusted setup. And also the security is based on more standard discrete log-based assumption as opposed to very fancy assumption that is required for Liz Snack. And for range proofs, which are required for variety of confidential transactions, they are actually super efficient and both in terms of proof size and the verification time. However, for arbitrary circuit, the verification time is high but the proof size is still, remains relatively small. And the advantage is the setup is trusted and the security depends on the standard assumption. And the direct cryptography maintains a bullet proof library that is implemented in pure REST. And actually you also have a bullet proof implementation in Hyperlink Ursa at present. And Monero is the first cryptocurrency that adapted the bullet proof. It is a private digital currency where transactions are confidential and untraceable. It uses one-time addresses and ring signatures and ring confidential transactions. And with bullet proof adaptation, Monero reported 80% reduction in the transaction fees. This was due to the reduction in the proof size as well as the verification time. And Monero source post includes the bullet proof implementation from scratch in C++ for ring confidential transaction privilege. Because it was so practical, please don't, right? Yeah, I mean, bullet proof search, I mean, it was a huge improvement. Even though this was a bit experimental when I think they started implementing it, but I think they just went ahead because of the thing the paper was well-received as well as they were seeing huge improvement. Yeah, so we've got 10 minutes left. Okay, maybe I should go quickly for the rest. So, and maybe I should try to finish within five more minutes and then we have five minutes for questions. So, there are also, so one of the disadvantage of the snark was the setup equal to the trusted setup. And that, now we have the plunks, which are kind of improvements of the snarks where the setup is universal and habitable. And it also relies on very much easier crypto assumptions called the gate commitments. And then you also have ZK Stark and they are kind of a, they are snarks which have the complete trusted setup. So, similar to bullet proofs. And it has a clipstark as the currency plus implementation and there is also a language called Cairo for that produces the production grade starks. So, why they are important we'll see shortly because they are getting used in the Ethereum ZK rollups. So, the ZK rollups are the solution that perform transaction execution outside the main Ethereum chain. But then they post the transaction data on layer one. So, actual chain, essentially they post the Zerger, the Juno is proof that everything is fine. And currently there are multiple implementation of ZK rollups and they are using different, this advanced crypto frameworks. So, one of them is loop ring. This is snark based and it uses live snark as backend and it's snark as front end. And then we have the Stark net by Stark word. This is based on starks that we just talked about and it uses Cairo. This is as a result, this is completely permissionless. So, the one thing that you might think that why you cannot use bullet proof over here. That is because in case of bullet proof, the bullet proofs are really efficient for range proofs but for, so they are fine when you are just doing pure to just transactions, but in case of Ethereum we are kind of going to prove something more. We have to run the smart contracts and we kind of need a more future company language. So, for that, bullet proofs are not so good because of the large verification times and that's where the starks come into play. And then we have the ZK sync. This uses the plonk snark. So, and this doesn't require the app specific trusted setup and they are similar to snark. So that's why this is faster verification than starks. And there is also Aztec 2.0. This uses more advanced plonks. And then there is Hermes and ZK tubes. They are also based on ZK snarks and plonks. Now, coming to Hyperledger. So we have the ZK proofs in the Hyperledger Indie as well as Hyperledger Fabric. And they are using ID mix. So ID mix is a cryptographic protocol that provides strong authentication as well as anonymity and unlinking ability. However, this doesn't actually use the general purpose journey as a framework. It uses specialized signature schemes. And as a result, they are very efficient and they are, you can implement it from the very standard assumptions. And so Indie also uses the animation credential which require proving the knowledge of signatures similar to ID mix. And Ursa is a Raspberry Shared Crypto library. It currently supports signature proofs of the knowledge, the bullet proofs, range proofs and set membership by cryptographic accumulators. And the Ursa bullet proof implementation is a bit different than the Dalek one, which was not supporting the pairing friendly cards. And in addition, Hyperledger Fabric also supports the general asset transfer. And this is also, this also doesn't require the general purpose framework and can be built using the knowledge of signature schemes. And in conclusion, so journal approved have come a long way since the inception in 1985. There are multiple practical journaled frameworks that support general purpose in relations. And these new protocols based on fancy are seeing rapid adaptation to practice because of their application to blockchain. And there are also GKB schemes used in practice that are used in standard assumptions. With that, I will go to any questions. Here, I generally see the practical and applied is not just in luck games, although that's where they're heavily used right now. It's with anything you want, kind of like custom circuits that you want to create. Basically, I want to be able to prove something to you without revealing what the inputs were. Just, I want to be able to prove a statement is valid. And that's starting to become more and more practical in these cases. So you can see there's a whole bunch of different schemes that you can pick to do that. And we're just showing you the ones that are the most practical today. Yeah, so I think that Jason over here has some interesting questions. Just to, or this is that visual. So one of you, I think he is asking about the implementation questions. So how do you transform a generic question to ZKP language that we have all the input variables and functions we're running? Yeah, so I think for that, so one option is using this feature complete. It's almost using complete zero-knowledge languages. And in fact, if you want to use the Libsnark, I think you can write your program in C and it will compile the C program to a tiny RAM format that is supported by the Libsnark. But if you know more about the program, it is always better if you can write it in a more high-level language that is supported by the framework. Yeah, I mean, I was thinking let me just share my screen. So I just wanted to reiterate one thing. So as I'm doing this, Jason's question about how do we transform a general function to ZKP language? There are a few questions in general with the event planners. There are a few things that the dashboard of the IT futures have. It's probably the best thing to do, for example, trying to break things down into what you're actually trying to do. So with the thing to keep in mind with Snarks or any of these base languages is you have what are called private inputs and public inputs. Public inputs are basically known to all parties, usually. And the private inputs are only known to the prover. So I like to break it down into that form. Okay, what does only the prover know? What does everybody else know? And then what is the exact statement we're trying to prove and kind of make it true or false statements? Once we can get it to that point, then we can kind of compose a circuit and what you call, I guess, encode and verify. But that's how I start breaking it down. I don't know if that helps. But that's how I think of it. Let's see, Dan has a question on the way back. It says, does Indy with CL signatures use ERSA to implement range-proofs, predicate-proofs? Yes, so because CL signatures are RSA-based, they don't have to use any bullet-proofs or any of these Snarks. But the downside is the range-proofs are large, like four kilobytes. So they're quite large and they're expensive compared to, say, bullet-proofs. So which library is appropriate when we introduce range-proofs to BBS Plus? I would say bullet-proofs. I know there's some research right now by the inventors of bullet-proofs that if you are going to use pairings, there might be ways to also make bullet-proofs even more efficient during verification by the use of pairings. So that's what I would recommend. Snarks and Starks are more for kind of general purpose statements, but if we just want range-proofs, bullet-proofs were designed just for that purpose. See, that's all the questions I can see. Here's one by Robert Aberdeep, if you want to answer it. What about a Monero-style voting system which the coins are issued by governing by to a wallet and then the vote coin can be spent into a candidate wallet without revealing the citizen identity? I'm not sure if that would work because the thing is voting, as far as I understand, it has different rules based on countries. Like at least in the United States, you don't get to know who cast the vote, but you also have to make sure that if I vote, that they know it was me that voted, but they don't know who I voted for and that I can't double-spend. So I guess that's why a lot of people don't think so. I don't think it's important to keep it in here. Yeah, I guess some properties would hold that you would want in a secure voting system, but I think there are some fundamental difference between voting and what do you want in transactions. There is some similarity and you can achieve those things, but for example, we want probably the, there should be somebody outside other than the, like the general public should be able to see that as a overall aggregate voting is fine. There should be zero proof of that one. So I guess for that we need to go to actual electric voting scheme.