Protecting user privacy: a technical discussion on privacy and zero-knowledge proofs

Date: 26/09/2024

Host: Kevin Whitmore, Business Innovation Advisor at Callaghan Innovation

Guests: Jeff Nijsse, Jeff is interested in all things to do with Bitcoin, cryptocurrencies, and blockchain technology. From the base layer protocols of consensus methods to the social applications of money and finance. Jeff is a Senior Lecturer in Software Engineering at RMIT in Vietnam. Previously he hosted the Blockchain New Zealand podcast. Jeff always runs his own node and has been liquidated more than once.

Webinar Length: 51:36

Introduction and International Guests

[00:00:00]

Kevin: All right, kia ora everybody. Today we have a bit of an international flair, we've got Jeff dialing in from Vietnam, which is very cool. And we also have Ben as well from AUT. So we've got multi, multi university stuff happening, which is very cool. And they're going to talk to us about protecting user privacy.

So today is going to be a bit of a technical discussion on privacy and zero knowledge proofs. But pretty topical at the moment, at least in the circles. I'm seeing at the moment, so really appreciative to both Ben and Jeff for taking the time and I will hand over to you both.

So in terms of Q& A, we'll do Q& A at the end. So yeah, we're going to run through their presentation first and yeah, just hold questions till the end. Thank you.

Jeff: Okay, great.

Understanding Zero Knowledge Proofs

Jeff: Good morning from Hanoi, specifically, everyone. So I'm Jeff and I was at AUT for a number of years and [00:01:00] recently I've moved to RMIT in Vietnam. Today, I've got my master's student here, Ben, with us, joining us, and we're going to talk about privacy and zero knowledge proofs and some of the work that we've been doing.

So I'll go first. and talk a little bit and then we'll pass it over to Ben. And he'll show us a little bit about what he's doing. We're going to look at sort of, what is ZK? Maybe some motivation about why we might want it and try to introduce a little bit about how it works. We won't go all the way into it and then we'll look at some of the applied bits that Ben is doing so we'll get into it I'll go for about 20 25 minutes and then we'll pass to pen and see what he's up to Okay, so my first Introduction to zero knowledge proofs and I found this example. It's still my favorite one And it goes a little [00:02:00] bit something like this I'm gonna prove to you that I know where Wally is now, this might be Waldo depending on Where you grew up.

So you know, these are the children's books and Wally is presented in a scene and we're supposed to look for him and find him. So here's a typical scene and Wally is down here. This is what he looks like, and the zero knowledge proof part is such that I'm going to say, yep, I know where he is, but I'm then going to convince you without actually revealing his location.

So that you are convinced, but you have no knowledge. of Wally's location. I'm not going to give you too much time to look at that. So, you know, we can't wait around all day, especially if we want to post some information to a public blockchain. This is one of the this is one of the criticisms of blockchains, right?

About speed, time to settlement, and so on and so forth. And when we're talking about zero knowledge proofs, [00:03:00] the same thing applies. The user doesn't really care what's happening. We just want it to get done quickly. So what I'm going to do is in the background, package up a proof, And I'm going to send it to you.

I'm going to say, look, here he is. He's a little bit small, so I made him bigger. And this would be like a visual proof. So you look at it and you're like, oh, yep, that looks like Wally. Okay, so Jeff does know where he is. And now I've taken some precautions here by putting him in the middle of my screen so that you don't really have a general location so that when you go back here, you might be tempted to look right in the middle and say, Oh, well, I'm not too sure if he's there or not.

And so I haven't given up the information, but I have shown you where he is. You can say, Sure, Jeff, I can just look for him though, right? Like, what's the problem with that? And indeed, you can look for him. So there he is, eventually you will find him, and this is the key word, that eventually you will find him, so in mathematics, right, [00:04:00] we could imagine scaling this up, so, you don't want it to be so big that your kids can never find Wally, that's not a, that's not a fun book but in terms of zero knowledge, we want it to be so big that you're gonna give up looking for him, and so, you know, if the paper, you Was one kilometer by one kilometer, you'd have to get creative and find some other ways to go about searching for Wally.

And so, you know, from the mathematics point of view, this is called like a brute force search. And it's quite easy just to make the numbers bigger and bigger and bigger so that you, so that it's not realistic for you to do that brute force search. And so, you know, there, it's, it's not a, a perfect analogy, but it comes quite close.

A few, maybe, maybe I'll say two other ones that are sort of easy to grasp, but one of them is a proof of age card. So rather than having to show your ID that has your birth date on it, which [00:05:00] is private information, you can just, you know, you can apply to the government authority, get the proof of age, and just show them that card, which doesn't have your ID, or it doesn't have your birth date on it.

