Episode 302 - ZK for web2 interop with zkLogin & ZK Email

Transcript

Welcome to Zero Knowledge. I'm your host, Anna Rose. In this podcast, we will be exploring the latest in zero knowledge research and the decentralized web, as well as new paradigms that promise to change the way we interact and transact online. In this week's episode, Kobi and I explore how ZK can be used to bridge Web2 identities and logins with Web3 accounts. And we look at this through the lens of two projects that emerged independently but share a lot of the same characteristics.

Our guests are Kostas from Mysten Labs to discuss the project ZK login and Ayush from the project ZK email. We discuss why they want to start using Web2 identities to help onboard folks into Web3, the problem that they're trying to solve, the solution that they each came up with independently, how this was built out, and the use cases that such technology would enable. This is a bit of an unusual episode in that we have two guests from two projects that are doing something quite similar. And yet, I think through the interview, we are able to tease out there are significant differences, especially in the community they are tied to.

ZK login is built by the Mysten team, which is also behind the Sui network, and they have strong connections to existing Web2 companies. ZK email, on the other hand, is coming out of the Zexe Park group and is deeply tied to Ethereum. This is one of the more interesting use cases emerging in ZK right now, and I'm really glad we had these two guests to explore how it can be used. Before we start, though, I just want to let you know that we're going to be running another ZK hack online event starting in January. For this event, we are going to be doing four weeks of workshops. Every week we'll be meeting to learn about a new tool. We'll also be running a puzzle hacking competition between the workshops, so there will be three in total over four weeks. And these are a

bit like ZK CTFs. Find the bug, exploit it first, win the prize. This is our fourth time doing the online event. It's online, completely free, and it gives you a chance to connect with members of the ZK hack community from all over the world over an extended period of time. So, I hope to see you there. Find out about the event on our website, zkhack.dev, and join the Discord for updates about the schedule. I've added the link in the show notes. Now, Tanya will share a little bit about this week's sponsor. Launching soon, Namada is a proof-of-stake L1 blockchain focused on multi-chain asset-agnostic privacy via a unified set. Namada is natively interoperable with fast-finality chains

via IBC and with Ethereum using a trust-minimized bridge. Any compatible assets from these ecosystems, whether fungible or non-fungible, can join Namada's unified shielded set, effectively erasing the fragmentation of privacy sets that has limited multi-chain privacy guarantees in the past. By remaining within the shielded set, users can utilize shielded actions to engage privately with applications on various chains, including Ethereum, Osmosis, and Celestia, that are not natively private. Namada's unique incentivization is embodied in its shielded set rewards. These rewards function as a bootstrapping tool, rewarding multi-chain users who enhance the overall privacy of Namada participants. Follow Namada on Twitter @namada for more information and join the community on Discord,

discord.gg/namada. And now, here's our episode. Today, we're here with Kostas from Mysten Labs, the company behind the Sui network, and Ayush Gupta from the ZK email project. Welcome to the show. Good to see you on again. Yeah, glad to be invited. Our co-host today is Kobi. Hey, Kobi. Hello. So, today we're going to be talking about two different solutions, both that take Web2 identities and onboard these into a Web3 context. And this episode came about, Kostas, we had originally reached out to you because there was a ZK Summit talk that you'd given that was really well received. And then you actually encouraged us to

invite Ayush because his solution is also kind of in the same category. Kostas, you've already been on the show. I will actually link to that where you gave a great backstory on the companies you used to work at and the type of cryptography, what got you interested. But for our listeners, do you want to just quickly introduce yourself? Yeah, very quickly. So, my background is on identity-based encryption. Actually, I finished in 2010, '09 and '10 where like Bitcoin has just started. And I had I was lucky actually working with one of the first developers of Satoshi back in 2016, '17, to to '18, Mike Hearn.

And we worked together on atomic swaps and many other privacy-preserving stuff. Then I moved to Facebook and from like the last two years, I'm in Mysten Labs working for Sui. Nice. When you last came on, we actually talked about What was it? For solvency, for proving solvency. Exactly, exactly. And by the way, there is an interesting stuff here. Some governments are now interested on this for proving unemployment rates. Like imagine if there is an unemployment rate announced, right? You want to prove I'm unemployed. Can I check that I'm included in these numbers, right? Wow.

Yeah, it's the same it's the same logic actually, using privacy for Yeah, and inclusion proofs. Oh, very cool. But yeah, today we're going to be talking about something very different. We're going to be talking about this new project. I'm really curious to understand also kind of like how research happens with you guys. Like what motivates it? But Ayush, let's first hear from you. It's the first time on the show. Tell us a little bit about yourself. What got you interested in this space? Yeah, so I used to be with Gubsheep at MIT. And as you know, he's working on Zexe Park.

And back when he was running these like Eth University programs where people would kind of onboard into crypto, I was working with a friend, Nick. This was back in I think January 2021 on like uh This is like my first exposure to ZK and we built like a small ZK message board. Um and then it kind of just spiraled from there. I started building more and more projects. We built like a really early like ZK Battleship. We built like a really early um Like we tried to do ZK airdrops, but they didn't work. And so because ECDSA doesn't have nullifiers. And so then Kobi and I worked together on these Bloom signature editions that allows you to get nullifiers and then you can do fun things like anonymous proof of solvency on Ethereum and things like that. And then searching for a new

project. And so then um me and one of my friends, Sampreeti Panda, may or may not have heard of him. He and I were digging through all of the Web2 identity primitives. And we were trying to find which ones had signatures. Our thesis was basically like if there's no signatures, there's no point in doing ZK because you're not actually verifying anything meaningful. And so we looked through and we found a bunch of primitives that had signatures. We found uh emails JWTs. And there's like a couple others. And we were like, okay, what is like the most used one here? It's It's It looks like it's emails. And so we kind of we built like the initial proof of concept in like a crazy week. And then uh that like hardly worked. It didn't

worked on like a couple of emails and failed on almost everything else. And then, you know, over the next like I think it's been like about a year or so till now, we like refined it, made like public SDKs, did a one and a half audits. And now we're like, you know, it's kind of really ready for public consumption. And we've had like a lot of cool folks joining and helping out. And it's it's been quite the ride. Cool. Ayush, the project you're talking about is ZK email. That's the name of the project at this point. Kostas, your project is called ZK login. Do you want to share a little backstory on, you know, where that those ideas come from?

Exactly. By the way, I won't debate with Ayush, but because we were also searching email against like SSO's, we decided, oh, most people are familiar with SSO's, not email eventually. Especially for the copy-paste part, right? You need to copy-paste headers and all of this stuff. So, for us uh Please debate. Please debate. I will try. I will try to keep it okay. Name fight. Uh there was a reason I invited you here, Ayush, but as a friend, mostly as a friend. Well, they used to debate. I I think I think it can be constructive. I don't think it needs to be an argument. Exactly. Um so, the whole idea for us is it was one of the reasons actually uh that I personally joined Facebook back in uh 20 uh '16, '17. We wanted to help like imagine Facebook has Instagram

users, there are like Messenger users, Facebook. We wanted to use some privacy-preserving methods for people to have accounts on the blockchain easily. Like imagine the average person on Instagram, they might not be like so knowledgeable on technology. And it started from there, but we never had a solution back then. When uh we moved to Mysten Labs, this is literally 1 and 1/2 year ago, at least for this particular research. We were trying to figure out, okay, how can we replace mnemonics, right? Because typically people have to remember the 12 words and all of this stuff. And after doing some experiments, we realized, okay, most folks are actually familiar with this login with Facebook, login with Google, login with Apple. And then we said, okay, can we hide the password completely? There is no password at all. However, yes, you want

to use your identity, but at the same time, you only want to reveal whatever you like every single time. So, we need the privacy. We need zero knowledge proofs. And then eventually we ended up into exploring all of the providers for SSO, single sign-on. And we ended up, oh, they have some properties where we can SNARK them, literally put them into um like a a circuit. We add a few things to make it like more compatible with the blockchains. It's not like just get the cookie from Google and eventually you I mean, you solve all of your problems. You need to do some extra work. And we managed to do it. And eventually now can someone can just login with Google and without any third party in the background, they can have an account on chain. And because of this we called it

