 Alrighty. I don't know how many people can see my screen, but I wanted to show you some cool stuff going on in Hyperledger Ursa. Ursa is a cryptographic library, so it's not like I have a ton to quote-unquote demo. I thought I'd walk you through it, and then I did want to show you it's issuing, finding a credential of the CL signature, because that seems to be the number one feature that people love about Ursa. Right now, Ursa is in the middle of some reorganization. The old folder, which we call Ursa, is in here. There's some advanced cryptographic features in what we used to call Xemix. That's going to go away, but it has the VBS Plus signature, punchable sender signature. It's got verifiable encryption and delegatable signatures. We're going to reorganize all that. The main thing most people are interested in is the CL signatures, which are found in here. Here's all the classes. Rather than walk you through all of that, I wanted to just demo one thing. Let's see here. Yeah, here we go. If you're not familiar with how a CL signature is, CL signatures are a type of multi-message signature, meaning you can sign as many messages as you want into the signature. What allows you to do is selectively disclose any number of those messages so I can choose to reveal some of them or I can choose to reveal all of them or anything in between. The other cool thing about the CL signature is I can do what's called a range proof. I don't want to reveal the attribute entirely, but I encoded it as a number. I want to prove it's over some number, like 18 for my age, or maybe it's the balance on my account when I was issued the credential, not to prove it's greater than something without revealing the actual number. That's what you see with this what's called predicates. You can go greater than or equal, less than or equal, greater than or less than, but most of the time you're not going to be working directly with those too much because usually this is wrapped for you in other libraries. In case you ever did want to, here's an example of multiple predicates where the issuer creates what's called a schema. This is what describes what that credential looks like. In our case, we're saying fun sold and securities purchased and a bunch of other kind of numeric terms, something you might see on a stock option sheet or a balance sheet, and we're going to issue a credential to it. We call it a master secret, but it doesn't have to be called. That could be called anything. What this is saying is this is going to be tied to an identifier that only that person knows, and it's never disclosed to anyone, but they can prove that all of their credentials are linked to the same identity. So that's what this is for. Now that we have our schema, right here we're just plugging in numbers. You can see I just put in raw digits. They're pretty simple. And then I go through and this is just kind of the multi step phase to get the credential because right now it depends on the two phase system where the prover does something first, then sends that to the issuer saying, yes, I accept the credential, among other things, and then when he gets it back, the prover finalizes it because it's what we call a blinded signature such that the issuer can't impersonate the prover in that in that way because he never knew what the signature was in the first place. Now comes the cool stuff. So now we can create all sorts of these proofs. See, I want to prove that this is less than or equal to a hundred and prove this one and a whole bunch of others, and we can create a proof and then send that on to a verifier. Now you'll notice this is all in one function. So when the prover is done here, he would send that on. Not, you wouldn't just have this all in one function. So so by running a cargo test, you can actually see this because this is all in Rust. So if you're not familiar with Rust, that's okay. We are implementing a bunch of wrappers and language wrappers like node and C sharp or Java. There's a bunch more in there that are on their way. So Ursa is mostly implemented and wrapped in, say, Lib Aries or the Aries project in Indy. They both use it and there's some other hyperledger projects that do and the Transact is one of them and I think Sawtooth was going to, but I think their adoption is on hold. There's lots of other things that you can do with Ursa, such as like what's called a key exchange. That's what this is for. You can do other types of signatures in here like e519, BLS, the Bitcoin, eCDSA curve. This is so you can use just a common interface and you don't have to reformat or do things in your normal code if we happen to change an underlying dependency under the hood that might be more secure and what you might want to use. So these are the three most common signatures used in blockchains and that's what Lib Ursa supports is blockchains. So there's some stuff in here that's not quite entirely blockchain based, but like there's symmetric crypto that's implemented in here. Here's kind of two NIST approved signatures and these two are like if you're a Libsodium person, then these are compatible with Libsodium. All right cool thing about Ursa is it's been, there's been a lot of eyes on this cryptography code, so it's underway to get audited, but in the meantime there's been lots of cryptographers and crypto engineers that have looked at this and made sure everything is accurate and so you shouldn't have to worry about whether it's insecure back doors. If you all look for back doors, this code's open source so you can look at it yourself. So as far as running tests or anything else, this is Rust, so anything that you can do from the command line will work. These are just running everything. FFI stands for foreign function interface, so if you're going to wrap it and go to C, this is what you would use. This is demoing what it looks like for revocation or just a plain demo. I will walk you through that code here now. So what that is doing with CL signatures is one of the things is if you want to do, if you want to issue a verifiable credential, it's pretty important to be able to revoke a credential. Let's say there's just bad data in it or in the case they think of a driver's license, they've committed to many DUIs so now I want to make sure their credential is completely and utterly useless. In the visual world that's a little hard because there's not a centralized database necessarily that everybody checks and you may want to prevent correlation. So what I'm doing is I'm searching for the test. So just give me a second while I find it. I think it's kind of, yeah here we go. So here's an example of a credential that just has kind of some basic attributes about someone that are going to get signed in there, but it also keeps track of what's called a revocation ID. Now in zero knowledge, we check that this credential has not been revoked in such a way that whoever is verifying it doesn't see the exact ID that was checked. It just knows is it in the set or not. So think of it as a set membership check where you don't know which element out of say 10 million was checked, but you do know whether the element was in one of those 10 million. So if it had been revoked, it wouldn't be in the set. That proof would fail. So in that sense we have a whole bunch of kind of proofs going on here. And so how this all works is remember the CL signatures, we're selectively disclosing some attributes to a verifier. We're never revealing the exact signature. We're presenting what's called a zero knowledge proof of a signature and we're presenting a zero knowledge proof that it's in its revocation ID is in a set that hasn't been revoked and some other numbers like age and height are greater than some thing. So there's quite a bit of zero knowledge proofs going on here. So ERSA has a lot of zero knowledge proof stuff that's probably the one thing it has to offer over any other library. This is what's actually replacing CL signatures called BDS plus. If you've been involved in this committee for a while, this is where the code has been written and maintained is in here. And it works very similar to CL signatures except that it's much smaller and it's faster than CL signatures. So pretty cool. Here's the source code. If you want to use it, if you don't care, you can go to one of the other wrappers that say matter global has done. But then I wanted to leave the last five minutes for questions. Are there any questions? Let's see. Can you go through how all the ZKPs are aggregated into a single proof? Yes. Let's start with the CL signature because that's what most people care about. So the CL signature, we have what's called an aggregated proof. And this is what's called a schnoar proof. And so there's a bunch of other proofs. Say you've got your zero knowledge proof of a signature, your revocation check, all your range proofs, your selectively disclosed attributes. There's a whole bunch of all those proofs. So each one of those is a proof. And then when you say aggregated into a single proof, there is one what we call a schnoar proof that kind of combines them all together. And that is what you check in addition to the individual ones. Because the individual ones like you might have some pass and some fail, but then there's an overall proof that will fail if any one of those has been modified or tampered to make sure it stays accurate. Which language wrapper do you plan to implement in the near future? It depends on demand. So the highest demand ones are node, a C wrapper, which can then go to C sharp or Java dot net. So those are probably the most the ones we want. I'm not sharing my screen and yeah, nothing more. Any other questions? Why do we check? Because the overall proof could still succeed even if one of the other little individual proofs fails. So let me give you an example. I could do a range proof, which the proof itself has not been tampered with, but the value I'm checking it against let's say I'm greater than 18. If that might fail, but the overall proof still succeeds. So meaning the signature was still valid, everything else about was valid. I'm just not over 18, for example. Ending in one minute. Dan, CL signature and Ursa plus equals original CL plus range proof. CL signatures support range proofs. So as far as we know, we are the only CL signature that's open source. There is one in ID mix, but it's not open source. All right, with that, that's the end of the session. Any other questions, feel free to contact me outside this on rocket chat. Thanks.