World Network: Ensuring Privacy and Accessibility at Scale

Transcript

all right hi everyone my name is Daniel uh I'm on the protocol team at tfh for those who don't know tfh or tools for Humanity is the first core contributor to the world ecosystem so you can think of World app world ID World chain these sorts of things and today we're going to go through some of the things that we've been working on that involve Noir um and really a big effort of ours to move a lot of the uh approving that we do to the client side and how we explore bringing CLI side proving to kind of you know uh uh pushing it as as hard as we can all within um you know bringing like maximally uh privacy preservation within ZK context so the first thing first if if you're not familiar with world or

World coin World chain um succinctly put it's the largest real human Network um we basically use a bunch of uh sensor data sophisticated sensors from the orb it's a hardware device that we manufacture uh and a bunch of mathematics to prove that a given person is a unique person amongst the set of all people who have ever come uh and verified through this process um what this allows us to do is it's enables us to essentially say who's a bot and who's a human um and this opens up a lot of really interesting use cases um with these uh uh uh two aspects we're able to create a really rich uh Network and ecosystem of applications protocol mechanisms to really deliver an enhanced

ux for for real people alongside Bots for example one of the things that we just launched on world chain sapoia was priority block space for humans um we're looking at you know gas subsidies for humans um because we can know that these users are real users and we can give them preferential treatment um for a better uh experience both on and offchain so I think it's valuable to go through kind of like end to end how the system works how a user on boards to the system and then how they actually use their world ID um so first things first a user will download the world app which will set up a semop for key PA set semop for is a protocol developed by the Privacy uh scaling exploration group that's supported by the ethereum

foundation which essentially allows you to prove membership inside of a set inside of a ZK context so the way this actually works is um the public key generated from this key pair set exists within a Merkel tree where then the user can take an inclusion proof proving inclusion of this ident in the set for a given route and then prove this uh uh proof within a ZK context alongside proving that they own the private key corresponding with this public key and so users can say without ever exposing who I am even an identity within this set um to a verifier that I am actually in this set so where this becomes really interesting is how we couple this with the orb the orb is essentially the entry

point um for the proof of personhood credential that um basically it's it's this Hardware device that has a bunch of sensors on board you can kind of think of it as like a a really high-powered camera that takes a really high resolution photo of your face and in that photo it's able to derive essentially the entropy in your eye this uh these values are translated into basically a bite array where it's compressed a bunch of filters are applied to it uh and it's uh translated into what we call the iris code this is encrypted and then it's sent off uh for a multiparty computation that verifies that this is a unique identity amongst all the identities that have ever signed up uh and gone through this verification

process there's a ton of uh technical docs there's a paper we published um so uh on the MPC setup itself so I'll kind of gloss over uh the details there and and keep that high level but feel free to come snag me after the talk and I'm happy to send you all the references and documentation it's actually a really cool setup if you haven't read into it um so just a quick review a user will will download the world app generate a semor key pair set go through the verification process and then the public key uh with the corresponding private key the public key will be inserted into a Merkel tree that exists on chain on ethereum Main net um then that route for uh you know the updated tree will be bridged to all of the corresponding

chains where World ID exists where then users applications both onoff chain can uh uh uh use this route to um create a world ID proof saying I am a a member in this set I verified without ever have to having to say which member of the set you are we exposing any sort of public data uh private data about that person cool so a brief look at the network today right now we have 11 million uh unique humans that have signed up and actually gone through that verification process there's 23 million users who have downloaded the app have a semicore uh key pair set and have some degree of a uh a credential whether that be like a device uniqueness credential

the proof of personhood credential via the orb and then we've cleared uh at this point over 267 million transactions facilitated via the world app so super exciting about this growth but there's a lot of scale to be had and so we want to evaluate and and look at what are some additional credentials um that we can use and incorporate into the world ecosystem and that brings us to things like a pass support a national ID a driver's license things that are that can be verifiably proven within a ZK context um not only is this something that is more accessible to many people across the world anyone who has an ID if we have this credential set up they can