So in that case, you don't have to reveal your birthdate, but you still prove that you're of age. And another one would be like saying like, Oh, I know the password to I know the password to my friends or my partner's phone, right? And you can prove to someone this by unlocking the phone and showing it to them without revealing the numbers that went into it.

So those are sort of some staircasing analogies for zero knowledge proofs.

Applications and Implications of Zero Knowledge

Jeff: Okay, so what do we want specifically zero knowledge for? You know, like, don't we have good enough privacy and systems as they are? So I'll motivate this by looking at the landscape. So I think that often, you know, privacy is the hot topic.

That's what we're really, what we're after. But privacy gets [00:06:00] grouped in with anonymity and security, and it's not like there is. A clear boundary between all of these things. So privacy is really about having the option to reveal information. So I can choose to keep it to myself. Private communication means that the recipient knows what we're talking about, but it's not open.

It's not posted anywhere. Anonymity is more about being able to conceal yourself in the crowd of people. And so for anonymity, we come up against this problem where if the crowd isn't big enough and we're no longer anonymous, right? An anonymous set of one is not an anonymous set. You might have like a pseudonym, but if you're the only one doing the activity, then it's pretty clear that it's you.

And security, this is easier to conceptualize. It's just about keeping your data or your information. Keeping something safe against somebody that wants to try to get it. [00:07:00] So privacy, this is just a password and security in the digital world, right? This is just encryption. Anonymity again, it's a little bit more loose here.

So we're thinking of like public message boards, which are becoming fewer and fewer on the internet. A generation ago, you know, message boards were how people communicated, and it was essentially completely anonymous. Nowadays, even sites like 4chan are under a lot of scrutiny for the activity that they're promoting.

So in the intersection between these bubbles, this is where we start to see some applications starting with encrypted email, right? This one is fairly standard these days, combining privacy with security. It's not anonymous because the sender and the recipient are still known, even if they are pseudonyms.

Tor browsing lets us combine security of [00:08:00] encryption with anonymity, so our packets are bouncing around and we don't necessarily know that a packet came from a particular user. It's not very private, though, because At the end points, you can still monitor the traffic. And so this is what law enforcement does.

They, they set up and they watch the traffic coming into and out of tour, and then they can do some, you know, other clever things to try to narrow down. What's, what's happening in terms of breaking the privacy voting here. If we think of traditional voting, you go to the ballots. ballot box. We want the vote to be private, which means that I don't want somebody else to be able to know who I voted for or what policy I voted for, right?

Or what like governance procedure I'm voting for. But we also might need it to be anonymous so that people can't even tell that I voted in the first place. So if we think about traditional voting, you might have to register to vote. And then there might be a [00:09:00] record that you showed up to vote. So that means that you're not completely anonymous because they know that Jeff voted.

They just don't know who I voted for. And so that's my, my voting use case here. Now I put it on the boundary because it's difficult to get into this anonymous bubble. What we need is we need a set that's big enough so that either everybody's automatically in it or that it's too hard to figure out exactly who's in it.

And so if we go from privacy, the zero knowledge application can take us into the anonymous mit with privacy pools. So you can put people into a set and we don't know exactly what the behavior is after that. And then ultimately we want it in the middle here. So we want ZK to bump us down into the security portion as well.

And really, I think this is where we're going with voting. Once zero knowledge becomes more accepted, As a cryptographic mechanism, we're going to be able to enable secure voting. And the [00:10:00] security comes from being able to look at the system and being able to assess mathematically that, for example, only one vote per address, meaning that you can't commit fraud by voting twice.

Also, we can mathematically put some bonds on here which is a little bit of what the zero knowlege does we can say you can't put in negative vote, and you can't put in ten votes so we can put a cap on one vote per whatever, per address, per validator and may be for special cases, that so you can mathematically put those limits on.

Okay a more crypto focused crypto in terms of cryptocurrency focused example right is the mixer. So mixers have been around for a long time since maybe like 2013 or so in Bitcoin and mixers arise because [00:11:00] Bitcoin doesn't have any privacy your transactions are all tracked especially nowadays with with modern tools and you know all the activity That there is in Bitcoin, and so a mixer can break that link between your transactions.

Now, the problem with the mixers, as they originally came about is that they're centralized and so you're trusting the security there that they're not gonna, you know, run away with your coins. And so. You know, fine if you need it to be, you're probably nervous the first time you send your coins to a mixer, but really a better idea here is to apply some zero knowledge and that brings us into the middle, meaning that we're adding the security and so Tornado Cash is an example of this using zero knowledge proofs to get us into this middle bubble or to get us into this intersection here.

