Written by: Vitalik Buterin Translated by: Yangz, Techub News The wallet is a critical layer in the Ethereum infrastructure stack, but it is often not taken seriously by core L1 researchers and developers. The wallet is the window between the user and the Ethereum world, and the user can only benefit from it if the wallet itself is also decentralized, censorship-resistant, secure, private, or other features provided by Ethereum and its applications. In recent years, we have seen great progress in improving the user experience, security, and functionality of Ethereum ecosystem 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 pay more attention to security and privacy, because there is almost no perfect wallet in terms of user experience. I think that wish lists are not as effective as simply deploying and iterating based on feedback for optimizing user experience. In my opinion, focusing on security and privacy properties is the most valuable. User experience of cross-L2 transactions The current route to improve the cross-L2 user experience has become increasingly detailed, and there are short-term and long-term parts. Here, I want to talk about the short-term part, that is, ideas that can be achieved in theory even today. The core idea of this part is to build in cross-L2 transactions as well as 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 a DEX to convert them to 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 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. The user wallet can then 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 to store the user's assets 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 recipient 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 recipient'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 for high-net-worth users). 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-SNARKs, 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 many forms of centralized IDs (corporate or government) and turn them into Ethereum addresses, and you can only send transactions from this address if you generate a ZK-SNARK to prove that you have this ID.
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 own 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 those keys themselves aren’t 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. 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 sign up. Therefore, wallets should provide a very simple option. A natural approach is to use zk-email for 2 of the 3 signatures, i.e. 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, they will be prompted to add more signers in some cases.
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, 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 a single click, 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, privacy technologies such as Privacy Pools that reduce regulatory risk 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 will 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 with multiple accounts per user 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 long-term ideal outcome, 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 are not only to strongly guarantee access rights, but also to 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 whereby a configuration contract representing an L2 (also for a specific chain address) can publish a function (perhaps in a similar fashion to ERC-3668) that contains the logic to fetch the most recent state roots, and verify state proofs and receipts against those state roots. This way, we can have a universal light client that allows wallets to securely verify any state or event on both 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. A comparable solution to this problem 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.
Weakened 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: The PIR algorithm is usually much faster if multiple servers are used and 1-of-N honesty is assumed between these servers.
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 authentication configuration of an account (whether it is changing keys or making deeper changes to the entire logic of the account). Below is a three-tier 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 saved 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 vanilla "privacy solution", suppose a user has a secret s and publishes a "leaf value" L on-chain, and the user proves that L = hash(s,1) and N = hash(s,2) are some (never-published) secret under their control. N is published to ensure that future spending on the same Leaf does not fail and does 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 UI code from a server in real time and then executes it in the browser. If the server is hacked, or the DNS is hacked, the user gets a fake copy of the interface that tricks the user into doing something arbitrary. Wallet features like transaction simulation are helpful in reducing risk, but they are not 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 if they are interacting with a secure blockchain (e.g., stage 1+, multi-security audit).
For privacy-conscious users, wallets could also be tougher and require 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 adjudication 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 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 extremely immature, so I would not keep my assets in a wallet that relies on it. However, this type of technology seems to be the wave of the future, so it is worth starting to explore more actively in this direction.
