ZK for web2 interop with zkLogin & ZK Email

00:05: Anna Rose:

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.

00:27:

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 zkLogin and Aayush 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 their significant differences, especially in the community they are tied to. zkLogin 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 0xPARC 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.

01:43:

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.

02:35: Tanya:

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.

03:35: Anna Rose:

Today we're here with Kostas from Mysten Labs, the company behind the Sui network, and Aayush Gupta from the ZK Email Project. Welcome to the show.

03:46: Kostas Chalkias:

Good to see you, Anna, again.

03:47: Aayush Gupta:

Yeah. Glad to be invited.

03:49: Anna Rose:

Our co-host today is Kobi. Hey, Kobi.

03:50: Kobi Gurkan:

Hello.

03:51: Anna Rose:

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 had given that was really well received. And then you actually encouraged us to invite Aayush 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?

04:27: Kostas Chalkias:

04:54: Anna Rose:

Nice. When you last came on, we actually talked about, what was it?

04:59: Kostas Chalkias:

For solvency, for proof of solvency.

05:00: Anna Rose:

Oh yeah, for solvency. Exactly, exactly.

05:02: Kostas Chalkias:

And by the way, there is an interesting stuff here. Some governments are now interested in 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?

05:17: Anna Rose:

Whoa.

05:17: Kostas Chalkias:

Yeah, it's the same logic actually, using privacy for any inclusion proofs.

05:23: Anna Rose:

Very cool. But yeah, today we're gonna 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 how research happens with you guys, like what motivates it. But Aayush, 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?

05:43: Aayush Gupta:

06:34:

And then from there, I was kind of searching for a new project, and so then me and one of my friends, Sampriti 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 then there's no point in doing ZK because they're not actually verifying anything meaningful. And so we looked through and we found a bunch of primitives that had signatures. We found emails, JWTs, and there's like a couple others. And we were like, okay, what is the most used one here? It looks like it's emails. And so we kind of we built the initial proof of concept in a crazy week, and then that hardly worked. It didn't... It worked on a couple of emails and failed on almost everything else. And then, over the next, like, I think it's been like about a year or so till now, we refined it, made public SDKs, did one and a half audits, and now we're like, it's kind of really ready for public consumption. And we've had a lot of cool folks joining and helping out and it's been quite the ride.

07:41: Anna Rose:

Cool. Aayush, the project you're talking about is ZK Email. That's the name of the project at this point.

07:47: Aayush Gupta:

Right, yeah.

07:48: Anna Rose:

Kostas, your project is called zkLogin.

07:51: Kostas Chalkias:

Exactly.

07:51: Anna Rose:

Do you want to share a little backstory on where those ideas come from?

07:56: Kostas Chalkias:

Exactly. By the way, I won't debate with Aayush, but because we were also searching email against SSOs, we decided, oh, most people are familiar with SSOs, not email eventually, especially for the copy paste part, right? You need to copy paste headers and all of this stuff. So for us...

08:12: Kobi Gurkan:

Please debate, please debate.

08:13: Kostas Chalkias:

I will try to keep... Okay, yeah.

08:15: Anna Rose:

Name fight.

08:16: Kostas Chalkias:

There was a reason I invited you here, Aayush, but as a friend, mostly as a friend.

08:22: Aayush Gupta:

Oh they are used for different things. I think it can be constructive, I don't think it needs to be argumentative.

08:25: Kostas Chalkias:

09:28:

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 a circuit, we add a few things to make it 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 zkLogin. So that's the whole idea here.

10:05: Anna Rose:

Interesting. There's two words or acronyms that you've both mentioned that we need to define, JWT and SSO. You just said the SSO, why don't we actually redefine that again? I know you said what it was, but I didn't quite catch it.

10:20: Kostas Chalkias:

Yes, so SSO is literally single sign-on. We press one button and we're logging into something, right?

10:27: Anna Rose:

This is the like, oh, do you want to log in with your Google account?

10:29: Kostas Chalkias:

Yeah, the button that you see from Google, Login with Google.

10:32: Anna Rose:

Yeah, yeah, yeah, got it.

10:33: Kostas Chalkias:

And the JWT, imagine that when you press that button, Google sends you a kind of cookie. And this cookie is like a JSON Web Token, JWT. That is what it is. Imagine JWT as a cookie, and SSO as the button that you're connecting to Google to get the cookie.

10:52: Anna Rose:

So JWT stands for JSON Web Token.

10:55: Kostas Chalkias:

Yes.

10:56: Anna Rose:

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.

11:05: Kostas Chalkias:

Yes, exactly. So because it's also easy and sometimes you know these are like human readable, you can also have easier ways to create circuits around them.

11:15: Kobi Gurkan:

So Kostas, actually, one thing that you mentioned before, 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 that 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?

11:52: Kostas Chalkias:

Exactly. So one of the problems of identity-based encryption, this is practicality, right? And I want Aayush actually to make these comments here. There are no identity providers that are very easy for the users to actually use them now, today, with 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 as a community. And the only things we have at the moment, like people are familiar with literally email for ZK Email and this button Login with Google, there is no other provider for identity. Anything else requires some custom tools that people are not familiar with.

