 session of time. So my name is Montauan, I'm the cryptography of Diplomatix and today I'm going to talk to you about this which is our work, ongoing work on integrating serocational theory. So well I guess everyone here knows about, thirdly, you guys know that these platforms are amazing, we have this EVM which is a perfect, which is a well, a very elite intersection environment, but the thing is, well it's pretty bad for privacy, right? You can go to smart contracts, but you need to go for a gas and so on and so forth. So, well, we thought about, okay, well, can we leverage this intersection environment to actually do seronal registration initiatives, right? And many people have been talking about that throughout the conference, and basically the idea is, okay, well, we have an encrypted state in some way, and we'd like to be able to prove in zero-knowledge that we end up in another state, which is also encrypted, like with encrypted data or committed data, and we want to prove in zero-knowledge that we're not creating value in this state condition. So, not double spending, not creating money out of tenure, of course. This is going to be our goal throughout this talk. So, let's first recap briefly what is a proof system. So, what is a proof? Well, a proof is just something that convinces someone that statement is true. So, if I want to prove to you, if I want to prove to me that you have a phone, just show me your phone, and well, now I'm convinced. The problem is that now I can see actually that you have an iPhone, and then actually I'm going to see a wallpaper and so forth, so I'm going to learn more information in the midst. So, we're going to be interested in zero-knowledge proof throughout this talk, and if you actually look into the literature, you may stumble upon the notion of a language, so you basically want to prove that X, which is some sort of instance that belongs to a language, and this is equivalent to say that there exists a witness W such that X and W are like satisfies a vital relationship. So, it's just like some formal jargon just to make sure we're all in the same vision. It's not super important for the professor to talk. What is a proof system? So, a proof system is just a set of procedures which enable you to actually generate proofs and define the rules of acceptance for proof and that should tell Verify what to reject the proof. Again, it's pretty informal, but I just want to make sure we kind of understand the same jargon. And you have many different settings of interest when you talk about a proof system. So, you can be interested in adding interactions back and forth with a prover. So, as a verifier, you're going to ask a lot of questions to a prover, receive the answer, and then decide whether you want to accept the proof or maybe you don't want these kind of interactions to happen and you just want the prover to send you a proof and then do the like see whether you want to accept it by yourself or not. And you also have the zero knowledge property which is basically showing that, well, as a prover, you know, as a verifier, you know, nothing except that my experience to the language. So, I don't, I'm just trying to do that some condition holds, but I don't want to tell you about my private information. So, what's very important to properly kind of understand these notions of pro-systems is to understand that when we talk about proofs, we are not going to refer to traditional mathematical proofs. Like, if I want to prove a theory, then you need to check it, like to check my proof line by line to make sure that I'm not violating any inference, any rules in the inference process, right? I'm not dividing by zero and I'm not doing probed it stuff. But in the context of probabilistic proofs, we are basically going to use randomness to only check very few locations in the proof and the proof system is going to ensure that the verifier is going to be tricked with very small probabilities. It's going to be negligible in the security parameter, something on the lines of one divided by two to the one by three. So, it's just like zero basically. Okay. So, I'm not going to spend much time on this slide. Snarks have been talked through, like, a lot throughout the conference. But, like, the key takeaways, well, snarks are not perfect but they are pretty good in the blockchain setting because they are very fast to verify and in general, you want the verification to work on a chain, not to violate the consensus rules. The proofs are pretty small. Again, in general, the proofs are going to be set up on a chain, so you'd better have them small. Otherwise, your blockchain storage is going to skyrocket. And they can support NP, meaning that you can basically prove whatever you want working on it. But, well, anything is not perfect. Like, there is nothing perfect in this world and the CK Snarks have some drawbacks, one of which being that they are trap-lord. So, you need to, like, generate this kind of toxic waste, which is quite annoying. So, you call it NPC to generate this common reference string thing and so on. And, well, you have an source, you have an source per volition. But, you're going to stir this here because, well, like, universal source snarks is a pretty active way of research area. And people have been publishing long, sonic, and global item of these things. So, it looks like we're making tremendous progress in this area. The thing is, well, the most efficient snark remains Pro 16. And, again, if you want to have very small proofs, very fast verification time, and so on and so forth, sometimes for big statements, you just better stick to Pro 16. Okay. So, in general, when you want to use a snark, well, first, you need to want when you want to prove. And then, this, well, this is just an English statement. So, I want to prove to you that I got a primitive edge or something boring like that. The thing is, well, I mean, this is not very nice. I mean, you need to have an algebraic structure in order to be able to actually do your mathematical operation to generate the proof and so on, right? To reason about it. So, basically, what you need to do is to represent your proposition. So, what you want to prove as an arithmetic circuit, which is defined over a finite field. So, this is like, I'm sure some of you guys are familiar with R1CS and all these things. And this is basically doing this kind of representation of your statement into algebraic constraints. And basically, the idea is that you are going to reduce your problem into an instance of circuit SAT, which is an empty complete problem, so which represents the empty class. This is what I said, snark support can be. And the idea is going to show that you have this relation that holds on your X and W. So, your public and your private input satisfy by your relation. But what you want to make sure is that you only use your private information inside the circuit. And you don't want to say anything about the state of your circuit. So, this might seem a little bit abstract, but let's see this with an example. And please stick around, because this is a very packed slide and potentially a little bit overwhelming, but I'm not going to go through it. I mean, this is boring. I just want to convey the idea here. So, let's first start by your statement. So, I want to, well, as a prover, I want to prove that I know the root of a polynomial. Okay, just an arbitrary example. So, well, this is actually quite nice. My polynomial is public, so A, B, C, and D are the coefficients of my polynomial. And they're going to constitute the input of my arithmetic circuit here. But, of course, I don't want to tell you the root I know because maybe it took me ages to compute it, right? So, what I'm going to do is, well, this arithmetic circuit is actually a representation of my statement. And I'm going to use my witness here, W, inside of my circuit. So, basically, I'm going to fit my witness inside of my circuit to be able to compute, like, to actually assign values to my input wires in my circuit and actually show that the output of the circuit is one. So, the key takeaway here is that in the zero-notch setting, as a prover, you just want to tell about your public input, the topology of your circuit, which expresses computation you want to generate proof for, but you don't want to tell anything about the integral state of the circuit because it carries some information about your witness. And, basically, all the, yeah, so, basically, all the left-hand side of this slide, which is a weighted path, is just showing that, well, this graphical representation of your arithmetic circuit can actually be represented as constraints. Like, this is equivalent, actually. And then you can massage a little bit this constraint system by using some vector notation and matrix representation to infinitely check the satisfiability of all this constraint into a single check using matrix notation, right? So, it's just like some massaging which is done. And, at the end of the day, what matters, and I think this is what's important because people potentially tend not to focus on this while it's underpinning all the modern proof systems. At the end of the day, what the verifier is going to do is just verify some properties on body models. So, whether you're interested in starks and snacks and whatever, bullet proof or whatever, like, all the, like, the mechanisms underpinning this proof system is just about checking the relationship of body models. So, now, all these proof systems are going to kind of become tied down into a relationship, into a set of conditions on polynomials. And you just want to make sure that the polynomials equals zero on a given domain. So, this process is basically called a representation. Again, this is underpinning, like, modern general purpose proof system. And, like, in this process, basically, the, like, the verifier is going to randomly query the proof system at some random places. And the reason why we want to do that is because we want to have success, right? I've just told you, we are not going to check the proofs line by line, but just at some random locations. So, you need to make sure that you catch any, any, any mistakes done by the prover with all the well-meaning probability, right? And this is why polynomials are used in the first place, because they are beautiful error-correcting codes. So, in this setting, the, like, the verifier is going to query the polynomials of the prover at some random places, and they decide whether to accept the proof. And because, because we're in the non-interactive setting, we need to have a way to actually encode the verifier queries, right? I mean, we don't want the verifier and the prover to communicate back and forth with each other. So, all these queries are, basically, we're going to institute toxic waste, and they're going to be encoded in the SRS in the context of smacks. And you have some extra condition that needs to be satisfied for keep on the sound of the SRS and so on, but I'm not going to go into these details in the topic for another day or four, just outside the room and that. So, with all this knowledge, let's go back to the initial problem. So, what we're going to have is we have some encrypted knowledge here, a zero-knowledge proof, and some other encrypted state here, and we're going to show, okay, we'll have just one something that does not violate the root of the system, but, like, believe me, I'm not creating value and so on. So, now, let's look at the code and see what is this encrypted knowledge. So, what if this, this encrypted thing is actually encrypting a pool of nodes, like, you know, just like a data structure, I think a value or recipient and many other attributes as you will, and what if my proof is actually proving that I, well, I own a node in this pool. So, I am one of the recipient or one of the owner, and I'm deciding to spend it to create another node of the same value, but maybe I'm going to change the recipient, and if I do so, then I just do a big, right? So, this kind of IT is encapsulated by the, by the zero-cash protocol, which is a, which is a, well, not really a very, a fantastic protocol, which has been released in 2014 by World Class Academics, and which aim to, like, present a decentralized and new spending scheme sitting on the whole Bitcoin. And more importantly, like, what makes zero-cash so powerful is that this is kind of like the evolution of zero-coin. In zero-coin, you have, like, fixed elimination, but in the context of zero-cash, you can actually, you can actually spend a set of nodes and create another set of nodes and show that the sum of the values of this node you spend is equal to some of the values of the newly created node. And if you do that, then, well, you might be, you might be realizing, well, this is kind of like enabling to do arbitraried and vanishing payments, right? I mean, you can do, like, like a Bitcoin and, like, join two of my nodes to create another node of a higher value and potentially take some, like, pay me back the change or something like that. And now you actually end up with a very flexible solution to do, like, payments of arbitraried elimination. So you basically reduce the, like, now your mixing system is as expressive as your underlying platform, which is not necessarily the case for the mixers designed to fix the elimination, say. The only issue, if I can say it's an issue of the zero-cash protocol is that it introduced new payment semantics to communicate with the shielded pool and this recorded out for it. So this is why Zcash, I assume, was actually creating the first place. Well, the good news is that, you know, analysis was provided to integrate zero-cash and theorem and my colleague, Mikhail Naik, decided to bridge this gap and actually do the analysis. Is zero-cash a viable solution for privacy and theorem? The answer seems to be yes, and I'm going to run you through some of our reasoning. And what's pretty good is that, okay, we have this exception environment, which is, which is, well, the AVM student group, so we can do whatever we want, basically. And, well, we need to pay for the gas to execute the state transition, that's for sure. But what's good is that we can include payment semantics or so, so we will not, we can just deploy and represent the shielded pool as a smart contract, and then we won't need to actually for it from Ethernet anymore, it's just going to be a smart contract. So it's actually a pretty good news. And this is how it works. So the goal is to deploy a smart contract, which is going to represent the shielded pool in chain, and we will be able to interact with this smart contract to actually, like, deposit some value, do some transfers, and actually do some restores. The only issue is that, well, when you hear about, like, the design of various midsers, in general, this tip was if three functions deposit transfer restores, but they actually need a ton of information. I mean, if I see deposit four as an observer, I know you just deposited four. I mean, I get exact information about what's going on. Well, in our case, what we decided to do is to have a single function on the midser, so we followed the same approach as Ccash. We actually, like, modified the statement, which was used in Ccash route, in order to have a single function on the shielded pool, which is called mix. So whatever action you want to undertake on the shielded pool, you're just going to call the mix function. So it's going to have a V in input, which is going to correspond to the value you actually want to make enter the mix, V out, some potential value that you want to retrieve out of the mix, and some commitments to actually represent the nodes that you want to actually spend inside the mixer. So what's really nice now is that if you, for instance, mix with a public value m of four, then an observer cannot really know whether you're actually depositing four for yourself, or whether you are depositing four and mixing it with some of the nodes you own on the midser to pay someone else eight or something like that. And because we support nodes of arbitrary value, if you deposit four, no one knows whether you are creating a node of value two and two, or a node of value three point two and zero point eight, I mean it's just not, it's just not given to the attacker, so we reduce the number of leakages by, by, by, by a lot, basically. And now you may be wondering, okay, well that's perfect, but if at least it starts to pay Bob and creates a node, a node on the midser on on ISP, so basically like destroy one of our nodes and create another one for Bob, then how is Bob supposed to be able to spend his node, right, because Bob needs to get some information about the node. And well, that's true actually, we will need to have some communication between Alice and Bob and you have two scenarios here. The first scenario is to do off-chain communication and no problems whatsoever, but you need to have an extra infrastructure to be able to have like a communication channel between a sender and recipient, you need to make sure this one is secure and so on, so you need to have a little bit more infrastructure. In our case we decided to go for an entry, a broadcast mechanism, which leverages the firm events, so basically what Alice is going to do, Alice is going to encrypt the node which is dedicated to Bob, so all this data, with Bob's key, and add the safer text of this node as another attribute to the midser. Now the midser is actually going to verify the zero college proof, is Alice actually not creating money, not spending a node twice and carrying out a double spend, and is Alice basically respecting the result of the system, if yes, the proof passes, and the midser edits the event on the network. The thing is, okay everyone is going to receive the safer text, but no one, all of them, the recipient should be able to actually encrypt it, so you may be a little bit worried and say, well wait a minute, what if a content attacker comes in and just writes everything well, that's right, that's a legitimate concern, and well, who answers to that? First off you can just use a plausibly content secure encryption scheme, and then you're just down, and your threat just disappears, and second solution, as I just said before, your communication options. The thing is, if you follow, if you use this encrypted broadcast, now you gain some resistance against our failure, because if you consider all the communications to be carried out of chain, then if your machine burns, I mean yeah, if your machine burns, then I mean, you just lose your data and your funds are just lost. What if in this scenario, you just need to have backup of your viewing key, and you just scan the chain again, try to put all the sacred text, and if you manage to decrypt them, they were supposed to be for you, and then you repopulate your wallet that way, so you have a pretty nice feature here. So something which is important to say though, is that this does not provide an enmity, because we still need to pay for the gas of the state transition, right? In the scenario, you still need to call the mix function, and well, you need to have a founded account here, and it's kind of like a well-known heuristic in the worst scenario to assume that if your account is founded, then it's known by at least one person, as soon as you're not a miner, and this person can be adversarial, and just say to everyone the knowledge they have about you, and everyone knows you. So this is like a very adversarial setting. So you can distinguish between users who are using this, or users of the network using this and users who are not. So if you're in a country that is prohibiting the use of privacy enhancing technologies, for instance, this is pretty much an issue. So do study like various solutions that maybe you can use really services, but in my personal opinion, this is not a very long solution. You need to have some mechanism against censorship resistance, so you need to have some incentive structure to incentivize delay, and so on. But maybe one more vital solution is just to do some changes in the protocol and potentially investigate a kind of structure or something like that. So if anyone here is up to date with that and more than a bigger discussion about this. So what about the software? Like I'm running out of time, so I'm going to go quickly about that. So we just follow this approach of concerned approach. I mean designing a secure protocol is pretty hard, and doing secure implementation is even harder, like there's a ton of things that can go wrong. So we decided to isolate, make sure to isolate the sensitive components to like to to focus all our attention on that and so on. And basically what's quite important is that our solution is plan technostics. So whether you're using IS, whether you're using GET, whether you're using whether you're using parity or whatever, well you can just use our solution instead of integrating the plan whatsoever. It's actually working on any like blockchain which is equipped with a virtual machine which is as expressive as one of the 30. And of course well it's already ready for its requirement. This is kind of like the architecture, I'm not going to go into these details because I'm genuinely running out of time, but well I mean we can talk about that later. This is just like the architecture and the different components. So that is pretty much working progress. We published a paper in April this year. So six months ago we were here. Please consult the paper but be aware that we are working on implementation and we've made a lot of optimization and security fixes. So now the implementation is not a perfect mapping of the paper anymore. We've made a ton of optimization and so on. So if you want to track the latest development please consult the data branch or the npc branch on which we have well implemented the npc and on which we're still fixing a few things and so on. Like master is a little bit old because we took back everything that we released in a couple of weeks, the release of the views. All right so well I don't have time to go through that but please don't use fixed elimination in services. It's pretty bad and it makes a ton of information and well thanks for your attention and if you have any questions well either we take them here but I think I'm out of time or maybe wait for me at the end of the group. Thanks.