Bringing privacy to the World with performant client side proving dcbuilder

Transcript

all right um hello everyone so just a disclaimer in the beginning um I didn't prepare slides um I wanted to sort of keep it uh a little bit more of a conversation in two ways like just asking for some interactions with the with the people in the audience and just discussing a little bit about what we're doing at world with cryptography and in general like how do we actually um build privacy preserving systems at scale um so first I would like to ask you a show of hands uh how many of you have heard of Zer knowledge cryptography before uh how many of you feel like they understand ZK somewhat or have worked with ZK okay that's good um that's more more than I thought okay so I'll I'll I'll

introduce some of the concepts in a high level and then I'll also go into some of the more nuanced uh topics for those who are curious and those who are more technical in the audience so to start um I want to introduce sort of like what we do at world uh formerly known as worldcoin maybe you remember that name um so world is building a a a network for real humans and that what that means is that we're trying to bring accessible digital finance and digital identity to everyone in the world uh however um with the sort of crypto ethos in mind right you want to bring Sovereign digital Finance the way that ethereum envisions it and digital identity in the way that sort of privacy preserving uh uh sort of

cryptography based systems allow you to do so because if you have uh Finance in a way that is not self Sovereign you end up with what we have already which doesn't work at scale and there's a lot of problems with that as we know and with digital identity we also don't want to end up in a dystopian environment where all of our identities are public and we can get monitored by governments Etc uh and all of that um so world has these values in mind so when we're trying to build something at scale these are the constraints that we're operating within we want the user to have control over their finances but we also want to give them accessibility to everywhere in the world so you need to make all these systems that we've been building in ethereum and the L2 scalability systems and all these really sophisticated

things um you want to give them to the user and make them accessible uh a lot of the systems that we're building are like really sophisticated and the user experience is not that great and so I would say that world is sort of a tale of a product driving technological innovation where if you actually want to make it available to the user there's a lot of things that permeate into the technical design of things that some other systems that have not reached scale don't really have to think about like we've seen in early ethereum designs or like early privacy or digital identity systems there's a lot of cool protocols there's a lot of cool ideas and theories but when you actually put it to the test you see that these things actually are not runnable at the target audience that we want which is the

entire world so what we what we have currently is a set of products uh one is World app which is the sort of uh hub for all things world where the user downloads this application on Android or iOS and they're able able to interact with their world app wallet and they're also able to interact with World ID which is the identity protocol that we built um world app and all of the user wallets essentially are a safe smart account and all of those live on world chain which is an OP stackl to part of the super chain and World ID um the way it works currently is that we have a um prover a ZK prover that lives on the app of the user and this is creating semafor proofs Sema is a protocol that was

developed by the Privacy Skilling expirations group at the etherum foundation um which we really uh are appreciative of because they they helped us build build a lot of things early on and what this protocol allows you to do is that um I'm able to prove that I'm a member of a set without without revealing which member in the set I am um in the case of proof of personhood which is what world ID allows you to do it's essentially proving that I own a private key to a public key in a merry without revealing which public key I own uh and this Merkle tree only has public keys of users that have been verified by the orb which is a hardware device that we manufacture uh maybe you saw it yesterday I brought one uh yesterday downstairs um so this orb essentially

verifies the IRS code pattern which is just as like some representation of the randomness of the IRS of the person uh and this is also encrypted in MPC so none of it is public all of it is encrypted in private we've worked with Partners like tasio who are here today um and some other partners as well on getting this uh shipped to production and so essentially it's a privacy preserving way of bringing a proof of personhood sort of attestation to many many users uh how many users you might ask well World app uh currently has about 23 million downloads we crossed that number yesterday or I think maybe the day before so 23 million downloads across IOS and Android and uh about like 10 and a half million users have been verified by the orb so 10 and a half