12:30: Kobi Gurkan:

Right.

12:31: Anna Rose:

Yeah.

12:31: Kostas Chalkias:

Right. So in theory, we were looking, 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 these IDs, 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.

13:17: Kobi Gurkan:

Very friendly integration.

13:18: Kostas Chalkias:

Yeah.

13:19: Aayush Gupta:

I think we had a fairly similar story there in the sense that we were also just looking for a solution which doesn't require anyone else to change anything. I think the second that you introduce these bespoke systems, it gets really confusing. The UI becomes really hard for people 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 original signature, you rely on some MPC network or some trusted enclave, or even some people just have centralized attesters entirely. And this kind of, at least to me, seems to undercut the premise of decentralization.

14:00: Kostas Chalkias:

Exactly. And in my opinion, there is another good outcome for both works here. You don't need the folks who are using them in their own dApps or their 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 a 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 Kobi, to hire Kobi, in order to have some business around these credentials, right?

14:31: Anna Rose:

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 Google button, but usually those are on Web2 applications, like web apps or whatever. What exactly is the problem you're trying to solve?

14:53: Kostas Chalkias:

Okay. So for us, one of the major issues that we realized is people, not necessarily degens, but other folks who want to join the space, they don't even know what it is to install a wallet. 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? So if you could hide it completely and literally by pressing the button of Google, you have a blockchain account. This changes the onboarding experience completely, right? You don't even know that there is something running in the background, zero-knowledge proofs and all of this, like creating an ephemeral public key, salts and all of this stuff. This is hidden from the user.

15:33:

So in practice, you can have 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.

16:00: Anna Rose:

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? This is the thing I'm not quite clear on.

16:18: Kostas Chalkias:

We didn't want people to even understand they are 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 zkLogin, 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 an Uber can come here and have login with, I don't know, email or login with Google in our case, and automatically have an account, right?

16:54: Anna Rose:

Is it just basically you've connected now the Google email string or whatever to a wallet? If they then go to another application, do they always create a new wallet in the background or are they actually tapping into the same wallet that's attached now to their email?

17:10: Kostas Chalkias:

Actually, it supports both. 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 zkLogin address. A zkLogin address includes the provider who is signing, like Google, the wallet that you are 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 BIP32 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.

18:05: Anna Rose:

But sometimes you do.

18:05: Kostas Chalkias:

If I want to be linked... Yes, sometimes you want to do it. So if someone can parameterize it, we are offering the primitive as a primitive and then wallet providers or dApp developers can decide what to do.

18:18: Anna Rose:

Did you just call it salt? What was the word you...

18:20: Kostas Chalkias:

Yes. Literally salt, pepper and salt.

18:23: Anna Rose:

Oh, I didn't understand what you were like, the different salts that you were... I didn't quite…

18:28: Kostas Chalkias:

Oh, yeah. Yes, exactly. Why is the salt there? Right? You don't want...

18:33: Anna Rose:

Is this like a general term that's used or is this...

18:36: Kobi Gurkan:

Yes.

18:37: Anna Rose:

Okay. I don't actually, I just don't know this. Sorry, sorry.

18:38: Kostas Chalkias:

Yes. Anything... Okay. There is pepper and there is salt and there are some other private stuff that we're putting on hiding things in cryptography. Yeah, imagine... I'm giving you a very simple example, right? Very simple example. Imagine that your identity in the blockchain was the hash of your email. Someone can just go and brute force it. 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 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 a framework to hide all of this stuff from the observers. 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? And then you might not want to see your cookie, like 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.

19:56: Anna Rose:

Okay.

19:57: Kobi Gurkan:

Kostas, you mentioned that, I guess, the zkLogin address, that's how you called it?

20:00: Kostas Chalkias:

Yes.

Kobi Gurkan:

So the zkLogin address is derived from, like say 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?

20:15: Kostas Chalkias:

Their wallet.

20:16: Kobi Gurkan:

Okay.

20:17: Kostas Chalkias:

Their wallet can actually do it. And by the way, the wallet, however, cannot impersonate the user to get the cookie for the user. So it's literally a 2FA scheme, somehow hidden, like 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 they provide you the salt, you are getting the cookie as well. And then you can sign in to your application.

20:41: Kobi Gurkan:

Okay. So you do still have to maintain something on your side.

20:45: Kostas Chalkias:

But not necessarily you now. Imagine if this was a private key, 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.

21:00 Kobi Gurkan:

Right. Okay. Because they still need the rest of the JWT, I guess.

21:05: Kostas Chalkias:

Yes, exactly.

21:06: Kobi Gurkan:

Okay. Makes sense.

21:07: Anna Rose:

Aayush, 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?

21:20: Aayush Gupta:

Yeah, so 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, call them programmable provenance data, and that's 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 Email Wallet idea that SORA had in a paper maybe about a year ago or so and we've been building. And yeah, in a sense we have a very similar model for that in which you send an email and your salt, we do 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, decentralized network of relayers. And again, the same thing, the salt only leaks your anonymity, it doesn't give power to actually control your account.

