ZK Email

Yep, I work on ZK email. Um, and I guess I'll just talk about briefly what we'll be focusing on in the next few weeks. Um, so one is, uh, we have this little nice registry where anybody can go define proofs in like two minutes. You can just say, oh, I want to make a new proof of this kind of email. Um, and you can basically go in and define it.

And then what ZKML does in the background is it creates a new kind of ZK proof that anybody can trigger that allows you to prove that you sent or received any email by verifying the cryptographic signature in ZK. So this specific QR code goes to the proof of DevCon rejection where you can prove that you had a rejected DevCon talk, which will then give you a secret ticket to an event that one of our partners is doing in two weeks. So if you go prove that you do, that you had this rejected talk, you can come to that event, which is going to be pretty sick. So I'll let folks scan this for a few minutes. And so for the next few weeks, we're going to be both, like, adding new patterns to this.

I think at this point we have something like 25 patterns already. Fixing bugs and we're rewriting the backend from scratch. Cool. All right. People have scanned, okay, cool.

There's like two or three more slides. Okay, what else are we doing? We redesigned our website recently, so we're gonna be actually building this and putting this into production. So you guys get like the first preview of what it looks like. Okay, what else are we doing?

Right, so we have, for people to do email proofs in Solidity, we have this like nice little library where you say, oh, I want to specify like some strings that look like recover account, ETH address to new owner ETH address. And you can just write that in Solidity and then call this API request. And then we will automatically handle sending the email, fetching the reply, making the ZK proof, and calling your Solidity function. And so we were trying to get some Solidity devs to experiment with this. So if you wanted to find a new ZK ML proof on-chain, it should be super easy now.

What else? We're exploring a little bit with, like, JWT keys. So a lot of folks have wanted, like, sign in with Google for crypto, but in a totally decentralized way. And so this is one of the things we're releasing. We're also working with the Noir team to make these proofs faster client-side.

And this is going to be kind of interesting. And so the hope is you can get, like, totally decentralized login with emails. I don't know where Cherry went, but that might be useful for them as well. What else? Right, so we have this account recovery product where you kind of can, if you have like some smart wallet or any existing like wallet, you can add emails as your guardians and then use those to recover your account.

And in the background, it uses the email so nobody, no like centralized server has control over your account. And so we're planning on releasing both with Clave on mainnet and hopefully with Safe on mainnet, but it's kind of, we, yeah, it kind of depends on how fast they're willing to move. But everything is audited, and so we should be able to get that up live soon. Yeah, so big team, a lot of focuses, but hopefully we can get these all done by the end of the residency and DevCon, yeah. Like how do you want, you mean like how do you want like Edge City folks to use the tech or?

Just generally. Hmm. Yeah. Right, right, how do users actually use this? The idea is that, for instance, for account recovery, inside your wallet, you would just say, oh, I want to set this as my recovery email, and then we would handle everything in the background.

And so the idea is for this, you would interface to it, through it, through your existing wallet, whether it's on Safe or Clave or wherever it is. There's like a couple other wallets we're working with. And then how would people actually use this? Like this would be integrated. This is like kind of a demo site, but you'd imagine that someone would just integrate like our sign in with Google button, and then we would generate the ZK proof in the backend automatically and log them into the website.

And so, again, people would interact with this just by an invisible login in the background of their website and they wouldn't have to think about zk-email ever. It would just work in a decentralized way. And then how would people interact with this? This is a more dev thing. If people want to do Solidity, build Solidity apps with zk-email, then they would interact with this and the users would use those apps.

And then for the proof one, anybody can go in and design a new proof. We'll be doing a workshop tomorrow at 2 p.m. If people want to come, let me know. Or people learn to define your new proofs, and then we automatically deploy all the info for you.

And so it would be exactly like the folks running the conference for rejected DEVCON speakers. They would just do exactly this. They would define the new proof and then ask people to either hit our website or integrate the API endpoints into their own website. Yeah, but it's a good question. Like, how would, like, users actually, like, interface with this tech?

Yeah. What is the, like, tech side of the website? Are you totally on Aztec? Yeah, so it sort of depends. So Aztec is, like, totally unaudited, and so it's only going to be mainnet ready in about, like, nine months or so.

And so currently for all of our mainnet applications we use Sircom because that's the one, like the tool stack has been audited multiple times and our circuits have been audited multiple times. We're waiting on audits from the ZKVMs as well. So it's kind of like, the idea is that this, you define some new pattern and then that'll get compiled into Sircom Noir SP1 and then for Noir we won't let you deploy on mainnets. And then for SP1, until it's audited. And then for ZKVMs, we'll say, also, I think their audit is finished in November, December.

Once those are finished, then we'll also allow you to deploy those. But those are basically the tool stacks we work with.