Original title: What I would love to see in a wallet

Author: Vitalik, founder of Ethereum; Compiler: Deng Tong, Golden Finance

Special thanks to Liraz Siri, Feedback and review by Yoav Weiss and developers of ImToken, Metamask and OKX.

A critical layer of the Ethereum infrastructure stack that is often underestimated by core L1 researchers and developers is the wallet. Wallets are the window between users and the world of Ethereum, and users can only benefit from any decentralization, censorship resistance, security, privacy, or other attributes offered by Ethereum and its applications if the wallet itself also possesses those attributes.

Recently, we have seen Ethereum wallets make great progress in improving user experience, security, and functionality. The purpose of this article is to give my own opinion on some of the features that an ideal Ethereum wallet should have. This is not a comprehensive list; it reflects my cypherpunk leanings, it is focused on security and privacy, and it is almost certainly incomplete in terms of user experience. However, I don't think wishlists are as effective at optimizing user experience as simply deploying and iterating based on feedback, so I think focusing on security and privacy attributes is most valuable.

User experience for cross-L2 transactions

There is now an increasingly detailed roadmap for improving the cross-L2 user experience, which has a short-term part and a long-term part. Here I'll talk about the short-term part: ideas that are still theoretically possible to implement even today.

The core idea is (i) built-in cross-L2 sending, and (ii) chain-specific address and payment requests. Your wallet should be able to provide you with an address (following the style of this draft ERC) like this:

0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045@optimism.eth

When someone (or some application) gives you an address in this format, you should be able to paste it into the "To" of your wallet field and click Send. Wallets should automatically handle sent data in any way possible:

If you already have enough tokens of the required type on the target chain, send the tokens directly;

If you have the desired type of token on another chain (or multiple other chains), use ERC-7683 (actually cross-chain DEX) to send tokens;

If you have different types of tokens on the same chain or other chains, use a decentralized exchange to convert them to the correct type on the correct chain of tokens and send them. This should require explicit permission from the user: users will see how much they paidfee, and how much the recipient received.

Model of possible wallet interface with cross-chain address support

The above applies to "you copy and paste An address (or ENS, e.g. vitalik.eth@optimism.eth) for someone to pay you" use case. If a dapp requests a deposit (see the Polymarket example for example), then the ideal flow would be to extend the web3 API and allow the dapp to make chain-specific payment requests. Your wallet will then be able to fulfill the request in any way needed. For a good user experience, getAvailableBalance requests also need to be standardized, and wallets need to carefully consider which chains user assets will be stored on by default to maximize security and transfer convenience.

Chain-specific payment requests can also be put into QR codes, which can be scanned by mobile wallets. In an in-person (or online) consumer payment scenario, the recipient will issue a QR code or web3 API call saying "I want X units of token Y on chain Z, with a reference ID or callback W" and the wallet will be able to Feel free to accommodate this request in any way possible. Another option is a claim linking protocol, where a user's wallet generates a QR code or URL containing authorization to claim a certain amount of funds from their on-chain contract, and it's the recipient's job to figure out how to transfer those funds to them on the account.

Another related topic is Gas payments. If you receive an asset on an L2 that doesn't have ETH yet, and need to send a transaction on that L2, the wallet should be able to automatically use a protocol (such as RIP-7755) to pay for on-chain gas where you have the ETH. If the wallet wants you to do more transactions on L2 in the future, it should also only send using DEX. A few million gas worth of ETH so that future transactions can spend gas there directly (because it's cheaper).

Account Security

One way I conceptualize the account security challenge is that a good wallet should function in two ways at once: (i) Protect users from hacking or malicious intent by wallet developers attacks, and (ii) protect users from their own mistakes.

The "error" on the left is unintentional. However, when I saw it, I realized it fit the context perfectly, so I decided to keep it.

My preferred solutions for over a decade have been social recovery and multi-signature wallets with hierarchical access control. A user's account has two tiers of keys: a master key and N guardians (e.g. N = 5). Primary keys are capable of performing low value and non-financial operations. Most guardians need to perform (i) high-value operations, such as sending the entire value in the account, or (ii) changing the master key or any guardian. If desired, primary keys can be allowed to perform high-value operations via time locks.

The above is the basic design and can be expanded. Permission mechanisms like session keys and ERC-7715 can help support different balances of convenience and security for different applications. More complex guardian architectures, such as having multiple timelock durations at different thresholds, can help maximize the chance of successfully recovering legitimate accounts while minimizing the risk of theft.

Who or what should the guardian be?

