zkLogin: Onboarding the next billion users to web3 with Deepak Maram | a16z crypto research talks

Transcript

so it's my pleasure to introduce Deepak maram today Deepak is a senior research scientist at miston Labs he got his PhD from cornal Tech advised by Jules um he had a lot of prominent works that uh arol space loves like Deco for example for the centralized oracles and in this talk he going to talk about his recent uh project login that's now in deployment in sui that allows clients who don't have wallets to get access to blockchain um and have an account thank you thank you Lara uh thank you for inviting okay so today I'll talk about ZK login which is a work which has been live since about uh 9 months now that allows people to use their existing accounts to create a blockchain wallet

without having to remember another pneumonic or password a little bit about me I've broadly worked in the space of web 2 to web 3 intersection trying to bring data to web 3 uh this work is about again using web 2 credentials to uh authenticate to a blockchain so some more work on interactive authentication if if any of this speaks your interest feel free to uh chat with me later I work at M Labs most of you know here about sui so I'll sort of keep it short and sort of relevant only to the stock sui is object Centric is it it basically means that it sort of has two types of object owned and shared object uh for owned objects we can basically skip consensus and and a canonical example is payment so if I want to send 10 sui to

Heim here and uh someone else wants to send T to someone else uh there's no need to order these two transactions in the same log uh and we exploit this property to get incredible incredibly high throughput and and short latencies for owned object transactions coming back to the point of the talk you know zik login is trying to address a fundamental problem the space of blockchains which is that um it's very hard for users to get onboarded um and just an example to illustrate this point uh you know if we really count the total number of wallets across all the blockchains today comes about let's say 100 million uh but on the other hand there are billions of web two accounts that people already have um that that

they're using in their day-to-day lives uh so it becomes a natural question to ask if we can leverage these billions of accounts to easily on board onto uh onto blockchains and uh anyone who has used web 3 kind of knows this problem that I'm speaking about um and metamask here uh is is a popular uh wallet that people use um so you know if you are a new user you've never used blockchains uh uh and then you know you come to the space so this is this is something like what you'll experience if you if you install metamask today uh you know you have to first install an extension which in and itself is a challenge and it's a it's a drop off point uh and after that it asks you to

remember this big 16w phrase uh and if you can't remember it uh you know it forces you to remember it and it really makes you actually remember it before you before you actually use before you can use the thing and you know uh how many people will actually cross this bridge of installing an extension and remembering a 16-word phrase uh not many so that speaks to the significant ux hurdles people face in blockchains today finally you you get to do your transaction right and so the the key hypothesis of us here is that neonic and keys will will definitely not get us Mass adoption for if we want these Technologies to see the end of the day and we want them to be used by people um

we need to come up with new ways of making it easy for users to actually use these systems a driving factor for us in in this um you know that led us to this work is is always Imagining the web to Alternative you know there are millions of websites out there but you know people don't remember millions of passwords typically the way people manage the complexity is you know they have accounts on a few different websites and kind of reuse their accounts across those across all the different uh websites right um and so it it it it again is sort of a phenomenon uh we've already gone through in the web to World um and you know it's it's almost natural to ask why can't we do this in in in blockchains too I would I

would maybe start with a very naive solution just to kind of highlight uh what is the simplest thing that we could do here um now oo is a is a protocol that is extremely widely supported um any any provider you take uses o and you and uh oo is essentially the way um essentially the technology behind uh allowing you know users to use a single account on one website on to to log to other uh to log to um uh different website so um so a really simple way here would be to um combine o with the model of a custodial wallet right so uh imagine you are logging into an a

website uh with your Google account uh so what would you do you would just use oo and there would be an interactive protocol between you Google and the website you're logging into at the end of which that website is convinced about your Google identity um now for us to build a wallet the this website can for example custody your private key um and uh thanks to that it can it essentially it can maintain internal mapping between your Google identity and your uh private key and that will allow you to um that will kind of hide all the complexity about of Key Management from the user um and so this is sort of a simple solution that works and actually there are many

um uh there are many companies that do something like this uh or slight variations of this um now uh the motivation for us was to get us get get get around this custodial issue uh what we would really like is to remove this custodian from the picture and somehow um achieve the same user experience as we have here meaning that as a user you never exposed to private Keys um while you're able to you know sign transactions uh undo everything with with a blockchain um but you know not have the trusted custodian uh and you know this this uh there's many motivations for this you would uh the the simplest of which would be to just remove the uh remove as many trusted