onboard they don't have access to like the orb for an example um they might be able to use their ID uh uh you know like a passport um but also it includes some interesting metadata that a user can use within a ZK context and you know uh um assert specific predicates over those data uh that data um to say like I am from this country I am you know y years old uh all without ever exposing any of that information to the verifier but this is uh this comes with challenges you know there's the question of like how do you actually ensure that the ID that was used to verify that person is is a legitimate ID and also corresponds with the person that using

it to sign up um this is like a challenging problem to solve there's ways to solve it with varying degrees trade-offs um complexity and often times people will default to the the bad option which is the simplest option which is send all of the data to a centralized server where authenticity tests can be done this is easy to implement um it's lightweight but at the end of the day it's it's you know zero uh privacy preservation and it just does not clear the bar for what we feel uh uh digital credentials should have so at the world Foundation tools for Humanity and a bunch of the partners that we've continually collaborated on this effort we we think there's a better

way this is certainly not the endgame and not something that um we want to uh settle for so the second option if anybody could have seen where this is going is using uh Zer knowledge to verify that the data associated with the ID is signed by a valid government or the issue ing party whatever is the verifiable piece of data associated with that credential can be proven within a ZK context um and then uh uh sent on chain where then an external verifier can verify that yes this is someone who has this uh credential the pro to this obviously is complete privacy preservation the downside is it's actually quite hard um there again

there's ways to approach this with various tradeoffs but one of the constraints that we have that's really spefic specific to the world ecosystem is is operating um within really uh uh constrained uh consumer Hardware devices like sometimes within some parts of the world people don't have like the flagship iOS or Android devices so for this to be an inclusive system we need this to run in kind of like the worst case with the the constraints of 2 200 megabytes of memory 10 megabytes of storage space and about a one minute runtime before you start to run into issues with the OS starting to try to kill processes that you're running on that device it starts to get hairy at

that point and so you know we have this set of constraints that we see as like this is the bar this is what we need to clear and so our solution is essentially using Noir as a a ZK front end a custom proving back end to to bring um all of these things to the client side and then after we generate a set of smaller proofs they're sent to a server that runs this recursive grth 16 proof where then that final proof can be sent on chain so a quick look at this um on the client side you know we're developing Noir implementations to firstly verify that U an identity is like a valid identity for example a passport is

signed by the correct issuing authority um that it it contains the correct met metadata that corresponds with the cryptographic commitment within that uh uh credential um and then further a Noir implementation that uh uh allows us to compute over various predicates with that metadata associated with that credential so for example you know what is the age of that uh individual what country are they from um and then with these we're able to take the intermediate representation generated by new arm uh and then transform that into a gr1 CS instance um or a set of them and then feed this into a Spartan sum Trover and so this kind of Rises our custom proving back end and this reduces

everything into one Pol polinomial evaluation over the gr1 Cs instance Vector which contains all the public inputs the public outputs the hidden inputs and then the intermediate data from the actual circuit as well and so then the this set of proofs is sent to uh the server side where we have a larger instance that can take all of the leg workk and the compute and run this recursive Groth 16 proof uh uh out approver um that uses a skyscraper hash function that basically compresses everything and then gives you one clean Groth 16 proof to put on chain and the reason why we use gr 16 um is to optimize for a proof size uh it's eight field Elements which translate to eight

words on the evm and then with some fancy math that uh Remco wrote a blog post about we can compress it even further down to four words uh and the reason that this is important is uh uh any Layer Two that's post to a DA layer um essentially is going to be competing for a blob space so not only are you going to be paying more money to actually post this data on chain and eventually post it to Da later but you're also making the blob availability a bit more contentious so by keeping uh the actual proof size as small as possible you're making um things a bit more scalable within a layer two context some of the benefits um on the client side using a Nora front end um

gives us the ability to work within rust likee syntax this is huge no longer does someone really have to uh have deep understandings of something like ccom um and they're able to with a more friendly uh uh programming language start to Grapple with uh building these programs um it also allows us to support a wide range of operations quite easily and iterate quickly this is something that we've had uh a really nice developer experience with uh so far and then in terms of the actual uh backend uh a proving backend we're using a Spartan in approver with a we valuation proof um that just gives us basically a maximally efficient um uh proving backend for a use case it also allows us to use uh to to have like zero knowledge to preserve

