Arweave TX
Since March of this year, we have been wildly intrigued by zero-knowledge Proof and started to think about the possibility of bringing ZKP for accounts to the Web3 ecosystems. We are not the first, but, for sure, won't be the last. Since August of the same year, Dauth.Network, Misfit.ID, Hexlink.IO, Consensys Verax, and a whole crew of other companies and products scattered around the space of wallet, wallet providers, account abstraction, zero-knowledge proofs; distributed across the Silicon Valley, New York, Singapore, HK, Shanghai are coming together to draft upon what the future of accounts can be. This article will, lightly, discuss the idea, the work we have done, and the challenges ahead.
Btw, the EIP-7522 "OIDC ZK Verifier for AA Account" is in draft. Critics, complains, compliments are all very welcomed.
When we talk about accounts, we are talking about accounts in general, including
BIP39-style HD wallets (the EOAs),
EIP4337-style abstracted accounts (the AAs),
Twitter/Google accounts (the Web2 Accounts)
Farcaster/Lens style Web3 social media accounts (the Web3 social media accounts).
We can make a fuss about fine distinctions of the definitions for "accounts", "wallets" and "identities" however we want. But, at least for now, we are just gonna call them all accounts.
On the HD wallets: it's a simple idea. Having a seed phrase and hashing the seed phrase with different derivation path generates a span of private keys that are one-way connected to the seed phrase. Those who know the seed phrase controls all private keys but not the other way around. (i.e. almost impossible to deduce the relationship of public addresses to be generated from the same seed phrase). It was introduced by BIP39, a bitcoin improvement proposal and has been the industry standard for wallet management for a decade.
The EIP4337 style abstracted accounts, or smart contract accounts, is a framework of the expansion upon the EOA standard. Typically, AAs are dedicated smart contracts on EVM chains controlled by one or a few EOAs and execute transactions for the controllers based on the ECDSA signatures generated by those EOAs. Funny enough, critics, mostly known from the zkSync founders, argue the virtue of having all accounts on zkSync to be abstracted account and I believe Vitalik talked about bringing the same idea to Ethereum as well. We won't get to the bottom of it, as we have pretty mixed feeling about it, but just gonna bring it up as a fun thing.
Web2 accounts are simple at first but are getting complicated as hell over years. In the early days, they were just rows in databases - a combination of user name and password hash. When the Web2 companies realized the user might forget their passwords, they built up systems for authentications, typically by sending a recovery email to the user. With the introductions of SMS APIs by companies like Twilio, phone number verifications got to join the crew for authentication method. Fancier methods like inviting friends to help unlocking accounts, type in mother's maiden name, or even social security number are also used by some. Later, Startups decides to outsource the account management chores to bigger Web2 companies and invented the OIDC standard, which is the typical big "Sign In With Google" or "Sign In With Twitter" buttons widely used till today.
More recently, Passkeys and the WebAuthn have joined the force and moved towards the self-issued, decentralized accounts paradigm. Most devices we use these days contain security enclaves. They are like silent storekeepers who would only nod or shake heads for "Yah" and "Nay" when authenticating but won't leak a single word on what's in the shops.
We will talk about the rest of our thoughts on accounts around these major 4 considerations. But let's start with this: It is hard to achieve all 4 and making compromises is part of life. Before we dive into that shitty part of life, what will be the security, speed, cost, and privacy concerns of accounts?
Security is straightforward - the right person is able to be authenticated as the right person all the time. To break it down, one cannot fake themself as another person and gain authentication and one shall always be able to authenticate themself without locking themself out of services.
Speed and cost are a bit compound & loaded concepts but still straightforward. As far as we are concerned in this blog: would it take several days for someone to audit one's record to be authenticated or would it be an instant authentication process? Would it cost me $200 for an auditor to prove who I am?
Privacy is indeed heavily loaded. We will only lightly touch on the privacy topic in this article. Questions people ask can be: Would it make sense for a big tech company to know my name/username? Would it make sense for anyone to know my user name? Would it make sense for anyone to know the relationship of all my user names? What about the content I produce? (i.e. think about transaction history, tax records, sign-in records, browser history, chat messages, blogs, tweets etc) What's the procedure for me to give permission for someone to gain access to my information?
While we don't have the silver bullet answer to all concerns, as they are complicated in nature, we do have opinions on how accounts should be handled on Web3.
For EOAs,
Security is, surprisingly, more or less terribly handled in Web3 accounts. While it is secure against another person to gain access to my wallets and assets (if you disagree, use a good hardware wallet, please), there is very little way for recovery without too much scarifies. Last year, when I was trying to make payment to a vendor, my Ledger prompted me to make a major firmware upgrade, while the paper copy of my seed phrase was misplaced. I slept on it and decided to YOLO the upgrade. As it turns out, I found the paper the second day and the upgrade went well, but that thrill was real. I can't imagine myself facing the same thrill outside of Web3. I do have a bank account that I seldomly used and forgot the password. The recovery took a serious and tedious 30 minutes with all kinds of verification but I have no fear of being locked out of my money at all.
Speed, Cost, Privacy: Decentralization and self-custodian touches on lots of intersections of speed, cost and privacy. Identifying myself takes milliseconds. It's a simple math process with just a few multiplications and additions called ECDSA and cost me nothing. Privacy can be somehow preserved if I'm savvy enough on key management with some public identity addresses and some private stashing addresses.
For EIP4337 abstracted accounts as we have right now, things got slightly shifted,
Security was improved and downgraded at the same time. Improved as the recovery of an account is now possible but not widely implemented. Downgraded as the authentication method, even though based on the same math of ECDSA, is coupled with smart contract verification logic and a fault implementation of the `verifySignature` function can compromise the security against malicious users to gain access to the account.
Speed + Cost: Changes in cost are subtle. While the users need to access their accounts through contract calls with some cost overheads, the increase in cost is minimal and it's theoretically possible to amortize the cost by aggregation and bundling. But still, it's almost free but not completely free. We will dive deeper into gas fees when we are onto ZKP aggregations. Change in speed is minimal if you are onto the right bundler.
Furthermore, the idea of social login for Web3 accounts is widely entertained. I would love to login to platforms like Paragraph or Zora with my Google Accounts and use the same Ethereum address for my public profiles on Web3 social media, while platforms like Paragraph and Zora have zero-knowledge about my Google accounts. The most common approach to a semi-self-custodian approach is by utilizing the MPC-ECDSA cryptography. But MPC-ECDSA is problematic because of its inherently centralization nature. MPC-ECDSA is like one step forward but ten steps backward type of situation:
Single Point of Failure: if the MPC service providers get shut down by law enforcement, bankrupt, or cease to serve their customers for any arbitrary reasons, there is no secure way for users to gain access to their accounts. One question that wallet providers sweating on answering is whether their users can still gain access to their wallets if they disappear.
Privacy: the separation between the users' Web2 identity to their Web3 address cannot be cryptographically guaranteed and results in a higher cost of trust between the users and the MPC service providers.
Vendor Lock In: there are few to no efficient ways to migrate from one MPC provider to another, because of the lack of standards and transparency for the cryptographic particulars. Usually, users will be locked into one single vendor to provide the MPC-ECDSA signature service.
ZKP needs no detailed explanations. In short, ZKP is a way to construct programmable cryptography and prove whether a certain procedure has been executed correctly. It's, usually, hard to prove an argument but easy to verify the proof. Verification is simply enough so that proofs are even verifiable within an EVM smart contract. ZKP inherent great features from typical EOA wallets: decentralization, self-custodian, and self-issuable. In the context of ZKP for accounts. We are more interested in proving ownership and authentication on Web2 accounts, as EOAs already implement a simpler form of cryptography called ECDSA. To be clear, we can always verify a Web3 account with a simple EOA signature, but verifying a Web2 account takes some additional effort.
Among all statically provable credential candidates for Web2, innovations had been made. ZKEmail proves email integrity from the DKIM signatures from the email server to verify its origin. During the TOKEN2049 week, we have seen delightful use cases. Among those, one company is thinking of proving Venmo transaction confirmation emails to facilitate ZKP-based decentralized OTC services. It is an awesome idea. There are also implementations that focus on proofs around Passkey/WebAuthn standards. For OpenID3, we choose to prove over JWTs.
There are three components of common JWT issued by providers these days: the header section, the claim section which contains the claimed user credential, and the signature section which is typically an RSA signature onto the hash of the combined header + claim section.
Specifically, OpenID3 proves the following argument:
JWT Integrity: the SHA256 hash of the header and the claim section matches the signature the issuer signed.
Inclusion of a plain identity claim: the user identity is located within the claim section of the JWT.
Masked Identity: the hash of the salted user identity matches the user-claimed hash.
While the zero-knowledge proof shall contains the following public and private inputs:
Private Inputs: the plaintext JWT header + claim section; the user claimed identity, a salt for the user identity.
Public Inputs: SHA256 hash of the JWT header + claim section; SHA256 hash of the user identity.
So that the on-chain verifier can easily verify the user identity, JWT signature, and masked user identity.
Getting back at the 4 core considerations: security, speed, cost, and privacy, the ZKP-based account validation has a mixture of upsides and downsides.
Security
the ZKP based account authentication brings an absolute upside on security. Given a correct proving system implementation, the security of the proof is equivalent to the security of the Web2 providers.
Speed & Cost + Decentralization
ZKP is notoriously slow. But less do people know, a typical ZKP system consists of two steps - commonly known as an application proof and an aggregation proof. In the OpenID3 case, the application proof refers to the process on the user's client-side to generate the proof of one JWT. The aggregation proof can be carried out on any server to batch a series of applications proof into one bundled proof to be verified on-chain. Per our current implementation, the application prover can take somewhere between 2-20 seconds and the aggregation prover will take ~5-30 minutes depending on different proving schema. For the end users, they would only need to produce an application proof and the proof will be perfectly zero-knowledge complaint.
Verifying a zero-knowledge proof is also not cheap on-chain. However, it is tricky because verifying an aggregated proof has very little correlation with the number of application proofs within. In short, verifying 1 proof will have a similar cost to verifying 1000 proofs. At a certain critical point, verifying ZKP will even be significantly cheaper than SECP256K1 ECDSA verification. With the right amortization, to our current estimation, an aggregated ZKP of ~20 proofs will yield cheaper verification fee compared to the typical ECDSA verified abstracted account verification gas fee.
Decentralization is not optional. It needs to be done. Therefore, the application prover needs to run on the client side. Memory consumption and prover speed need to be balanced against on-chain verification gas cost.
We are in the process of building implementation based on the combination of polynomial commitment schemes, witness construction methods, and implementation languages performance, plus optimizations like the folding scheme. But after all, we aim to compromise and reach a balanced point of memory/CPU consumption and on-chain verification fee.
Privacy
Again, privacy is a heavily loaded concept. Our implementation will focus on eliminating the risk of associations between the user's Web2 identity and Web3 addresses, while making it possible for end-users to intentionally & efficiently expose the proof of their Web2 identity for certain products.
Dauth.Network is providing a zkSigner service for abstracted accounts. By default, the user will generate an ephemeral local session keypair that will be recognized as an ephemeral owner of contract wallets, while the ZKP produced by the user will have the absolute authority to refresh the owner of the wallets. Such an approach will have the user take a few seconds on a new machine/browser to log in and transact as if they are using typical EOA accounts.
Misfit.ID is building an infrastructure for decentralized Proof of Humanity. It takes a Bayesian probability approach to prove if a user is a real and unique human being. The users can link more Web2/Web3 credentials to an abstracted user-space and invite others collectively update the probability of being a real and unique human being. The whole process shall not leak any unintended information of the user's identity.
Hexlink is reshaping the digital realm by shifting from an app-centric to a user-centric model, enabling personalized online experiences while maintaining consistency across applications. With Hexlink, users will be able to carry global account settings and service preferences across different applications, prioritizing individual control.
Song Z - Cryptographer @ Misfit.ID + Chief Scientist @ DAuth.Network; Lead on the ZKP component of the OpenID3 protocol;
Dean Y - Co-contributor @ DAuth Network; Co-contributor of OpenID3 protocol;
Shu Dong - Founder @ Hexlink; Author of EIP-4972/EIP-6662/EIP-7522; Co-contributor of OpenID3 protocol;
songz