points as you want in your system um just from a from a security point of view and so our idea here is to combine o with zero knowledge proofs in an interesting way where you don't have any any more custodians in the picture the the the main property we're looking for is non-custodial um and given that um uh given that we are using web 2 identity which may be considered private U depending on the context uh privacy becomes an important issue you don't want to for example let's say post your Google identity information directly on the chain that would be uh a big no no and and of course the whole point of this exercise was to build a userfriendly wallet and

and uh that and and that sort of drives the design of some of our choices we we we'll see soon it turns out that uh what we need is not exactly oo um so what ZK login bases itself on is an extension of O called open ID connect um so it's it's not um as widely used as oo 2 but it's still reasonably widely used um and the main difference between open ID connect and oo 2 is this presence of uh what is called an ID token this ID token is is basically a bunch of information that uh is signed by the provider which in this case would be let's say Google if you're using Google and given to the client this is basic information that sort of

has let's say your your name your email um just very very basic information that Google kind of is attesting to and giving to the client so that the client can um Can can be sure of who uh who is authenticating with essentially um this is this is exactly how this this ID token looks like um it it is it's sort of Base 64 encoded Json um sort of has three parts to it a header a payload and the signature um and in our experience this uh is usually RSA signature that's that's what's widely used in practice although the standard does um specify an alternative using

ecdsa uh what we've seen in practice is 99% of of the providers use RSA one more I guess key Point here uh we don't really have a lot of flexibility in choosing the payload claims so the payloads are fairly static uh even the clients the the clients don't have flexibility to ask for you know different fields uh by and large um you know some sometimes there's flexibility to add emails but that's very rare by and large these are very static uh signatures or like uh Bas very basic information about the user um now it turns out that this very basic information is enough for our purpose at least um for that which is authentication um and that's what we

will we will kind of Leverage the rest of the work and so fundamentally the idea here is fairly simple well can we just use knowledge of this JWT um as an alternative to private key so can we come up with a signature scheme that um that leverages knowledge of the JWT in the same way uh traditional signature schemes leverage a private key to sign things um so that is that is precisely what we will try to do in the rest of this work this is a real JWT by Google um so you'll see a little more information here um so there is there is the ISS which tell tells you the name of the provider AUD is is a unique identifier for each client so if a website when a website wants to implement oo it will go to Google and

register and do all the needful and then Google issues it a unique client ID and that's that's what you see here in the AUD field uh sub is a unique identifier for the user there is some variance in how providers implement the subject identifiers basically some providers use the same identifier across websites so if you log into thousand different websites for Google in particular you will get the same sub um but the aod will differ because for every for every website you have a different AUD uh but there are other providers like uh Facebook for example I think um which use a different subject identifier for each website you log into it it it becomes important as sort of a privacy uh the reason they do that is for

privacy as far as Z login is concerned it largely doesn't matter but it may matter if you of trying to build and do some extensions of it um nons is is literally the only claim here that the client can control so um the way the protocol works is the the client can specify a nons and Google will then sign over that nons um everything else here is set by the provider X is an expired time that is set set by Google is there a time stamp yeah so uh exp here is an expiry time um so it's pretty short from yeah so typically uh it is set to about an hour oh okay right so as I said sometimes you

can ask for other info but it's very limited let's say email uh and and many times we actually wanted to remove some info from there for example Facebook was always sending um the URL of your profile picture which like we don't care about and there was no way to actually remove it so it's it's it's it's weird and there's not much control over what actually comes there so let's get to sort of the main piece here uh you know we have this JWT you somehow want to now authorize a transaction with it and you know how do we do that typically you know in a private key based signature scheme you just sign with a private key well there's no uh there's no such thing here there is no key or secret the user knows and so the trick we come up with is to replace uh nons which is sort of

the only field we can control here really with the Emeral public key um so it's ephemeral in the sense that the user does not need to remember the corresponding private key key for too long it's fine if they forget it um so what we really do is put an feral public key along with an expired time into the nons uh and and and then use the corresponding Emeral private key to sign transactions and the idea is that uh when you actually submit transactions there will be two parts to it one with the feral private key sign message and and the other part proving that the corresponding Emeral public key was in the nons that's the basic idea um now in theory there are other ways to do it like if you just want to authorize a single transaction maybe you could put