ZK login. Mhm. So that's the whole idea here. Interesting. There's two words or acronyms that you've both mentioned that we need to like define. JWT and SSO. You just said the SSO. Why don't we actually redefine that again? I know you said you said what it was, but I didn't quite catch it. Yes, so SSO is literally single sign-on. We press one button and we're logging into something, right? This is the like oh, do you want to log in with your Google account? Yeah, the button that you see from Google, login with Google. Yeah, yeah, yeah. Got it.

And the JWT, imagine it that when you press that button, Google sends you a kind of cookie. And this cookie is like JSON web token. Mhm. JWT. That is what it is. Like imagine JWT as as a as a cookie. Yeah. And SSO as the button that you're connecting to Google to get the cookie. So JWT stands for JSON web token. Yes. Okay. Got it. I feel like these words are going to be used a fair bit in this conversation. So I think it's good to get them defined.

Yes, exactly. So because it's also easy and sometimes you know, these are like human readable, you can also have like easier ways to create circuits around them. So Kostas, actually one thing that you mentioned before like where you started from is you started from identity-based encryption. Like that was your original path. Traditionally, this has also been an approach of removing passwords or more correctly removing key material from users so they don't have to maintain it. But what you're saying is that with all of these new services that has JWT or with ZK email that will I guess hear later on how they have key material inside,

we basically don't need this trade-off of identity-based encryption. Exactly. So one of the problems of identity-based encryption this is practicality, right? And I want I use actually to like make these comments here. There are no identity providers that are very easy for the users to actually use them now today with the existing tooling. So if there was an identity-based encryption provider, it would be by far easier, but we have to work with what we have like as a community. And the only things we have at the moment like people are familiar with literally email for ZK email.

Yeah. And this button login with Google, there's no other uh provider for identity. Anything else requires some custom tools that people are not familiar with. Right. Yeah. Right? So in theory, we're looking uh I can go to the backstory like there is a very interesting story how we ended up here. But the whole idea is we were looking for providers about like with ID and some key material that is embedded into this IDs um for which we didn't want these providers to change their tools. Because we couldn't go easily even if I'm coming from Facebook originally, we couldn't go to Facebook hey, go change all of your flows and now I want you to provide the zero-knowledge proof-friendly algorithm for this.

I get what you have, you don't need to do anything and I make it work with zero-knowledge proofs. This is I guess pretty much what ZK email did as well, right? Email providers don't need to change anything. And we did the same thing with this button. ID providers for login with Google, Facebook, Apple don't need to do anything now. Very friendly integration. Yeah. I think we had a fairly similar story there in the sense that so just looking for a solution which doesn't require anyone else to change anything. I think the second that you introduce like these bespoke uh systems, it gets really confusing. It the UI becomes really hard for people to to grok and also you often introduce these trust assumptions that are not super relevant necessarily to the

original source of the data. And so in many of these cases because there's no, you know, original signature, you rely on some MPC network or some trusted enclave or even some people just have centralized attestors entirely. And this kind of at least to me seems to undercut the premise of decentralization. Mhm. Exactly. And in my opinion, there is another like good outcome for like both works here. You don't need the folks who are using them in their own dapps or the wallets to also have cryptographic knowledge necessarily, right? Because I guess I usually provide all of the SDK now and for them it's literally just following the documentation. You don't need to have a cryptographer necessarily. And it's the same thing with us, right?

Because one is you don't need the provider to change anything and the other is you don't want the wallet to go and find copy to hire copy in order to have some business around these credentials right? I want to just expand a little bit on the problem that you're trying to solve. It is this idea of like is it for web3 products or projects that you would need this or is it for anything? Like you talk about the the Google button, but usually those are on web2 applications like web apps or whatever. Like what exactly is the problem you're trying to solve?

Okay. So for us, one of the major issues that we realized is people not necessarily pigeons, but other folks who want to join the space, they don't even know what it is to install a wallet. Okay. What does it mean? I'm installing a wallet, right? I have to go to my Chrome or my app, download something, install it and what is this thing? Mhm. you could hide it completely and literally by pressing the button of Google, you have a blockchain account. Mhm. This changed the onboarding like experience completely, right? You don't need to even know that there is something running in the background, zero-knowledge proofs and all of these like creating an ephemeral public key, salts and all of this stuff. This is hidden from the user. So in practice, you can have like a web2 website today

and they can have an invisible wallet that people don't even know they're installing something. They just think they do the same thing as they did with the other apps like your e-banking and everything, but automatically you have a blockchain account as well. And this is a non-custodial account because you can only login to Google and if Google even tries to impersonate you, we have the salt that the wallet now has the other part and it's like a 2FA for us. In this case, is the wallet being used in a web3 context? Are you trying to get people to be able to build into web3 or are you just like we're just going to create this wallet on the side, but actually still interface with web2 places? Like this is the thing I'm not quite clear on. We didn't want

people to even understand they are in the in the web3 world. Literally the same experience as you had with web2. Nothing changes. Somehow you have automatically an account in the background. So if you see all of the partners that are coming now and implement on top of ZK login, they're web2 companies. They want to go to web3 in the sense that they want to help their users to have an account, but they don't want their users to either install stuff or actually remember passwords. Right? So imagine a new person can come here and have login with I don't know, email or login with like Google in our case and automatically have an account, right?

Mhm. Is it just basically you've connected now the Google email string or whatever to a wallet? Like if they then go to another application, do they always create like a new wallet in the background or are they actually tapping into the same wallet that's attached now to their email? Actually, it supports both. Uh you might have an invisible wallet that is installed on all of the applications. So the wallet is literally shared between the different game studios, the different apps you're using in the web2 world. Or you can even say, okay, my address in the blockchain I can explain actually what is a ZK login address. A ZK login address includes the provider who is signing like Google, the wallet that you're using, it might

be shared between applications, your user ID in Google and then eventually some salt value. If you imagine these four entities can be the same across applications or someone might decide, okay, because we have a salt, I'm using different salts and I have multiple accounts as we do BIP 32 on the blockchain. Or what I can do is I can use different wallet IDs in particular situations. So in practice, I don't want these accounts to be linked. I play League of Legends and then I play another game and I don't want my activity to be linked. If I want to be linked, yes, sometimes you want to be linked.

So we it someone can like parameterize it. We are offering the primitive as a primitive and then wallet providers or dapp developers can decide what to do. Did you just call it salt? What was the word you used? salt, pepper and salt. Oh, I I didn't understand what what you were like the different salts that you were I didn't quite Yes, exactly. What why is the salt there, right? You don't want Is this like a general term that's used or is this Yes. Okay, okay. I don't actually I just don't know this. Sorry, sorry. Uh anything Okay, there is pepper and there is salt and there are some other like private stuff that we're putting on hiding things in cryptography. Yeah. Okay, okay. I'm

giving you a very simple example, right? Very simple example. Imagine that your identity in in the blockchain was the hash of your email. Someone can just go and brute force it. Yeah. Right? I know all of the emails in the world and I'm brute forcing until I find Anna's email into the blockchain or I can like pin your address with something. But if we add some randomness, imagine salt is the randomness that we're adding there. And someone doesn't know your salt, they don't know what to brute force. Right? So you are linking your identity, however, you are hiding your identity at the same time with privacy.

And then what zero-knowledge proof actually offers here is it offers the framework to hide all of this stuff from the like observers. This is this is why it's required. Because in the past, there were cookie providers that you just put the cookie on chain. But if I put my cookie on chain, I will see your email, right? Mhm. And then you might not want to you to see your your cookie like to to make this available for everyone. So let's snark it. Let's create a circuit, snark it and then there are some other things that we did, so you can also sign transactions on top of it. Snarking the JWT is not enough. You have to do extra stuff.

Okay. Kostas, you mentioned that I guess the ZK login address, that's how you called it? Yes. Um so the ZK login address is derived from like say the user the user ID, the application, and the provider, but also the salt. So does it mean that the user has to maintain a salt kind of like a private key in their own application? Their wallet. Okay. Their wallets can actually do it, and by by the way, the wallet however cannot impersonate the user to get a cookie for the user. So it's literally a 2FA scheme somehow hidden like uh uh you you don't understand that it is, but in practice it is.

So your wallet every single time is providing you the salt. And then if you they provide you the salt, you are getting the cookie as well, and then you can sign in to your uh to your application. Okay, so you do like still have to maintain something on your side. But not necessarily you now. Imagine if this was a private key, you couldn't you couldn't share it with your wallet, right? Because a private key would have so much power. But now the salt is literally an extra randomness. Whoever has the salt cannot do anything on your account. Right. Okay, because they still need the rest of the JWT I guess. Yes, exactly.

Okay, makes sense. Ayush, I want to ask you how does yours compare? How does ZK email compare to this? Is it similar? Is it like up to now in the description, would you say it sort of follows the same ideas? Does it actually offer the same things? Yeah, so I'll there's kind of a couple aspects here. One note is that ZK email the primitive is used not just for login, but for general proofs about anonymity, and so that's very powerful because you can build things that have nothing to do with web3, or you can build arbitrary social attestations, um call them like programmable private data, and that's like a completely different separate thing that I can talk about later. In terms of the ZK email as a wallet, so this is kind of our our email wallet idea that Sora had in a paper maybe

about a year ago or so, and we've been building. Um and yeah, that that in in in a sense we have a very similar model for that in which uh you send an email, and your salt we use the exact same thing to hide your email address from going on chain. You also have a salt which can be maintained yourself or maintained by a relayer, um decentralized network of relayers, and again this the same thing, the salt only leaks your anonymity, it doesn't give power to actually control your account. And subsequently, you can trigger transactions by sending emails. And so for instance, I can send an email to someone that has a specific subject, because that subject is directly parsed on chain, you can then get on chain transactions just by a sent email.

And so in that sense, it is sort of similar, um except that instead of managing a wallet private key uh made from the salt, instead we just directly control the transaction by the ZK proof, which might be the same in Kostas's case as well. I'm not It's very similar. We are also embedding a public key there, so you can sign multiple transactions with one login. Mhm. Right, there there are some difference. We are not putting the transaction hash into the email, because there is no email in us, but what you do is you are like putting there a delegation public key, and with this delegation public key, you can sign multiple transactions just by signing once with a login with Google.

There are few differences. So I suppose the analog in our case would be like proof aggregation or something, is that you could just send multiple proofs at once, and you could get that working on chain. Um and then I guess the final thing is uh so there was a team of students that we had mentored. So this team built also the ZK JWT primitive, but they they didn't attach it to a wallet. The idea was uh this was like Emma, Sayon, and Kaylee, and what they did is they created the ZK JWT proof of directly uh from we actually used the OpenAI one because like a million people had signed up just signed up for ChatGPT, and so we have a massive anonymity set. Um and then you would use basically that JWT in order to authenticate yourself into a private message board. And so this

private message board and the ZK proof for that only expose like your email address, and so you could then post on behalf of someone like a Berkeley.edu and not reveal who you are. And so um this was an entirely like no web3 involved no no blockchain, and it still is like a really compelling application. There's a ton of really compelling I think web2 applications that have nothing to do with wallets that are still super compelling, although the wallet use case is a really nice onboarding tool. That's interesting. One thing you haven't mentioned here like sort of I I I hear the this not replaces, but it connects to the like web2 login, the SSO, but what about comparing it to what is currently used in web3, which is like having a wallet browser potentially, and like

MetaMask? Is it sort of trying to replace MetaMask in any way, or like is it sort of operating in spaces that you would just never have your own crypto wallet? And actually, as a second to this, can you actually then like keep that wallet that you've connected to and do stuff with it as well? Like do you ever get the private key for that? Yeah, I I can go first on this if uh because I have like a strong opinion here. I don't believe like all of the users will use ZK login or all of the users will use MetaMask. They're it's for different like types of like profiles, right? Some people who want like convenience very quickly like you you open your phone and you're making a transfer, not remember any PINs, any passwords.

Like login with Google or maybe with email would be like ideal because you I mean you can do it on the go. There is also like some work that we're doing. You can also have like multi-sig on top of both. Someone can have a password plus a ZK login. So you can decide what do you want, right? And maybe you can have even like uh extra rules on top of this. Like you might say for 1,000 uh like dollars or more, I need to use a password. Or for less than $1,000, I'm using ZK login, it's it's fine for me. Right? And then there is also the as I said before, the the convenience of not requiring to see that there is a wallet.

Like this invisible wallet as we call it. Literally, I mean people are used to logging with Google, but imagine if logging with Google is a wallet, you don't even know it's a wallet. Mhm. So uh in my opinion, if you I mean I don't know, if there are some whales and they're doing trading, probably they will go the mnemonic way like MetaMask. And if there are like people who like interact regularly with a blockchain, playing games and all of this stuff, they can use ZK login. Mhm. I I guess there's one more benefit that maybe Ayush touched on briefly, which is that since you're using one of these existing providers like Google or something that is already huge.

And also I guess that's related to the work that Ayush and I did on the and on Plume signatures, you can reuse this big set of identities that exist and be be lost with within that set, right? Like you you don't really expose who's doing what or who's doing transactions, because you're just like a Google user, right? Yeah, I I definitely agree. I think you know, in terms of the wallet question, I think I expect these kinds of wallets to actually be a gateway to self-custody. Um I think ultimately trusting a web2 provider is not ideal if you're managing like millions of dollars for instance. I

don't think you should trust that. And so I actually expect this to be a way that either microtransactions or assets that aren't even worth things like collectibles for instance can happen on these kinds of substrates. And then as people start understanding more and more, they can graduate to self-custody wallets, um which ultimately are the most secure version. And so I actually expect this to be an intermediate onboarding flow. And in terms of Kobe's point on the anonymity, I agree. I think there's a lot of power you can get from for instance instead of even using the entire email address or the entire login as your token, you can use just a subset of it. You can say either the domain, or you can prove arbitrary parts of that, say like something from your email, and that becomes part of your identity. And so I

think being able to splinter your identity into not just like this is me and I have my email, but hey, there's a whole spectrum of things between you don't know anything about me and you know my entire email address that I think is quite interesting. Mhm. I think we're starting to get a pretty good sense for the problem space, the actual like construction of of these systems. Um I do have one question though for you, Kostas, which is I know you as the you know, what one of the applied cryptographers engineers at at Sui. Is this coming out of Sui? Yes.

Like I'm just curious if if like and and why? Like what is the connection then to the rest of your work? Because this sounds like almost like a standalone project. Yeah, the the reality is it's a primitive in Sui. We literally have precompiles now because you know, on Ethereum you have the account abstraction. And in Sui and in some other blockchains, the the way like objects work and how authentication works can actually go natively. So every wallet can implement it without relying necessarily on this particular company that offers a threshold wallet, and you have a dependency there. So as foundation, like the foundation was looking for solutions that it's open for everyone to implement. You don't need to rely on a particular vendor wallet that

you're actually tied with them forever. Right? If they go out of business, you are losing the threshold, and then what do you do, and so on. Um but there was another very interesting stuff. I know we didn't cover it before, for which it's not only onboarding, and I know that like ZK email can be used for this in the future. The zero knowledge can be used for many other things. And one of them is discoverability. It's KYC, right? We're talking about identities. If I know your email now, what I can do is I can email you a salt.

I know your email and your ID, and I can create an address for you where you can go and claim the money before you even have an account on Sui. Imagine how this changes the full process, right? You have like a big like commercial website like at the size of eBay and all of these big companies and they want to airdrop to everyone that they know something or you have a friend where they don't know even what Sui is or what Ethereum is or whatever it is. You just send them a link with a salt and only them with a with a login with Google can actually claim the money. Mhm. So I literally sent money to my parents. I don't know if you've seen my latest Twitter like Twitter post.

I I yeah. I sent money to my wife's grandma. I'm not kidding. She has a Gmail. She's using it I don't know twice per year. But anyway, she received the link login with your Gmail and you now got 100 Sui. Right? And this is possible now. Imagine how can you convince people that are older actually to remember passwords? Mhm. It's impossible, right? And then I believe it all started because we were all not biased, but we knew the problem on what's happening when you're targeting a mass if you are working for a funk like Facebook.

You know people are not going to remember passwords or they're going to lose their passwords. Yes, yes. But they're more sensitive or they use it often with their email accounts or their Facebook accounts. It happens there as well, but at least they're used to it, right? So personally as an engineer it was and a cryptographer it was a very interesting problem to solve. And what do we try to do is to kill two birds with one stone in practice. You solve onboarding, but you also solve discoverability now and claimability. And this is huge, right? Yeah, yeah. It's so interesting that I see I had not put it together with the account abstraction concept, but actually this this to me is like a connection point.

This idea that it's on that level. And there is something that is coming actually. It's coming out in the next few months. I can I can mention it even today. Uh We don't necessarily need to put a public key inside the cookie. What can we put Kobe? Can you imagine of like something interesting that you can do? Mhm. You got me there. Okay, imagine if I put there a contract ID. So in practice you have account abstraction off chain. So I can decide now that I'm using this smart contract to authenticate. And this is only possible for the next 1 hour.

And then I can say oh from now on I created a new smart contract. It's a new account abstraction method and I put the object ID into the into the cookie and now the cookie says oh you can use this smart contract now to login. And it changes completely the story around account abstraction because now you can have dynamic account abstraction as I call it. Oh, wow. Mhm. You understand what I mean, right? Typically you want to put in the cookie some delegator. Mhm. You can put a transaction. So you sign the cookie is literally signing the full transaction.

You can put a public key. So a public key can sign multiple transactions, but you can put a logic there. And this logic is delegated into something else that signs transactions. Yeah, yeah, yeah. Yeah. So it opens the space of account abstraction completely and actually you can do it on chain off chain dynamically now. Mhm. That that's really cool. So you can get a lot of the power of account abstraction, but maybe maybe it would be good to to see what can you usually do with account abstraction that would be useful in this context? Yes, okay. So what is account abstraction, right? I will try to at least provide a few features.

One of them is you can define your own logic to sign transactions. Mhm. Literally you create a smart contract. This smart contract now has the logic. It's not just a signature with a public key. You can create like like a Daily limits for example. Limits like some restrictions or whatever you want. There is another thing on account abstraction which has to do with who pays for the gas. Mhm. And this is like the sponsor of the transaction. And because even in Sui and I guess on Ethereum now with some ERCs you have these options.

What you can do is we said okay, you want to login with Google, but the first time you don't even have funds, right? How can you send something if you don't have like to pay for gas? You received an NFT. How do you send this NFT to Kobe if you don't have any Sui? However, if you support sponsors, you can just from someone hey, can you sponsor my transaction, pay for my gas and I will transfer this NFT to to Kobe. And then imagine sponsoring and custom like account logic are under the umbrella of account abstraction. You are literally abstracting all of the who is paying, with what logic you are paying.

Um you can do like multi-sig like processes internally multi multiple users like DAOs and many other things that can happen now under this umbrella of AA account abstraction. Mhm. So you have to combine these things like the easy onboarding, the easy claimability with sponsoring as well if you want to have success on the average person to go on chain and be able to to transact. Because now if I send you something, let's assume I'm sending you like a bunch of NFTs, you don't know what to do with them Anna if you don't receive also some Sui, some Ethereum, something, right? Yeah, yeah, yeah.

you knew I can watch a video and someone can sponsor my transaction now. Now the story completely changes. Yeah, yeah. Can can I receive something in this method before I I did the ZK login process? Yes, go to zksend.com. You can do it now. This is how I sent money to my wife's grandma. Okay. zksend.com, okay. zksend.com, yeah. I sent her something and then she was able to login with Google and send it to someone else. She didn't have an account before. Yeah, how how do you derive the address in that in that situation because you don't have all the send you the salt, right? Oh, I see.

I have to say salt is still very confusing to me. Are you maybe you can help me. What is this salt stuff? How would you define it? Like and why are you sending it around? This is what I don't get at all. Yeah, so in our case we also have this salt and I I should say that a better name for a salt as you alluded to might be like anonymity key or something like that or might be like privacy value or like hiding value or something like that. There's none of these names are really perfect, but they the idea that this value is just something that keeps your anonymity on chain. Mhm. It's something that separates you know your email address is known to yourself and it's a thing that breaks the link

between that and the on chain value because no one can calculate the hash of this random salt. Um in our case the way that we ensure that the recipient has we actually have a very similar system and the way that we ensure the recipient has a salt is that we email them that salt. We make sure it's part of a you know a message ID to an email that goes to them and so we can guarantee in fact that they have the salt, but I'm curious Costas in your case there isn't always a bidirectional communication link like this that you can verify especially with just the JWTs. How do you ensure the recipient has access to the salt? We're sending it as well. You create the link and you send the link through I don't know WhatsApp or something else. Sweet.

Okay, that makes a ton of sense. Yep. It's the same thing, right? I mean you're using email for all of your flows. In our case we can decide use email, use like messenger, whatever you want. But you're sending this is is it just like Yeah, imagine it has a key. Yes, random number. And and you as a user if you receive this salt, you don't have to save it. Like this is not it's it do you? Do you have to use it for anything? It depends on what you want to do. In our case where where I mean in the example that I gave you before, we want to send money for one time to someone and this like addresses that are created we want them to be one time.

You go there, you get the funds from this like one time address that uses the salt that I sent you and now you can send the money to your official address that you have a salt that you remember it or your wallet remembers it. Or as I you said you might have a decentralized network that remembers a salt for you. Mhm. So yeah, for one time payments maybe you don't need it, right? It's a one time use. You get the $100 and then you can forget it. When you're talking about the way that you guys do the JWT flows, I was wondering it's honestly the exact same thing that we offer with the email wallet specifically is that you can basically exactly send to any email address. It doesn't even need to be login with Google or login with Outlook.

Any email address that has a mail server key which is basically every email address can receive this these funds and exactly you can mass onboard you know thousands of people on chain. And we have the exact same concept of unclaimed funds. As we're talking about this, I'm wondering if we should like co-author an ERC or something so that it becomes a standard and not like you know hundreds of people need to to rethink the same system from scratch. But exactly so we have this concept of unclaimed funds in which precisely for all the people that you send to, you can define their salt for them, you can pay their gas for them, you can do whatever you'd like to them.

You can pay their account initialization costs, everything and as a result those people you can also guarantee that they receive that salt and they just get an invitation email saying hey, you've been invited to join email wallet. You can reply to confirm or you can continue to send this money on or you can off ramp it to an Ethereum account or you can do ZK P2P or something, send the funds to Venmo. There's a lot of kind of options that you can do. Mhm. Do either of you connect actually with any of the APIs of those actual services? Like or are you just using this kind of like the fact that you're sending the salt and there's something that's now with that user? For us we don't interface with any of that at all.

Actually we only use mail tool links to make some of the mailing process slightly easier, but ultimately we're actually just bootstrapping off of the email infrastructure directly. So I guess you could say like SMTP and IMAP which are like these kind of email protocols. You could kind of say that in a sense we we interface with those, but those are again just if you're running a relay. And so user never has to think about this or and we never hit any of the the APIs that exist. Although I would imagine actually in Costas' case it's different. Yeah, for us it's production ready, right? People are using it now. For real money.

So it's happening. Yeah, yeah, we're getting audited this week as well. So I'm I'm excited. We're going to have a bunch of these going in there. Good luck with it. We also had two two or three like on top of ZK login. It's quite an experience as well. We found also a bug on Costas' algorithm at the very beginning. Not a bug. Not not a bug. It was unused. Okay, it was unused. Okay, cool. So yeah we But it was published, so my bad. Yes. Anyway, this this audit helped and actually what I realized is when you go and actually do something like uh on hands, not just reading the papers, reading the documentation, then it's the best time to identify bugs.

Right? Yeah. And this one was not related to a circuit, by the way. It was related to the phases of ceremonies. How do you do growth 16 ceremonies? Yes. But I want to go back to what Ayush just said though. That this difference. Like so you were saying that it's production ready, but Costas, is is your system different? Someone can use Twitter and Google now and we're working on cacao and some other Slack, Apple, Facebook and all of them, right? People are using it. like what are you building to be able to incorporate that? We just get the cookie as received and we do the ZK magic on top of it. Okay.

They know that we're doing this stuff. Like obviously we're talking to to to all of these like big companies. And then we also got some feedback on like for example, there was one of the big fangs that they didn't want to track transactions on chain. Even if you can use me I don't want me, like my team to be able to track that this particular account in Facebook, Google or Apple, whatever. I'm de-anonymizing like anonymizing this now. To know that like Anna has this particular account on chain. Even if the cookie came from me. So you have to work on some requirements from from their side because they also want to reduce liabilities, right? This is like GDPR stuff, maybe?

Yes, there is there is many things that you have to take into account and actually there were many back and forth. Like as Ayush said, a lot of things actually on this research area happened last year, 2022, including us, right? The whole situation with us started even on 2021. But getting into production, like production ready things, takes time, right? You have to talk with regulator, you have to talk with many different people until you have a product that is acceptable by like the mass. So this is interesting because we kind of we we never talked to any of these people actually. We never talked to any of them. Also we never talked to any any anyone in these companies. We we're not working in these companies. We don't have necessarily the same connections and we just kind of

stumbled upon like we think privacy matters and so actually we should make this private on chain. And it's kind of funny that we reached the same solution but without discussing with any of the people. Yeah, what I'm saying is they there are many requests that they have. For example, even what you can put on the header on their header they might have an opinion. Mhm. And sometimes you have to talk just to be complying with whatever they're also thinking for the future. It's not only what it is today on their emails, right? They might change something and then you have to be prepared to to support your users of the past. So we have to be very very careful with I suggest that you will also go one day.

Now because you're not production ready, maybe you have like some flexibility and freedom, but eventually when there is real money the situation and the story changes, eh? Yeah, I mean our audit is intended to finish this month, so we're we're intending to start supporting real money this month. So if there's any of these specific people or companies we should talk to, I would love if you like, you know, let us know and we should we can we can reach out to them and we should be like, "Hey, by the way, we're doing this, just a heads up." Um it might be a useful conversation for us to have. To tell you the truth, in my opinion, nobody wants liabilities. It's it's a very sensitive thing there.

Imagine you're going to a company where they're doing just emails and now they know their email server is responsible for money transfers and other things. Yeah. So they have to know. Yeah, that's true. If we're talking about APIs, I'm curious about the other side of it, which is let's say the on-chain side. And specially I'm curious about the level of integration needed between the two different solutions. And is there some kind of a special place for ZK login in Sui or is it on the level of a contract that verifies a proof and uses an address or and same for ZK email, I guess, which is more definitely I guess on a contract level. Yes, I mean

in Sui it's actually the authenticator side. Like on Ethereum you have ECDSA K1, right? This is the only method that you have and everything else should go in the in the smart contract. Sui is crypto agile here. You can sign transactions with ECDSA K1, you can sign transactions with EdDSA, you can sign transactions with multisig. And what we did, because we didn't want people to actually look for which smart contract ID is this and that we just embedded it there and now it's just a counter. If you're using number one, it's ECDSA. If you're using number two, it's EdDSA. If you're using number five, it's ZK login. And it's happening at the prologue, even before you execute any like smart contract logic. And there is a benefit here. Can you imagine what is

the benefit? Apart from the fact that you don't look for smart contracts. Um maybe about gas payments? Yes, you don't pay gas. Yeah. You can avoid it because if it's happening in the prologue, the most important stuff is you can parallelize it. It's stateless. Yeah. Right? And when something is stateless and you know it's stateless because we did it like this, you can actually have imagine like how web two companies work today, you can have many off-loaders when they're receiving transactions on the validator side. I can verify SNARKs on parallel from many users. And now the system can maintain the speed that we promised at the very beginning even if we added the extra layer of zero knowledge. Because you know, zero knowledge verification is still more expensive than a signature.

Yeah, it's still pretty slow. Well, I mean so so in in the defense of zero knowledge verification, if you do, you know, like so so what we're doing is exactly correct. We verify the ZK SNARK on the EVM and then execute the transaction after that. And because this is happening on a ZK roll-up or an L2, actually the execution gas cost is also basically zero. You're only paying the cost of the call data gas. And so in practice it actually ends up being from what we can tell more or less the same thing when execution cost is zero. It's just that the additional proof values need to be passed in as call data, which is actually nice for data availability.

You get that data available on chain and you can make queries on top of it. You can operate on that on on chain, which is actually a feature for us. You get that raw data. So Ayush, you have a roll-up, right? In our case we don't need a roll-up. That's a benefit. Yep, yep. Right? Because you want to wait for people actually to form a block like with 100 transactions. Well, in our case every user is acting independently. I don't need to wait for someone else. There is no roll-up here. So that's that's that's an another benefit of SNARKs being able to be executed in milliseconds. More expensive than signatures, but now you can parallelize it.

Ayush, is most of the ZK email work connected to the Ethereum blockchain? Is it connected to a blockchain? So so I I I would say ZK email right now is roughly split into like two kind of main buckets. There's the bucket which is verifying the emails and that's completely divorced from the Ethereum blockchain. That is like you can do like whistleblowing, you can do like a complete different host of things with that. In terms of the email wallet, that's almost like an independent product that is directly interfacing with the blockchain and I would also put the ZKP2P team in this bucket in the sense that you're using these emails to directly interact on chain. And in this case yeah, we have a lot of these, you know, we have to consider very carefully the gas and security account abstraction standards

and so on. And and if you're doing ZK proof of email, you know, on the first side and you're not interacting with the chain, then you have a completely different set of assumptions where you don't have to worry about, you know, is this gas efficient? Is this happening on chain? It's just like, "Well, no, like can can a journalist at the New York Times understand this?" becomes your question. It's a completely different set of problems. And so the hope is that by exposing like a public SDK that anyone can build on their own ZK email proofs, prove any data in their email, that that unlocks like an entirely new paradigm of identity um which which in a sense is is almost unrelated to the wallet stuff. I mean the wallet stuff is is very interesting, but that's kind of you're authenticating transfers with emails and

it's going between different people and that's it's kind of its own thing. Ayush, I have a question. Um how how do you I mean you mentioned roll-ups, right? Do you run your own roll-up for this? So so currently we don't run our own roll-up because that's like a maintenance burden that we don't think is necessary. I think like the way that we currently structured is that because our entire relayer network is decentralized, the relayer can choose I want to post these proofs to this chain or the user can specify I want to go on this chain and that allows interoperability on like the user's preferred chain. And by default we'll launch on a specific roll-up so there's, you know, some uniformity, but we expect actually like we could run our own roll-up, but we ultimately expect users to want to interoperate with their say friends or

their favorite protocols or whatever, which are all all happen to be on maybe their favorite roll-up and we don't think we should be opinionated about that. I see. Okay. Do you then have like EVM contracts ready to deploy to do that? Like how how does one run what you're talking about? Yep, it's a great question. So there's kind of three main parts of this. There's the ZK circuits and so these circuits are going to be running either locally if you're self-hosting or you can punt those to a relayer. There's the exactly the smart contracts. There's a set of Solidity contracts that includes your, you know, ZK verifier as well as your account logic. Um and there's the relayer. And so the relayer, you can imagine, is a

piece of infrastructure that you can self-host. It doesn't need to be necessarily you're trusting someone else's relayer. But they did that this is a thing that makes the UI of the proof generation really easy. Um this means that the proof generation can happen in a way that no one can steal your funds, but you also don't have to put in all the work of calculating the proof yourself on the client side because that can be extremely expensive. You can if you want to, but also we actually expect that the way most users will interact with this is they just email a relayer. The real relayer handles it all for them and they don't have to think about it at all. But then you would want to do it for anonymity, right? If you want to do it yourself.

Precisely. So if you want to do it yourself, that's probably because you want full anonymity. Exactly. Uh I use out of curiosity because we spent a lot of time to compress everything into less than 1 million gates. And I'm telling you it made a huge difference. I mean, 1 million plus a few gates actually made our like ceremony by far uh less effective on the browser, but the 1 million bracket was exactly what we needed to run the ceremony on the browser. How expensive is a proof like on your side? I mean, how much time does it get at the moment?

Yes, so we have two current SDKs. The first one is Circom and second one is Halo 2 and these have different trade-offs with client-side proving versus service-side recursive proving versus on-chain verification. And so what we currently do is we say we prefer that people use Halo 2 for client-side proofs because that can happen under 20 seconds in a browser. And then you can either post that directly on chain or that can be recursively verified and then posted on chain for substantially cheaper execution gas cost as well as proof size. Alternatively, you could use our Circom SDK in that case. If you're using Circom, you can do a rapid SNARK proof on a server in, you know, under 10-20 seconds and that proof can directly be posted on chain or you can do a client-side. Um I agree that it would be nice if it was cheaper than a

million gates. I would actually love to see you guys' circuits. Um but currently the circuits for that are between two to six million gates depending on the complexity that you want in that email verifier. Um I would even say between one and six million gates if if you have like the most bare-bones version of the email verifier. And so in the browser it's possible, uh but it's not particularly efficient. It takes on the order of minutes uh to do that proof. And so this is why kind of the email wallet is is the initial entry of ZK email into people doing proofs because we think that by allowing people to do this kind of service-side proof that's pointed to a relayer, the the friction of that proof gets way lowered.

Um but yeah, I I would love to see the optimized Groth16 circuits that you have. It's it's kind of I mean, I assume you guys have like an RS256, RSA, and SHA256 uh circuits and we tried to optimize it a little bit, but I'm I'm sure you guys have some some great tricks that I I would love to take a look at. Yeah, indeed. We were also like very consistent on the Facebook bias that we had. Nothing should take more than 2 seconds for the user. I mean, you're losing your user. Mhm. Like if someone goes the browser though in 2 seconds, that's like with a million gates that doesn't something No, no, no. We we don't do it in the browser, these 2 seconds. But we managed to reduce the number of gates, so as you said, rapid SNARK and other like offline

uh servers could actually produce proofs in less than a second. Huh. And this was important for us, right? When you press the button of login with Google, you want the user to feel the same experience. And what's happening is, okay, we know that when we're pressing the button, there is a loading. I mean, it takes 1-2 seconds even today without zero knowledge. Just because you're connecting to Google until Google gives you the cookie, blah, blah, blah. And you hide it there. You hide the zero knowledge proof in this uh period. So the user doesn't even realize they they had the zero knowledge. That's beautiful. Yeah. Okay, let's talk a little bit about the actual SNARKs that you're using. You talked about the number of gates. Are are you using the same ZK system under the hood? I usually mentioned Circom and Halo 2. Is it still

Groth16? Yeah, so so Circom would be Groth16 and Halo 2 would just be Plonk. And so yeah, I guess it sounds like you guys are also using some R1CS-based system. Yes, at the moment we are also Groth16, but we implemented it in the risk zero. We're now implementing it in uh for Plonk, like not Groth16. We are implementing it also, you know, I was one of the co-authors of Winterfell in in the past, right? Yeah. So we do STARKs as well. And then eventually Nova, now we're doing everything until we reach a state we can get rid of the ceremony. This is our goal, by the way.

Groth16 is great, but Cobby knows better, right? I running a ceremony, I didn't sleep for 1 month. I I was sleeping 3 hours. It's it's very difficult to put all of these people into one place, right? And you have to wait. Oh, yeah. Anyway, so in the future we want last month. Exactly. In the future we want to avoid it. And the main reason is not speed because we managed to have this sub 1-2 second uh like proof generation. Now the problem is what if we want to make an update? If you go to these big guys, you will realize that they're scheduling updates in the future.

So you cannot just work with one R1CS. Yes, you might have one R1CS today, but be prepared to change it in the future. Mhm. Yeah, I think I totally agree with that take as well. Like it's also the case that like I think Circom is the easiest thing to get up into production. There's auditors, like there's there's there's tons of tooling. There's things like Potion to do trusted setups for you, uh which is like this PSC tool. And and this is why I think a lot of the initial deployments of these are going to be Circom, but I totally agree. Like we're also like excited about building a Nova-based solution. We're also excited about like, you know, getting the Halo 2 stuff audited and into production. And I think and you know, even STARKs uh eventually, but on-chain verification of STARKs is is a little bit trickier. And so I think

I completely agree that in the future I don't expect Groth16 to be the the standard that everyone is using. I think there's going to be like a much more complex system, maybe like some hybrid Nova recursive verification, something going that allows things to be like super ultra fast. By the way, I I talked to Cobby in the past. I guess he did it as well in one of his personal projects. There is a way for Groth16 to avoid the trusted ceremony. Huh? Yeah, you don't necessarily need to use the KZG commitments, the the sequence Yeah, the user can create their own, right? It's it's authentication. The user can create their own ceremony. But you cannot expect from the user to run 10 minutes or in the browser ceremonies and all of this stuff. The The UX is the

issue that Suyi decided to do a ceremony. Because we had the solution even with Groth16 to avoid the ceremony. Mhm. Which is great, right? We're preparing a paper around this. Cobby, I might require your like I mean, to enlighten us a bit here. But there are ways, even people say Groth16 is only with ceremonies, there are ways for some particular problems to avoid it. Yeah. So in this case the user would have to generate though the entire ZK locally on their browser. And I assume that might be expensive. Yes, that's the problem. It's UX. Yeah. I do maybe have one response to using Groth16 for now and maybe something that is either setupless or just have a universal setup in the future.

I do think that first of all, great choice for starting with what's easiest and Groth16. I also think that there may be some dream that is not entirely true across the ZK community that when you're using Plonk you're out of the wood. But I do think that every update is going to be very, very painful, maybe almost as a setup. Um because you every time you change a circuit, you have to get it deployed, you have to get it really deeply audited.

And I I do think that the agility of development is definitely a good thing to focus on. I'm 100% sure you have some company names in your head now. Maybe. Because this thing this thing is happening today, right? We know many are updating their circuits every now and then. Do they audit every update? I guess this is what you're referring to, right? Ooh. I hope they do. Uh I hope as well. I'm not sure. I hope as well. Wow. Yeah, so Cobby's right on this, right? When you're updating the contract, you have people have to, especially in the blockchain space and when you're handling a lot of uh like big value of uh like assets,

every update in theory should require an audit. You cannot just go and update things arbitrarily. But audits, I use know is it as well, takes time, right? You it might take you months uh just because you need to find the best people and these best people are typically occupied and then they have to work on your project and they need some time to understand what's happening. If it's not big changes, maybe you can have this continuous audit as I call it with someone who is you are actually paying them and they stay on the background. They they use their slots for future requests. And this is what we do actually. Uh Cobby, we're very serious on this.

Nice. But obviously, as as you understand, it's not like one day we're just switching something and the new zero knowledge works, right? This cannot happen. And this is dangerous. Eventually it will bite us. Yeah. Cool. So now now that we've talked about like what proving system, maybe it would be interesting to dig deeper into what do these circuits actually prove? Like what what can they do? Yeah, so maybe I can comment on what our ZK email circuits are doing. So at a high level, all the emails are structured as RSA signatures of SHA hashes of the data of the email. So you can imagine that your standard email is, say, Google's mail server, they have some public-private

2048-bit RSA key, and they're going to sign the SHA hash of to email, {comma} from email, {comma} subject, {comma} a hash. And if you want to extract body only from the subject, then you don't need to do the second SHA-256 hash. If you want to get data from the body, then you do need to do at least part of the second SHA-256 hash. And the final thing that allows kind of the programmable provenance, which is the the interesting part of this, is that you can define arbitrary regex inside of the values parsed out from the inside the SHA-256. So, you can run a regex on the subject of your email. You can run like arbitrarily complex string matching algorithms, and then extract out only the information you want to reveal or process on or do whatever data you want to on. And so, this is really powerful

because in email you maybe you have like you want to say like I can prove my bank account balance to you. So, then what we'll do is we'll like regex out that value, we'll SHA-256 that to the end, we'll prove that it was done correctly by basically SHA-256ing that again with the header, and then proving the RSA signature of that matches. And so, there's kind of like a couple of components here including this like whole like separate fully featured like ZK regex library, which allows you to get a lot of this interesting programmable cryptography. So, this is for instance how we define like a transfer. Like if someone wants to send, you know, I don't know, 10 die to someone to another email address, what happens is the regex inside the circuit extracts out the destination email address. It makes that private, and it hides that actually on chain, and it