A viable option for experienced crypto users in the community of experienced crypto users is the keys of your friends and family. If you ask everyone to provide you with a new address, no one needs to know who they are - in fact, your guardians don't even need to know who each other is. If they didn't tip you off, the chances of them colluding are slim. However, for most new users, this option is not available.

The second option is an institutional guardian: a company that specializes in providing the service and will only sign the transaction if they get additional confirmation from your request. A confirmation code, or a video call for high-value users. People have been trying to make these things for a long time. I introduced CryptoCorp in 2013. However, so far, such companies have not been very successful.

The third option is multiple personal devices (e.g. mobile phone, desktop, hardware wallet). This is doable, but can also be difficult to set up and manage for inexperienced users. There is also the risk of losing or stealing the devices, especially if they are in the same location.

Recently, we have started to see more and more key-based wallets. Passwords can only be backed up on your device, making them a personal device solution, or in the cloud, making their security dependent on a complex mix of password security, authority, and trusted hardware assumptions. In reality, keys are a valuable security gain for the average user, but they are not enough on their own to protect a user's life savings.

Fortunately, with ZK-SNARK, we have a fourth option: ZK-wrapped centralized IDs. This type includes zk-email, Anon Aadhaar, Myna Wallet, and many more. Basically, you can take a centralized ID in one of its many forms (corporate or ) and convert it into an Ethereum address, and you can only send transactions by generating a ZK-SNARK that proves you have the centralized ID.

With this addition, we now have a wide range of options and ZK-wrapped centralized IDs that are uniquely "newbie-friendly"sex".

For this, it needs to be achieved through a simplified and integrated UI: you should be able to specify only that you want "example@gmail.com" as a guardian, and it should automatically generate the corresponding zk -email Ethereum addresses are under the hood. Advanced users should be able to enter their email (and possibly the privacy salt value stored within that email) into an open source third-party application and confirm that the resulting address is correct. The same should be true for any other supported guardian types

Possible security interface models

Note that. A practical challenge facing zk-email today is that it relies on DKIM signatures, which use keys that are rotated every few months and are not themselves signed by any other authority. This means that zk-email today has some level of trust requirements beyond the provider itself; This can be reduced if zk-email uses TLSNotary within trusted hardware to verify updated keys, but that's not ideal. Hopefully email providers will start signing their DKIM keys directly today. One guardian uses zk-email, but it is not recommended for most guardians: do not store funds in Broken zk-email means you can't use funds in settings

New users and in-app wallets

New users don't actually want to enter a large number of guardians on their first sign-up experience, so the wallet should work for them. A very simple alternative is to use zk-email on their email address, a key stored locally on the user's device (perhaps a master key), and a backup key held by the provider, Go 2-of-3 options. As users become more experienced or accumulate more assets, at some point they should be prompted to add more guardians to the application as it is inevitable to try to attract them. Apps for non-crypto users don’t want users to download two new apps (the app itself, plus an Ethereum wallet) at the same time Coming to a confusing user experience, however, the easiest way for many app wallet users to link all their wallets together so that they only have one "access control issue" to worry about is to adopt a layered scheme. A quick "linking" process that allows users to set up their main wallet as the guardian of all in-app wallets. The Farcaster client Warpcast already supports this:

By default, recovery of your Warpcast account is controlled by the Warpcast team. You can "Takeover” your Farcaster account and change the recovery to your own address.

Protect users from scams and other external threats

In addition to account security, today’s wallets do a lot to identify fake addresses, phishing, scams, and other external threats, and trying to protect users from such threats, many of the countermeasures are still quite primitive: for example, requiring a click to send ETH or other tokens to any new address, no matter what you do. Are you sending $100 or $100,000? There's no single silver bullet here. It's a slow, ongoing series of fixes and improvements for different classes of threats. However, there's a lot of value in continuing to work on improving privacy

Now is the time. Get serious about privacy on Ethereum. ZK-SNARK technology is now very advanced, privacy technologies that do not rely on backdoors to reduce regulatory risks (such as privacy pools) are becoming more mature, and like Waku and ERC-4337 Secondary infrastructure like mempools is also slowly becoming more stable. However, until now, making private transfers on Ethereum required users to explicitly download and use a "privacy wallet" such as Railway (or for stealth addresses). Umbra). This adds significant inconvenience and reduces the number of people willing to make private transfers. The solution is that private transfers need to be integrated directly into the wallet. A simple implementation of this would be as follows. A portion of the asset is stored as a "private balance" In the privacy pool. When users make transfers, they will automatically exit the privacy pool. If the user needs to receive funds, the wallet can automatically generate a stealth address for each application the user participates in. The program generates a new address (for example, defi Agreement). Deposits will come from the privacy pool and withdrawals will go directly to the privacy pool. This allows users’ activity in any one app to be unlinked from their activity in other apps.