the transaction hash into the nons um there there are there are potentially other ways but this is sort of the most extensible way where you can just insert uh a key pair and kind of reuse the same JWT and uh for as long as you want so what we really have here is a certificate over our key uh you can really think of this um in analogy to a CA right so as a user you're kind of going to the ca which in this case is Google um and getting a certificate over your key and later using that key to do uh to do whatever you want more like a clarification question y you have three components one is the blockchain one is this Wallet app MH and the other is the Google right yep so Google is trying to

authenticate to the wallet or wallet Google is trying to directly authenticate through the wallet app to the blockchain which problem are you looking at so we we are trying to find a way for a user to use um their Google login to authenticate to the blockchain directly to the blockchain and what is the role of wallet here it just more of a facilitator okay yeah so yeah so the wallet would maybe implement the front end interfaces that will you know say sign in with Google um but yeah that that that is pretty much it uh it uh in in a way the whole point of it is to make sure that the wallet isn't a custodian so um the wallet here would not uh should not have any information that let's say allows it to sign

arbitrary transactions and now how deep is the certificate chain um till you get to the public signing key um so the question is how deep is the certificate till we get to the signing key of the Google yes um no so the the these are very shallow so um in the sense that Google the way it works is Google posts its public keys on a uh publicly known URL um and uh it's just those keys there is no chaining really yeah it's a such just the first layer uh I only mention CA or certificate as an analogy there is no uh there is no chain of certificates really

here yeah but but when you present uh I guess the proof about this token back to the blockchain yeah together with the signature with the transaction do you verify the chain of trust yep yep um so so the question is if we verify the chain of trust when you post this on chain so the the thing we need to verify here is that so let's say Google posts their keys at google.com/ Keys um and and the way it works in practice is that they rotate it every so often so we need a way for the chain to know what the current set of keys are and um those can then serve as a basis for doing all of this so there's multiple ways to do it

but broadly you need an oracle to kind of Fetch and post uh to do this yeah so so in sui we kind of bake it in to the protocol level so the validators themselves act as oracles but fundamentally you need oracles to to get those keys No with this solution if Google wants they can stay steal most of the money if who wants Google wants um so there are some new aners to it uh but maybe in some variants of it yes um I'll come to the new aners yeah so we talked about how to authenticate transactions the the the other challenge here is um related to privacy in particular as I said um there are certain Fields here in particular the

subject identifier that may be sensitive especially for Google which uses the same identifier across all websites you don't want to reveal that publicly um and so uh the question is well how do we derive a unique identifier for the user on on a blockchain that we can sort of use to consistently uh remember them right uh the simple answer would have been just use the sub field right that's what Google assigns as the unique identifier um but that um but that is that is a bit too much from a privacy standpoint because it kind of links all your offchain Google activity with your onchain activity by default um and so the uh the solution we use is to add um

this add a sort of a secret that we call that we call a salt to the address derivation so you the identifier we used to um represent you on chain um is something like this not exactly this but anyway it sort of is a good representation of what we do actually so it's a hash of let's say the provider id which is like Google the wallet ID which is the wallet you're using uh the the user ID you your user identifier and salt the key points about this address derivation so this wallet ID here is crucial because otherwise any random app that you log to with Google can sort of steal your assets potentially steal your assets um so that that's that that's why we put the wallet ID here um provider id is just more of a again sort of a

similar reason just to uh avoid any uh collisions um and uh I guess coming to Salt the the key question is well who maintains the salt there's a couple options here and I'll talk about it a little later um but given that the main goal of this work is to make sure that users don't remember yet another secret uh the main solution we uh propose is to use uh use sort of a backup service which backs the salt up for the user um and kind of sends it to the user upon you know relevant authentication um in the context of this work this will um you know this is usually the app the wallet provider that can sort of ser uh provide the service for the users that

is sort of one main way we with we consider in terms of how uh users manage Sals maybe also worth mentioning this user ID as I said could also be the email address which enables some interesting um applications just to mention one it may be that certain users May let's say be okay with revealing their email address maybe they're a content creator who want to publicize their work or whatever it is they're reasoning um and so in that case they could for example use an email address here and have no salt and therefore then there is sort of a onetoone mapping between sort of a public onetoone mapping between their uh identity and their uh between the two web two and web three identity so I just want to make

