ZK Email: Fast Proofs and Production-Ready Account Recovery | Devcon SEA

[Music] [Music] today we'll mostly be talking about ZK email new applications and production ready account recovery I'm aush I'm San and most of this work was only made possible because of this incredible team of folks we have working with us so huge shout out to them so we'll start by mostly going over the basics what is ZK email how does it work then we'll dive a little bit into how you can make proofs really easily and we'll discuss a new registry in SDK that lets you do that and we'll try to expand the possibilities for how you think zkl proofs can be used in reality finally we'll talk about account recovery and how you can generally have email triggered transactions on chain and last we'll talk about Dev tooling all the different ways that we've put together tools for people to build these kind of proofs really easily into existing apps so to start with the basics what is ZK email the idea is that emails are signed according to the deim protocol an RSA signature of the shot V6 of the content of the email this is applied to every single email sent to reive since 2017 usually used for spam filtration but we prove this inside of a ZK proof and add selective disclosure and parsing this means that we can get proofs of emails where we can get privacy as in we can hide or reveal whatever we want we get Providence we can verify the data from the web two Services mail server directly and it's portable we can verify it directly on chain on any any chain that can verify these proofs you can imagine the simplest intuition for this is something like whistleblowing we take an email you've already received and we redact different parts of the email and then we prove that the email was still valid or sent by The Source but you can do much more than this for instance ZK PP builds marketplaces on top of these emails one example is a domain Marketplace the idea is that you can take any name Che domain that you own and you can list it on this Marketplace and when you sell the domain to somebody AK you transfer it to them both of you receive a confirmation email from Nam CH automatically if you prove that confirmation email on chain you can then unlock esro money directly to pay for that domain this is quite compelling and the idea that can interoperate these web 2 assets or things in the real world with things on chain is extremely compelling and how can we get more of these so our idea was what if we made it really really easy for somebody to create new proofs and update those proofs so we'll talk a little bit about how this can be applied uh to General proof infrastructure in a couple of different ways a registry that lets you reuse proofs that other people have already defined and Define new ones very easily and SDK lets you use them very easily in your application and find finally some inspiration around what are some apps that people are actually building with this so one of the main problems with ZK development today is that an app developer who's trying to build something related to their emails should not have to think about the nitty-gritty details of which proof system they're using and the different trade-offs and different systems so the idea is you can abstract this all the way you just Define a sort of a blueprint like oh I want to prove that I was rejected from giving a Devcon talk for instance and then if I Define this kind of blueprint anybody can use it without having to think of the proof system that's happening in the background how does this work well the idea is you can create new patterns very easily for instance after naming your pattern and uploading a sample email we can automatically parse out the relevant information from that email to help Define this new kind of pattern for instance we can take out the center domain automatically or things like the email length of the header or the body then we have this nice feature where because we want to define a Rex to extract specific information from within that email we automatically throw an AI on top of that raw email data and Define that Rex for users we found that historically this has been a bit of a roadblock because having to adapt Rex's to odd different kinds of email templates is often not a very intuitive task but we're hoping this makes it super easy for anyone to define a new kind of proof with no relevant ZK or necessarily even parsing experience and finally it'll give you a configuration like this this is a decent amount of text but the main thing to take away from this is that it's only about 20 or 25 lines this defines all of your rexes where they occur and who the email was sent from and other metadata about it but this is a full encapsulation and definition of your proof then in the background we can automatically compile this to all the proof systems that we listed right now we have circom and Noir incoming and also ZK VMS um and once it's completed the compilation is completed we automatically will deploy an interface that anybody can use to create this proof we see this kind of like almost like a bit of a versel you can sort of create your proof and deploy it without having to think about any of the infrastructure behind the scenes concretely for instance for the proof of Devcon rejection you will automatically get an interface for you where you can automatically sign in with your email and then it will fetch the relevant emails that might possibly satisfy this proof we can filter those emails entirely client size that our server never sees those emails and then let the user choose the proof they want to select to make a proof of in this case for instance for GitHub uh for Devcon you can choose one of the specific Devcon rejection emails or for GitHub you could choose for instance uh a GitHub username email to let you prove your GitHub username finally the proof can happen in the background and you can share that proof out to whoever you want to share um and we also show you the metad data very clearly and even let you look at the raw proof the idea is that once we have these kinds of definitions we can expand this even one step further we can also kind of treat it like a bit of a GitHub where each of these configurations can be edited and Modified by other people and you maintain a version history so for instance you can imagine that each of these patterns comes with versions depending on email templates as they change or users as they want to parse different kinds of things and if you decide hey I don't like this pattern I want to replace it with a different one say I want to take my Devcon rejection email and instead I want to prove Devcon acceptance I can just Fork it change that value and recompile it and so we see these kinds of flows that developers are very used to also being useful for General people to be able to create these new kinds of proofs you can try this out live if you go to registry zk. um we've put a QR code up um these you can define a new proof by logging in and then creating a new pattern or trying any of the existing ones within the interface um note that there will probably be a decent amount of load all the folks in the audience try this but we will have a workshop tomorrow where we go through detail uh step by step how exactly to do this now if you want to integrate this into an actual application again you don't need to read the code but just the idea that this can just be three or four lines someone can just Define this is the kind of blueprint that I want to prove within my app in this case the Devcon rejection proof they can say if they want to be local or not and then they can again you don't have to read the code but they can just generate the proof and verify it on chain if they want without having to think about the proof proof system we've seen people build a lot of really exciting stuff with just this primitive for instance folks have built proof of U sign or hello sign where you prove you signed some document with some title from somebody can prove you took a flight to from so and only reveal where you took it from in the destination someone created this proof or you can prove you're part of a slack workspace you can now start seeing how these things might start combining you can build a system where you prove you're part of an organization on slack and then you automatically get reimbursed for your flights by proving you took them and as people start realizing oh you can bolt these things together you can build actually interesting systems on chain where you combine different facets of ideas or identities or actions we've taken in the real world people have also proved for instance you've exported your LinkedIn data which they then sell to for instance openai to train on you can then prove you exported all of your openi chat data and then sell it to for instance anthropic you can also prove you automatically resolve the GitHub issue and then automatically disperse contributors for their contributions John did this fund proof where you can prove you ordered a pad Tha in Thailand where you basically show you have a grab receipt which has the word Pat Thai on it and a location that's in Thailand and of course you can prove that your proposal was rejected from Devcon so now that we have all of these basic concepts around how you can make proofs of emails that you've received in your inbox one might imagine that you can also make proofs directly on chain so far we've just talked about severe identity that already exists in web 2 but emails you can imagine are an interesting interface to actually interact with onchain apps directly so concretely how might you get this new kind of email triggered transaction well the idea is that instead of doing what we were doing earlier where you log in with email for instance and you select one to make a proof of you instead send an email to trigger a transaction on chain this is quite interesting because now you can have a smart contract that's directly gated just by a sent email this primitive is quite powerful you can build things like account recovery for instance where you add emails as wallet Guardians directly on your existing smart accounts things like email signers where you can add an email directly on your multisig and have that approved transactions for instance as a TFA or for folks who don't have eoa wallets to be able to still approved transactions you can log in with emails this is something folks have wanted in the existem for a very long time but the idea that you can interact with aage application or crypto app just by logging with your email and then using that to authorize an Emeral session key or an email wallet where you can receive assets directly to email addresses even if they've never signed up but today um we'll mostly focus on I guess to start with exactly how we can do these kinds of smart contracts with emails so for instance the flow here is is that users can receive some email asking them to trigger some kind of transaction and by replying to it they can initiate that transaction on chain They will receive an email kind of like this we've moved the actual value that's getting approved to the subject so it's easy for you to read um but the idea is that you would receive a command kind of like recover account eth address from Old owner eth address to new owner eth address in reality users would just see a simulation in their email not this text but we've put it here so it's easy to read and the idea is that by replying to this email they're effectively signing this message which can then be used to send onchain flow here is that a user will try to trigger some sort of transaction a relayer will send them an email when they reply to that email action is then sent directly by the relayer on chain as they make a ZK proof of that action one of the cool properties of this is the idea that we have this account code for both privacy and decentralization you can kind of see again we've elevated it into the subject here but normally this would just be embedded into the body where the user doesn't have to think about it but what is the point of this long hex string it's not really private key or something we're necessarily exactly used to and anyways it's abstracted away from the user but it is nice because this value gives us direct email address privacy on chain we never reveal the email address we only ever reveal a hash of the email address and that code we can also prove availability to the user in this email that is concretely we can ensure that the access to the user's account cannot be withheld by us going malicious because as long as they have the account code they can still transact with that email contract and finally it allows for relayer decentralization anyone can run this kind of system can run email servers that send out emails receive replies and then trigger transactions on chain you could imagine this can happen via email replies as it does right now or even directly via Google logins the difference between these is mostly basic security for instance on the side you can show concrete simulation data to the user of what they're signing for Google signin it's more like a blind signin uh and a blind signature but the idea is that applications can choose whatever they want based on what is most convenient for them okay so from now our among the products using email trigger transactions U here we introduce the details of the email account recovery so in short using email account recovery you can specify anywhere with an email address as a guardian for your wallet and when you lose access to your private key this Guardian can help your account or this Guardian can help recover your account just by sending emails and in this way this achieves a similar ux as a a bank account or PayPal such that user can reset password from their email account and we also believe the combination of the email account recovery with the pasy wallet is makes a super easy wallet ux uh because pasy allow users to sign transactions through the face ID and so and even and when user lose a device or we you user can use email account recetly to recover your recover users account on the an Dev so from now we explain the details so how email account details of how email account Rec works with showing the UI of the email account Rec feature in the C wallet we are building now so in the first step the user configures recover setting or such as Guardian guardian information so in the C Ur the user just needed to specify the guardian email address like this one so in the Second Step the guardian will accept this request so the guardian will receive an email like this one from the relayer and if the guardian can approve this request the guardian just need to reply to this email and the guardian will finally receive an confirmation email like this one and in this process our Guardian actually generates DK proof of the guardian's email and send this email proof onchain to register Guardians address and once once the user loses the access to the private key we actually start the recovery process so in this process Guardian uh the word user puts the email guardian's email address again and the guardian will receive an email from the rayer in the same way and the guardian if the guardian approves this recovery request the guardian will reply to this email and Rees the confirmation email and in this process the reer similarly generates de proof of the Guardians email and in the first in the final step step in the final step or Guardian the wallet user can complete this recovery request once more than slh hold number of the Guardians approves recovery request however there's a time delay before before completing this recovery request and this improves the security when the Guardians email account is hacked because wallet user can cancel Pro cancel Rec request or if the email account is hacked so in this way we can keep the security and the accessibility of the users account as long as the the user can access to the private key or emails the guardian's email account is honest sweet so we have those account recovery deployments audited and live on mainnet for both clave which will roll out in the clave wallet over the next week for pasy wallet and also in our recovery UI for safes um but this can be larger than just a couple of wallets the idea is that any smart wallet can integrate this into their wallet and so we've created a bunch of Dev tooling to make it really easy for anybody to use these kinds of proofs concretely for instance a recovery module is a 7579 compatible smart account standard this means any wallet is really easy to integrate with uh this specific account recovery and even if you're not 7579 compatible it's still quite easy to add account recovery to your wallet we have a set of very simple apis that users can call again you don't need to read all the details here but to trigger each of these requests you can simply hit each of those apis and your own wallet or your own application can trigger any of these kinds of uh transactions directly and finally installing it to any kind of wallet in a front end is also very easy again you don't have to read the exact code but just the idea that installation is just five lines in for instance the permission sjs uh smart wallet creation interface you can read more about it on our docs on the right side we'll have more links the end if you want to Define your own kinds of proofs not account recovery but say any of the other application ideas you can Define your own kind of pattern in solidity directly here we show that you can say something like recover account eth address to new owner eth address once you've defined this kind of solidity code you can then hit any API that any of your layer has deployed the API request looks kind of like this again the main thing here is it's just about 10 lines and it will automatically handle sending the emails for you getting the response making the ZK proof and sending it on chain you can see again these docs for how exactly to build with the dev tooling over here and we'll have a workshop tomorrow where we go over more of it in detail um so for instance uh you can imagine this abstraction can be used to build account recovery email signers login and the email wallet primitive we talked about in the beginning but we're excited for folks to explore with kind of email Tri trigger transactions to build more different kinds of things so just to quickly recap we went over the very basics of how ZK email works and simple kinds of proofs you can make how to make new kinds of proofs very easily and access them from a shared registry then switching from making proofs of received emails to making proofs of sent emails we went over how you can do email trigger transactions and then account recovery and finally how we've made this really easy for new folks to either directly use or integrate directly into their wallets or projects Etc we're super excited to jam more with folks if people want we'll have some boots um specified on the left you can catch us there after this talk and also over the next two days and if you want to learn more about how to specifically use these tools in your applications we'll have uh a concrete Workshop tomorrow at 1:30 p.m where we go over how to actually integrate each of these things um directly with help from the team who actually built it sweet so if you want to read see or hear more we recommend following our Twitter on the left side looking at our homepage in the middle on zk. Emil and if you want to view an original copy of these slides you can scan the QR code on the rightmost side sweet thank you for coming and we'll take some questions sweet thank you a shant that's was a very interesting talk by the way all right yeah I like to see zkps being used for something else rather than Z ZK OLS right and it mixes both web 2 and web three so we have some time for QA so how about we take um the first one so it says what zkp framework you are using and why yeah it's a good question so we've used and benchmarked all of the Frameworks that um we kind of listed in the beginning we have versions in circom and now Noir and also now in Z kvms like sp1 and RIS zero um we generally so because most of these things are happening on for instance main Nets we want to make sure that there's both high security and extremely high speed So currently we use circom on the service side and also on the client side just because it's kind of the main one that's very main net ready right now and also can prove extremely fast on the server side and within like 5 to 10 seconds usually for most of the proofs we're talking about um but we intend to work closer with Noir to get those client side proofs working in Noir and closer with the zkm to get much more sensible proofs on the server side yeah that makes sense actually by the way you can up vote the question so that we can see those that you up upvoted first here on the screen so maybe or if we take the second one would trusted situp ceremonies ever be required if so when yeah so this sort of depends on the exact proof system you're using if you're using the circon proof system we have in production right now then yes you'll need to do a trusted setup um however if you use the Noir system on the client side we're moving to or the zvm systems on the server side that we also have um then you won't need to do a trusted setup for that specific circuit um yeah so we have two votes uh yeah maybe this question so is there any prerequirement for an email to be ZK approved um not really any email you've sent to receive can usually be ZK proved because all emails require this DM signature to go through spam filtration um there are some restrictions like for instance hot mail is not exactly pursuant to the standard so some things that you can't access a two email within a Hotmail email but in general almost every email that you send or receive can be proved okay got I think we've still got time for more questions yeah um yeah maybe this one when we can see I think we can see them also here I guess the top one is there a key rotation problem uh yes so the public keys that the deom uh verification actually happens with are rotated every maybe 6 months to two years for some folks never rotates um the nice thing about this is that the smart contract that holds those keys is publicly auditable anybody can go in and say yep those are the keys that my DNS is fetching as well um but yes to relay those keys on chain there has to be some sort of a system of Oracles in our case we use like a specific multisig in which all of the like a bunch of autonomous computers are calculating those and putting it on chain and you can also double verify that with for instance an ABS TLS notary or TLS proxies to ensure that all those values are correct the important thing here is that you can use a single public value that DNS value to verify private data and that public value is auditable so the idea is that if there was ever some fault somebody pushed malicious keys there are enough time locks built into the system uh and also ways to to stop it or ways to uh override those key Registries for each user that we think this is not actually that big of a problem in practice that makes sense thank you for the detailed question uh answer um yeah so maybe why if we take this one since DK I private keys for the whole domain rather than the than Pender presumably the security model realiz and we don't see the question anymore yeah um so so I mean I'm just repeating the question for the live stream so that people uh yeah so the origin MTA preventing Cent proofing within the domain yeah so the the idea here is that yes because you're only verifying the signature from the domain you are trusting that that specific domain is in fact like disambiguating senders correctly the nice thing here is that most email providers that most people use like Gmail Outlook iCloud Etc definitely have this in by default because it' be very bad if they didn't but we have noticed that some folks don't so for instance we disable um most edu domains uh from most of these models because often they don't have very good uh parsing of this kind of which sender exactly in the domain sent that email um but in most cases for instance that you received an email from Twitter or Devcon or whatever uh usually you can constraint exactly the the email address that sent it and that's usually good enough and they're usually using something like Google workspace so it's usually possible and in the context of the email trigger transactions uh while this depends on the earth private key of the specific email or de de or server like Gmail uh we believe this achieves the or better thread off between the ux and the security thank you so I think we are on time uh please thank again aush and Sora and please upload him upload them for for their talk [Applause]