million users have a private key that can create a zero knowledge proof they can create a zero knowledge proof of that they they're members of this unique set of humans that have been verified by the orb um so now if you look at the sort of demographics or some of the like distributions of these uh World app users well they're not all in Europe right or or in America where people have um Flagship phones or like modern phones that have like lots of ram they have lots of memory um they have a good CPU maybe sometimes even acceleration devices uh like like gpus or or some like specific specialized hardware for doing specific things you can tap into and so often times you find yourself working with uh devices mobile devices

in our case which uh are underpowered or essentially they're like old phones from like 2013 which have like two gigs of RAM one gig of RAM is consumed by the the operating system and so you only have like one gig of RAM of memory you can work with which is very little uh and you also have limited bandwidth for downloads and uploads and so so so many other con straints so when the user is downloading the world app they also cannot afford to download like a 200 megabyte application because maybe that's like half of their mobile plan for the month and so when when they're creating for example these proofs the proofs cannot be big they need to be small they need to be accessible yada yada so when you're working Within These sets of constraints uh it sort of pushes you to innovate because the existing

focus in the Zer knowledge space has mostly come from things like rollups and scalability solutions where all of this state is public hence you don't really need ZK you don't need zero knowledge this is sort of like the great misnomer of our space where we call everything ZK but sometimes we just mean snarks or Starks not ZK snarks ZK Starks uh we don't mean privacy we just mean I'm able to create a computational proof of Integrity of some computation uh happening and so when you actually need ZK you need to have the witness the private data you're making the public and private data you're making a proof of you actually need it to be at the at the client you need to be you need to have that data where the proof is happening and if that data is private you don't want to put that data in the

in a server right because if I want to proof make a proof about my identity I don't want to make I want to give my identity data to a server to give to create that proof uh of of that data right and so these are sort of like the fundamental sets of constraints that we have if you actually want to have true privacy so um what we have currently is the semaphor protocol and semaphor for those who are technical uh essentially you have a miracle tree of posidon hashes because posidon is a friendly hash function function for ZK ZK systems and it's just a grostic steam proof it's it's a circom circuit it's written in circom and we're using arcworks the arc circom back end which just compiles to um arm and that arm binary runs in the world app uh and you're able to have a

custom witness generator and just just runs a client side performance proof and even in lowend devices of the distribution of 24 million users that proof happens in less than a second because the circuit for uh for semaphor specifically is like about 20,000 Gates or 20,000 constraints uh it's not that much it's quite simple to create a proof of but if you move into the wider spectrum of identity and what we want to have in the future of identity we want to create General programmable predicates about your identity we don't want to just create a proof of personhood but you also want to create a proof of uh maybe like I'm over 18 or I want to create a proof that like maybe you've heard of web proofs right I want to create a proof that uh I've done more than 10 rides in Uber or I've done I've

bought more than $100 worth of this Adidas store um or I've done any any X things on the web or also onchain right with storage proofs I can create a proof that my balance on this wallet is greater than x or I've interacted with a more than 100 times my cauterization ratio is over whatever um so the these are sort of the whole realm of your identity that is fully um sort of available to you but right now there's no ways to actually create proofs about that in a privacy preserving way if you want to create this proof you usually are constrainted to like serers side provs that are really performant and you cannot really create the proof at the client and so what we want to do is invert this on its head and create a performant client side prover that is

able to allow you to do arbitrary statements arbitrary predicates arbitrary proofs about your identity all in your mobile device and when you're working within the constraints of a mobile device and with the user base that we have with the tailand distribution of all the users that have mobile phones that have World app installed you you have to make this performing client side Pro performant even on low-end devices so that it's accessible to the world um pan intended um so in this case what we've been doing is over the last sort of half a year we've been contacting a bunch of different partners who are interested in working on client side proving um one of them I don't know if I see jakomo in the room but uh uh for example one of them is here uh jaom fenzi who created the we