the point here that it's not always obvious that we do even need a salt it's more of a thing we should we have as an option and kind of people can then sort of do whatever whatever they prefer to do here salt is just a random seed random string to pretty much yeah then why you store back it up why not just maybe ask the user to type in random values or so they do need to remember it across invocations right uh so it's a unique identifier that is being used should uh remember the user so it's your so your address is basically the hash of all of this okay it's not per signing per exactly it's per user okay consistent yeah okay yeah so that that's where the

challenge comes from I I mean in in theory the simplest thing here to do would be to just post the JWT directly on chain and validators just verify it um which um may work in certain very special cases uh meaning that uh if the JWT doesn't have anything sensitive and if all parties agree that there is nothing sensitive there you could in theory do that but that is usually not the case for for reasons that I just talked about meaning that there either certain claims that are sensitive or this the subject identifier can be sensitive if it is not uh if it is the same one across all websites um and so we uh and so we we kind of uh we kind of need a way to uh hide these things uh

when doing the uh when doing the user user login and that's where we bring in snarks the statement we prove here um is something like this so you want to prove that you have a JWT that is signed by a Google public key then verifies certain claims in the JWT so you know let's say say that uh the nons has the right key um and the address is derived from the right claims in this Json payload you care about certain claims so you kind of need to pass those claims out and prove certain facts about those and then do some signature verification as I said before uh Google's public key uh we we are here assuming that Oracle post that on chain and so it's a it's a public

input to this uh to this to the snark uh which which gets verified on Chain by by the real Google public key um uh and but everything else here is private input you're not revealing anything about the JWT even the signature um not header nothing nothing about it is being revealed um really really the the only two public inputs here are Google's public key the fact that it's Google um and and the Emeral key paer sorry the Emeral public key that's how it works at a at a high level so just to I guess quickly summarize what we sort of did was uh take took the GWT that is signed by you know Google Facebook whoever um added a salt to to derive um to sort of hide the unique identifiers to hide the

sensitive identifiers but derive a unique identifier for you on chain inject a key pair to a low transaction authorization and then do a zero knowledge proof over it the thing that you submit on chain has two parts to it a zero knowledge proof that proves the validity of this JWT and a signature with a with an ephemeral key so that is in a nutal how how zik login Works going a little bit into the snark details which was Gro 16 for now due to its You Know Rich ecosystem of circuits which allows us to kind of prototype and build things and and um and a Fast Pro we are constantly exploring if there are newer systems proving systems that we could use um and we're definitely open to those but at least at the time we made the choice I think R 16 was sort of a

clear winner um but the problem with grth 16 uh is that these proofs are still slow to generate on end user devices um and so we uh we came up with a hand optimized circuit that um that tries to minimize the ZK computation as much as possible even then uh in our sort of experiments it was clear that these proofs were not um it wasn't tenable to run them on user devices for example browsers in our experiments for example browsers were crashing when we try to run it not not always but once in a while um probably due to memory requirements um so uh so due to these reasons we delegate the proving to a to

an untrusted zkp service um so the key Point here is that the zkp service is untrusted so we want to delegate the proof computation but in a way that uh um the ZK service can't let's say sign arbitrary transactions um so that's that's that that's that's sort of what I mean by untrusted there you know ideally we also want to do this delegation with privacy which is a bit of an open question as to how to do that um because currently if if you look at the witness before there's a lot of somewhat sensitive things here like your JWT details or your salt um so all these all this information will be revealed to the to the prover there there is some some of a somewhat of a privacy issue there

talking about the circuit itself let's the key burden here is really the signature verification as I said everything um as I said it uses RSA uh signatures which implies that uh you know there's a bunch of Shu computation which took which takes about 75% of the constraints and RSA signature verification which takes about 15% we spent a good chunk of time trying to optimize everything other than these two uh which you know at the end of the day only took about 11% um I'll talk a little about some of the optimizations we did um but for RSA you know we kind of borrowed tricks from existing works and and for Shu we used some some circuits that were already out there um the prover itself is based on rapid

snark which uses some assembly instructions and and and uh and paralyzes Rapid snark is is is is quite fast I'll have some benchmarks soon so the key uh idea here to minimize the ZK computation is to pass the jwd as little as possible um what that means concretely is that we kind of want to avoid uh you know passing the full Json um so we we assume that the open ID provider sends valid Json and just pass the key pair key value pairs we care about and and for that we come up with some bitwit manipulation tricks to efficiently slice out small strings from a bigger string um uh I I won't go into the details of the tricks here but

basically it allows us to uh it we don't have sort of an asymptotic improvement but in terms of constants we have sort of circuits that can slice strings in in much more efficient ways to summarize we the end to end zik Logan system looks something like this um we have a user who uh uses the open ID provider uh so sort of logs into the open ID provider uh gets the JWT sends that to the app's front end so this is in the case of an ex ension wallet it's your extension um in the case of a mobile wallet it may be your mobile app um so the front end can then use the JWT to um fetch the salt from the salt

service so this is the this is the sort of thing that is managed by the app uh on behalf of the user and it can also uh fetch the zero knowledge proof from the zkp service um these two um in in uh so these two are basically the external services that that are being called and typically managed by the app um and once you get the zero knowledge proof the app front end can can sign a transaction and send it on shine so we we we ran some benchmarks to test how uh how fast zik login is as you may expect the ZK service sorry fetching the zerge proof from ZK service is the expensive operation which took about 2.78 seconds um I don't have the machine specs here

but it it it had about 16 cores in it and more details are definitely in the paper I guess a couple points here um as I said before we don't need to fetch a zero knowledge proof for every transaction you're signing so so the real latency perceived by end users um differs so you know the first time you log in to your extension or app you may experience the 3 seconds delay but subsequently um as long as the Z proof is cashed in your local local memory it will uh feel like a normal signature that you're signing um so so the Laten see that users face is kind of different and they're not really fully exposed to the to the latency incurred in Computing the zero knowledge proof what expiry do

you have for the feral key yeah so we we have very uh relaxed uh expiry I think um I think the default is 2 days uh but I think it can be extended to about 30 days yeah then after expiry I need a new exactly right um so so it's fairly generic uh sorry it's fairly uh lose uh and it really depends on the where the wallet sits and whether they have access to a secure area where they can put that proof and and you know uh not just the proof you also need to purchase the Emeral private key for whatever time it's worse on browsers because you don't have any place where you can put this feral private key in a in a secure place

and so there um it may have to be flushed out every session uh but it's much better on mobiles for example private key is the sensitive part right the proof is okay technically yes right um and I guess the transaction confirmation times it also includes signature verification so the signature verification burden is about 2 milliseconds which is again uh what about one or two orders of magnitude more um for now we haven't faced a problem there but it is it is potentially a concern because for validators you you do care about um bottlenecks and things like this the benefit here is that this is completely paralyzable if I get a million zik Logan transactions I can in theory verify them in parallel um but uh I I think for now

it it is sort of manageable with a cache to kind of make sure that you don't spend the same time whenever you see the same proof again um and and a little bit of paralyzation I think I'll spend a little time talking about various trade-offs in ZK login no at a at a protocol level we don't make any of these choices you know whether to use a pro or service whether to generate the proofs locally how the sols are managed all of these are details that are um uh that need to be figured out by the app or the wallet that is implementing Z login so if you use a service as I said before there is a little bit of a privacy leakage in that the pr sees the JWT and the salt which allows it to link the two identities the alternative which

is to generate proofs locally at least today the problem is that uh it's too time consuming but maybe on Modern devices certain modern devices it works even today um and and and there is definitely the benefit here uh there is also the point here that the proofs can be cached so even if it takes 10 to 15 seconds today um on a on a user device that may be fine if it can be cached for a long time um as far as salt is concerned um I talked about the the model where the salt is managed by the app uh this obviously means that the app now knows uh your salt and therefore can link your web two and web three identities um the alternative which is salt managed by the user is not as bad

because the salt here is not really as sensitive as the pneumonic again it kind of depends on how you perceive it uh you asked the question before of uh whether Google can sign arbitrary transactions and the answer sort of hinges on how the salt is managed you could view the salt as a second factor in which case Google can't uh sign arbitrarily because even if uh Google can you know sign arbitrary statements it can't get the salt on behalf of you and if if it can't get the salt you can't prove the statement and derive the address um so there is there there there is an option of using the salt as a literal second Factor there is the option of using the salt as not a second Factor as just for privacy and you know you manage it somewhere um so

there are there are all these variations in in how people can use uh the system and of course there is also the option of using a multisig we we have multisig support for ZK login so you could combine a ZK login Google with loog in Facebook and create a uh create an address that way um so that that that that could also be used to uh mitigate the risk associated with any single open ID provider your idea would be that the user uses the hash as an address to receive funds uh the idea for what sorry if I want to pay you you give me that this like hash uh and then I send funds to that address um in general how would this work um so there's there's some

