Translating ZK Research into Web3 Solutions – Mahdi Sedaghat | Onchain Soirée [1] @ KU Leuven

that uh I'm going to introduce the the next two speakers. Um and uh Maddi uh maybe you can already come and set up. Uh so so Mi uh Mi Sedagot is a posttock researcher in the Kosi group. Yeah, you can just u take take control. Um and he's going to um so Maddi um did his uh PhD uh with Go on Zero knowledge proof cryptography.

He's really an expert in that and he's also worked uh I think with the people of the Suie project miston labs on uh actually applying that zero knowledge cryptography to give us some really cool new building blocks uh in particular zk login which is a system where you can log into web3 protocols using your web two credentials. I think mi is going to talk more about that. He's also part-time working as an industry consultant and as a chief scientist at soundness. Um so I'll give the floor to Mi and then I will introduce uh Victor later. Thank you so much for the introduction.

Uh hello everyone. Um so today as you can notice from the title of my talk I'm going to talk about ZK proofs uh or zero knowledge proofs. So the great advantage of talking in Ethereum community is you're already familiar with this concept uh by following some previous talks and articles from the big guys like uh Justin Drake's uh at divcon that was presenting this uh part of the slides and also the article by Vitalik that was posted last year that how Ethereum is going to snarkified be a snarkified and how Ethereum 3.0 O is going to be in the ZK era. So the main purpose of the verge uh to give you some context is to enable uh resource constraint devices like phone and a smartwatch to be able to validate the validity of the blocks which is like a big step and it is the magic behind the zk proofs or more importantly zk snarks.

So to give you some statistics on Ethereum uh ecosystem uh as you can see this is the graph by AC A6C crypto uh and as you can see there are a lot of projects that they are working in the ZK space uh but unfortunately or fortunately most of them these days are focusing on the scalability purposes but as you can see in the headlight A6Z crypto believes that the ZK proof is the endgame for blockchain for privacy scalability and interoperability and in this talk I want to just talk about the privacy but outside the Ethereum ecosystem unfortunately. So the rest of the talk is going to be about Zik login that I uh contributed to this work during my internship uh at Miston Labs. Um and Miston Labs for those of the people who are not familiar is the company behind three blockchain and other projects. You might already heard about warus and move smart contract developed by aptus and uh sui both um but zika login was deployed on sui which is uh object centric blockchain. Uh what that means it means that the objects can be divided either to or shared objects and whenever there is an object you don't need to check them in the same lock.

Okay. So it it gives you a huge um improvement in the latency and also the scalability which gives you around 300,000 transaction per second and also half a second for the latency. As you can see uh in around one year uh Zika login has became uh one of the most widely used ZK apps to date uh with around 8 million transaction till March 14th. I'm pretty sure it's around 10 million right now uh with 2.4 million unique proofs.

I will discuss that why there is a difference between the number of the transactions and also the number of the proof generated in the later in the in the next slides. So the problem statement that we are trying to solve in Zika login is uh pretty fundamental. Um as you know that there is a huge gap between the number of the active web three users and web two users. So we have maybe around 100 million active web two users according to the statistics but we have more than five billion web two users and there's order of magnitude gap here here so most of you already on boarded to a wallet which is metabask is one of the widely used one um and those of the people who are not uh tried this one you can try or you the other people can attest um you need to remember uh 12 to 16 nemonics um which is equivalent to maybe four to five passwords in terms of the complexity and sometimes you've been forced to remember. Uh I think this is the step that usually most of the people uh stop uh somehow like a bridging the gap and then afterwards is is now possible to uh continue the process.

So once you enter to wallet you can interact with the with the chain that you would like to do and it's mostly I just want to highlight here that the your recovery phrases is somehow giving access to your secret key for making the transactions. Okay. So what we do in Zika login we combine the OOTH OOTH is stands for open authentication mechanism. I mean we are not reinventing the wheel. Uh we already saw that how web two uh is creating and bringing you a better user experience.

you have one single maybe account on Google and you are using for multiple web apps and different applications and you don't need to create separate accounts for that specific app. Okay. So and then we combine it with zk snarks but we would like to be non-custodial and also user friendly and more importantly privacy preserving because I want to highlight the importance of the privacy on that respect as well. So a quick uh summary about the open uh open id connect which is an extension to o of 2.0 Oh um there is multiple flow uh that you already I mean maybe we are using daily uh this protocol that you would like to get some resources from some web apps like LinkedIn let's say and then instead of uh creating and entering your credential on LinkedIn you'll be redirected to some ID provider which is like Google and if you enter your credential correctly you will get a token this token is the most important part of this slide and this token is in the format of the JSON web token some of you might already have experience working with it.