paper um for those who are technical I'm now going to go into a little bit of the more technical uh side of things um there is currently we're using gra 16 right gr 16 is great because onchain it's easy to verify onchain but the problems with go 16 are several uh one is that um you have a trusted setup meaning that the prover needs to have the trusted setup files in the phone for SEMA 4 The Trusted setup file is quite small because you only have like uh 20,000 constraints so it's two to the I forget like what the power of two to get over 20,000 constraints so that you have a trusted setup for the bigger circuit that that that is but it's quite small for a tree depth 30 so you have like a billion identities in the Merkel tree um and so the problem is that if you

actually want to create a proof of a large circuit a large attestation a large statement about your identity that number of constraints is going to grow uh a lot it's going to be in the order of like 2 million 4 million constraints like 2 to 23 2 to 24 uh constraints um and so you want to make proofs of something that is that big like from 1 million to 10 million to maybe like 20 million constraints because that with that you can already make sophisticated proofs about your identity um because often times the the credentials you work with are for example passports um I presume most of you have a passport I don't think I need to to ask that question um and in your passports most modern passports I I presume most of you

have a digital digitally enabled passport which has this cool logo in the bottom with this like oh it's a digitally enabled uh fingerprint passport and so what that passport essentially has is that all of the information that is written in the front page is actually written in the NFC chip itself and that data is hashed and signed by the issuing authority and the problem of these systems is that they were not made with zero knowledge in mind all of these existing cryptographic systems that are in these sort of hard in these passports are sort of traditional cryptographic Primitives right you have like RSA as a signature scheme and maybe like sha as a as a hash function and these are not ZK friendly and the blowup factor is quite large and hence you're going to grow the size of the circuit by a lot um so it's it's infeasible to do this

then you also need these client side proving systems so when you get to all of this if you want to create a grassic steam proof of this it's nearly impossible on a low-end device because just to have the The Trusted setup Files The Trusted setup files themselves would be like 200 megabytes and you cannot download 200 megabytes for the world app just to create a proof of that because then maybe you want to create another proof and then you have to D another 200 megabytes so it just never never scales so you really need a transparent proving system so this is something that we had in our sort of set of constraints um but then there's all other things right you need the proof proof time to be really fast uh and for some things like like hash based schemes some some of those

things are not quite friendly and so what what we ended up choosing is uh Spartan Spartan is a proving system that uh came uh I think in 2016 2017 is one of the first ones and it's a transparent proving system uh so it doesn't need a trusted setup the cool thing is that it's really performant uh however the proof size is quite big so if you want to make it succinct it takes a long time of like lots of rounds um and so this this is sort of something that we don't want but the cool thing is that you get the properties of soundness and uh succinctness uh sorry soundness and zero knowledge uh with within just like one round of of of some check I think uh and one commitment and one opening so it's it's it's like you can get zero

knowledge which we care about we want privacy at the client and we want soundness meaning that the proof is correct and I cannot like uh fake a proof um that you can get that immediately which is great and so now that we have that we can defer that later to a server to actually make it succinct and recurse it and make it make it actually small so you can verify it on chain we can do that later so what we ended up coming to like end to end or what we're working on right now with multiple different themes is uh we're using Noir which is a DSL uh built by the team the reason for Noir is that circom has outdated tooling is hard to work with and if you've ever worked with a circom code base it's mostly just jordy's JavaScript that he wrote uh in

2018 2019 and it's really hard to work with um and rust is just the better programming language all around because of memory safety and lots of other things I don't need to nerd snipe you on Rust uh now or maybe later um so essentially we're using Noir because it's a really good developer experience and it has an agnostic backend uh you can just compile that to anything uh okay I have time still so you can compile that to anything um so the cool thing is that we are creating a backend for no to Target this Spartan prover uh Spartan works with R1 Cs and there's this other version of R1 CS called gr1 CS which is just general uh R1 CS instance and you're able to compile Noir to gr1 Cs and then from there you're