And so Tornado cash, especially if you have a public smart contract, so you can audit it. [00:12:00] And if you can burn the admin keys so that the contract creator can't go in and make updates, then you're in this nice happy zone in the middle here of, of all of these as we've seen, though, tornado cash is not without its drawbacks.

So a real quick run through of Tornado Cash. It's a mixer, just like a, just like a centralized version that lets you now hide in the crowd. But the crowd of privacy here is only people that are using Tornado Cash. It's not everybody. So that's where you can be guilty by association or maybe innocent by association.

So the depositor creates a proof that you deposit your ETH. Here's a graphic from Coin Center, and when you deposit your E TH what you do is you save this proof and just keep it to yourself. And then you're gonna come back at some time later and you're going to redeem your ETH So the ETH sits in a contract, [00:13:00] which is pretty wild if you're not used to, you know, smart contracts and blockchain stuff.

You send your money to the contract and it just sits on chain. When you wanna withdraw, what you need to do is you need to submit. That proof that you held onto, and then the contract, what it needs to do is it needs to verify in this case that you haven't already redeemed your ETH right? Pretty catastrophic.

If you could send one ETH and then just keep withdrawing over and over one ETH. So we need some method to do that, and that's really what Tornado Cache does. The zero knowledge part here is the application such that. Excuse me, such that you have no knowledge of the deposit address. So if I look in the graphic here, zero x 1 2 3 was my sending account, and zero x 4 5 6 was my receiving account.

Some of the problems with tornado cash are timing. So how quickly do you need to get your money out That may out you, how many people are using it, you know, if there's only one person using it, again, [00:14:00] it doesn't matter that the address is broken. And also. If other people are going to accept funds that have touched mixing address or contract.

So a more contemporary example comes from ZKKYC, so zero knowledge, know your customer. So I just pulled this example because I thought that they were using quite up to date modern tech. So this company galaxy here has been implemented. Coinbase is layer two as a way to sort of solve this social multiplicity problem, meaning that I might have an ID on base.

I might have an ID on X. I might have an ID, you know, with my bank account and I don't want to have to always use that hole set, to verify my identity. So the, the part that's interesting here is that we're going to compose an ID of signals, which so like I just mentioned you take your social media accounts take your take [00:15:00] your official government id or your bank or what have you those are all signals that go into your id and then each id itself comes with a nullifier that can be proved so this is what tornado cash also does they say that Well, we're going to nullify that redemption so that you can't redeem twice, for example, and that would be like a one of one scenario.

Well, here we have like a one of many scenario where we can, you know, just prove our address if that's all we need to do or just prove our social media if that's all we need to do to post. So the tech here is the libraries are snark. js. So that's JS for JavaScript and snark is the ZK. The crypto application and Ben is gonna talk to us about Sircon and show us how the library works as well.

This here, so we've gone kind of like tornado cache is old identity is [00:16:00] now, this is what I see as the future. So really scaling up state with ZK, and We already know this if you're into blockchains we already know that there's a bunch of layer twos and there's a lot of chatter, right? There has been for years and years about scaling state.

So I pulled this from an L2 beat. So these are a bunch of L2s and they list the technology and they also go through some of the details of the tech. So the first five here are optimistic roll ups. These are not zero knowledge roll ups and they're right now sort of like leading the way. Of course, Coinbase is quite popular.

Big push there. These are ranked by the total value locked on the platform, but down here it's six through nine, these are all ZK rollups. And so this is really where I see that this is heading. These ZK rollups are not going to stay bundled in second place. One of them is going to break out and move up into, you know, first or second place.

So what we're doing here with, with a roll up, You And we're saying we can [00:17:00] prove some computation, right, which is the idea of blockchain. You can see the work that's happened, so we can prove some computation, but we're not going to have to show you the work, meaning that L1 just gets a proof and then it can verify that it's correct, but all that hard work was done on the layer 2.

And the way that both of these roll ups work is you're batching transactions, which is, you know, a classic way to scale a system, and then you and so you batch up the transactions and then only post what you need to to layer One, We should note, though, that recall from how digital signatures work.

You still need to sign that transaction on Layer two. So the ZK here is not like we might imagine, like personal privacy to And The zk here is sort of allows an efficiency boost by only posting a subset of information on layer one. and you know, the privacy advantage you know to It could be from a point of view of the blockchain.