There are some main fields like header, payload and signature. And this signature is in the format of the RS2 RSA signature which show 256 in 99% of the times. And in the payload there are some sub fields including the client ID which is uh I mean the web app uh LinkedIn has a separate client ID than other uh let's say uh websites and there is a issuer ID Google and a Slack or to each have separate ID as well and there is a nons that the user has a full control on it. You can put whatever that you want. You can put the hash of your uh wedding image or whatever that you would like and Google is going to sign it.

Okay, this is the hint that you can get from my talk that play with it. Google will sign everything that you would like if you put it on the nons. Okay. And then essentially there is a user ID u that for for all of us that if you are using this mechanism Google knows that where you have an account. Okay.

So if you are I mean having an account on takeaway if you have an account on Uber or other places because this is a static and it's not going to be changed. So now the question that we want to ask uh and answer is um can we change and instead of having a secret key for signing the transaction detail can we replace it with a JSON web token because this is like a somehow a secret key that is only owned by the user who has already entered the credential. Okay. So let's take a look on the exact uh way of and format of this uh JSON tokens. There are a lot of details.

The first one is the issuer ID that I already told you. Uh, and I just want to focus on the nons that I told you before that you can put whatever that you want. But in Zika login, we put it a firm public key and an expiration time. Okay. And a firmal public key here is important because we need to have a signature for the integrity purposes for the underlying blockchain.

If you are sending 100 and if someone is and if you are not signing, someone can change it to 1,000 and steal your money. Okay? So this is the importance of using a signature for the flow of making a transaction. Sounds good. And now someone might ask that what about address if this affirmal public key is not required to be remembered because if you remember from the recovery phrases we said that if you remember the recovery phrases you can retrieve your secret key and you can retrieve your public key.

But if this is a firmal, a firmal means that you don't need to remember and you can change it if you are changing your device or the session is going to be ended. And what about the address? Because basically we define the address as a hash of the public key. But if you define it in this way, it means that whenever you are changing your device, your address is going to be changed and you need to swap all of your assets from the previous account which is like a pain. So we define the address in a different way.

As you can see all of these inputs are user dependent and are static. It's the Blake 2 of IDP which is the identity identity provider ID which is like Google let's say and we have the client which is the SUI wallet and we have also the user ID which is a constant but we need to add a salt for the onchain privacy and this salt is somehow disconnect the web two and web three identity of the user otherwise Google can sit down and see that what are the transaction that the user is making. Again here is uh another image that you can see that how we are fetching the data from the JSON web token to uh define the address. So we need to use the ZK proof because we cannot actually provide and send the JSON web token to the validators on chain to check otherwise they can impersonate you secret this JSON web token is a secret key and they can enter to any content that you have like Twitter and other places. So we need to use the zk snarks to hide some part of the data and more importantly the JSON web token.

So essentially the the relation that we are proving using zk snarks is in this format that the user proves I have a valid JSON token that is signed by Google. Okay, you need to fetch the public key of the Google and then additionally you say that the address is consistent with the specs and information in the JSON web token and additionally the signature that I'm claiming for transaction creation can be verified under the firmal public key that is inside the JSON web token. Okay, so this is the gist of the uh protocol. Uh so this is like uh Zika login in one slide. Um we have like the uh credential issuing space in the first step and whenever the user wants to make a transaction it needs to create a zik proof plus a signature and then send it to sui blockchain for the finality of the transaction.

So uh some benchmarking um so for the first the good part of the zika login is the proof can be reused and you don't need to create a separate proof for each transaction and once you create this proof which takes around 3 seconds right now we outsource the proof generation because the number of the constraint for this is deployed using cross 16 by the way uh with 1 million R1 CS constraints um and unfortunately it's not possible to generate the proof locally on a browser uh and we outsource the proof and it takes around 3 seconds. But once you create this proof and cache the proof on your browser, you don't need to regenerate it. So this is the demo uh that you can see the user just click on the on the Google uh and then um it already opened a session with Google didn't need to enter the credential but ideally it should create and then uh takes around 3 seconds and now the transaction is done. So by doing this uh actually as I told you before uh the proofs are not uh doesn't need to be re created and regenerated and it was the main reason that I told you 8 million transactions while there was only 3 million around 2.5 million generated proofs.

So there are maybe three times uh each proof is being used on average. So I just want to leave a question here uh for the uh uh networking session. Why we don't have a similar tool to Zika login on Ethereum? Um that we can discuss afterwards if you're interested. Thank you so much.