able to feed it to Spartan uh and you can create a Spartan proof client side another thing that we've been working on is an efficient uh interactive Oracle proof uh so you can do a commitment to the to the witness Vector of polinomial um that we have and for that we're using where uh so where is a direct rep replacement for stir and Fry um so where essentially I'm not a cryptographer myself but I understand sort of the high level uh where is a proving or an IOP that um is uh like stir but also takes some ideas from Bas fold and it allows you to commit to multilinear uh polinomial really fast and so jakomo who is somewhere around either if not here he's somewhere around the conference is the author of that paper and he's

working with us on that and he is like we're helping him build the perform and implementation of this so we can use it ourselves and it's fully open source published on ePrint I suggest you read that paper um so with Spartan and were you're able to create a performing client side proof um that you can then uh work with later on the server side because now you already have privacy and soundness so let's recap right we have Noir Noir into gr1 CS for the representation of the PO constraints gr1 CS allows you to have custom Gates and lookups and it also allows you to have like polinomial that are not quadratic like regular R1 CS like just more complex polinomial which is good and then you can feed that into Spartan and with were as the IOP it it's sort of like the most performing C side perview

you can have and this is what we have right now the reason for Noir also is that there's a lot of performant implementations already in Noir of different protocols maybe like if you know aush or the ZK email team they built a great protocol for creating client for creating proofs of uh email data right like all of your emails are usually signed by some email uh key uh which is an RSA signature usually and you just verify this RSA signature and then you can do this like Z regx of your email data so it's another part of your identity so once you have all of that you combine it with a recursive gr 60 improver the reason for why we still using gr 16 in the end is mostly because of Legacy reasons of the evm it's still unbeatable because gr 16 has a constant

size proof time uh proof size and it's just eight uh field elements b254 field elements so in the in the evm it translates to eight words like Q 56 words and you can also compress that to four with a cool block post that Remco on our team wrote so you can compress it to just four uh evm WS which for when it comes to like cold data consumption if you want to submit hundreds of thousands or millions of these proofs like we do on world chain you really need something that is small and so so this is why we're using still gross because for legacy reasons where the evm has a lot of uh constraints on verification it only supports bm24 pre compiles and so that's why we we're doing that and also the constant call data size because World chain is already consuming a lot

of blob data on on ethereum and so you really want to minimize your footprint of how much data you consume on chain so essentially you take this part proof you recurse it with the general grth 16 circuit and meaning you can uh the reason why it's General is because you can recurse multiple spart time proofs into one gr 16 proof and the GR 16 improver will just have the maximum amount of the powers of tow for creating the maximum circuit size for the aggregation of all these part and imprs and so once you have this you have this like really efficient endtoend system where you're able to go from a Noir circuit that allows you to make proofs about your identity it might be semaphore it might be ZK email web proofs storage proofs this nfci ID proof of the passport data that you have all

of that client side and from the benchmarks that we have you're able to create uh these proofs in sub minute in lowend devices right and sub minute is already sort of like a a user experience that is acceptable by the person that that lives somewhere where they they're not able to afford phones right it's still a trade-off we'd like to make it faster but it's just impossible with current technology so these are sort of the constraints and now back to the non-technical side of things um if you worked with real world constraints like we do where we're operating in all five continents in the world where there's users of All Sorts um uh from all kinds and if you want to actually support them and give them access to finance and ID

you need to make the systems and Technologies you built actually usable by them on a technical level but also on a user experience level um so these are sort of why I believe that working for the end user always ends up making the best technology because you're always factoring the real world constraints and then you have the massive distribution and actual change that you can affect on the real world by actually allowing them to use that at scale uh and then now you have fully privacy preserving digital identity for all sorts of things that you can make proofs about um in the hands of millions of people which is what we've been here for all about in all these years in ethereum and other places as well so this is what we've

been building and if you want to contact me feel free to just grab me at the end or uh go to my telegram or Twitter it's DC build 3r instead of DC Builder is just substitute that with the three um I'm happy to talk to you anytime and thank you for listening and I hope you enjoyed it thank you [Music]