So layer one doesn't necessarily know what [00:18:00] happened on base, okay? But it knows that it is a correct execution on base. And then let's say you want to go find out what happened, you have to go to base yourself and, and look into it and, and figure out what happened there. The drawback here. For this group, six through nine is money.

So it's a bit expensive these days to verify. Cost is a nice limitation because it can come down very quick with efficiency gains. Okay, I'll take just a couple minutes to talk about a little bit about how we do this. So how does a ZK set up work? We need to choose an elliptic curve. We're not going to talk about elliptic curves today.

But I highly recommend if you're interested in this stuff, it can really improve your trust in these systems by looking into what elliptic curves do for blockchains. So to create the proof you have to like do this hard work off chain, send it to someone that can verify it [00:19:00] quickly. We need a problem first to be able to convert into what's called an arithmetic circuit.

Then we need to extract a polynomial and we need to do a commitment to that polynomial. And then we need to send the proof to the verifier. So to turn the problem into a circuit we'll leave this. This is a view of CIRCOM. I'll leave this, I'll leave this for Ben's part, but CIRCOM allows people just to code this up as a bunch of signals.

And then CIRCOM and SnarkJS will do some work for us. So I'll just, let me see here.

Let's do a quick example.

Okay. So here's the example we're going to do. We're going to do prime number factorization, right? So 21, we're going to factor it into its primes seven times three, and we want to be able to, so, you know, this. This is the hard work. There's kind of a loose analogy here to [00:20:00] RSA encryption, which relies on the prime factorization problem.

So finding 7 and 3 is hard. Again, think really big numbers. And we want to be able to convert this into a mathematical object that we can work with. So what I can just do here is I can say y equals x minus 7 times x minus 3. And if I look at my parabola here, my roots of the polynomial are at seven and three, you know, which is to be expected.

So what I can do is I can expand this into a polynomial. Let's call it P at X. So X times X is X squared. Combine those middle terms minus 10 X and then plus 21. So I haven't changed anything. So the purple and the blue, All of these are the same, but now that I have this polynomial, what I've [00:21:00] done here is I've included, I've included, I've encoded my prime numbers into a polynomial.

So not only are those factorizations appearing here, but there's a bunch of other points on the polynomial, right? There's infinite points on the polynomial. And so I can use this information to my advantage by being able to have people agree that, yes, this mathematical object is what he says it is, but oh, he didn't necessarily give up these two numbers.

They're just somewhere in there.

So what the libraries that these developers are using, they're encoding this information like this in a polynomial, and then they're creating a circuit, which if you've done any engineering, this might look familiar. And so there's not much going on here. We have X squared. So we have two inputs of X.

These are input signals. We get a medium.

We'll do the same with x and minus 10. We get another intermediate value, and then we're going to add it to 21. So this gate [00:22:00] is an addition. So these circuits, they can only add and multiply, which is really fast and easy for a computer to do. And then what we can do is we can build a system of equations here.

This is how we prove that the computation is correct, meaning that we need to show our work, we need to show these intermediate steps. The edge case here is that you could just guess the result without doing the work yourself and get lucky. And that wouldn't be as secure. So this is CIRCOM output, which is officially called a rank one constraint system, but it's just a series of linear equations.

From there, we're going to take these equations. We have to do some more math. I'm not going to talk us, talk us through it. This does take a little bit of time to get through. Get our heads around what we're going to make a polynomial commitment, which is something you hear a lot about, like committing to things.

So there's like hash commitments, there's Merkle commitments in cryptographic protocols, like multi party [00:23:00] computation and stuff. All committing to the poly, polynomial means is that if it's my polynomial committing, that it's the truth, meaning that if I change it and come back later, it's going to be different.

And we know this from hash functions. Blockchain people know a lot about hash functions. If you change the data, the hash function itself changes, so you could think of it like that. If I change, my 7 and 3 are inside here. If I change those values, then the commitment itself is going to change. This part here is where the hiding or the ZK happens.

And we have an exponentiation. So some number raised to an exponent, and this is where it's easy to calculate, but difficult to undo. And this is actually where the the cryptographic safety comes in from the discrete logarithm. If you've done exponents, it's easy to calculate, you know, two to the power three, but it's difficult.

number to calculate a logarithm. [00:24:00] In green here, this is some of the public stuff. We need in advance. These are just like the rules of the game. So for Wally we say the rules are that you know what he looks like and he's going to appear only once in the scene. So we need an elliptic curve to set the ground rules and then we need to develop some other stuff.

And then we send this proof to the verifier. So this mathematics, it can take a bit of computing power, it can take a bit of time, but we do it off chain, or we do it offline, and then we send it to the verifier. The S here is highlighted because it has to be short enough and succinct enough to be able to send out.

