Self Workshop I Evi Nova

So um yeah, welcome to the self workshop or the integration. Now I am a little bit biased but I promise you self is really easy to integrate. So what is self for those who don't know? Um basically KYC kind of sucks. You have to rely on trusting people with your data.

I don't know about you but I hate uploading my passport or my ID card. You have to trust people. You have to trust they're not selling it. They're going to trust that their servers aren't going to get hacked. So what's the solution?

Introducing self. So with self, you can use your biometric uh ID or your passport or your ATAR, which is a Indian national ID card, and you can basically prove your real person and prove information that's on your passport. So any kind of data field you see on your passport, nationality, date of birth, you can check that you're not on the OFAC sanction list, you can check that you're over a specific age, you can check that someone's not from a restricted country like North Korea, for example. Hello Lazarus. Um yeah, and obviously uh self is great for providing civil resistance, right?

Making sure that your users are not bots. Uh and you obviously prove your facts about your passport. uh again certain above a certain age, not from the sanction list, not in a set of countries. Uh so basically when you're thinking of your hackathon idea, think anytime that you want to have unique users and not bots, great use case. Anytime that you have to upload your passport and you get pissed off, great use case.

Um yeah, so that's like the that's like the basis. Obviously, we want to see really cool unique ideas. You can also use self to verify information on your passport and then use that with other data sources to like chain the uh the proofs of information. Um so yeah we have AR support now which is awesome. Uh opens up a lot of new people in India.

Um well this is uh when the internet's working this shows the map of our coverage. Uh a lot of country mo basically most countries I say will support us at this point. Um so yeah so what does it look like? Uh basically you grab your passport and it scans the MRZ which is the two lines at the very bottom and then it uses that to read the NFC chip. It grabs the data from the NSE chip and it creates a ZK proof.

Uh that ZK proof is stored on chain and then you can use that to make disclosure proofs which is proving information to the app upon request. Um so I don't want to get too deep into it. I just want to get into the code and showing you how it works. But basically, you can see the passport gets scanned by the mobile app and then you have a secret generated and this secret is what gives you access to your ZK proof that's stored on the Cello blockchain. We send your passport data to a TE and we verify that it's the correct TE which destroys your data upon creating the ZK proof.

Um the zk proof does the proof generation uh using groth 16 and then it sends that to the onchain merkel tree on cello. Yeah. So um there's two different ways to integrate itself. So basically you can see we have the app um which is running and you have the front end which has a QR code. The QR code is what users will scan.

it'll do the verification and then the ZK proof is returned back either to the onchain verification smart contract or your own backend can do the verification as well. So we have two different tracks. We have the onchain verification and we have the backend verification. So the main prize uh pool is the onchain verification. So QR code gets scanned, ZK proof is then sent to the smart contract and you do the onchain verification on Cello.

The other track is for doing the backend verification. This one in the workshop we're going to focus on the onchain verification. So um let's get to it. So I'm going to pull up our workshop repo. So if you go to our GitHub, we have the workshop repo that I'd highly recommend you just fork it because it's already working.

Okay. I'm just gonna Oh, maybe too much. Okay, cool. So, you have forked the workshop repo. Now, what do you do?

So first of all you want to go to so we have two different folders here right we have app and we have contracts app is your front end integration contracts is your smart contracts so firstly you're going to go into your app um you're going to do npmi to install all the packages you're also going to copy the env example and you're going to make av you can see here we have app name uh the scope seed it's very important that your front end and your back end uses the same scope seed. Otherwise, you're going to run into issues. The self endpoint here, that is where is the verification happening. For onchain verification, it's your smart contract address in lowerase. If it's the backend verification, this is your HTTPS link to your server.

So then in the contract we have the ENV example here, right? So you're going to f again copy this ENV example to your ENV. Fill out your deployer private key. Make sure you have uh Cello Sepia uh selected. Now if you deploy on Cello mainet, you need to use real passports.

But if you're on seller sepalo, you can use the mock passports that you can generate in our app. Um, so you can see here we also have the uh verification hub contract. Just make sure you're using the right one depending on where you deployed. This is optional just for verifying your smart contract. And again, the scope se this needs to match up with the other one.

So uh this is a very very simple integration called proof of human and it's just basically checking that you have a passport that's on self. You need to inherit from this selfverification route contract which is what interfaces with our verification hub. So you can just go through this at your own pace, right? Um these are just like uh for testing purposes. This you'll will need to set up.

This is like the core stuff, right? Um so we can see we're going to pass in the verification hub uh contract. So that depends on seller mainet or sepia the scope seed. Uh the verification config. The verification config is basically like when you call the verification contract, it's basically telling the hub what are you doing?

Are you checking that someone's over the age of 18? are you checking for the nationality blah blah blah. So yeah, you set that up and then there's two functions you have to um implement that are virtual functions uh from the parent contract. So you have the custom verification hook. This is what gets called after your verification succeeds.

So you can see here you have an output and the user data. So the user data is passed in from the front end. So your front end can actually pass this in and the output is uh containing all of the information they've disclosed. So you can see here uh they can disclose their nationality, the date of birth, the gender, expiry date, older than whatever age. Um so if they have disclosed that data, you can call that information otherwise it's going to be left blank.