um user privacy and then lastly some of the big benefits of using a recursive approver on the server side um it takes the compute off of the client and so because we want to have this be you know a flexible extensible accessible uh um proving system being able to have the user generate smaller proofs on their device and then send them to the server allows us to preserve privacy and then offload the compute um to to a larger instance so some high level advantage of this there's no downloading massive uh uh common reference strings Spartan and where doesn't require a trusted setup it's quite efficient um and allows

mobile devices um to do do this work client side uh under the constraints that we're trying to optimize for and then it you know retains uh complete zero knowledge and then Noir just gives us like massive flexibility as we are developing iterating and thinking about like what sort of credentials can we use what sort of predicates can we assert over this data um and really just quite a nice developer experience so the road map moving forward the core um concept to to Really nail home is World operates on the principle of never storing any personal user data biometric or otherwise and the client side proving

needs to also adhere to these constraints so that means it either needs to transmit zero user data or attain statistical zero knowledge so a ton of work is going into adding zero knowledge to the Spartan inner prover including the the war evaluation proof and then um this also is the case for the the um Noir programs that are asserting that a given credential is a valid credential coming from a government coming from you know really anything that's a verifiable credential um we we hold ourselves to these standards today uh with the signup data uh that already um is is used in the sign up and verification process we use a h HX pomal uh signature scheme

it's all open sourced we've got a ton of data that you can take a peek at papers all this kind of stuff um and then thec check as I mentioned as well is all open source paper is published uh happy to chat about those details also so at the moment the world network is one of the most privacy preserving networks and we're super excited about using Noir and seeing you know how can we really push the bleeding edge of client side proving um as well as opening up the possibilities that you know World ID can bring uh to the world so that's it um thanks for taking the time to listen um typically the applied research team is with us so if there's any really lowlevel technical details on the proving back end I'll I'll be happy to

defer some of those questions to them and get back to you on that otherwise happy to take uh questions and thanks amazing thank you so much um if there are questions please raise your hand awesome bring the mic over if you don't mind just keeping your question on the briefer side so we can get to more thanks I'll try thank you uh really really cool work you guys are doing amazing stuff really impressive I I had a question about this biometric stuff so you use a biometric to register into a semaphor and then you get a secret key right and so if you lose the secret key you have to re-register but you could lie and then you could get two identities for free into that semaphor so how do you deal with this problem yeah not not quite so um two things to

clarify one is when you download the world app you generate a semop for keep eror so you don't actually have to come to the orb it doesn't know your private key like you are essentially just giving the public key to the semop for key PA set that you already have generated on your phone to the orb to then insert onchain uh into the Merkel tree but the second thing is um the the actual uh software and Hardware that the orb employs is doing exactly um what you're you're mentioning it's it's thwarting against or it's a you know its job is to stop that so if a user comes and tries to sign up again um it'll again take that high resolution photo capture the entropy in the eye create that uh you know the bite array that is compressed

filters Iris code encrypted and then it's sent out to the AMC check thatc check is the actual logic that's ensuring that a user is not um has not been seen before this is a unique user so um again happy to send you a ton of really cool papers I think you'd love to to read if you're interested in the topic that dive really deeply into how thatc check works so there's no like uh duplicate identities that can happen there okay next question hello um I've got a question about the collection of the the iris data between when it collects it and when it goes to chain on chain um have you any had anyone come and try and uh inter

interact with it take it um like any attacks basically yeah to be very clear the the there's no biometric data that goes anywhere near the chain the public key for the semore key uh key par set is the only thing that goes from the orb to and hits the chain right so that Iris code that's derived from the entropy in the eye encrypted goes to the ampc it's a multiparty computation check to do the UN uniqueness check um and so again I'll I'll kind of defer to I'll send you all the papers happy to go in the details there but I know we're kind of short on time y that's good thank you okay any other questions please yeah get your hand up and we still have a

minute for maybe one or two more okay thanks I was wondering if you had any plans for a Turn Style or some other recovery for any of your any of the public weight list yeah I I can't speak on I guess uh the road map in terms of recovery there's nothing that um is is different from what we've already kind of talked about and is published in our road map um but happy to chat further about some of the ideas you might have and and you know stay in touch there okay thank you so much I think we're good at time and yeah just another round of applause Daniel thank you so much really cool

work thank you