Lastly, once we, you know, go to all this work to make the proof, like, oh gosh, seven times three I thought should be easier than that, right? The hard part is done, but we need someone to verify it. So the smart contract here, it kind of sits on chain? Well, not kind of. It does. And we want it to be cheap and quick to verify.

So what we're gonna do is we're just gonna send. Information to the smart contract that we [00:25:00] need to verify it. And that's where the N comes in, meaning that it's non-interactive. So we want it to be short, non-interactive. And then the argument of knowledge is just that it contains information about the seven times, the three an interactive version would be that you have to keep going back and forth where the verifier says, how about this?

And you say, yep. The verifier says, well, what about this case? And you say, yep. So we just wanted to go to the smart contract quickly and be able to be verified easily. So I'll skip past the summary slide unless we need it a bit later and I will stop there and let Ben pick up and he'll show us some of the work he's doing.

So maybe Ben, if you give us a quick intro as well. Yeah.

Ben: Yeah, sure. Yeah. Hello. Thank you, Jeff. Thank you, Kevin, for having me here.

Okay. Let's start with explaining. I, I just was working the last couple of weeks in in a prototype.

Exploring Smart Contracts and Energy Usage

Ben: [00:26:00] Let's start first explaining that. Well, I implemented this is a prototype which this is this is an Apple ledger fabric working in my own computer. And basically what it has is two smart contracts. They are, they are communicating with each other.

So they are interacting here. To the interaction basically the apartment, I mean, this is, this is the context of The smart city tends to be where the energy contract, which represents most, mostly the energy grid has to get the information from the apartment wood, which should be the power, the power meter.

And in order to do that, the energy smart contract. It's gonna send some signups. These signups were created [00:27:00] off chain, but these signups are zero knowledge proof generated. So the apartment to, to be sure that the, the, the energy grid who is trying to read the power meter of the apartment is going to verify that that information, that signal, and if it's everything fine, is going to answer with the energy usage to the smart contract energy.

So I will start this running with the apartment smart contract. So I'm expecting this not to fail.

Here it is here. This is going to create 10 apartments. As you can see here is the energy usage. I mean, this is just the information I need to, to share with the other smart [00:28:00] contract and this here, the energy usage just random numbers. So from apartment one to 10, that is what I'm using here, I have now the idea of the apartment and also the energy usage for each of them.

So, from the energy smart contract, I will do, I will run the smart contract as well.

If everything works fine, what's going to happen here is. It's going to start creating the apartments with the energy usage zero. And after that, it's going to update each of the assets. And it's going to bring the energy usage from the apartment a chain code or smart contract, which is, which is the same actually.

So now it's creating all the apartments with energy usage zero. Yeah.

Latency and Zero Knowledge Proofs

Ben: One [00:29:00] important thing here was the motivation when I started this this prototype is to measure about the latency because I wanted to know I'm using Plunk here plunk in the SNAR JS library to, to create the proof.

And I wanted to know how much time takes for the Energy Smart contract to fetch the energy usage from the apartment. So, as you can see here, what is happening is. After create, after all the apartments are created with energy usage zero. The event started to to fetch information from the apartment.

So I have here, for instance, apartment three. This is the energy usage. Declare here for apartment, apartment three. This is apartment 3 34. And. What [00:30:00] this smart contract is doing as well is recording the start time. So when the call was done to fetch the information from the apartment and also recording the end time, and the latency is just the difference.

This is 25 milliseconds. This case is 27 milliseconds and so on. It's between 20 and 30. 30 milliseconds. Yes, this is the, yeah, the update assets. All right. After that, in the very same function, what is, I mean, I already have all this information here, but I wanted to produce well, an invoice, so I needed a price.

And in order to do that, I, maybe that is a little bit out of scope, but well what I'm doing is bringing information from [00:31:00] Outside the chain, which is conceptually speaking, we are talking about here about an oracle because I'm bringing information from the Aku weather. API the type ID zero.

Which is what I'm bringing from, from there is basically that is not going to rain. So if it is not raining, the price is going to be 23 and if it is raining, let me show you here. For instance, if it is raining, the price is gonna be, I mean, the top Id brought from fetched from the, from the Accu weather, API is gonna be one and the price is gonna be 19.

And this Smart contract, the Energy Smart contract is calculating, making all the calculations to produce the, the price for the invoice. Maybe to, I mean, to [00:32:00] clarify here, I have some sequence diagram. This is the energy, this is the energy smart contract. There is a timer start. This is the function called the get energy usage with the sign all, the apartment, checking on this, snark JS library.