only exposes the other part of the subject, which is like send 10 die or whatever, which is what actually And in addition, you know, the 10 and the die are going to be parsed out and then transferred on chain in order to be anonymous as well. So, the 10 and the die will go directly on chain so that those can trigger the transaction, and the email wallet address target will be anonymous. Mhm. Make makes a lot of sense. And just to break it down, so for example in the bank account balance, you would look in the from that it is from the bank, and you would look that um in the to address that it is the specific user that you're looking for, and then you would do a regex search on something very specific that says like account balance colon 100 USD, for example. Precisely.

And that's what you would expose, right? And this this actually you kind of want to constrain email a little bit more. So, you ideally want to say like it's not just that we're searching for account colon 100 because you kind of want to make sure the format of the email isn't changing. And so, once you probably want to constrain as much of the static email as you can, and then also extract that out of the middle. And you know, there's some applications where you don't even need to constrain the body. Like for instance, for the email wallet, we only constrain the header and we don't do the body hash SHA-256 check because we just don't need to. All the information is in the subject, and so that ends up saving us a ton of constraints as well. Nice. Amazing. The pretty much the same idea

is happening on ZK login as well, as you can imagine. Originally, we had to decide between two two options, right? If the RSA signature should happen outside the circuit or inside the circuit. And this is important because you can save the RSA snarking of things. But the problem was that then Google and Facebook would be able to track their RSA signatures on chain, so they could match accounts. Mhm. Right. You are hiding user ID. You're still hiding user ID, but now you're giving some power to Google and Facebook to go and check their matching signature with something else because they know their signature. And if the RSA signature is happening verification is happening on chain, they go and find it.

So, eventually you have to verify everything about this cookie in our case inside the circuit, everything. And then what we did copy is for RSA we there is a like a an interesting trick on the XJ snark paper where you can optimize the RSA signature verification. So, we're using this trick. So, eventually this results about 15% of our verification being like RSA. And the SHA-256 is about like 75% 74% of all of the calculations. And then we have some Poseidon hashing. This is fast, and some extra ruling, and all of the rest are about 11%.

I need to quickly ask. You keep mentioning RSA. Do we know this? Yeah. Is this the RSA? Like can you just say what that stands for? Maybe we maybe I do know it. I just don't know if I know it in this context. is the digital signature scheme that we are all familiar with, right? Yes. The one the one that we know. Rivest, Shamir, Adleman. It's funny actually. So, my first exposure to cryptography, there's a class at MIT taught by like Ron Rivest on cryptography. Yeah. And so, that was how I initially learned everything I know about cryptography, and then, you know, here we are now using RSA, which is which is pretty sweet. Another interesting part is at least for JWTs for cookies, almost all of the signatures today in the TLS world and including like JWTs are still using

RSA. Got it. We found a few providers that are using ECDSA. What about HMAC? I noticed there's a bunch of JWTs that don't even use signatures. They just have HMACs. Not on JWTs right? Because on JWTs if there is no real signature, then eventually it cannot be verified by someone else, not the website. And yes, they use RSA. I found one however that is using ECDSA. Mhm. And now we need Plonk. We need something else for this provider. Yeah.

Yeah, I guess that's one other interesting thing is that you guys for each new provider you have to make like a bespoke login setup with like bespoke button that allows people to interact with that. But I think one nice thing about ZK email is that the way we upload a new kind of mail provider is we just put their public key on chain, and then subsequently we have a new mail provider. The circuit doesn't need to change. Nothing needs to change in order to onboard a new a new mail server, say if you're using ProtonMail or whatever. We don't need to change anything if there is a new provider because the root keys of the providers are actually maintained by the validators. This is another thing that was very useful to put this at the authenticator level and not at the smart contract level. Now the

validators are working as oracles as well. They are checking the root keys of Google, Facebook, Apple, blah blah blah, and they are updating it. The main question is if they are still using RSA, and if they are still using the structure of the JWT that we want and we can understand in our circuit. You will realize it as well that in the future you will see ECDSA, and you will have to update your contract. Mhm. Wait, when you say validator, do you mean like Sui validators or is it validators of the system? Okay. Okay. Sui validators. All of the security is based on the same guarantees that you get on the blockchain. Huh. ZK validator is about to be a validator on Sui. It might actually already be so by the time this airs. But does that mean then like we as the ZK validator will be

validating ZK stuff? Yes. You're welcome to contribute into this. Exactly. If they send with with account type five, then we do ZK login, right? Yes, exactly. And imagine what this means, right? Our validators in theory are certificate transparency validators as well because this is what you do, right? You are verifying some root certificates. So, in practice we created the first blockchain CT. It didn't exist before. Kobi's shaking his head a little bit. No, I I need I need to be adjusted.

Yeah. Are there any differences in the security guarantees between ZK login and and ZK email? From what I heard, it seems that there are no big differences. I don't know if I use believe something different. But I don't find something now that we are completely different regarding the security guarantees, right? There are differences in the circuits and other things, but they are using a salt. We are using a salt. They are also using some signature verification of the root provider. We are doing the same thing, and they are also using Groth16 as well with Circom, and also they have a Halo 2. It's pretty much what we are also doing and exploring.

So, the nice thing with the general like ZKPs, which is very interesting, right? Is because now the security is on the security of the circuit itself. Mhm. Because you are using the same algorithm, right? It's not a new protocol that you invent. There are there are small pieces that you're putting there, but the security guarantees of the zero-knowledge proof properties at least and the compression are based on the Groth16 or whatever system you're using. They're not based on the value of the underlying thing or anything, right? It's like not It doesn't It doesn't matter what the underlying system has. I've seen many many protocols that are like customized zero-knowledge proofs, so they're not using a generic like algorithm. This require a security proof, right? An

extra security proof. By the way, we are also having a paper as well. I guess I use you also have a paper on ZK email, right? Yeah, we have a paper on ZK email, and then Sora has one on email wallet. Yes, exactly. So, these things are like they are already reviewed, but you will soon see a publication as well, which is peer-reviewed by some of the like biggest conferences in the world. I also think it's it's pretty similar to me. You're you're relying on some the DKIM key matching like in in their case the validators are validating the DKIM key. In our case, you're trusting that whatever organization is putting it between the DNS and on chain is similarly trusted in that that can be self-custodied as well. Yeah, and there's trust in the mail server key.

I guess one interesting thing that we have in our circuits that I'm curious if you have in yours is for invalidation of mail server keys because these keys rotate every 6 months or year or whatever. One interesting thing we have is that if you upload the private key in plain text for that mail server key on chain, then it'll invalidate that public key, and that's the only way to invalidate a public key, meaning you have censorship resistance. No one can just delete some DNS public key. And so, I guess you guys don't necessarily need that given that validators are safe doing that lookup, but I'm curious if you guys have thought about the problem of avoiding like say leaked mail server keys still being on the mail server, but the secret key being leaked. So, what's happening on JWTs, typically they like Google for example is doing it pretty much every

month or so. Some they never rotate. I've I've seen many providers in the last 2 years. I've also seen a few that never rotate. Yes, never rotate it, right? So, what's happening is its validator have their own look up at the moment and they are also receiving multiple keys that are active. I don't know if it's the same thing for DKM. Yeah, there's multiple keys for a few of them. There are multiple keys, exactly. So, you have to be prepared because they advertise the key that will be active in a day or something. So, that's why the validators constantly checking what is the what are the active keys. Plus, when someone is creating a ZK login request where inside the cookie, we're also putting the expiration time. So, a user might say it's only for one epoch, one

day. You cannot use this cookie next day. And that's this is how we are also protected even from the wallet side that they might have more aggressive or more defensive like uh let's say strategies for the user to decide for how long their proof is available. So, now I have a question. If your JWT is only available because it's only signed for one day and you create your JWT in your wallet and then say two days later you've forgotten about your wallet and you come back. Now, that original authentication you had is no longer valid and so, how do you actually claim those funds if the JWT has expired?

Because the JWT is only required to create a new proof of for a new delegation key. You're just changing your key and you're getting a new cookie and you access your funds. Your address is not related to the cookie. This is important, right? The cookie's rely is is is required to create a zero knowledge proof that you own the address. Got it. And that's on the email directly, but not the cookie. Yes. So, pulling on the security guarantees thread again, how does it affect the security when a lot of emails or more correctly email accounts and services are delegated like a lot of companies use Google apps and things of that sort?

Is that means you're placing more trust in Google specifically like in contrast to JWT, for example? So, I would say like for emails for instance, a lot of organizations do just say, "Okay, we're we're going to punt the say Google to do all of our management." And what happens is that public private key is managed by Google and the public key is posted under the mail server in the DNS of that specific website. And so, yeah, what this would do is it would basically say instead of having to trust, you know, end different websites and all of their security parameters and guarantees, because the majority of them use Google, for the most part you just have to trust that the way that Google does their mail server key management is robust, which we already in a sense assume this

day-to-day. I mean, given that email is usually your 2FA for your bank account, your social media and basically your entire life, we already kind of put a significant amount of trust in these mail server keys. That makes sense. And yeah, and JWT I guess like it's still very much self-managed by the services or is it different? The JWT okay, there is a small difference, right? I mean, ZK mail if I understand correctly, they can work with all of the email servers in the world. Correct. For us, we are picking the companies that are compatible with the JWT, which means that the big companies. It cannot be a random email server. So, we are restricting a bit the the space here for for attacks, but at the same time we have more restrictions on what different email someone can use.

Okay. And there is a second thing that I realized with some wallets that they support ZK login because at the moment as we said, there is this salt, right? This salt can be provided to the user through a two like 2FA. If you want, you can add your phone and you can receive the salt in in another device, right? Or receive something a code to access your salt in another device. So, even Google cannot sit. Mhm. Even if Google wanted to cheat, they have to have control of your phone number plus your email number. Makes sense. These are these are really great points about like the trade of space.

Thanks. I believe we will see wallets now that they will introduce into their flows a 2FA. Not a 2FA on your email, a 2FA in the wallet to give you the extra piece of information. Mhm. I want to sort of wrap up our interview with a question about the sort of ZK-ness. Uh both have ZK in the name. Are these private systems? Like so far, I think we see a lot of the practicality of it being very easy to to sort of onboard a new user and to like, you know, have them without knowing what's going on behind the scenes like use sort of their web two logins or web two things, emails or what have you. But yeah, is there a privacy component? Like I know

there's a SNARK, but is it private? And I know there's like sort of anonymity, but yeah, I'm just curious if if this is actually a private system. In both cases, I believe that that's the plan, right? Because in theory in JWT case as I said before, we could publish the cookie itself. And then the system would still be secure, but you are revealing your identity. Mhm. Right? So, we needed ZK to hide the identity of the user. And then we also needed ZK because we are also providing these extra features. Sometimes you want to prove something about your identity, but not your full identity. You're proving you are MIT student, but not who exactly you are.

So, one is anonymity, the other is selective like partial anonymity. You have all of these features, right? And there are other elements. For example, I use you're also using growth 16. It's also the compression element here, right? Now you know, every single request is pretty much the same size because the proof is what it is. While if you send the cookie, there are some cookies that might be big. And you don't want all of the cookie or of the email to go on chain, obviously. So, we are using both properties in my opinion that these generic zero knowledge proof systems are offering.

Both for privacy, but eventually both for compression as well. Mhm. Yeah, I think I agree. I think both zero knowledge and compression are used here. Zero knowledge to provide anonymity on chain and the compression to ensure that you don't have the entire bulk of data that's selected put on chain. And so, the succinctness comes both from the compression of the amount of input data. Like instead of having to pass the entire email header, you don't have to pass in specific public words. And in addition to verification constant to verify the entire RSA signature, you can just verify the ZK proof.

Another interesting primitive that we literally put in mainnet two weeks ago is someone can even prove what wallet they used for the cookie. And this is important, right? Because sometimes you might have wallets in with mnemonics you cannot do it. You don't know from which wallet you actually signed the transaction. Mhm. But with this one, there might be a MetaMask wallet that might create a campaign, "Guys, use my wallet to get these airdrops." You just prove that you used my wallet in these one-time addresses or whatever you're using and I indeed know that you are my users.

It's not like you're random users out there. So, we will see some applications with selective disclosure of information Mhm. uh going public as well. So, yes, there is anonymity, Anna, but there is also this thing that some people might want partial anonymity Mhm. or other types of like privacy. This is very cool. I'm actually, you know, of both systems and just the in general thing. Like it's sort of opening my eyes to what going to how wide reaching something like this can can be. The type of things you can do once you have a system like this. I use by the way now I'm curious, right?

How can I use your system today? We have it a testnet demo right now on emailwallet.org and hopefully we'll have the the V1 with all of the decentralized relayers and there's like a number of features that we added including the private key validation. Um Is it a real testnet? I mean, are you are you planning to have a token? No, there's no token. So, so the the So, right now it's just on a normal like Ethereum testnet like Goerli and Sepolia and eventually we intend for the the V1 basically with all of the features to be on the mainnet.

So, hopefully that you'll also be able to access that on emailwallet.org. Okay, but this will be a for-profit like product, right? So, so right now we're positioning this. So, it it's funded by Ethereum Foundation PSE. One of whose mandates is, you know, don't release for-profit products. So, the hope is that at least for now this is kind of released almost like a like public good in a sense where we kind of expect that different people would run different relayers and we expect that, you know, maybe some company wants to run the relayer and they they kind of want to be able to say, "Look, we we we are hosting this and you pay the fees to us." And that's totally fine.

We hope that they use the audited contracts that we put all this effort to. If they decide they don't want to, that's also totally fine. But you guys are part of a for-profit company, right? So, are you guys intending on being for-profit? No, because ZK login as I said is on the foundation side. It's a primitive on Sui. Yeah. So, what's happening is we opened the door for wallets to use it. Yep. Yep. Yeah. Right? So, everyone everyone in Sui can use this particular primitive to have their own business. But like as a product, it's similar to you, right? It's a open source in Sui and everyone can go and use it. It's all friendly and public goody.

And I think there's another like small detail here, which is that if you're kind of making money off of such a service, it gets a little bit legally tricky. And so, that's also something you can just entirely sidestep by having it be a a public good. Yeah, I I guess here as well, right? I mean, if there is this primitive, you can build a product on top of it. Exactly. But the primitive itself in both cases, Anna, seems to be open source and available for everyone. At least their product on Ethereum and in our case on Sui. Yeah. And the And I I in fact expect that both of these it's not too hard to port to any other chain. Like you can kind of it it's just a change in the verification logic and I actually expect the the system I mean, the the the really difficult part is

getting the ZK proofs to work consistently, but the verification is completely modular and composable. You can you can do whatever you want wherever you want with that. Well, I want to say it was very fun to have these two projects on the show where there's like obviously a lot of overlap. I love the idea that both teams basically came to very similar conclusions about certain things, but also made a few decisions to like differentiate one another. Although I I realize it wasn't necessarily done on purpose, but there does seem to be like different use cases or different communities that might be into some one one of these solutions versus the other. But yeah, thanks for coming on, guys. Yeah, thank you for inviting me.

This is called convergent evolution, Anna. Uh obviously, we ended up into similar ideas because that's the way to do it, right? They're good ideas. It's funny. Yeah. Yeah, thank you both. It was super interesting and very much looking forward to see both of these deployed. Yeah. Oh, I have one quick question about a difference between the systems. Um so, in our case, one thing that we have is when you send money to someone, that money is like unclaimed until they decide to claim it. And so, as a result, if you send money to someone, you don't immediately learn their wallet balance.

Um I guess I'm curious if you guys do the same kind of like unclaimed fund unclaimed state in the J wallet. this is This is at the product side, right? Because we're talking about the primitive, you know? Yeah. Yeah. Yes, but products on top of it like Zcash send.com who is using which is using like Zcash login. At the moment, you can send like funds to someone with a like private salt and so on. They can claim it, but there is also a version you can even send it to a smart contract, and you can claim it from there. But if you don't claim it, the sender can get it back. Yeah. Yeah, we have the exact same thing.

literally in one one out of two thing, right? Not automatically, you have to go and claim it, but it goes back. Is it the same with you? Yes, and that's what we like. I'm telling you, convergent evolution again. All right. Well, thank you guys again. Thank you so much for coming on. Um I want to say thank you to the podcast team, Henrik, Rachel, and Tonya, and to our listeners. Thanks for listening.