 We are going to start with a quick demo because the Wi-Fi here is not fast enough, so we're running this remotely, and so we're going to begin that right now. Yeah, so we have a UI built up. It's pretty primitive, but the idea is that it, we know ZK is not efficient now, so it's going to take a couple of minutes to run this proof, so hopefully it works. I don't know if this internet is going to, oh, it did click nice. So we're going to let this proof run, and then we'll come back to it some point later and see if it's generated. And we'll explain everything that we just did. But yeah, I'm Sampriti. I've been hacking with 0xpark for the last couple of months on your knowledge proofs. I'm Ayush. I'm also hacked with 0xpark for a while, and now I help run Persona Labs. And I want to say this project has a lot of people behind it. We've used our work from a lot of open source libraries, a lot of people who've helped us behind the scenes. And these are some of the names who are also in the crowd, but we can't mention all of them, so thank you to everyone again. So today we're going to talk about trustless email verification on chain. It's trustless in the sense that we don't run our own server, so we don't see any of your private data. But at the same time, we are trusting, because this is an interoperability protocol between Web 2 and Web 3, we are trusting mail servers and DNS to be operating as they should. But we do not operate any of our own infrastructure. So what exactly is proof of email, or a ZK email? Well, every time you receive an email, you have to know that it came from the source that it claims to be coming from. And so I might imagine a great way to do this is signatures. So what they effectively do is every email you receive is RSA signed with the SHA-256 of the from address, the to address, the subject, and a body hash, along with, and this entire hash is RSA signed with the key belonging to the email mail server domain. So you can imagine that if a user provides this header or the signature of an email, then, and we verify it in zero knowledge, then no one, including the mail server or a key stroke tracker on someone's computer, can verify that someone is using this protocol. There's some small email quirks, not everything works like this. Gmail doesn't sign self-emails and didn't even do this till 2016. Hotmail doesn't include it to field. And mail servers have slightly different bit keys. So the specific demo that we have prepared today is trust us Twitter verification on chain. The way it works is you get a Twitter reset email into your email from twitter.com. We then create a ZK proof of this email. We effectively reveal only the sender domain, which is something like verified twitter.com. The RSA modulus, which would be from the DNS record of Twitter. And the masked email body, which only has in zero knowledge the specific keys that we want to release. So like in this case, it would be, for example, it says this email was meant for use G right here. So we could kind of use that to extract that part and like use that as like the username. The things we want to keep private are all the information that does not relate to what the user wants to release. That is specifically the entire decim signature would denonymize them because the mail server would know who they are. The length of the pre-hash message data or general lengths that we pass around to ensure that computation is efficient. And all of the raw data. So the raw message data, the raw sender data, the identities that everyone involved. In the circuit, what we do is we check that that decim signature that we showed you earlier verifies the shot hashes verify the RSA signature is verify and that all of the text is well structured in the message. And this requires a little bit of reg X parsing. Finally, in the smart contract, we verify all the things that are very either very expensive to do in a snark or have to be done on a decentralized layer. So things like verifying the sender domain is actually the sender domain that people trust and verifying the claimed RSA key is an RSA key that people trust. Let me go see if the demo is done. So it's still going on. So I'll just talk about some of the innovations that we did. So obviously, one of the things you noticed was reg X. And we also had to do a bunch of shadow 56 inside the proof. Now, since we want this to run in the browser, obviously, we don't want people to have to send their email to a private server that we own and then we run the proof. So everything has to be done in the browser, which means it has to be very efficient. So we had to use some tricks to make sure our proof runs within a reasonable amount of time. So one of the things was shadow 56 hashing. So we have this really long email body. Let's say the one that Twitter sends us is 16 kilobytes. And if we try to just hash that entire thing in, it'll take millions of constraints. So what we realized was we could only take the part of the message body that contains the username we want, which is, for example, the Twitter username, which is at the end of the circuit. And we can only do that part of the hash inside the circuit. And we can hash the first, let's say, 10,000 bytes of the message outside the circuit and pass it as a private input. Now, this doesn't really break any security guarantees since we still check that the final hash is equal to whatever is signed by the mail server. And if you could break this, then you would basically be calculating a preimage for the hash. So it's the same security properties, but we don't have to do as many computations. The other one is obviously verifying regex. So email headers and email protocol is a very tricky thing. So email is a very tricky thing where it can be in many different orders and there's no specific structure. So it's hard to verify that within a snark and just using if-else checks. And obviously the first thing that comes to mind is kind of like when you try to parse the email addresses to use a regex. So that's kind of the most simplest thing that would provide more security. But there's no obvious way to do a regex inside a snark in an efficient way. So the thing we used was there's a way to convert all regexes into deterministic finite automator, so which is basically like a graph. And it's kind of like an automator graph and you traverse the state. So for example, each edge has kind of like a letter with it. So if the letter is h, then you go from one to two. And if there's a e after that, then you go from two to three. And obviously at any point, if a letter doesn't exist, then you kind of fail and you just go back to the beginning. So in this case, if we get to the last state, which is 12, then we accept. So this is obviously like a very simple regex for hello world. But we can kind of build a more complicated regex which is for like checking an email header. So for example, checking that there's a to and a from and it is like valid according to the SMTP protocol. And we can kind of check that and make sure everything matches. So and using this also, we can kind of use regex like what is it called? Catch groups or something like that to reveal what we want. So in case we just want to reveal the domain which is in this case, 0xpark. But in the demo we want to reveal the Twitter.com. So we'll see how that happens. So the regex for this thing is like a huge graph. So obviously I'm not manually coding that in Sercom. So we did some tricks to like automatically generate Python Sercom code given like a graph. And you can see in that slide on the right side auto-generated Sercom code. It works. I don't know how it works, but it works. All right, let's go back to the demo. Hopefully it's done. Oh no, I have to type my password on screen. All right, maybe we don't do this. All right, I still have a like kind of like a video showing the same thing. Because trust me, this is exactly what happens. So after we go through all of this. Okay, I'll type my password if you guys don't believe it. Okay, but maybe at the end. So anyways, as you can see, the proof got generated at the end. And this proof is obviously something you can send to the smart contract. And it also gives some extra data, which is like the public data that we're talking about. So I'll just let this play here. If this, so as you can see, like we have all the extra data masked out and only the things we want to show. So like for example, Twitter.com to Gmail.com. And then if we go down to the end, we have the username, which is usually username from the circuit. So those are the things that only the public input from the circuit and everything else remains private. And since all of this was verified using a proof, you can kind of, if you submit this to a smart contract, you can verify that this was indeed actually something that happened. So some precaution of this technology before we dive into specific use cases are that this enables a tragedy of the comments on institutional reputation. Now what this means is that using ZK email, you can prove trustlessly that you're part of some organization and post or act on behalf of the organization without spending your own personal reputation. And as a result, for the first time effectively ever, you can spend institutional reputation and have no cost to yourself and no personal accountability. It is quite dangerous. And so we do think it's important to have something like ZK nullifiers or different mitigations to think about how to release this technology safely so that we don't enable this degenerate spiral. One second thing to think about is liability. It can be argued that you want to be able to argue at some point in time that you can deny that you sent an email. And so the way that a lot of mail servers do this is every year or six months, they'll rotate their mail server keys and release their past keys. And some of them will even release the past secret keys, meaning that if you get an email more than a year old that someone could have easily forged it using that secret key that was released. And so this poses problems both for the scheme, but also is a good question of do we want to enable and encourage this or do we think that this is something that we should hold people accountable to for a long period of time? And finally, one interesting thing is that if we want a nullifier, that is something that would avoid people from claiming again and again and again their identity on chain or possibly selling this identity even, then we have to allow a nullifier which is derived from the information in the email. But this would allow the sending mail server to de-anonymize someone. And so there's a trade-off here where you can either have uniqueness and anonymity or you can have the mail server able to de-anonymize the people who are interacting with the protocol. So I'm gonna talk about a couple of different applications you can build that require no server. You can build something like proof of personhood. And one way you could do this is you can verify in zero knowledge that someone received an email from a KYC provider that checked their KYC, but you don't reveal any of the information about their personal information or the KYC information. And thus you can prove that someone was an individual human but not reveal who they are. You can do something like have Edward Snowden release the NSA emails on chain and prove that they came from the NSA but not that he was Edward Snowden. You can do something like proof of company where you prove that you work at a certain company or a certain domain and you mask out all the rest of the information enabling something like ZK Glassdoor or ZK Blind. You can do oracles. If oracles send emails to you with information say price feeds or any other information that you want on chain, you can simply verify these email headers on chain and not have any centralized server that you trust or decentralized network of verifies that you have to trust to accurately represent this data. I can keep going on and on but you can imagine that any data that you can have in an email you can verify on chain using this primitive. This is extremely powerful for decentralized and anonymous applications and we think this is gonna enable a whole new era of ideas. Proof of residence you can do by proving for instance you have a gas bill or a water bill, the oracles, Glassdoor. And the number of anonymous groups you can create is also quite unlimited. You can prove for instance groups of people who have 10 million Twitter followers or people you can prove that you made some call option on Robinhood that went really well or you can prove that you have some dollar bill bank account, dollar bills in your Chase account because Chase actually sends your balance to you in plain text if you request it. I just wanna point out one thing is like right now the one thing we have to rely on is DNS so either we hard code the DNS keys the keys in the DNS in the contract where we get it from chain link. Now if only we had something called DNSSEC which had actually taken over we could have actually done all of this in a contract because we could have just verified the certificate like to the root trust but unfortunately nobody ended up using DNSSEC so we can't do that. So if you're interested in any of these primitives we're working on them at Persona Labs and we'd love if people reached out and were able to help us or we're interested in talking more we think this is a very fascinating interesting space and it's gonna rapidly change how we think about decentralized identity over the next year or two. If you want to see more updates about proof of email including. It's not that weird but eventually. Eventually. If you wanna see more updates about proof of email including our website or open source code and experiments as we release them we recommend following us on proof of email and our front end where you can generate your own email and your own ZK proof from an email is live at zkemail.xyz. The user flow is you have to go through these four steps but you'll notice that there is no sending to server involved. And we had a great brainstorming session in the morning in which we got a ton of these ideas together so kudos to all the people who came to the morning session and helped us come up with the ideas that you saw earlier. Awesome thank you so much and we'll take any questions. Thank you. Do we have any questions? So the NSA example is cool because it's like oh Edward Snowden could have done this without revealing his identity. But on the flip side a Russian spy within the NSA could also just reveal all of the NSA's information and never reveal who they are. How are you guys thinking about how to prevent stuff like this from happening or what safeguards can we build? Yeah this is a great question and this kind of comes back to the tragedy of the comments point that we brought up. I think part of this is that you have to enable some amount of accountability ideally in these situations and this can come in the form of say like upvotes and downvotes where if certain, if you have like say an LFR associated with a certain account or certain address and this account gets a certain number of downvotes then you can hide this from feeds that are being shown to users. So although the data will forever be immutable on chain from the perspective of users who might benefit from this or get harmed by this you can at least do your best to shield them from it. But part of it is that it might be very difficult to solve these problems and it requires a lot of thought to think about how to do this very carefully. That's a great question though. Who's there one over here? Okay thank you. I'm from Unipass and finally somebody discovered the emails. We are also using emails as a proof of ownership of the smart control wallet and my question is how is the cost of the ZKP on chain? Like you know you have to verify RSA signatures, you have to verify ZK proof. So we are building the same solution so I wonder what's your benchmark now? Yeah. So right now since we are hard coding the DNS keys we don't actually have to verify any signatures on chain. So the only thing we verify is obviously the verification of the ZK proof which is a grad 16 proof and usually that takes about I think like 400, 500 K gas. It's a constant time thing. Yeah 400 K right? Yeah 400 K gas. Including the RSA verification. Which RSA verification? You have to verify the DKM signature right? It's RSA signature. Oh that's verified already inside the circuit. From the VP. Yeah. ZKP covered this right? Yeah that's all verified inside the circuit. But why you have to put the DKM public key on chain? Because then anybody could just take any random like RSA key and just use that to sign their own header. So it's just like a DPKI right? Availability purpose? So what do you say DPKI? DPKI is a centralized public key infrastructure. It means you just put the public key on chain to like others can verify. Yeah yeah exactly. And the contract also. They can verify with a simple HTTP request actually. Yeah so like our front end just makes a DNS request to just check that. But yeah but like on the smart contract we have to hard code it or we could use a chain link or a code to fetch the DNS as well. So I won't take too much time. We can talk later. Yeah.