And getting back with the authorization here is when the timer stops.

Jeff: Maybe you can highlight where the ZK stuff is. Is it in this diagram?

Ben: Yes, exactly. It's just here. It's the Snark. js plonk verify. It's the communication between the apartment and the Snark. js plonk. Verify. So the verification, what is doing is just receiving the proof, the keys and the sign out to check that everything was done correctly.

The energy smart contract, who is contacting, who is talking with the apartment is what. He [00:33:00] says he is. So yes, the apartment is calling this verify, verify function, which is which is actually defined in, I mean, I have everything in the, in the smart contract defined just for, because it's to, to make it easier to implement, but yeah, actually, let me show you, I can show you the code here in just one second.

So, this one here is the apartment chain code, the smart contract.

So this is the verified function. This is just receiving the inputs and it's also getting the verification keys and the proofs. I have that set in the, in the, in the very same script, just because it's easier for me, but those were created of change, of course.

Well this, this function is just checking that all the process was correct. If it was correct I'm going to [00:34:00] get I'm not going to get the result of unauthorized. So in case I don't have a result, this is going to throw an error and the error is going to say unauthorized. Here I'm using this function verify, for instance, in this query energy usage, yeah, this query energy usage is the function called from the smart contract energy

here. This is, I mean, this is the, the function doing all the hard work here. This is the invoke. chain code. Here we are, as you can see, we are in the energy smart contract. Passing here as an argument is the apartment, which is the name of the other smart contract, and also the function that is going to be used to, to retrieve that information that, that is the energy usage from the apartment, from each apartment.

This is the ID of the apartment [00:35:00] first also the signal. This is the signal. The signal is basically which it was defined here in this circuit which is just a multiplication between two values. This, this were two prime numbers, seven and three. And after that was the cube was calculated. So this is the, the, the argument passed here.

The other parameter is the name of the channel. So so yeah this query energy usage is just checking as I show, show you before that the inputs received are okay. So if it's okay, it is gonna answer with the asset with the apartment. It's the apartment ID and the energy usage. Let me show you, show you one more thing before finish this yes, that, well, out of scope again, but well, this is the, the [00:36:00] Oracle sequence diagram. And this is the process where the energy node application just bring the information from the weather API and just send it back to the energy smart contract to calculate the price. Well, and, and I think that's pretty much it.

Jeff: Great. Thanks, Ben. So I, I could prod you with some questions, but I'll leave it in case any, anyone else, and then I'll come back if we do.

Future of Zero Knowledge in Identity and Blockchain

Jeff: In terms of, Ben, in terms of you know, being a developer and someone comes to you and says, Hey, can we ZKFI this stuff? Can, can you, can you do this? What's your feeling having done this development so far on, I guess, maybe ease of use, technical knowledge requirements do you need to know the math that's happening in the background?

What's your take?

Ben: Well, no, not necessarily. Here I mean, you, you have to know how to use the, the library, right? In this case, it's an ArcGIS, could be a different one. [00:37:00] And you have to understand the methods. Thoughts and how they work and what are they going to answer? That is mostly reading, reading the, the documentation, right?

I mean, this is mostly that regarding regarding the latency what I was looking for here when I was developing this. Yeah. I must say that, I mean, milliseconds, I mean, measuring milliseconds sounds good. However, if I had to criticize my work or, or say something that in the future could improve.

could improve it. I would say that maybe having the smart contracts working in different channels would be a good starting. Probably make two different blockchains work each other using zero knowledge proofs would be the next step. [00:38:00]

Jeff: Yeah, I think that's an obvious next step. What is the effect of latency?

Where do you think that that is at in terms of, is it good enough?

Ben: I mean, yeah, this was this was thought in a smart city context, right? So the expected information to travel here, I mean, it's supposed to be huge. Plonk. I was, I was reading about Plonk. Plonk seems to be good enough in terms of, of timing to generate the proof.

However, I realized that growth 16, which is a different protocol to to generate the proof It could be faster. I don't know. I would like to try that. So I expect to improve this prototype in this I mean, in this, I mean, tomorrow, maybe the day after tomorrow, but yeah, I expect to improve it and have [00:39:00] the other the other protocol implemented just to compare each other.

Kevin: Maybe this is a question for me. Where, where's, where would you both suggest people get started with some of this? I mean, obviously there's, there's quite a bit of complexity there. Where, where would somebody that's interested in ZK's kind of benefit by, by going first, if they want to actually step into this world and start playing with them.

Jeff: Yep. So I can, I can take that. So let me copy a link here. https://www.rareskills.io/ So, there is a, so I thought about this, about like, yeah, exactly, exactly that. How do you, Get involved and learn more and so

I've done a lot of learning off of this company's website called rare skills I have no affiliation, but they have they'll sell you a course But also they have a blog which is I think pretty accessible [00:40:00] which goes through a lot of the mathematical foundation so I would rate rare skills as like easy or accessible level in terms of learning more about this stuff, and from there, what I would suggest is another company's website that I found. So this is one of the ZK EVMs. One of the layer twos, which I've been following. So let's see, so I'll paste this link in now. https://scroll.io/blog So this was on L2B, this blockchain called scroll. And they're trying to do they're trying to do a universal EVM. So a lot of the ZK stuff right now is application specific, meaning you've got, you know, you, you've got your application. So my application might be might be ID KYC.

And so I have to fit [00:41:00] the KYC problem specifically and develop a custom circuit using CIRCOM. And I probably have to hire, you know, a very expensive professional to do this for me. And then later when I want to branch out into somewhere else, my circuit no longer no longer is applicable for that new problem.

So sort of that's why I said like, this is the future is that we get like generic computing that is automatically has ZK built in. So Skrull also has a blog and I would rate the blog as medium, but it's like quality, whoever did the blog again, no affiliation here, but whoever wrote the blog, they know what they're doing and they've done a good job of it. And then. I got one more. The advanced level is, hmm, I could have prepared a link in advance, but I didn't. The advanced level is, it's on YouTube, and it's a series of talks delivered [00:42:00] by the people that wrote this stuff themselves. So for example, Jens Grat, and let's just find a good link to post. https://www.youtube.com/watch?v=6uGimDYZPMw&list=PL8Vt-7cSFnw29cLUVqAIuMlg1QJ-szV0K

Okay, so this playlist is advanced level series of talks. I say advanced because when University professors and so on are talking. They put up, they put up a slide with heaps of math and then two minutes later, they're onto the next one. And it can only be followed by someone that's put in the prerequisite effort to already get to that stage.

Kevin: Maybe the last question To what degree are you seeing these zero knowledge already sort of incorporated into things like verifiable credentials and the likes? I'm just looking at sort of a broader digital identity kind of use case. Is that is that something that you're seeing ody? Or where are you seeing the majority of zero knowledge proofs kind of being used at the moment?

Jeff: Yeah, for something like VC, I would say the degree [00:43:00] is it's almost one, it's almost a hundred percent. Okay. Everybody that is working on it realizes that that is the direction that's going. And so even if, You go to some product offering and it doesn't say it on the front. When you go to their documentation, it'll be there.

Or there'll be, there'll be working on it. But I think that's only, that's only, that's only an application. Sort of, I'm more, I've more closely following the broad blockchain tech space. You know, protocols like what Scroll is trying to do, generic compute and scaling. And so the same thing there, meaning that if you're a developer that has been around for seven years, you're probably bored of standard blockchain stuff.

And you have at some point pivoted into looking at this and trying to help.

Kevin: Okay. Pram, do you have a question? Yeah, you

Pram: pretty much got my question. But I [00:44:00] guess talking more about the identity space and maybe something you're working on. So I'm, I'm in the RWA space. So for me, KYC ing, People before they invest into RWA products, real world asset products, like stocks or whatever, bonds, it's super important.

Have you seen things that like KYC on chain that, you know, has struck your fancy, I guess? Just like the base one, anything?

Jeff: Yeah, I would say so two kind of two different use cases there. The base one has struck my fancy because they've been able to throw a lot of money at improving UX, and this, this is where it's at.

However, that's a different use case, right? Because. You sort of, they're running sort of a light KYC for being able to buy NFTs and swap tokens. You, you guys need a stronger KYC because you're up against you know, I guess regulation of whatever jurisdiction you're in. I haven't necessarily [00:45:00] seen that overlap, but you can imagine, or maybe it already exists.

You can imagine like a two tier system where you still have your strong regulated KYC, but then also you're building out some ZK. KYC, because you're probably going to want to at some point like grow and expand and get into more of the, I don't know, maybe alternate side of blockchain stuff and having that ZKKYC.

I think it's good for branding. I know it's kind of been a hot topic lately, but I think it really is good for, good for branding and pace of development has been astounding in like the last six years. I've only been sort of looking at it for two or three years and seeing everything that's come out.

I mean, Planck's, there's a academic paper just this year, and it's already been developed, been implemented in the next version of Polygon. And so the, the pace is pretty fast. So I think. In summary, you probably want to look at it but I [00:46:00] think it's a slightly different use case.