22:12:

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 passed on-chain. You can then get on-chain transactions just by a sent email. And so in that sense, it is sort of similar except that instead of managing a wallet private key 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 100% sure.

22:41: Kostas Chalkias:

It's very similar. We're also embedding a public key there so you can sign multiple transactions with one login. Right? There are some differences. We're not putting the transaction hash into the email because there is no email in us, but what you do is you're putting there a delegation public key and with this delegation public key you can sign multiple transactions just by signing once with Login with Google. There are a few differences.

23:03: Aayush Gupta:

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. And then I guess the final thing is, so there was a team of students that we had mentored. So this team built also the ZK JWT primitive, but they didn't attach it to a wallet. The idea was this was like Emma, Sehyun, and Kaylee. And what they did is they created the ZK JWT proof of directly from... We actually used the OpenAI one because a million people had just signed up for ChatGPT and so we have a massive anonymity set. 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 would then only expose your email address and so you could then post on behalf of someone like at berkeley.edu and not reveal who you are. And so this was an entirely like no Web3 involved, no blockchain, and it still is a really compelling application. There's a ton of really compelling I think Web2 applications, nothing to do with wallets that are still super compelling, although the wallet use case is a really nice onboarding tool.

24:07: Anna Rose:

That's interesting. One thing you haven't mentioned here, like sort of, I hear that, this not replaces, but it connects to the Web2 login, the SSO, but what about comparing it to what is currently used in Web3, which is having a wallet browser potentially, like Metamask, is it sort of trying to replace Metamask in any way or 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 keep that wallet that you've connected it to and do stuff with it as well? Like, do you ever get the private key for that?

24:46: Kostas Chalkias:

25:37:

And then there is also, as I said before, 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 Login with Google, but imagine if Login with Google is a wallet, you don't even know it's a wallet. So, 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 they're people who interact regularly with the blockchain, playing games and all of this stuff, they can use zkLogin.

26:10: Kobi Gurkan:

I guess there is one more benefit that maybe Aayush 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 Aayush and I did on plume signatures, you can reuse this big set of identities that exist and be lost within that set, right? Like you don't really expose who's doing what or who's doing transactions because it's just like a Google user, right?

26:48: Aayush Gupta:

Yeah, I definitely agree. I think in terms of the wallet question, I think I expect these kinds of wallets to actually be a gateway to self-custody. I think ultimately trusting a Web2 provider is not ideal if you're managing 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 microtransaction 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, which ultimately are the most secure version. And so I actually expect this to be an intermediate onboarding flow. And in terms of Kobi'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 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 and 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.

28:00: Anna Rose:

I think we're starting to get a pretty good sense for the problem space, the actual construction of these systems. I do have one question though for you, Kostas, which is I know you as one of the applied cryptographers, engineers at Sui. Is this coming out of Sui?

28:20: Kostas Chalkias:

Yes.

28:21: Anna Rose:

I'm just curious if like… and why? What is the connection then to the rest of your work? Because this sounds almost like a standalone project.

28:31: Kostas Chalkias:

Yeah. The reality is it's a primitive in Sui. We literally have pre-compiles now, because, on Ethereum you have the account abstraction, and in Sui and in some other blockchains, the way 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're losing the threshold, and then what do you do and so on.

29:13:

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 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 a big commercial website, 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 is, you just send them a link with a salt and only them with a Login with Google can actually claim the money.

30:12:

So I literally sent money to my parents. I don't know if you've seen my latest twitter, like twitter post. 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? It's impossible, right? And then I believe it all started because we're all not biased, but we knew the problem on what's happening when you're targeting a mass, if you're working for a funk like Facebook. You know people are not going to remember passwords or they're going to lose their passwords, but they are 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 and the cryptographer, it was a very interesting problem to solve. And what 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?

31:21: Anna Rose:

Yeah, it's so interesting though. See, I had not put it together with the account abstraction concept, but actually this to me is like a connection point, this idea that it's on that level.

31:32: Kostas Chalkias:

And there is something that is coming, actually, it's coming out in the next few months. I can mention it even today. We don't necessarily need to put a public key inside the cookie. What can we put? Kobi, can you imagine of something interesting that you can do?

31:52: Kobi Gurkan:

You caught me there.

31:53: Kostas Chalkias:

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 one 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 cookie. And now the cookie says, oh, you can use this smart contract now to log in. And it changes completely the story around account abstraction, because now you can have dynamic account abstraction, as I call it.

32:27: Anna Rose:

Oh, wow.

32:28: Kostas Chalkias:

You understand what I mean, right? Typically, you want to put in the cookie some delegator. 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. So it opens the space of account abstraction completely, and actually you can do it on-chain, off-chain, dynamically now.

32:56: Kobi Gurkan:

That's really cool. So you can get a lot of the power of account abstraction, but, maybe it would be good to see what can you usually do with account abstraction that would be useful in this context.

33:07: Kostas Chalkias:

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. 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...

33:23: Kobi Gurkan:

Daily limits, for example.

33:25: Kostas Chalkias:

Yes. 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. And this is 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 log in with Google, but the first time you don't even have funds, right? How can you send something if you don't have to pay for gas? You received an NFT, how do you send this NFT to Kobi, if you don't have any SUI? However, if you support sponsors, you can ask from someone, hey, can you sponsor my transaction, pay for my gas and I will transfer this NFT to Kobi. 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, you can do multi-sig processes, multiple users like DAOs and many other things that can happen now under this umbrella of AA, account abstraction.

34:30:

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 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? But if you knew I can watch a video and someone can sponsor my transaction now, now the story completely changes.

35:02: Anna Rose:

Yeah.

35:03: Kobi Gurkan:

Can I receive something in this method before I did the zkLogin process?

35:10: Kostas Chalkias:

Yes, go to zksend.com and you can do it now. This is how I send money to my wife's grandma.

35:17: Kobi Gurkan:

zksend.com, okay.

35:19: Kostas Chalkias:

zksend.com, yeah. I sent her something and then she was able to log in with Google and send it to someone else. She didn't have an account before.

35:28: Kobi Gurkan:

How do you derive the address in that situation because you don't have all the...

35:31: Kostas Chalkias:

I can send you the salt, right?

35:33: Kobi Gurkan:

Oh, I see.

35:36: Anna Rose:

I have to say salt is still very confusing to me. Aayush, maybe you could help me. What is this salt stuff? How would you define it? And why are you sending it around? That's what I don't get at all.

35:48: Aayush Gupta:

Yeah, so in our case, we also have this salt. And I should say that a better name for a salt, as you allude to, might be anonymity key or something like that, or it might be like privacy value or like hiding value or something like that. None of these names are really perfect, but the idea that this value is just something that keeps your anonymity on-chain. It's something that separates... our 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. In our case, the way that we ensure that the recipient has, we actually have a very similar system and the way we ensure the recipient has a salt is that we email them that salt. We make sure it's part of 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, Kostas, 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?

36:46: Kostas Chalkias:

We're sending it as well. You create the link and you send the link through, I don't know, WhatsApp or something else.

36:52: Aayush Gupta:

Wait. Okay. That makes a ton of sense. Yep.

36:54: Kostas Chalkias:

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 a messenger, whatever you want.

37:03: Aayush Gupta:

Awesome.

37:04: Anna Rose:

But you're sending this. Is it just like random numbers?

37:06: Kostas Chalkias:

Yeah, imagine it as a key. Yes, a random number.

37:09: Anna Rose:

Okay. And you as a user, if you receive this salt, you don't have to save it. Like this is not... Do you have to use it for anything?

37:17: Kostas Chalkias:

It depends on what you want to do. In our case where we're... 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 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 Aayush said, you might have a decentralized network that remembers the salt for you. So yeah, for one-time payments, maybe you don't need it, right? It's in one-time use. You get the $100 and then you can forget it.

37:53: Aayush Gupta:

When you're talking about the way that you guys do the JWT flows, I was wondering, it's almost 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 an email address, can receive these funds. And exactly, you can mass onboard 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 co-author an ERC or something so that it becomes a standard and not like...

38:23: Kostas Chalkias:

Let's do it.

38:24: Aayush Gupta:

Hundreds of people need 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 ZKP2P or something, send the funds to Venmo. There's a lot of options that you can do.

39:05: Anna Rose:

Do either of you connect actually with any of the APIs of those actual services? Or are you just using this kind of the fact that you're sending this salt and there's something that's now with that user?

39:19: Aayush Gupta:

For us, we don't interface with any of that at all. Actually, we only use mailto 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 an…which are like these kind of email protocols. You could kind of say that in a sense, 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 APIs that exist. Although I would imagine actually in Kostas' case is different.

39:48: Kostas Chalkias:

For us it's production ready, right? People are using it now for real money. So it's happening.

39:55: Aayush Gupta:

Yeah, we're getting audited this week as well. So I'm excited. We're going to have a bunch of these...

39:59: Anna Rose:

Guys are close.

40:00: Kostas Chalkias:

Good luck with it. We also had two or three like on top of zkLogin. It's quite an experience as well. We found also a bug in Kobi's algorithm at the very beginning. Not the bug.

40:13: Anna Rose:

Kobi's algorithm?

40:13: Kobi Gurkan:

It was unused.

40:16: Kostas Chalkias:

Okay. It was unused. Okay, cool. So yeah, we...

40:19: Kobi Gurkan:

But it was published, so my bad, yes.

40:22: Kostas Chalkias:

Anyway, this audit helped and actually what I realized is when you go and actually do something on hands, not just reading the papers, reading the documentation, then it's the best time to identify bugs. Right? And this one was not related to a circuit, by the way, it was related to the phases of ceremonies. How do you do Groth16 ceremonies?

40:44: Anna Rose:

But I want to go back to what Aayush just said though, this difference. So you were saying that it's production ready, but Kostas, is your system different?

40:52: Kostas Chalkias:

Someone could use tweets in Google now and we're working on Kakao and some other Slack, Apple, Facebook, and all of them, right? People are using it.

41:01: Anna Rose:

But in that case, what are you building to be able to incorporate that?

41:04: Kostas Chalkias:

We just get the cookie as received and we do the ZKP magic on top of it. They know that we're doing this stuff, like obviously we're talking to all of these big companies. And then we also got some feedback on like, for example, there was one of the big funks 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 like anonymizing this now, to know that Anna has this particular account on chain, even if the cookie came from me. So you have to work on some requirements from their side because they also want to reduce liabilities, right?

41:47: Anna Rose:

This is like GDPR stuff, maybe?

41:49: Kostas Chalkias:

42:18: Aayush Gupta:

So this is interesting because we never talked to any of these people, actually. We never talked to any of the mail servers, we never talked to anyone in any of these companies. We're not working in these companies, we don't have necessarily the same connections. And we just kind of stumbled upon, 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.

42:39: Kostas Chalkias:

Yeah. What I'm saying is 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. 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 support your users of the past. So we had to be very, very careful in this. I suggest that you will also go one day now because you're not production ready, maybe you have some flexibility and freedom, but eventually when there is real money, the situation and the story changes. Yeah.

43:17: Aayush Gupta:

Yeah. I mean, our audit is intended to finish this month. So 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, let us know and we should... We can reach out to them and we should be like, hey, by the way, we're doing this just to heads up. It might be useful conversation for us to have.

43:33: Kostas Chalkias:

To tell you the truth, in my opinion, nobody wants liabilities. 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. So they have to know.

43:51: Aayush Gupta:

Yeah, that's true.

43:52: Kobi Gurkan:

If we're talking about APIs, I'm curious about the other set of it, which is, let's say the on-chain side and especially I'm curious about the level of integration needed between the two different solutions. And is there some kind of a special place for zkLogin 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.

44:23: Kostas Chalkias:

Yes, I mean, in Sui, it's actually on 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 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 zkLogin. And it's happening at the prologue, even before you execute any 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.

45:10: Kobi Gurkan:

Maybe about gas payments.

45:13: Kostas Chalkias:

Yes, you don't pay gas. You can avoid it because if it's happening in the prologue, the most important stuff is you can parallelize it. It's stakeless. Right? And when something is stakeless and you know it's stakeless because we did it like this, you can actually have… imagine how Web2 companies work today. You can have many offloaders 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 zero knowledge verification is still more expensive than a signature.

45:48: Kobi Gurkan:

Yeah, it's still pretty slow.

45:50: Aayush Gupta:

Well, I mean, so in the defense of zero knowledge verification, if you do... So what we're doing is exactly correct. We verify the zkSNARK on the EVM and then execute the transaction after that. And because this is happening on a ZK rollup or an L2, actually the execution gas cost is also basically zero. You're only paying the cost for 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 the 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 the data availability. You get that data available on-chain and you can make queries on top of it. You can operate on that on-chain, which is actually a feature for us. You get that raw data.

46:28: Kostas Chalkias:

So I guess you have a rollup, right? In our case, we don't need the rollup. That's a benefit. Right? Because you want to wait for people actually to form a block with 100 transactions. Well, in our case, every user is acting independently. I don't need to wait for someone else. There is no rollup here. So that's another benefit of SNARKs being able to be executed in milliseconds, more expensive than signatures, but now you can paralyze it.

46:54: Anna Rose:

Aayush, is most of the ZK Email work connected to the Ethereum blockchain? Is it connected to a blockchain?

47:02: Aayush Gupta:

So I would say ZK Email right now is roughly split into 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 whistleblowing, you can do 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... We have to consider very carefully the gas and security account abstraction standards and so on. And if you're doing ZK proofs of email, 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, is this gas efficient? Is this happening on-chain? It's just like, well, no, can a journalist of 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 a public SDK that anyone can build on their own ZK Email proofs, prove any data in their email, that that unlocks an entirely new paradigm of identity, which in a sense is almost unrelated to the wallet stuff. The wallet stuff is very interesting, but that's kind of your authenticating transfer of emails and it's going between different people and that's kind of its own thing.

48:18: Kostas Chalkias:

Aayush I have a question. How do you... You mentioned the rollups, right? Do you run your own rollup for this?

48:25: Aayush Gupta:

So currently we don't run our own rollup because that's a maintenance burden that we don't think is necessary. I think 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 and 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 rollup, so there's some uniformity, but we expect actually like, we could run our own rollup, but we ultimately expect users to want to interoperate with their, say, friends or their favorite protocols or whatever, which all happen to be on maybe their favorite rollup. And we don't think we should be opinionated about that.

49:01: Kostas Chalkias:

I see. Okay.

49:02: Anna Rose:

Do you then have EVM contracts ready to deploy to do that? Like how does one run what you're talking about?

49:12: Aayush Gupta:

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 for self-hosting or you can punt those to a relayer. There's exactly the smart contracts. There's a set of Solidity contracts that includes your ZK verifier, as well as your account logic. 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 trusting someone else's relayer, but the idea is that, this is the thing that makes the UI of the proof generation really easy. 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 of 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.

50:05: Kobi Gurkan:

But you would want to do it for anonymity, right? If you want to do it yourself.

50:09: Aayush Gupta:

Precisely. So if you want to do it yourself, that's probably because you want full anonymity, exactly.

50:13: Kostas Chalkias:

Aayush, out of curiosity because we spent a lot of time to compress everything into less than one million gates, and I'm telling you, it made a huge difference. I mean, one million plus a few gates, actually made our ceremony by far less effective on the browser. But the one million bracket was exactly what we needed to run the ceremony on the browser. How expensive is a proof on your side? How much time does it get at the moment?

50:40: Aayush Gupta:

Yes. So we have two current SDKs. The first one is Circom and second one is Halo2. And these have different trade-offs with client-side proving versus server-side recursive proving versus on-chain verification. And so what we currently do is we say, we prefer that people use Halo2 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 post it on-chain for substantially cheaper execution gas costs as well as proof size. Alternatively, you could use our Circom SDK. In that case, using Circom, you can do a rapid SNARK proof on a server in under 10, 20 seconds, and that proof can directly be posted on-chain, or you can do it client-side. I agree that it would be nice if it was cheaper than a million gates. I would actually love to see you guys' circuits.

51:26:

But currently, the circuits for that are between two to six million gates, depending on the complexity that you want in that email verifier. I would even say between one and six million gates if you have like the most bare bones version of the email verifier. And so in the browser, it's possible, but it's not particularly efficient. It takes on the order of minutes to do that proof. And so this is why kind of Email Wallet is the initial entry of ZK Email into people doing proofs, because we think that by allowing people to do this kind of server-side proof that's punted to a relayer, the friction of that proof gets way lowered. But yeah, I would love to see the optimized Groth16 circuits that you have. It's kind of... I mean, I assume you guys have an RS-256, RSA and SHA-256 circuits and we tried to optimize it a little bit, but I'm sure you guys have some great tricks that I would love to take a look at.

52:17: Kostas Chalkias:

Yeah, indeed. We were also very consistent on the Facebook bias that we had. Nothing should take more than two seconds for the user. I mean, you're losing your user. Like if someone goes...

52:30: Aayush Gupta:

A proof in the browser though, in two seconds, like with a million gates, that doesn't...

52:34: Kostas Chalkias:

No, no, no. We don't do it in the browser, these two seconds. But we managed to reduce the number of gates. So as you said, Rapid SNARK and other offline servers could actually produce proofs in less than a second. 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 one, two 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 period, so the user doesn't even realize they had the zero knowledge.

53:11: Kobi Gurkan:

That's beautiful.

53:12: Aayush Gupta:

Yeah.

53:13: Anna Rose:

Okay, let's talk a little bit about the actual SNARKs that you're using. You talked about the number of gates. Are you using the same ZK system under the hood? Aayush, you mentioned Circom and Halo2. Is it still Groth16?

53:27: Aayush Gupta:

Yeah, so Circom would be Groth16 and Halo2 would just be Plonk. And so, yeah, I guess it sounds like you guys are also using some R1CS-based system.

53:37: Kostas Chalkias:

Yes, at the moment we are also Groth16, but we implemented it in the RISC Zero. We're now implementing it in, for Plonk, like not Groth16. We're implementing it also... I was one of the co-authors of Winterfell in the past, right? 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 Kobi knows better, right? Running a ceremony, I didn't sleep for one month. I was sleeping three hours. It's very difficult to put all of these people into one place and you have to wait. Anyway, so in the future, we want to avoid it. And the main reason is not speed because we managed to have this sub one, two second 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.

54:42: Aayush Gupta:

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, there's tons of tooling, there's things like Poseidon to do trusted setups for you, which is like this PSE tool. And this is why I think a lot of the initial deployments of these are going to be Circom, but I totally agree, we're also excited about building a Nova-based solution. We're also excited about getting the Halo2 stuff audited and into production. And even STARKs eventually, but on-chain verification of STARKs is a little bit trickier. And so I think I completely agree that in the future, I don't expect Groth16 to be the standard that everyone is using. I think there's going to be a much more complex system, maybe some hybrid Nova recursive verification, something going on here that allows things to be super ultra fast.

55:33: Kostas Chalkias:

By the way, I talked to Kobi 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.

55:43: Aayush Gupta:

Yeah, you don't necessarily need to use the KZG commitments.

55:47: Kostas Chalkias:

Yeah, the user can create their own, right? It's authentication. The user can create their own ceremony, but you cannot expect from the user to run 10 minutes in the browser, ceremonies and all of this stuff. The UX is the issue that Sui decided to do a ceremony. Because we had the solution even with Groth16 to avoid the ceremony. Which is great, right? We're preparing a paper around this. Kobi, I might require you... 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.

56:21: Kobi Gurkan:

Yeah.

56:22: Aayush Gupta:

So in this case, the user would have to generate, though, the entire Z key locally on their browser, and I assume that might be expensive.

56:28: Kostas Chalkias:

Yes, the problem is UX.

56:31: Kobi Gurkan:

I do maybe have one response to using Groth16 for now and maybe something that is either setup less 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 woods. But I do think that every update is going to be very, very painful, maybe almost as a setup. Because every time you change a circuit, you have to get it deployed, you have to get it really deeply audited, and I do think that the agility of development is definitely a good thing to focus on.

57:21: Kostas Chalkias:

I'm a hundred percent sure you have some company names in your head now.

57:25: Kobi Gurkan:

Maybe.

57:25: Kostas Chalkias:

Because 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?

57:36: Kobi Gurkan:

Ooh. I hope they do.

57:39: Kostas Chalkias:

I hope as well. I'm not sure. I hope as well. Yeah, so Kobi is right on this, right? When you're updating the contract, people have to, especially in the blockchain space and when you're handling a lot of like big value of assets, every update in theory should require an audit. You can not just go and update things arbitrarily, but audits, Aayush know it as well, takes time, right? It might take you months, 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 use the slots for future requests. And this is what we do actually, Kobi, we're very serious on this, but obviously 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.

58:43: Kobi Gurkan:

Cool. So now that we've talked about what proving system, maybe it would be interesting to dig deeper into what do these circuits actually prove? What can they do?

58:55: Aayush Gupta:

59:45:

So you can run a regex on the subject of your email. You can run 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 an email, 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-256-ing that again with the header and then proving the RSA signature of that matches. And so there's kind of a couple of components here, including this whole 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 a transfer. Like if someone wants to send, I don't know, 10 DAI 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 DAI or whatever, which is what actually, and in addition, the 10 and the DAI are going to be parsed out and then transferred on-chain in order to be anonymous as well. So the 10 and the DAI will go directly on-chain so that those can trigger the transaction and Email Wallet address target will be anonymous.

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 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: 100 USD, for example.

Precisely.

And that's what you would expose. Right?

And there's 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: 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 there's some applications where you don't even need to constrain the body. Like for instance, for the Email Wallets, we only constrain the header. We don't even 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. Pretty much the same idea is happening on zkLogin as well, as you can imagine. Originally, we had to decide between 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, 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 Kobi is for RSA, there is an interesting trick on the xJsnark paper where you can optimize the RSA signature verification. So we're using this trick. So eventually this results to about 15% of our verification being RSA. And the SHA-256 is about 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 I do know it, I just don't know if I know it in this context.

Yeah. RSA is this digital signature scheme that we're all familiar with, right? Yes. The one that we know.

Yes, Rivest–Shamir–Adleman. It's funny actually, so my first exposure to cryptography, there's a class at MIT taught by Ron Rivest on cryptography. So that was how I initially learned everything I know about cryptography. And then, here we are now using RSA, which is pretty sweet.

Anna, the interesting part is at least for JWTs, for cookies, almost all of the signatures today in the TLS world and including 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. And now we need Plonk, we need something else for this provider.

Yeah. I guess that's one other interesting thing is that you guys, for each new provider, you have to make a bespoke login setup with 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 providers, 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 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're checking the root keys of Google, Facebook, Apple, blah, blah, blah, and they're updating it. The main question is if they're still using RSA and if they're still using the structure of the JWT that we want and we can understand in our circuit. You will realize it as well in the future, you will see ECDSA and you will have to update your contract.

Wait, when you say validator, do you mean like Sui validators or is it validators of the system? Oh, okay, okay.

Sui validators. All of the security is based on the same guarantees that you get on the blockchain.

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 we as the ZK Validator will be validating ZK stuff?

Yes, you will contribute into this. Exactly.

Cool.

If they send it with account type five, then we do zkLogin.

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 need to digest it. Are there any differences in the security guarantees between zkLogin and ZK Email?

From what I heard, it seems that there are no big differences. I don't know if Aayush believe something different, but I don't find something now that we're completely different regarding the security guarantees, right? There are differences in the circuits and other things, but they're using a salt. We're using a salt. They're also using some signature verification of the root provider. We're doing the same thing. And they're also using Groth16 as well with Circom. And also they have a Halo2. It's pretty much what we're also doing and exploring. So the nice thing with the general like ZKPs, which is very interesting, is because now the security is on the security of the circuit itself. Because you are using the same algorithm, right? It's not a new protocol that you invent. 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 matter what the underlying system has.

I've seen many protocols that are customized zero-knowledge proofs that they're not using a generic algorithm. These require a security proof, right? An extra security proof. By the way, we're also having a paper as well. I guess Aayush, 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're already reviewed, but you will soon see a publication as well, with this peer reviewed by some of the biggest conferences in the world.

I also think it's pretty similar to me, you're relying on some, the DKIM key matching, 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 and 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, and I'm curious if you have in yours is, for invalidation of mail server keys, because these keys rotate every six 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 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 with JWT is typically they... Like Google, for example, is doing it pretty much every month or so. Some they never rotate. I've seen many providers in the last two years.

I've also seen a few that never rotate.