One advantage of this technology is that it is a natural path not only for privacy-preserving asset transfers, but also for privacy-preserving identities that already happen on-chain: any application that uses identity proof gating (such as Gitcoin). Grants), any token-gated chats, Ethereum compliance protocols, etc. are all on-chain identities. We want this ecosystem to be privacy-preserving as well. This means that a user’s on-chain activity should not be collected in one place: per project. should be stored separately, and the user's wallet should be the only thing that has a "global view" of all your proofs at the same time. The native multi-account per user ecosystem helps with this, EAS and Zupass. The same goes for off-chain proof protocols

This represents a pragmatic vision for Ethereum privacy in the medium term, although some features can be introduced in L1 and L2 to make privacy-preserving transmissions more efficient and reliable.It can be achieved. Some privacy advocates believe that the only acceptable thing to do is complete privacy of all things: encrypt the entire EVM. I think this could be the ideal long-term outcome, but it would require a more fundamental rethinking of the programming model and is not yet at a level of maturity ready to be deployed on Ethereum. We do need default privacy to get a large enough anonymity set. However, focusing first on (i) transfers between accounts, and (ii) identity and identity-related use cases (such as private proofs) are pragmatic first steps that are easier to implement and wallets can start using now.

Ethereum wallets need to be data wallets, too

One consequence of any effective privacy solution is that it creates the need for users to store off-chain data, whether for payments, identity, or other use cases. This is evident in Tornado Cash, which requires users to save “tickets” each representing a deposit of 0.1-100 ETH. More modern privacy protocols sometimes keep encrypted data on-chain and use a single private key to decrypt it. This is risky because if the keys are leaked or quantum computers become feasible, the data will all be public. Off-chain proofs such as EAS and Zupass have a more obvious need for off-chain data storage.

A wallet needs to be software that not only stores on-chain access rights, but also your private data. The non-crypto world is increasingly recognizing this as well, for example. See Tim Berners-Lee's recent work on personal data storage. All the issues that we need to address around robust assurance of access control, we also need to address around robust assurance that data is accessible and not leaked. Maybe these solutions can stack up: If you have N guardians, use M-of-N secret sharing among those N guardians to store your data. Data is inherently harder to protect because you can't revoke someone's share of the data, but we should come up with decentralized hosting solutions that are as secure as possible.

Secure Chain Access

Today, wallets trust their RPC provider to tell them anything about the chain. This is a vulnerability that has two sides:

RPC providers could try to steal money by feeding them false information, for example about market prices

RPC providers could extract information about Private information from the applications and other accounts the user is interacting with

Ideally, we would like to close both of these vulnerabilities. To solve the first problem, we need standardized light clients for L1 and L2 that can directly verify the blockchain consensus. Helios already does this for L1 and has been doing some preliminary work to support some specific L2s. To correctly cover all L2, we need a standard by which configuration contracts representing L2 (also used for chain-specific addresses) canDeclare a function, perhaps in a similar way to ERC-3668, that involves getting the nearest state roots, and certifying and receiving the state roots based on those. This way we can have a universal light client that allows wallets to securely verify any state or event on L1 and L2.

For privacy, the only realistic approach today is to run your own full node. However, now that L2 is coming into view, running a full node with everything is becoming increasingly difficult. The light client equivalent here is Private Information Retrieval (PIR). PIR involves a server that keeps a copy of all data and a client that sends an encrypted request to the server. The server performs calculations on all the data, returning the data the client needs, encrypted to the client's key, without revealing to the server which piece of data the client accessed.

To keep the server honest, individual database projects are themselves Merkle forks, so clients can use light clients to verify them.

PIR is very computationally intensive. There are several ways to solve this problem:

Brute force: Improvements in algorithms or specialized hardware may make PIR run fast enough. These techniques may depend on preprocessing: the server can store encrypted and scrambled data for each client, and the clients can query that data. The main challenge in the Ethereum environment is adapting these technologies to rapidly changing data sets (just like ). This makes real-time computation cheaper, but likely makes total compute and storage costs higher.

Weaken privacy requirements: for example, there can only be 1 million "mixins" per lookup, so the server would know about the 1 million possible values ​​that the client has access to, but not any finer granularity .

Multi-server PIR: If you use multiple servers, and the honesty between these servers is assumed to be 1-of-N, then the PIR algorithm is usually faster.

Anonymous rather than confidential: Requests can be sent over a mixnet, thus hiding the sender of the request rather than hiding the content of the request. However, doing so effectively will inevitably increase latency, thus worsening the user experience.