Pram: Yeah, yeah, I mean, five years ago, I worked on identity tech, and we looked at CK.

It's too early back then. And recently we've been working, well, two years ago now, that's recent, we were working with the Kiwi access card to try and create a CK based identity. So, you know, you can access certain services with IoT revealing. All the pieces of your identity, right? You can just say, oh, you're 18, getting into a bar.

That seems to be the best use case. We've seen, you know selling alcohol seems to be the best motivating factor, but it's, it's quite research intensive high capital industry without much money on the other end so just doesn't promote a lot of products in that space That's that's the only problem with CK I've seen but blockchain tech has a lot of capital behind it So I do see it being pushed there like you've seen with scroll [00:47:00] and the CK chain for Polygon, you said

Jeff: one of the I mean, you, you could like sort of internally run some ZK validator and so on, but you're not really getting the benefits, right?

The, the benefits and the growth here has come because you can, you can post your contract on chain somewhere. And so, you know, we're still not at that, at that point where like publicly traded company is willing to just post it. Post contracts on chain and see what happens. They're, they're still a bit risky.

Pram: Yeah. Yeah. I mean, like with KYC, for example, that's, that's a big one because even if you KYC on chain, you still need to have some sort of centralized location where you can go back and check that, you know, check the information. So you can't do full KYC. Maybe you can look at IPFS for that. I don't know.

But what we've seen in the past, and protocols like Goldfinch, which is the on chain lending or borrow borrowing and lending platform, real world lending they have an NFT, which they give you, you [00:48:00] store in your account but that links to a centralized identity, which they can attest to it's the best one I've seen so far that's easier to use and other protocols can use that as well, but we have to believe in what Golfinch is saying, right?

So I guess For me, the gold standard would be to use some, like, full end to end decentralized check, like a D PIN like IPFS, to store that information, like, okay, yeah, they have a passport, a US passport or something, they are of this age and this is their name, but hiding that information is the, is the tough part and not, and removing that centralized layer I'm pretty sure people have it.

Thought about solutions and they might be developing it. I don't know.

And that's like, that's the final frontier for RWA KYC for me. If we can solve that issue and can take you out of the centralized party, I don't want to be in the middle.

Right. I want it to be fully end to end verifiable on chain somehow.

Jeff: Yeah. I [00:49:00] mean, someone on stage at token 49, I forget who, right, but that, it. They reiterated how silly it is that we have paper passports. I mean, there are some smart card IDs in there, but it's like a perfect example where government issues your passport and they maintained a database, right?

They should, could be government chains, zk, k by c, so that only one person has access to all of it. And you know, the Driver's license place only gets what they need to know. The airline only gets what they need. Yeah,

Pram: well, Devcon had an interesting thing where if you you have to prove your identity to get the cheaper tickets like the, if you, so Devcon's in Thailand and they're, they're giving cheaper tickets to anyone in the Southeast Asia region and for that you could use the app to give you a CK passport, so you verify it just with your phone, there's nobody else around, just verify, you take a picture and then you scan the RFID tag, and it generates you a CK proof that is your passport, and then you submit that to them, [00:50:00] you submit it a hash, I think you submit it on chain and then you get a hashback and you submit that to them to prove that you have this passport. So that's something they're trialing. It was a test flight app as well, so I know they're definitely trialing it, but it's a DevCon, so that's obviously Web3 heavy use case.

Jeff: Yeah, I mean, that's, that's a great use case. And that, but, and then you sort of zoom out and you're like, Oh, these are all super nerds, right? Of course they can get excited. They love that stuff.

Pram: I was, I was trying to do it as well with my Sri Lankan passport, but I realized they don't have RFID to take on that one.

So I had to give it a pass. So I had to do it manually.

Kevin: Alright, just conscious of time. Thank you very much to Jeff and Ben. That's been awesome. Very informative. I'm sure there'll be some follow up questions and topics that fall out of that as well. As I mentioned, yeah, these are Topics that they have been around for a wee while, but I'm seeing more and more relevance right now in various areas.

So very happy and grateful for you guys to jump [00:51:00] on and share your, your thoughts and experience with us. Yeah. Any final comments? Otherwise we might wrap it up there.

Jeff: No, no final comments and look forward to, yeah, this, this being posted and happy to contribute to this conversation. I think privacy has always been important, right?

But sometimes we experienced this idea of creep where a couple of years go past and you don't realize exactly how something has been eroded or also how it's evolving. And so I think privacy is always something that can be improved and we should think more about it.

Kevin: That was a good final comment.