[Music] With that, we are ready for our last talk. This we're saving the best for last. So, please join me in welcoming Kevin from Self. All right. Hello everyone.
I'm Kevin from Self Protocol. I'm software integration engineer and so before getting started I want to ask how many people here uh have already know or even download self app before okay nice that's why I'm here so today um in this talk I'm going to introduce what kind of problem we are focused at self and how do we solve it and also sharing some good news with all of So how do we really on board the next billion people? That's the question we keep asking internally in self and that's also uh why we feel so excited to build self. So throughout the history there's a lot of different way people trying to make this happen. Uh as far as I know there's three main category to achieve this.
We have proof of work. So basically people invest their capital into um electricity or computational power to try to solve some uh problem or challenge and then contribute to the um stability of the network and get reward for some token. That's what Bitcoin miners do and later on we have proof of stake. So people basically um stake their crypto assets and also help to reward uh the stability of the network and get some um reward as well. We have a lot of different defy application.
Uh since D5 summer we have DAX lending market. You can provide liquidity. You can stake through farming. you can provide to the lending pool and still get some rewards uh from the incentive and all of this method I just mentioned have one things in common they all require user to bring access capital um that's what's the reason it's because capital itself is a very good and very intuitive way to defense against the SIBO attacks If you are a D5 protocol who try to uh distribute your incentive uh proportion to how much people contribute to the how much capital people contribute to the protocol to make the TVL grows to make the metric grows then capital itself didn't provide any incentive for people to create fake account but the people uh the question is that we really need a way to solve CIBOT without requiring uh capital because there's still a lot of real utility use cases that uh people may not want to do trading related or they don't have access capital to provide to participate again currently we create so that's where sales comes in so we are the first production ready uh ZK passport protocol and solution we started this February in East Stanford and now um We we also uh announced our support for EU car during uh canis um during ECC. So what we achieved this is by leverage the most trusted attestation and the mature identity system is basically uh biometric passport.
Why is because this is obviously uh difficult to obtain um difficult to forge and then it's unique to individual people store it very securely if you lost it you are not able to get access to a lot of uh services you cannot do travel around the world and most importantly it's machine readable so I'll explain later uh what do I mean by machine readable and this time for India we are excited to introd introduce now we are officially support Adahar uh for self. So what does that mean? That means now uh if you are an Indian user you are able to use Adaha to register with self and then prove anything you want uh the tribute on Adaha you can prove uh you are Indian people without revealing your age your gender so it's all selectively disclosure and from the metric uh of the government 1.4 follow million billion people uh in India have other and more than 850 million people in India as internet user. So from the builder perspective this is super exciting.
So now you can utilize self SDK to easily verify your user to easily on board your user uh to verify that they are Indian people. you can build an Indian exclusive uh community uh via our plug-and-play SDK. So um let's talk more about the technical behind the scenes. So what do I mean by biometric and machine readable? So basically all of the biometric passport they have an NFC chips um inside it.
So once you scan the machine readable uh information and then use your phone to tap you can read the NFC chips and we can get the signature inside the NFC chips. So basically you can verify the entire authority chain of the uh passport. So it's hard to forge and this is also the system uh the way um egate when you try to travel around the world there's a e-gate so it will ask you to um scan the passport and then they will read the NF ship inside it and then it will open the first gate. When you get into it uh there's a camera they will scan through your face make sure you are the same person. So this is um existing and the mature solution.
We directly migrate and move the entire uh signature verification into a ZK circuit. So you can now verify the validity and the authority of a passport. So what self really enable is that we let you prove yourself without a counterparty. So now when you try to access the services, when you try to prove that you are a real human, you don't have to spend half an hour, upload all your information, your passport, your ID card, your proof of address, you did the bill. No, now you just scan your passport and then proof within like five or 10 seconds.
It's super easy. And not only um the user experience uh improvement, we also uh very um enhance the security and the privacy preserving part. So with self we also use Zcash circuit. So then you can selectively disclose all the attribute on your passport. No matter uh you are a citizen of a country, you're from um any specific country you are above or below some certain age.
So you are maybe within 20 to 29. So this could be very useful for some dating apps. We're also exploring any collaboration as well. And also you can prove that you are not a part of off checklist. This could be very useful for some financial apps.
They can require the user they can do this compliance check uh without asking user to upload any information and user will be super comfortable to do that as well. So what does the experience like and how does it works? So we split the workflow into two steps. So step one is restriction registration. So basically you open the camera and scan through your passport and then you just tap your cell phone in on the passport.
It's like doing an Apple Pay and then we will generate ZK proof to verify the authority chain to make sure okay this passport is valid it's um not being forged by any malicious actor and once it's been um proof we will also generate the nullifier it's a hash of the data and we will also generate a commitment is a hash of users secret plus the data so this will be useful to prevent a double registration and also we will add your commitment into a Merkel tree. So in the future if you want to do any disclosure proof you don't have to verify the authority of your passport again you just have to do a Merkel proof. This will significantly improve the uh speed of proving as well. And so after finishing the registration the step two is that user can now disclose their attribute uh on any apps that integrate self. We provide a front end backend SDK and also onchain SDK.
So for those DAB or any service provider they can integrate self and then on their front end there will be a QR code or DIP link popup. Once the user scan or click the QR code they can see what kind of information specifically explicitly uh on their self app like let's say this example it require user to prove that they are above 18 and they are not part of OAC checklist and if user feel comfortable to share with that they can just long press and then we will generate ZK proof and then no other information will be disclosed. And behind the scenes is that it will have a Merkel inclusion proof and then we'll also generate uh Z um action nullifier which is the hash of the user secret and scope. So why what's the decision to do this like registration and disclosure separate architecture is that it's uh fully anonymous. So given different apps have different scope that means the nullifier is completely different and it's also different from the nullifier you do you use uh when you do the registration.
So from the um others perspective they cannot check the nullifier and trace back that okay this user uh have been access service A service B they cannot do that because all the nullifier is different. So let's do a quick recap. So uh the entire architecture look like this. We have five uh important uh tech component uh within self protocol. So basically user first download their app their mobile app and then read through the passport or other documents that we support uh u car or the at the hot now and then it would generate a secret to use either it's keychain or you can store it on any password manager you're comfortable with or you can write it down or on your app notes uh Android notes whatever if you can as long as you can remember it that's fine.
And here we also do a very interesting ar decision. We use TE instead of a client side proving because as a production ready application we didn't expect user to download like a three or five gigabyte circuit. So to improve the user experience here we use TE. So whenever user do a registration or they scan the QR code they will establish a connection between the uh user mobile to TE and before sending any information or sending any sensitive data to the TE we will first do a testation for the TE which is we want to make sure that okay the the program run inside the machine is expected it's not a malicious TE or any random um any random server that we create. So you can truly trust that okay no one are able to modify the code the program run inside the TE and so the logic once you establish connection make sure the TE attestation pass then we will in you encrypt the passport data and then send into the TE and inside the TE we will decrypt the data and then generate uh gross 16 ZK proof and then finally delete the PES data and we will be the relayer to relay the proof to the endpoint you specify either it's um offchain endpoint if you integrate with our um backend SDK or it's a onchain address it's a verifier contract then we will help to relate your proof to that so that also means your user do not have to know anything about wallet do not have to know anything about how to manage their gas token because we relay the proof to And and this time we offer 10k bounty for uh is global nudity.
So if you are interesting to build on top of self we have 9k on our onchain verifier bounty and 1k to our offchain track. So if you are looking into uh building any interesting app you can talk to us. All of us are will be on the booth and if you are if you want to grab some interesting swag like we have um our t-shirt or passport cover so yeah just make sure you download the self app and you can talk to us build on top of self as well. So after understanding all the architecture and the tech behind self. So you may wondering how can we use self now?
So we just announced our partnership with a few weeks ago. So now if you are a user of self you can use uh self to verify that you are a real human and you will get a self so token with that so token on the cello uh USDT and we a market you can enjoy double incentive which is around 13 to 15% for USDT. So make sure you are registered when you access the A uh market and not only a web to part we also collaborate with Google cloud. So in the near future um they will have their test net faucet and mannet faucet. So you will have to prove that you are a real human to get uh mannet token mannet faucet.
And we also have others partnership like Veladrome you can um basically the ERC20 will verify that okay you are the owner of the sale SBT. So the swap and uh provide liquidity can only within the verified uh human and verified address and forecaster talent protocol. You can use self to prove that okay uh you are the real human you um fulfill some criteria then this will increase the profile or the score of your profile. So that's all about my presentation. Thank you so much.
Hope you guys enjoy. [Music]
Automatic transcript — names and jargon may be misspelled.