Building for Real Humans with World - ETHGlobal Bangkok 2024

[Music] hi everyone I'm Ian I do devell for world and I'm here to tell you about building for real humans so we have this one really big important question here how do you know who is a real and unique person online you might think about captas or things like that but it's really hard to solve this problem in a like really powerful strict way but that's what we built World ID for World ID is our proof of personhood protocol letting your application know that this user is a real human with only one account but with that user not revealing anything about which real human they are right so I'm a unique human I'm doing an action only once or really however many number of times you want and optionally with this tamper proof message that we call the signal we've built World ID to be private inclusive and robust we don't want the user to have to reveal extra information about who they are we want as many real humans as possible to be able to use this technology and we want to make sure that it's robust ensuring that every real human only gets this one account and when we think about how to meet all of those requirements with email and phone numbers they don't work super well I have many email emails I have multiple phone numbers we might think that kyc of official government IDs is the way to go but less than half of the global population has a digitally verifiable government ID so it's not scalable enough for us web of Trust Systems also don't scale to like all of humanity in their current implementations very well most web of Trust Systems start with an initial trusted set of like a hundred or a thousand people but scaling that to eight billion doesn't really work that well because every hop away from that initial trusted set you are in a web of trust is really the less trusted you can actually be and so we settled on using Biometrics because they can be unique to every human there is like obviously the human component of Biometrics at all um but there's multiple different biometric factors that we can use we looked at fingerprints Palm scans face scans right things that you might be more familiar with for like touch ID or face ID on your phones but those actually don't have enough entropy to determine uniqueness at the scale of all of humanity right like Bas ID on my phone can distinguish about one in a few million people which is totally fine for unlocking my phone I like those odds a lot but one in a million for determining if you're unique amongst all eight billion or so humans that exist breaks down really really quickly we also took a quick look at DNA right it's very very unique to every individual but it can't be done in a private manner right there's no way that we could say we don't know anything about who you are if there's DNA involved so ultimately we settled on using the iris which has a lot of entropy it's Unique to every human even like identical twins have very different irises and it's also something that requires a level of of consent right you can close your eyes if you don't want someone to see your iris it's not something that can be scanned like passively while you're walking past on the street like your face could be you're not leaving fingerprints or like palm prints everywhere like you are on glasses at restaurants and things like that so then how do we actually use these Iris Biometrics phone sensors just aren't high quality enough uh there's one phone I'm aware of that did have an iris scanner for unlocking and it was was very easily broken with like some hard contact lenses and printing an iris on a piece of paper we looked at off-the-shelf Hardware like what clear uses at airports in the United States for a faster line through security but they're really big they're expensive they don't meet the requirements that we have so we became a hardware project and had to build custom Hardware just because we care about solving this problem as effectively as we can and that Hardware is the orb so the orb has a couple different sensors on it it's job is to First make sure you're actually a human running over a dozen machine learning models locally on the orb it takes a photo of each Iris and calculates this Iris code this digital representation of the pattern of your iris and that's what we use to check and make sure that you're unique these Iris codes are stored in this really fascinating MPC system if you want to learn more about like the cryptography behind that how we do this super privately and super safely and securely I'll H I'm happy to chat about that at our booth after this Workshop um but once we know that Iris code is unique your world ID gets verified and your world ID is essentially just a key pair in World app on your phone verifying it means that the public key goes into a Merkel Tree on ethereum mainnet it's essentially just the list of verified world idas and we've built this whole system to be privacy first decentralized and open source right everything about the protocol is open source the majority of the orb hardware and firmware and software is open source I can go more into decentralization at the booth like too many like great things to talk about in a short workshop and when it comes to actually using World ID like what it makes sense for civil resistance and Bot resistance make sense for a ton of different use cases right the protocol call that world IDE is built on top of semore was actually built with like voting in mind as a key use case obviously social media makes sense right Twitter sucks because of how many Bots there are it would be great if you could know that there is like a real human and this is their account customer incentives are one that I particularly like Netflix used to have their twoe free trial every time a new account was made so people just spun up more and more email accounts to get this Netflix twoe free and never ended up paying for Netflix Netflix doesn't like it when people don't pay them so they got rid of the twoe free trial but with World ID they could offer a twoe free trial or even longer maybe a month maybe three months knowing that you as a real human only get that one free trial and then you also get the free trial back just for being a real human but when when it comes to all of these use cases how do we actually like get these use cases into the hands of people who have been verified with World ID and that is mini apps so we recently announced mini apps at a keynote in San Francisco last month and mini apps are these applications that open inside of World app where you can interact with World ID and have users verify like they would in an external app just with a better user experience they don't have to switch applications or anything like that and for the first time external apps not built like by the world project can interact with the wallet in World app so you can do things like sending payments or even just general transactions interacting with any smart contract you want on world chain our own op stack layer to and additionally we can give these applications distribution to our millions of verified humans in world apppp World app has over 15 million users over 7 and a half million of which are verified at the orb and your app can be listed in this app store and if it's especially great it can be highlighted on the homepage of World app in like a card so that users can hear about your app for the first thing that they do when they open World app so how do you actually build a mini apppp so every mini apppp is a web view in World app right it's essentially a pwa but instead of added to your app's home screen it's accessed through World app and we built a new SDK called minikit specifically for these mini apps so something I'm not showing in the workshop but is like the first thing in our docs that you'll see is actually installing minikit uh you'll wrap like the main body of your like Javascript app in the minikit provider so that you can access this minikit object globally so to start start let's see like what it looks like to actually verify with World ID in a mini app when you first configure mini kit and like set up that provider it will already have your app ID as you've set up in our developer portal so for this verify input we need the action the user is going to verify for in that app the signal if you choose to use one right as an example of what you might actually use that signal for if your user is say voting on a poll in your mini app that signal might be which poll option they selected because that signal can't be tampered with between when this verification is generated on the user's phone and when that proof is later verified with our developer portal API or with our smart contracts on chain so it's optional definitely not required but useful in a lot of circumstances and then this verification level defines which like World ID credential your user is required to have I've already talked about the orb credential we see that is sort of the gold standard for knowing your users are real human with only one account but there's also the device verification level for offchain use cases where world apppp has checked that it's running a legitimate version of the app on a real phone not a virtual machine and that it's not in like an app cloner environment so instead of knowing it's a real human you at least know it's a real device if I want to try to Cil attack your program with that device verification level I'm going to have to buy a lot of like $50 Android phones or something like that so it's definitely a weaker credential but one that every like real world app user has whether or not they visited the orb and is much more scalable so I've configured all of these things for this action I want the user to verify for and then I Define this like handle verify uh function here which I'll just call whenever like the user clicks a button in my app to actually like go ahead and verify with World ID we'll first just check to make sure that minikit is actually installed and configured and then we issue this async command to minikit so this verify command takes the input we defined earlier that promise resolves when the user has completed the flow of like tapping verify in the app or declining to verify by tapping out of the model and then we get this payload so this payload will have a status field uh that'll be like success or error uh just to see if the user actually went through the verification or if there was something that prevented them from doing it and then we take that payload and we have to verify that proof right so that payload actually you know also has the success field this is ripped from an older Workshop sorry but it has a su that success field or error field and then this is the actual Zer knowledge proof that was generated on the user's phone the Merkel root is actually like the root of the tree that the user generated that proof against right gotten from ethereum mainnet the nullifier hash is the identifier of that user in the context of your app ID and action ID right so if I try to do the same action twice I generate the same nullifier hash which is how we actually Implement that Cil resistance but if I do two different actions there's two different nullifier hashes and there's no way to tell that those two nullifier hashes actually belong to the same real human and that's how we have this privacy where it's not revealed which user is verifying just that one of these real users is verifying and only doing it once this proof is this very long hex decimal string that's mathematically like the zero knowledge proof itself and then which verification level that proof was generated for so in this example we'll verify this proof with our developer portal API so you'll Define a route on your app's back end uh that will receive this proof uh so here we're just passing that proof the action and the signal if you used one to your backend and if that backend function that I'll show in the next slide uh does verify correctly and your backend returns this positive response then you should just go ahead and uh like redirect the user to the next page because you know they're verified now or else show them some sort of error to actually verify your app in the back end we have this helper function called verify Cloud proof that will take in the proof the app I the action and the signal and handle calling our developer portal API to verify that proof so you'll either get this successful response or an error response if it's successful in your back end is where you should like Mark the user is verified in your database or something like that right but you want to like take some action with that successful result in your back end because your backend is a secure context if you were to just pass that successful result back to your front end and then like try to Mark the user is verified from there right make another call to your backend to like change the database or something like that the user would be able to manipulate that information in the front end so that even if they verified unsuccessfully they can then just change it to say it was successful so you have to like keep certain things within the secure context of your back end but this is like literally the whole like backend code here it's super simple but you can also verify these proofs on chain so in your smart contract right in this example let's say there's just one like action for your whole app that the user wants to perform uh in your Constructor you'll pass in the address of the world ID router you can find that in our documentation uh for World chain is supported on other chains but for mini apps you can only use World chain so that's all I'll talk about here and then you'll pass in the app ID and the action ID so we'll have this world ID as just like the instance of the world ID router contract this external nullifier is a combination of the app ID and the action ID that is what actually determines like the uniqueness of an action it's more of an underlying protocol thing uh that's just needed when you're verifying these proofs on chain uh so just rip that code from our templates that I'll show you later and reuse it you don't need to modify it or worry about it too much and then in this function which is just verify and execute right what you're actually executing is sort of undefined here that's up to you we'll pass in the signal the Merkel rout the nullifier hash and the proof that we got from those from that like proof object when the user verified in your mini app uh you'll note that we don't take in the verification level here like we did for the backend verification and that's because only the orb credential is supported on chain that device credential is not supported on chain uh so if you want to do that device verification level your app has to be offchain for that proof verification so the first thing we'll do when we get this proof in our smart contract is check if we've seen this nullifier hash before um so we'll have this mapping of nullifier hash to a Boolean that nullifier hash is a you know 256bit unsigned integer uh so if this nullifier hash already maps to true in that mapping then we RT with this invalid nullifier like event uh and that just means the user's already done this action we don't want to let them do it a second time if that isn't set to true the user hasn't done this action before so then we'll continue and call the verify proof function on the world ID router smart contract so we'll pass in that route the group ID defines like which credential we're working with uh for the orb credential on chain that is always one uh we will hash the signal in a specific way for that uh for that verification with the smart contract that hashto field helper function is defined in our templates as well we pass in the nullifier hash the external nullifier that we set in our Constructor and then the proof If this proof doesn't verify for whatever reason maybe the signal didn't match up with when that proof was generated or something like that this will revert otherwise it simply continues it doesn't return anything so you already have that like flow control there built into this verify proof function so if that doesn't revert and continues then we should make sure that we Mark that nullifier hash is used to prevent the user from doing this action again in a separate transaction and after all of that that's where you should put your logic of what you want to allow the user to do behind World ID that might be minting a token to them that might be claiming an nft that's totally up to you that's what's up to your application but you should verify the proof at the start of this function and after that proof is verified and the nullifier hash is marked as used that's when you go ahead and do the thing that requires World ID and how do you send these transactions with minikit so as I mentioned with minikit everything happens on world chain our own op stack L2 and in World app we have some like fancy functionality for covering all the gas of our users transactions and batching all of them together so you can't send these transactions with typical tooling like wag me for example but we have this send transaction command for minikit and when you want to send this transaction similarly as earlier because it's an async command that promise will resolve when the user actually like completes the flow either tapping send transaction or clicking out of the modal you'll specify the address of the contract to interact with on world chain you'll have the ABI of that contract uh which you can either import or just Define inline if you really want to you'll have the function name right verify and execute as we had in our contract and then you'll put in all of the like Arguments for that function that you're calling so in this case for verify and execute we have the wallet address of the user as the signal we have the Merkel rout we have the nullifier hash and then the proof you have to like split up into an array of 8 256bit unsigned integers it's a little wonky but again you can just use the code from the template that we'll provide so sending transactions with mini kit is fairly easy one thing to note is that if you want to have a transaction that involves sending a token that isn't eth uh you do have to use permit to our documentation will go into this uh because for the user experience we'll have you request the permit to in the same like send transaction command and then on the world app side it's actually just one like tap for the user to send that transaction that will generate that permit to signature and then send the transaction with that signature included in order to you know allow those tokens to be transferred by the smart contract so that's sort of like the quick rundown of how to build with a mini app we have 20K worth of bounties available and we're giving $10,000 to the best mini app $5,000 to second place $2,500 to third place we are all in on Mini apps at the hackathon we want to see these mini apps get built in this 36 hours and ideally be shipped to the mini App Store in World app we want to see these real things be built that we can put in front of users and show them what they can use their world ID and their funds on chain for we're committed to providing support after the hackathon to help you to polish and grow your application uh and Leighton Leon will you raise your hand he does ecosystem for us if you really want to chat about a lot more like stuff you can do with mini apps like it he's a great person to talk to about everything that isn't a technical question relating to mini apps that $2,500 po prize will be split equally among all projects that submit for our bounties and make a good faith effort to build a mini app uh but don't receive one of these larger prizes and all the documentation you need for mini apps you can find at docs. world.org Min apps and thank you so much so he was asking if you need to be a verified user in order to use the app no so you can download and install World app without ever verifying at an orb you'll have that device verification level right you can still use the wallet you can still use the mini apps but if Min app requires that you verify with that orb credential you won't be able to verify for that specific thing but you can still use all these mini apps you can build all these mini apps without verifying we do not have any rust support for mini apps to my knowledge at the moment can ER is there a a is there a way for a for your application to for worldcoin to know if a person is registered ER anywhere for example if a we are installing anything a person is registered yes or no I so wait is the question if like will you just repeat the question I'm sorry it it say from it say you are using an orb and you are verifying that you're yourself but you do don't have your cell phone uh I ER with is there a way to verify that that person has already been onboarded into worldcoin so to make sure I understand it the question was like if someone doesn't have their phone with them is there a way to verify like with the orb that that user is already orb verified um not for your application like the orb will reject a second verification for that user so they wouldn't be able to verify again but your application can only like verify that that user has a world ID when they can generate that proof okay I think my okay my question okay better way to better way to explain my question uh can I know if a person has been registered to workcoin or not or not I the way that you can know if that user has been verified or not is by making them like verify and generate that proof and then your app verifies that proof correct you you can only prove that you are verified you cannot prove you are not verified how hard is it to set up a new orb station in a country so today tools for Humanity manages orb operations uh for most of the world next year we'll have this community operator program where people will be able to like buy or rent an orb to operate in their local communities uh we announced that at the keynote in in San Francisco last month uh still fleshing out a lot of details there but it will be easier to bring orbs to new countries starting next year [Music]