Finding the right combination of technologies to maximize privacy while maintaining practicality in the Ethereum environment is an open research question, and I welcome cryptographers to try to do so.

Ideal Keystore Wallet

Besides transfer and state access, another important workflow that needs to work smoothly across L2 contexts is changing the verification configuration of an account: either changing its key (e.g. recovery), or make deeper changes to the entire logic of the account. Here are three tiers of solutions, in order of increasing difficulty:

Replay updates: When a user changes their configuration, the message authorizing this change will be replayed on every chain where the wallet detects that the user owns assets. Potentially, message formats and validation rules can be chain independent and therefore automatically replayed on as many chains as possible.

Keystore on L1: The configuration information is located on L1, and the wallet on L2 reads it using L1SLOAD or REMOTESTATICCALL. In this way, you only need to update the configuration on L1, and the configuration will automatically take effect.

Keystore on L2: The configuration information exists on L2, and the wallet on L2 reads it using ZK-SNARK. This is the same as (2), except that keystore updates may be cheaper, but reads on the other hand are more expensive.

Solution (3) is particularly powerful because it integrates well with privacy. In a normal "privacy solution", the user has a secret s, a "leaf value" L published on the chain, and the user proves that L = hash(s, 1) and N = hash(s, 2) for some ( never revealed) the secret they control. An invalidator,N,is issued, ensuring that future expenditures,of the same leaf fail without revealing,L,. It's up to the user to keep s safe. A recovery-friendly privacy solution would say: s is a position on the chain (such as an address and a storage slot), and the user must prove the state query: L = hash(sload(s), 1) .

Dapp Security

The weakest link in user security is usually the dapp. Most of the time, users interact with applications by visiting a website, which implicitly downloads user interface code in real time from the server and then executes it in the browser. If the server is hacked, or the DNS is hacked, users will get a fake copy of the interface, which could trick them into performing arbitrary actions. Wallet features such as trading simulations are very helpful in reducing risk, but they are far from perfect.

Ideally, we will move the ecosystem to on-chain content versioning: users will access dapps via their ENS name, which will contain the IPFS hash of the interface. Updating the interface requires an on-chain transaction from a multisig or DAO. The wallet will show users whether they are interacting with the more secure on-chain interface or the less secure Web2 interface. Wallets can also show users whether they are interacting with a security chain (e.g. Stage 1+, multiple security audits).

For privacy-conscious users, the wallet can also add a paranoid mode that requires users to click to accept HTTP requests, not just web3 operations:

Possible Interface Model for Paranoid Mode

A more advanced approach would be to go beyond HTML + Javascript and use a dedicated language (perhaps a relatively thin overlay on Solidity or Vyper)Write the business logic of the dapp. The browser can then automatically generate the UI for any desired functionality. OKContract is already doing this.

Another direction is cryptoeconomic information defense: dapp developers, security companies, chain deployers, and others can set up a deposit to protect users if the dapp is hacked or harms users in a highly misleading way. The deposit will then be paid to the affected users. Determined by some on-chain DAO. The wallet can display a score to the user based on the size of the bond.

The Longer Future

The above is all in the context of a traditional interface, which involves pointing and clicking things and typing things into text fields. However, we are also on the cusp of a more profound change in paradigm:

Artificial intelligence, which may lead us from a point-and-click typing paradigm to a "say what you want to do and the robot will figure it out" paradigm;

Brain-computer interfaces range from “gentle” methods such as eye tracking to more direct and even invasive technologies (see: the first Neuralink patient this year);

Client active defense: Brave The browser proactively protects users from ads, trackers, and many other undesirable objects. Many browsers, plugins, and crypto wallets have entire teams actively working to protect users from various security and privacy threats. These “positive guardians” will only grow stronger over the next decade.

Together, these three trends will lead to a deeper rethinking of how interfaces work. Through natural language input, eye tracking, or eventually more direct brain-computer interface, coupled with your history (perhaps including text messages, as long as all data is processed locally), the "wallet" can clearly and intuitively understand what you want to do thing. AI can then translate this intuition into a concrete “action plan”: a series of on-chain and off-chain interactions to accomplish what you want. This can greatly reduce the need for third-party user interfaces. If a user does interact with a third-party application (or other user), the AI ​​should think adversarially on the user's behalf, identify any threats and suggest a plan of action to avoid them. Ideally, these AIs should have an open ecosystem, produced by diverse groups with different biases and incentive structures.

These more radical ideas rely on today's extremely immature technology, so I wouldn't put my assets in a wallet that relies on them today. However, it seems clear that something like this is the way of the future, so it's worth starting to explore more actively in this direction.