Yes, never rotate it. Right? So what's happening is it's validator have their own lookup at the moment, and they are also receiving multiple keys that are active. I don't know if it's the same thing for DKIM.

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 validator is constantly checking what are the active keys, plus, when someone is creating a zkLogin request, we're 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 this is how we're also protected even from the wallet side that they might have more aggressive or more defensive, like 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 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 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. It’s 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 going to punt to 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 and 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, and different websites and all of their security parameters and guarantees, because the majority of them use Google, for the most part, you sort of trust 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 in JWT, I guess, 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 Email, if I understand correctly, they can work with all of the email servers in the world.

Correct.

For us, we're picking the companies that are compatible with the JWT, which means that the big companies, it cannot be a random email server. So we're restricting a bit the space here for attacks, but at the same time we have more restrictions on what different email someone can use. And there is a second thing that I realized with some wallets that they support zkLogin, because at the moment, as we said, there is this salt, this salt can be provided to the user through it, like 2FA, if you want, you can add your phone and you can receive the salt in another device, or receive something, a code to access your salt in another device. So even Google cannot cheat. Even if Google wanted to cheat, they have to have control of your phone number plus your email number.

Makes sense. These are really great points about 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.

I want to sort of wrap up our interview with a question about the sort of ZK-ness, both have ZK in the name, are these private systems? So far I think we see a lot of the practicality of it being very easy to sort of onboard a new user and to have them without knowing what's going on behind the scenes, like use sort of their Web2 logins or Web2 things, emails or what have you. But yeah, is there a privacy component? I know there's a SNARK, but is it private? And I know there's sort of anonymity, but yeah, I'm just curious if this is actually a private system.

In both cases, I believe that that's the plan, right? Because in theory, in JWKs, as I said before, we could publish the cookie itself. And then the system would still be secure, but you are revealing your identity. So we needed ZK to hide the identity of the user. And then we also needed ZK because we are also providing this extra feature. Sometimes you want to prove something about your identity, but not your full identity. You're proving you are a 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 guess you're also using Groth16. 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 a cookie, there are some cookies that might be big, and you don't want all of the cookie or all of the email to go on-chain, obviously. So we're 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.

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 compression of the amount of input data, like instead of having to parse the entire email header in, you don't have to parse in specific public words. And in addition to verification content, having 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. 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 this one time addresses or whatever you're using, and I indeed know that you're my users. It's not like your random users out there. So we will see some applications with selective disclosure of information going public as well. So yes, there is anonymity, Anna, but there is also this thing that some people might want partial anonymity or other types of privacy.

This is very cool. I'm actually in awe of both systems and just the in general thing. Like it's sort of opening my eyes to what kind of how wide reaching something like this can be, the type of things you can do once you have a system like this.

Aayush, by the way, now I'm curious, right? How can I use your system today?

So we have a testnet demo right now in emailwallet.org and hopefully we'll have the V1 with all the decentralized relayers and there's a number of features that we added including the private key invalidation.

Is it the real testnet? I mean, are you planning to have a token?

No, there's no token. So right now it's just on a normal Ethereum testnet like Goerli and Sepolia and eventually, we intend for the V1, basically, with all of the features to be on the mainnet. Hopefully, you'll also be able to access that on emailwallet.org.

Okay. But this will be a for-profit product, right?

Right now, we're positioning this, so it's funded by Ethereum Foundation PSE, one of whose mandates is don't release for-profit products. The hope is that, at least for now, this is released almost like a public good, in a sense, where we kind of expect that different people will run different relayers, and we expect that, maybe some company wants to run the relayer and they kind of want to say, look, 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 zkLogin, as I said, is on the foundation side. It's a primitive on Sui. So what's happening is we opened the door for wallets to use it. Right. So everyone in Sui can use this particular primitive to have their own business, but as a product, it's similar to you, right? It's an open source in Sui and everyone can go and use it.

It's so friendly and public goodie.

Yeah. And I think there's another 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 public good.

Yeah, I guess you 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 in fact, expect that both of these, it's not too hard to port to any other chain. Like you can kind of... It's just a change in the verification logic, and I actually expect the system... I mean, the really difficult part is getting the ZK proofs to work consistently, but the verification is completely modular and composable. 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 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 differentiate one another, although I realize it wasn't necessarily done on purpose. But there does seem to be different use cases or different communities that might be into some, 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. Obviously we ended up into similar ideas because that's the way to do it, right?

They are good ideas. It's funny, yeah.

Yeah, thank you both. It was super interesting and I'm very much looking forward to see both of these deployed.

Yeah.

Oh, I have one quick question about a difference between the systems. So in our case, one thing that we have is when you send money to someone, that money is 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. I guess, I'm curious if you guys do the same kind of unclaimed fund, unclaimed state in the JWT wallet.

Okay, this is at the product side, right? Because we're talking about the primitive now.

Yeah.

Yes, but products on top of it like zksend.com which is using zkLogin, at the moment you can send fund to someone with private salt and so on, they can claim it. But there is also a version that 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, we have the exact same thing.

So it's literally, and one out of two things, right? Not automatically you have to go and claim it, but it goes back. Is it the same with you?

Yes, it's exactly.

I'm telling you, convergent evolution again.

All right. Well, thank you guys again. Thank you so much for coming on. I want to say thank you to the podcast team, Henrik, Rachel and Tanya, and to our listeners, thanks for listening.