Sign and send transactions by sending an email via account abstraction and ZK
This project implements an ZK-AA wallet which allows users to interact with any Smart Contract/sign any transaction request by sending an email. When our relayer receives an email, it uses ZK to trustlessly and veritably prove that a reputable email server like Gmail, Skiff, or Hotmail signed the message by verifying the email server's DKIM signature. Additionally, since the email server uses the same public key to sign the email's body, we can use ZK to parse out the contents of the email. The result is that it is safe for a 3rd party to submit transactions on the behalf of the user and they can generate a ZK proof proving that they received an email requesting that transaction.
Because the ZKP validates that the relayer received the transaction request email, anyone can run a relayer without needing to be a trusted party, as it is impossible for them to forge a transaction request email without colluding with the email server. If the user takes adequate precautions (such as hosting their own server, or using Skiff or ProtonMail) this becomes near impossible. Additionally, the user can opt into anonymizing their account activity by deterministically hashing and salting their email inside the ZKP. However, the user still must share their email with the relayer - a trust flaw that can be remedied in future builds of this project by moving more of the ZK constraints client side using Halo 2.
This project builds on top of 0xPARC and EF PSE's ZKEmail and ZKRegex Circom circuits, and is also inspired by their recent SendETH project. However, unlike SendETH, we implement and inject a generalized EIP-1193 Wallet as well as the WalletConnect Wallet SDK interface, allowing almost all Dapps to connect with our Wallet without additional configuration. Additionally, we follow EIP-6963, and also inject our wallet into the providers object as Coinbase Wallet allowing our wallet extension to coexist with other providers in a user's browser. While our contracts closely resemble ERC-4337, they do not follow the interface exactly, as there is no signing involved anywhere in the protocol.
For this hackathon, we only implemented a subset of the EIP-1193 interface, and don't handle some edge cases in our ZKEmail + ZKRegex circuit. However, we believe this is a compelling proof of concept.
Other trust assumptions: The email server's public key must be injested on chain via an Oracle. Originally, the plan was to injest this data on-chain using the EF's TLSNotary, which is suited for this use case. However, we ran out of time.
Data flow:
Components: