By: Vitalik Buterin
Compiled by: Yangz, Techub News
Wallets are a critical layer in the Ethereum infrastructure stack, but they are often overlooked by core L1 researchers and developers. Wallets are the window between users and the Ethereum world, and users can only benefit from them if the wallet itself also has decentralization, censorship resistance, security, privacy, or other characteristics provided by Ethereum and its applications.
In recent years, we have seen great progress in improving the user experience, security, and functionality of Ethereum wallets. The purpose of this article is to express my personal views on some of the properties that an ideal Ethereum wallet should have. This list will not be complete, but reflects my crypto-punk tendencies. For wallets, I value security and privacy more, because there is almost no perfect wallet in terms of user experience. I think wish lists are less effective in optimizing user experience than simply deploying and iterating based on feedback. In my opinion, focusing on security and privacy properties is the most valuable.
User experience for cross-L2 transactions
The roadmap for improving the user experience across L2 is becoming increasingly detailed, with both short-term and long-term parts. Here, I want to talk about the short-term part, which is the ideas that are theoretically achievable even today.
The core idea of this part is to build in cross-L2 transactions and chain-specific addresses and payment requests. The wallet should provide such an address:
When someone (or an app) gives you an address in this format, you should be able to paste it into the "to" field of your wallet and hit "send", and the wallet will automatically take care of it:
If there are enough tokens of the required type on the target chain, they are sent directly;
If you have a token of the desired type on another chain (or multiple chains), you can send the token using a protocol like ERC-7683 (effectively a cross-chain DEX);
If you have different types of tokens on the same chain or other chains, you can use DEX to convert them into the correct type of token on the correct chain and send it. Of course, this also requires the user's explicit permission, that is, the user will see how much he paid and how much the recipient received.
The above is the use case of "copy-pasting an address (or ENS, such as vitalik.eth@optimism.eth) to have someone pay you." If it is a deposit to a DApp (see the Polymarket example ), the ideal flow would be to extend the Web3 API to allow the DApp to make a payment request to a specific chain. This way, the user wallet can fulfill the request in any way. For a good user experience, the getAvailableBalance request also needs to be standardized, and wallets need to consider which chain the user's assets are stored on by default to maximize security and ease of transfer.
Payment requests for specific chains can also be placed in QR codes for direct scanning by mobile wallets. In an in-person (or online) consumer payment scenario, the payee can call "I want X units of Y tokens on Z chain, with a reference ID or callback W" through a QR code or Web3 API, and the wallet is free to fulfill the request in any way. Another option is the claim link protocol, where the user wallet can generate a QR code or URL containing authorization to claim a certain amount of funds from its on-chain contract, and the payee's job is to find a way to transfer these funds to their own wallet.
Another related topic is gas payments. If you receive assets on an L2 that you don't yet own ETH on, 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 gas on the chain where you own ETH. If the wallet expects you to make more transactions on that L2 in the future, it should also use the DEX to send a few million gas-worth of ETH so that future transactions can use gas directly (which is also cheaper).
Account Security
My understanding of the account security challenge is that a good wallet should protect users both from hacking or malicious attacks by wallet developers and from their own mistakes.
The typo "mistakles" on the vertical axis was an unintentional mistake. I felt that the mistake fit the context well, so I did not modify it.
For more than a decade , my preferred solution has been social recovery and multi-signature wallets with hierarchical access control. A single user account has two layers of keys, including a master key and N signers (for example, N = 5). The master key can perform low-value and non-financial operations. However, for high-value operations, such as sending all the assets in the account, or changing the master key or any signer, the participation of a majority of signers is required. If necessary, the master key can be allowed to perform high-value operations with a time lock.
The above is just a basic design, and we can expand it. For example, session keys and permission mechanisms (such as ERC-7715 ) can help support different applications to achieve different balances between convenience and security. More complex signer architectures, such as setting multiple time lock durations at different thresholds, can help maximize the chances of successfully recovering legitimate accounts while minimizing the risk of theft.
Who should be chosen as the signer of a multi-signature wallet?
For experienced cryptocurrency users, a viable option is your friends and family. In fact, your multisig wallet signers don’t even need to know who each other is. The chances of them colluding without your knowledge are extremely small. However, for most new users, this option is not feasible.
The second option is institutions, companies that specialize in providing services. Such signers will only sign transactions after receiving additional confirmation information (such as a confirmation code, or a video call from a high-net-worth user). People have been trying to create such companies for a long time, for example, I introduced CryptoCorp in 2013. However, so far, there are no very successful representatives of such companies.
A third option is to use multiple personal devices (e.g., mobile phone, desktop, hardware wallet). This approach can work, but it is also difficult to set up and manage for inexperienced users. There is also the risk of devices being lost or stolen at the same time, especially if they are in the same location.
Recently, we've started to see more passkey-based wallets emerge. Passkeys can be backed up on the device only, making it a person-to-device solution, or they can be backed up in the cloud, making their security dependent on a complex mixture of cryptographic security, institutional, and trusted hardware assumptions. In practice, passkeys are a valuable security gain for the average user, but alone are not enough to protect a user's life savings.
Fortunately, with ZK-SNARK, we have a fourth option, which is a centralized ID processed by ZK. This type includes zk-email , Anon Aadhaar , Myna Wallet , etc. Basically, you can use various forms of centralized IDs (corporate or government) and convert them into Ethereum addresses. Only when you generate a ZK-SNARK to prove that you have the ID, you can send transactions from the address.
With this new feature, we have multiple options, and centralized IDs processed by ZK are very friendly to newcomers.
To achieve this, we need to use a streamlined integrated user interface. Users only need to specify "example@gmail.com" as the signer, and the wallet will automatically generate the corresponding zk-email Ethereum address. In addition, advanced users should be able to enter their email (and the privacy salt that may be saved in the email) in an open source third-party application and confirm that the generated address is correct. The same should be true for any other supported signer type.
It’s important to note that one practical challenge with zk-email right now is that it relies on DKIM signatures , which use keys that rotate every few months, and the keys themselves are not signed by any other authority. This means there’s a level of trust required beyond the provider itself; if zk-email used TLSNotary in trusted hardware to verify updated keys, the trust requirement could be lowered, but that’s not ideal. Hopefully, email providers will start signing DKIM keys directly. Additionally, I recommend using zk-email with just one signer, rather than a majority of signers. That way, even if zk-email crashes, you won’t lose access to your funds.
New Users and In-App Wallet
In reality, new users will not want to enter a lot of information about multi-signature wallet signers when they first register. Therefore, wallets should provide a very simple option. A natural approach is to use zk-email for 2 of the 3 signatures, that is, a key stored locally on the user's device (can be a passkey) and a backup key held by the provider. As users gain experience or accumulate assets, in some cases they will be prompted to add more signers.
Integrating wallets into apps is inevitable, as apps trying to attract non-cryptocurrency users will not want to make users download two new apps (the app itself and the Ethereum wallet) at the same time, which would create a bad user experience. Users who use multiple wallets should also be able to connect all wallets together so that they only need to worry about "access control issues." The simplest way is to adopt a hierarchical solution, where users can set their main wallet as the signer of all in-app wallets through a quick "linking" process. Currently, the Farcaster client Warpcast already supports this approach.
By default, recovery of a Warpcast account is controlled by the Warpcast team. However, users can "take over" a Farcaster account and change it to their own address.
Protect users from fraud and other external threats
In addition to account security, wallets today do a lot to identify fake addresses, phishing, scams, and other external threats, and work to protect users from such threats. However, many countermeasures are still fairly primitive. For example, sending ETH or other tokens to any new address is just a click away, whether you are sending $100 or $100,000. There is no single solution in this regard, but rather a slow series of ongoing fixes and improvements for different categories of threats. However, there is great value in continuing to work on improvements.
privacy
ZK-SNARK technology is already very advanced, and privacy technologies such as Privacy Pools that can reduce regulatory risks without relying on backdoors are becoming more mature, and secondary infrastructure such as Waku and ERC-4337 are slowly becoming more stable. However, to date, private transfers on Ethereum still require users to explicitly download and use a "privacy wallet" such as Railway (or Umbra for stealth addresses). This has caused great inconvenience to users and reduced the number of such users. The solution to this problem is to integrate such transfers directly into the wallet.
A simple way to implement this is that the wallet can store part of the user's assets as a "private balance" in a privacy pool. When a user makes a transfer, it is automatically withdrawn from the privacy pool first. If the user needs to receive funds, the wallet automatically generates a stealth address. In addition, the wallet can automatically generate a new address for each application (such as the DeFi protocol) in which the user participates. Deposits come from the privacy pool, and withdrawals go directly to the privacy pool. In this way, the user's activities in any one application are unrelated to their activities in other applications.
One advantage of this technology is that it not only achieves privacy for asset transfers, but also for identity. Currently, identity is already implemented on-chain, and any application that uses proof-of-personhood (such as Gitcoin Grants), any application that requires a specific token to chat, and the Ethereum Follow protocol are all on-chain identity. We hope that this ecosystem can also have privacy, that is, users' activities on the chain should not be collected in one place, each project should be stored separately, and the user's wallet should also be the only thing with a "global view" that can see all your proofs at the same time. Like off-chain authentication protocols such as EAS and Zupass , a native ecosystem where each user has multiple accounts helps achieve this goal.
This represents a pragmatic vision for Ethereum privacy in the medium-term future. While it can be achieved today, introducing some features at the L1 and L2 stages will make privacy-preserving transactions more efficient and reliable. Some privacy advocates believe that the only acceptable thing is for everything to be completely private, encrypting the entire EVM. But I think that this is probably the ideal outcome in the long term, requires a more fundamental rethinking of the programming model, and it is not yet mature enough to be deployed on Ethereum. We do need privacy-by-default to get enough anonymity. However, focusing on privacy for transfers between accounts, as well as identity and identity-related use cases is a pragmatic first step that is easier to achieve and can be built for wallets at this stage.
Ethereum wallets also need to be data wallets
Any effective privacy solution, whether for payments, identity, or other use cases, will result in users needing to store data off-chain. This is evident in Tornado Cash, which requires users to save each "note" representing a 0.1-100 ETH deposit. More modern privacy protocols sometimes save data encrypted on-chain and decrypt it using a single private key. However, this is risky because if the key is leaked, or quantum computers become possible, the data will be fully public. At that time, the need for off-chain data storage will become more obvious for off-chain authentication like EAS and Zupass.
Wallets need to be software that not only stores on-chain access rights, but also stores private data. This is increasingly recognized in the non-cryptocurrency world, see Tim Berners-Lee's recent work on personal data storage. All the problems we need to solve must not only strongly guarantee access rights, but also strongly guarantee the accessibility and non-leakage of data. Perhaps these two solutions can be superimposed on each other, assuming that you set up N multi-signature signers, then you can use M-of-N secret sharing between these N signers to store data. In essence, data is more difficult to ensure security because you can't revoke someone else's share of data, but we should come up with secure decentralized custody solutions as much as possible.
Secure blockchain access
Many wallets trust the RPC provider to tell them everything about the chain. This is vulnerable in two ways. First, the RPC provider may try to steal funds by providing false information (such as market prices); second, the RPC provider can extract private information about which applications and other accounts the user interacts with.
Ideally, we want to prevent both of these vulnerabilities. To prevent the first, we need standardized L1 and L2 light clients that directly verify blockchain consensus. Helios has implemented this for L1, and has done some initial work to support some specific L2s. In order to properly cover all L2s, we need a standard by which the configuration contract representing the L2 (also for a specific chain address) can publish a function (perhaps in a similar way to ERC-3668 ) that contains the logic to obtain the most recent state roots and verify state proofs and receipts based on these state roots. This way, we can have a universal light client that allows wallets to securely verify any state or event on L1 and L2.
As for the second vulnerability, the only viable solution currently is to run your own full node. However, as L2 becomes more popular, it becomes increasingly difficult to run a full node that contains everything. For this problem, the equivalent of a light client solution is Private Information Retrieval (PIR). PIR involves a server that holds a copy of all the data, and a client that sends an encrypted request to the server. The server performs computations on all the data and returns the data the client needs (encrypted with the client's key) without revealing to the server what data the client has accessed.
In order for the server to remain honest, the individual database items themselves need to be Merkle tree branches, so clients can verify them using their own light clients.
PIR is computationally expensive, but there are several ways to address this:
Brute force: Improvements in algorithms or specialized hardware could potentially make PIR fast enough. These techniques would likely rely on preprocessing, where the server stores encrypted and shuffled data for each client, which the client can query. In the Ethereum context, the main challenge is adapting these techniques to datasets that change rapidly (e.g., state changes). This would reduce real-time computational costs, but would likely increase total computational and storage costs.
Weakens privacy requirements: for example, there can only be 1 million "mixins" per query, so the server will know 1 million possible values that the client may access, but not finer granularity.
Multi-server PIR: PIR is usually much faster if multiple servers are used and 1-of-N honesty is assumed between them.
Anonymity rather than confidentiality: Requests can be sent through a mix network to hide the sender of the request, rather than the content of the request. However, doing so will inevitably increase latency and deteriorate the user experience.
In the Ethereum environment, finding a combination of technologies that can maximize privacy while maintaining practicality is an open research topic, and cryptographers are welcome to try it.
Ideal key storage wallet
In addition to transfers and state access, another important workflow that needs to run smoothly across L2 environments is changing the verification configuration of an account (whether it is changing the key or making deeper changes to the entire logic of the account). Below is a three-layer solution, with increasing difficulty:
Replay updates: When a user changes a configuration, the message authorizing the change is replayed on every chain where the wallet detects that the user owns assets. The message format and validation rules can be chain-agnostic so that it can be automatically replayed on as many chains as possible.
Key storage on L1: Configuration information is stored on L1, and the wallet on L2 reads the configuration information through L1SLOAD or REMOTESTATICCALL . In this way, you only need to update the configuration on L1, and the configuration will automatically take effect.
Key storage on L2: Configuration information is stored on L2, and wallets on L2 read configuration information through ZK-SNARK. This is the same as case (2), except that the cost of updating key storage is lower, while the cost of reading is higher.
The third solution is particularly powerful because it stacks well with privacy. In the ordinary "privacy solution", suppose the user has a secret s and publishes a "leaf value" L on the chain. The user proves that L = hash(s,1) and N = hash(s,2) is some (never-disclosed) secret under their control. N is published to ensure that future spending on the same Leaf will not fail and will not reveal L. In the account recovery-friendly privacy solution, s is a location on the chain (such as an address and storage slot), and the user must prove the state query, that is, L = hash(sload(s), 1).
DApp Security
The weakest link in user security is often the DApp. Most of the time, users interact with the app by visiting a website, which downloads the user interface code from the server in real time and then executes it in the browser. If the server is hacked, or the DNS is hacked, the user will get a fake copy of the interface, which can trick the user into doing something arbitrary. Wallet features such as transaction simulation are helpful in reducing risk, but they are far from enough.
Ideally, we need to move the ecosystem to on-chain content versions, where users will access DApps by their ENS name, which will contain the IPFS hash of the interface. To update the interface, an on-chain transaction from a multi-ID or DAO is required. Wallets will show users whether they are interacting with a more secure on-chain interface or a less secure Web2 interface. Wallets can also show users whether they are interacting with a secure blockchain (e.g., stage 1+, multiple security audits).
For privacy-conscious users, wallets could also be tougher, requiring users to click to accept HTTP requests, not just Web3 operations.
A more advanced approach is to go beyond HTML + Javascript and write the business logic of the DApp in a dedicated language, such as a relatively lightweight language overlaid on Solidity or Vyper. In this way, the browser can automatically generate a user interface for any required functions. OKContract has already done this. Another direction is crypto-economic information defense, that is, DApp developers, security companies, on-chain deployers, and others can set up a deposit. If the DApp is hacked or otherwise harms users in a highly misleading way, the deposit will be paid to the affected users after the on-chain arbitration DAO makes a decision. Wallets can display scores based on the size of the deposit to users.
The Longer Future
All of the above is done in a traditional context, but we are now on the verge of a profound paradigm shift:
Artificial intelligence (AI) may enable us to move from a “click and type” model to a “say and bot figures it out” model.
Brain-computer interfaces: These range from relatively “gentle” methods like eye tracking to more direct and even invasive techniques (like the first Neuralink patient )
Client-side active defense: Brave Browser actively protects users from ads, trackers, and many other bad actors. Many browsers, plugins, and cryptocurrency wallets have entire teams actively protecting users from a variety of security and privacy threats. These “active guardians” will become even more powerful over the next decade.
Together, these three trends will prompt a deeper rethinking of how wallets work. Through natural language input, eye tracking, or ultimately more direct biometrics (BCI), coupled with knowledge of the user's history, the "wallet" will intuitively know exactly what the user wants to do. The AI can then translate this intuition into a specific "action plan," such as a series of on-chain and off-chain interactions to achieve the user's intent. This can greatly reduce the need for third-party user interfaces. If the user does interact with a third-party application (or other users), the AI should also think adversarially on the user's behalf, identifying any threats and proposing an action plan to avoid them. Ideally, these AIs will form an open ecosystem, generated by different groups with different biases and incentive structures.
Of course, these more radical ideas rely on technology that is currently very immature, so I would not put my assets in a wallet that relies on this technology. However, this type of technology seems to be the trend of the future, so it is worth starting to explore more actively in this direction.