And how you would call that is like for example just say I want to store their nationality. I would go nationality equals output nationality, right? But we're not doing that for this one. We're just doing a very simple um just making sure like just grabbing the data. Um okay, so uh yeah, we have get config ID.

Uh this can basically be used to have different verification configs. So you can see like in the constructor we set this and we we defined it. But if you want to make it different like the user identifier or a user defined data can be passed in here. So just say on your front end you say have a button I'm over the age of 18 this would be like over 18 you know um or if you wanted to have like they have different buttons and then that data can be passed in the userdefined data and used for different verification configs. Hopefully that makes sense.

But basically you don't have to touch this if you don't want to have different verification configs. It's like dynamic uh configs. So, um, that's the smart contracts. Um, so basically what you would do is you go into the contract. No.

Right. And then we're going to run uh, we have the deploy contracts here. Uh, the deploy script as well. Um, so I'm just going to do Oh, actually the internet is not going to let me deploy this, I think. Yeah.

So, the obviously with the Wi-Fi working, this would this would deploy a contract. Um, but right now it's not. Uh, I also just want to highlight in the front end the main uh QR code logic. So we have here where it okay so then yeah in the front end this is the main component for constructing the QR code that the users will scan um again the scope needs to match up um and the endpoint uh and you would have your disclosures uh you'd have your disclosures down here, right? So, we're just checking that they're over 18.

Um we don't have any excluded countries, I think. Oh, yeah. We're just checking that they're not from the United States here. But then, um yeah, you can uncomment this if you want to get, you know, like name issuing state. You would just have this under your disclosure struck.

Okay. So, um, okay, I'm a little concerned with the the no Wi-Fi situation, but basically, uh, so you run the deploy script, right? That's going to give you your contract address. You and it should give you the contract address in lower case. We then go to our ENV and we put this here, right?

Um, did I have a workshop? Okay, nice. I I'm not sure if this was set up correctly, but we're going to we're going to scan this and see what happens. But this is what you would see right on your front end for the demo workshop. So then what I'm going to do is I'm going to have my self app and if you go to self.

xyz and you scroll down a little bit, you'll get the download link for our app. Uh we also have at the booth the QR codes you can scan for the link tree and that'll contain it as well. So, I'm a user. I want to prove my identity. So, I'm just going to scan.

So, yeah, again, the Wi-Fi is an issue here, but you know, basically what happens is your self app shows the uh disclosures that you're going to do. So, you can see ahead of time. Lena, Lena, don't take that photo. only have limited photos.

Um, yeah. So, it's going to on your phone, it's going to say, "Okay, what are you going to be disclosing, right?" And then you hold to verify and then it's sending uh your ZK proof through the circuits with the verification config, making sure everything lines up. If it all passes, then the smart contract gets that hook called and the front end also gets uh some data passed into it that you can use as well. Um, if I go back to the front end, oh wait, sorry, different screen.

Uh, yeah. And then there's uh yeah, handle verification. So once the uh verification passes, your front end has this called, right? And then you can do what you would like with it. Um, and I think uh, so yet also another point here, user ID.

Um, you can either, so for our demo example, we're just passing in a zero address, right? But you could grab the users's connected wallet, for example. Uh, or you could create a unique user ID. Um just be careful when you are connecting a user's wallet because if you have the user's connected wallet and they disclose all their passport data for example, you've just tied their onchain wallet to all this data. So you can get if you want to be a little bit more private, you can create the unique user ID.

So then your front-end server knows okay this wallet is assoc associated with this unique user ID and then on the smart contracts on chain all it's seen is unique user ID is associated to this disclosure proof. Um and then also you have the uh userdefined data. So you could have like the user input something right and then this gets put into user defined data and then that is obviously passed into the smart contract. Yeah. So that's user data right.

So it goes for the veration, then your smart contract has that data to work with as well. And that's it. It's it's honestly it's really simple. Front end with a QR code, back end with the smart contract verification. And this is where you put all your custom logic on chain.

And yeah, that's basically it. Does anyone have any questions? Yes.

Hello. the userdefined data you mean? Okay. So,

okay. So, uh this is userdefined data, right? So, you could have like uh this be filled out by uh something on the front end. They fill it out and then you pass this into here, right? Uh this is all sent to the uh onchain verification in our example.

After the verification has succeeded, then this function gets called and user data is passed onto the smart contract as well. Does that make sense?

Yeah. But basically the userdefined data is just some data that you want the smart contract to also have some kind of interaction with um yeah after it's done the verification.

This is an example of the verification.

This is an example of the onchain verification and I recently created a branch. So I also have a backend verification example. I also have a hyperlane example showing showing you how to do because right now it's all happening on Cello, right? But if you want to do some kind of crosschain interaction, you want to take the message like after this custom verification hook, then you say, okay, and then we're going to take this this output, this uh generic disclosure output which contains the disclosed information, and then we can bridge that with hyperlane with layer zero. We also have a layer zero example as well.

So if you're looking to integrate with one of those two partners, then definitely check those out. Uh because these are working examples that you can build upon. And I highly just recommend just forking and then working on top of that because then you know this works and then you add your logic on top of it, right? Cool. Uh is there any other questions?

Okay, it seems like we're out of time. So if you have any further questions, just come to the booth. More than happy to help you out. And um yeah, best of luck. Thank you.