interesting nuances even there um so one thing that could happen is you create an address for me because you know my email address let's say uh and you create a new salt you just create an address freshly of the out of yourself and just send the salt to me so from now on um if I can manage the Sal myself then I can access the account you created for me you you know you send some funds to that address and just send the salt and the address to me yeah so that's that's one way uh in which you can create is which is kind of new and uh in the sense that you can send funds to someone even before they even know they have an account can you can you repeat what the Privacy implication of the zkp server it

cannot sign arbitrary transaction it just yeah it can see the JWT and the salt so it can break the unlinkability um and if there's other sensitive details in the JWT it it'll know that but not sign transaction exactly as long as the Emeral private key is is safe can't and you mentioned you're doing um RSA signature verification inside the circuit and why don't you reveal the hash um in the clear like and do that outside yeah do the yeah I think that we we did explore that a little but uh the uh one of the requirements was to make sure that this whole thing was Private from the open ID providers perspective so um as an open ID provider even they should not be able to link so this

unlinkability that I talk about yeah so that is even with respect to the open ID provider so I'll talk a little about how we integrated with uh sui and also what it takes for any blockchain to really integrate something like this um so as I said we need an oracle to fetch the public Keys um and you know you you just need to verify Zer knowledge proof so it's fairly simple what needs to uh what a blockchain needs so onui we uh support it as a first class primitive in the in the sense that if you're a user uh we don't charge you additional fees or anything for using Z login as opposed to uh something else um and uh if you're an app there is sort of a uh depending on which app you are there there there's

there's a couple of options you know obviously wallets can serve it as an alternative but there is also the interesting option that native apps can just embed zik login directly into their into their website so if I a website and you want to avoid the wallet popup which is sort of so common and sometimes useful sometimes uh irritating um what you could do is just have a sign in with Google button there and uh create an account for the user directly on your website so there's no need for user to even have a wallet popup uh in your website so so it uh like in our experience this option was very useful for things like games where they don't where there's too many

interactions and kind of people don't want uh users don't like to see that many wallet popups I have a let's see if it works I think it is working so this is sort of how it will look if you if you use uh if you use sui wallet today it's which is one of the wallets that supports ZK login um maybe it's happening a little too quickly but uh essentially what you saw is a user logged in using their Google account they sent some money to someone else click to your Google account logged in um send some sui uh VOA so all it took was like a few seconds and and uh you know the reason there wasn't a password ask was that the

go user was already signed in there was a session the a Google session running in the browser if that's why there was no enter your password but um yeah as you can see it's all very very very smooth um and you know in our public mainnet we already support four providers Google Facebook twitch and apple uh with more in the pipeline Okay so quickly summarize the key features that ZK login has is you know we have native authentication that is cheap so users can just use Google login as if they were using uh you know sign in with private key proving your identity is is is a is a is a feature that we haven't uh haven't touched upon until now so the point here is that if you are using your email address you could in theory reveal

a part of your email address like the domain um and you could imagine creating uh a sort of an account that is controlled by anyone in an organization uh if you just derived the address from sort of the suffix of the email address right um so there there are in the fact that emails are there in the gwts allows us to explore some interesting ideas related to identities and playing with identities on blockchains um embedded you know you as I said apps or websites can just embed them directly without even needing for a wallet popup um and you know in terms of uh authentication there there there's all sorts of uh interesting uh mixes that are possible here uh combine Google

Facebook Apple to create a single account uh you combine this with neonics one more recent thing we saw was to combine webon with uh this so you kind of use put the Emeral key in a webon and so the user uh and so the the key kind of can live for a long time um so there's there's all sorts of things that can that that are possible here but I guess last but not definitely not the least the one of the key point of all of this is to make all make these accounts very very hard to lose unlike a pneumonic account which you know as many of you uh night know many people kind of lose blockchain accounts left and right because it's so hard to remember these pneumonics and maintain these pneumonics um which is which is uh complete

opposite here it's kind of very hard to lose your Google or Facebook account because there are so many recovery Parts um mature recovery Parts embedded into these accounts to finish the talk I'll talk a little about some other applications Beyond blockchains um so we've already seen a couple of these you can view ZK login as a tool that allows anyone to start signing statements without having to have a key pair and you can start signing things and and uh attribute your email address to it so for example um one one cool application I think for this would be for Content creators or let's say news Publishers or whoever it is to uh authorize to sort of sign their content with their email address or a part of their email address

