Recently, I’ve been getting more and more interested in how we could bridge web2<>web3 worlds.
A potentially very powerful primitive that can close this gap is ZK-Email.
Apparently, almost all emails sent from web2 servers are signed by a private key owned by the sending domain. This is true for pretty much all emails across major web2 platforms since 2017, as they all adopt a common simple protocol known as DKIM.
Given the corresponding public key and the signature, on-chain smart contracts can therefore “trustlessly” (w/o need to trust clients/users) verify the authenticity of emails and read their content!
Simple private-public key cryptography would do the job but with ZKPs the process becomes practical in terms of verification costs and privacy (e.g. to ZK prove you are a Twitter user , you don’t have to reveal your username, email etc. on-chain)
This is huge! Emails are the lifeblood of web2. If you think about it, every major user activity (sign up, subscribe, purchase, delivery, cancelation etc.) in any web2 platform (Tinder, Airbnb, Twitter, Amazon, Venmo etc.) has an associated email footprint.
What excited me a lot is that this is not theoretical. There are already working example apps!
-
Email Wallet: You can send crypto directly to any email address. Recipient doesn’t need to download any wallet software to receive the tokens and/or send them to another user. Every email user becomes a crypto user. Very cool project! Check it out here: https://zkemail.xyz/
-
Trustless p2p Fiat<>Crypto On/Off-Ramp: this hackaton project enables people to *trustlessly* on/off ramp to crypto by making a Venmo transfer. Once the smart contract verifies the ZKP corresponding to the Venmo email dealing with the Venmo transfer, it releases a previously unlocked USDC. It works today in testnet and here is a 5 min demo!
https://drive.google.com/file/d/1BmTyeAfsi4K9iuZQ-G6YBGv5SqysUHj5/view?pli=1
Challenges
While a very exciting primitive there are some open research / engineering challenges as well as concerns.
-
Trust assumptions: The primary trust assumption here is the sending mail server. For this primitive to work, we need to assume the sending mail servers won’t forge emails. While reasonable assumption for many (considering reputation of major web2 platforms) there is certainly a limit on how much of the crypto economy can depend on this. Then again we all trust our overlord Circle so maybe this is not a step back.
-
Server vs client side proof generation: in current MVP implementations proofs are generated on the server side; there is a relayer service that generates the ZKPs. With beefier machines they can reduce proof generation times from several minutes to seconds. Server side proof gen doesn’t impact safety but it does impact privacy. With more efficient mehcnaisms users should be able to generate proofs on client side in their browsers so no one besides user, knows what info is being verified on-chain.
-
Extensibility / Modularity: The ZK circuit follows a specific parsing method to extract info out from emails. (e.g. to verify you are an employee in firm ABC, the circuit parses the recipient address and checks if the domain is xyz@ABC.com) This begs the question how modular/extensible can circuits be, to what extend they depend on email format and how quickly they can adapted to changes there.
Helpful Links
Here is a website https://blog.aayushg.com/posts/zkemail/ that shows the team and projects. For a more in depth write up on the technology please check out https://blog.aayushg.com/posts/zkemail/