depending on the privacy considerations and you know we're seeing something like this already for uh being used by Docker to sign um some uh to sign the docker images so if you are uh if you're the owner of a Docker container they they care about the problem of how do you prove that a particular Docker image was signed was sort of uh uh who is the author of a particular Docker image and how do we record that um they they use a no zkp variant in in their use case there's no need for hiding anything in the in the JWT so they kind of just use the JWT directly to sign uh to sign a Docker image and and attach that um but I think it it

probably has applications uh for for all sorts of content creators and and and uh and in sort of uh software transparency and and all the other transparency uh certificate transparency and other sort of transparency world okay that I uh I'll finish my talk I've talked about how to use uh zero knowledge proofs for authentication in particular signing in popular providers like Google Apple Facebook and so on to blockchains um thank you and I'll take any more questions if if there's any do you have any actual concrete numbers of how many people sign up with this service as opposed to kind of like traditional Services yeah so I think um I don't know if I have the comparison numbers I do know that we have about

uh I want to say 30 to 40K zik login accounts um I don't know what it is compared with you know the traditional ones um I think some of the uh I would say that some of the challenges here relate to the pr and the salt management uh as an app you kind of need to figure those pieces out uh before you're able to use ZK login and provide that to your users I think we're probably we are hopeful that this number will go up um you know we're seeing sort of services that kind of manage these uh for the users uh so for example Mist itself has has a service called enoi which does a managed prer for for for

other apps as the uh ease of development for apps app developers uh increases this this this can uh really grow um I think we do have um we do have some air drops where like let's say millions of s were dropped to ZK login accounts um but I think really what are used on chain are like let's say 40K you mentioned non-custodial at some point uh how how is that enforced or how do you even Define that also was this always a goal I feel like I've seen previous versions where that wasn't mentioned um no I think so yeah um but what so what does it actually mean maybe you could break it down I am no legal scholar and this term

really is a legal term um so we can try to put a technical our technical hats and put some meaning to the word um but I just want to say that I I uh sure this isul whether we call it noncustodial or not is is not the determinant for for what is considered non-custodial from a legal lens I mean the argument for for it being called non-custodial is is something like this yeah so there's uh the well who controls who controls the account uh assume I guess the uh you know in some variants the answer differs but let's say the default variant of it uh you

could argue that Google can sign arbitrary things and therefore control accounts but on the flip side it is I would say a lot more equivalent to you storing your private key in a Google Drive does that make Google a custodian in theory yes but in practice I would not call that a custodial wallet either because Google doesn't know that you're storing uh your private key there Google built a service which is a storage service you put your private key there I I view zik Logan in that lens in that Google has a service it is offering and we are using it to sign transactions that doesn't necessarily make Google a custodian I hope that sort

of gives the answer uh of course from a technical perspective Google can in theory act maliciously and sign if that's your definition of what a custodial wallet is so I guess like you you didn't design it any differently to make it non-custodial there's not like a guardrail or something like you like you can use it for any application on on chain I guess exactly no I mean I think I think the well uh I mean we've designed it in a way that there is no uh service that can sort of unilaterally sign transactions on for a user right that's so we've we have designed it intentionally to be non-custodial I guess that makes sense but I mean I guess you said Google doesn't know that

you're using it for this purpose but don't they don't you have like a an ID that you know when you make the request that they see and that they know it's for this service and not for some other use of their aath um like if they treat it the same as anything else but there is there is a token there that kind of maps it to that it's being used for ZK login yeah no I mean I didn't mean that it's uh invisible to Google I only meant it's not really invisible it's I would say it's like transparent like they don't have to implement anything special but they also could they could very easily map requests to this application if they wanted to right um yeah um yeah yeah no

they can uh yeah so it's it's I didn't mean that we're trying to do it in a way where everything is hidden from Google I just meant that we're using a service that they offer in a in a way way that sort of seems to make them a custodian but it's also it also feels wrong to call them a custodian because they haven't built the service for that Outsourcing uh the proving with the with the to the to like a server that sees the private witness doesn't break any of the security assumptions in the paper right so it doesn't because we the Prov service does not see the Emeral private key and and that's why it can't sign anything how much higher are the fees if you use uh this account versus uh

there's no difference temporarily at least there's no difference thank you