Written by: Vitalik Buterin
Compiled by: Yangz, Techub News
Wallets are a crucial layer in the Ethereum infrastructure stack, but they are often undervalued by core L1 researchers and developers. Wallets are the window for users into the Ethereum world, and users can only benefit if the wallet itself also has the characteristics of decentralization, censorship resistance, security, privacy, or other features provided by Ethereum and its applications. In recent years, we have seen significant progress in Ethereum ecosystem wallets in improving user experience, security, and functionality. The purpose of this article is to share my personal views on some attributes that an ideal Ethereum wallet should have. This list will not be exhaustive but reflects my crypto-punk tendencies. For wallets, I prioritize security and privacy, as there is unlikely to be a perfect wallet in terms of user experience. I believe that wish lists are not as effective for optimizing user experience as deploying and iterating based on feedback. In my view, focusing on security and privacy attributes is the most valuable approach.
User experience of cross-L2 transactions
Currently, the route to improving cross-L2 user experiences is becoming increasingly detailed, with both short-term and long-term components. Here, I want to discuss the short-term component, which theoretically can be realized even today. The core idea of this part is to build cross-L2 transactions along with specific chain addresses and payment requests. Wallets should provide such an address:
When someone (or some application) provides you with this format of address, you should be able to paste it into the wallet's 'to' field and then click 'send', and the wallet will automatically handle it:
If the target chain already has enough of the required type of token, send directly;
If you have the required type of token on another chain (or multiple chains), you can send tokens using a protocol similar to ERC-7683 (essentially 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 tokens on the correct chain and send them. Of course, this also requires the user's explicit permission, meaning the user will see how much they paid and how much the receiver received.
The above is the use case for 'copy and paste address (or ENS, such as vitalik.eth@optimism.eth) for someone to pay you'. If it is a deposit to a DApp (see the Polymarket example), the ideal process is to extend the Web3 API to allow DApps to make payment requests for specific chains. This way, the user wallet can fulfill the request in any way. To ensure a good user experience, it is also necessary to standardize getAvailableBalance requests, and the wallet needs to consider which chain to default store the user's assets on for maximum security and ease of transfer. Payment requests for specific chains can also be placed in QR codes for mobile wallets to scan directly. In face-to-face (or online) payment scenarios, the recipient can call 'I want X units of Y token on Z chain with reference ID or callback W' via QR code or Web3 API, and the wallet can freely 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 task is to figure out how to transfer those funds to their own wallet. Another relevant topic is gas payment. If you receive assets on an L2 where you do not yet have ETH and need to send a transaction on that L2, the wallet should automatically use a protocol (such as RIP-7755) to pay gas on the chain where you have ETH. If the wallet anticipates that you will conduct more transactions on that L2 in the future, it should also use DEX to send ETH worth millions in gas so that future transactions can be completed directly with gas (making it cheaper).
Account security
My understanding of the challenges of account security is that a good wallet should protect users from hacking or malicious attacks by wallet developers, and also shield users from their own mistakes.
The typo 'mistakles' on the vertical axis is an inadvertent mistake. I feel this error fits the context well, so I did not modify it. For over a decade, my preferred solution has been social recovery and multi-sign wallets, using hierarchical access control. A single user account is set up with 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, to perform high-value operations, such as sending all assets in the account or changing the master key or any signer, the participation of the majority of signers is required. If necessary, the master key can be allowed to perform high-value operations with a time lock. This is just a basic design; we can further expand on it. For example, session keys and permission mechanisms (like ERC-7715) can help support different applications in achieving different balances between convenience and security. More complex signer architectures, such as setting multiple time lock durations under different thresholds, help maximize the chances of successfully recovering legitimate accounts while minimizing the risk of theft.
Who should the signers of a multi-sign wallet be?
For experienced cryptocurrency users, a viable option is your friends and family. In fact, your multi-sign wallet signers do not even need to know who each other are. The likelihood of them colluding without your knowledge is extremely low. However, this option is not feasible for most new users. The second option is institutions, those companies that specifically provide these services. Such signers only sign transactions after receiving other confirmation information (like confirmation codes or video calls with high-net-worth users). For a long time, people have been trying to create such companies; for example, I introduced CryptoCorp in 2013. However, so far, such companies have not had very successful representatives. The third option is to use multiple personal devices (such as mobile phones, desktops, hardware wallets). This method can work, but it is also challenging for inexperienced users to set up and manage. Additionally, there is a risk of devices being lost or stolen simultaneously, especially when they are in the same location. Recently, we have begun to see more passkey-based wallets emerging. Passkeys can be backed up only on devices, making them a personal-to-device solution, or they can be backed up in the cloud, making their security depend on a complex mix of password security, institutions, and trusted hardware assumptions. In practice, passkeys provide a valuable security gain for ordinary users, but they alone are not enough to protect users' life savings. Fortunately, with ZK-SNARK, we have a fourth option, which is centralized ID processed by ZK. This type includes zk-email, Anon Aadhaar, Myna Wallet, etc. Basically, you can use various forms of (corporate or government) centralized ID and convert them into Ethereum addresses, allowing you to send transactions from that address only by generating ZK-SNARK proofs of owning that ID.
With this new feature, we have multiple options, and the ZK-processed centralized ID is very user-friendly for newcomers. To achieve this, we need a streamlined integrated user interface. Users simply specify 'example@gmail.com' as a signer, and the wallet will automatically generate the corresponding zk-email Ethereum address. Additionally, advanced users should be able to input their email (and possibly privacy salts that may be stored in the email) in open-source third-party applications and confirm that the generated address is correct. Any other supported signer types should work similarly.
It is important to note that a practical challenge currently facing zk-email is its reliance on DKIM signatures, which rotate every few months and do not have signatures from any other entities. This means there is a degree of trust required beyond just the provider; if zk-email uses TLSNotary to verify updated keys in trusted hardware, it can reduce trust requirements, but this is not ideal. It is hoped that email providers will start directly signing DKIM keys. Additionally, I recommend using zk-email with only one signer rather than most signers. This way, even if zk-email collapses, access to funds will not be lost.
New users and in-app wallets
In reality, new users will not want to input a lot of information about multi-sign wallet signers at the time of initial registration. Therefore, wallets should provide a very simple option. One natural approach is to have 2 out of 3 signatures use zk-email, which are keys stored locally on the user's device (which can be a passkey) and a backup key held by the provider. As users gain experience or accumulate assets, they may be prompted to add more signers in certain cases. Integrating wallets into applications is inevitable because applications trying to attract non-cryptocurrency users would not want to require users to download two new applications (the application itself and the Ethereum wallet), which would lead to a poor user experience. Users with multiple wallets should also be able to connect all their wallets together, so they only need to worry about 'access control issues'. The simplest method is to adopt a hierarchical scheme where, through a quick 'linking' process, users can set their main wallet as the signer for all in-app wallets. Currently, the Farcaster client Warpcast supports this method.
By default, the recovery of Warpcast accounts is controlled by the Warpcast team. However, users can 'take over' the Farcaster account and change it to their own address.
Protecting users from fraud and other external threats
Apart from account security, modern wallets are doing a lot to identify fake addresses, phishing, scams, and other external threats, striving to protect users against such threats. However, many countermeasures are still quite primitive. For example, sending ETH or other tokens to any new address is as simple as clicking a button, regardless of whether the amount is $100 or $100,000. There is no single solution for this; instead, a series of gradual, ongoing fixes and improvements need to be made for different categories of threats. However, the continued effort to improve is highly valuable.
Privacy
ZK-SNARK technology is already quite advanced, and privacy technologies like Privacy Pools, which can lower regulatory risks without backdoors, are becoming increasingly mature. Secondary infrastructures like Waku and ERC-4337 are also gradually stabilizing. However, up to now, private transfers on Ethereum still require users to explicitly download and use 'privacy wallets', such as Railway (or for stealth addresses, Umbra). This creates significant inconvenience for users and reduces the number of such users. A solution to this issue is to integrate such transfers directly into wallets. A simple implementation method would be for the wallet to store a portion of the user's assets as 'private balances' in privacy pools. When a user makes a transfer, it would automatically first withdraw from the privacy pool. If users need to receive funds, the wallet would automatically generate a stealth address. Additionally, the wallet can automatically generate a new address for each application the user participates in (like DeFi protocols). Deposits come from the privacy pool, and withdrawals go directly into the privacy pool. This way, the user's activities in any application are isolated from their activities in other applications.
One advantage of this technology is that it not only achieves privacy for asset transfers but also for identity verification. Currently, identity verification is implemented on-chain, where any application using proof-of-personhood (like Gitcoin Grants), any that requires specific tokens to chat, and protocols like Ethereum Follow, are all forms of on-chain identity verification. We hope this ecosystem will also have privacy, meaning users' on-chain activities should not be collected in one place; each project should store data separately, and users' wallets should be the only thing with a 'global view' to see all their proofs simultaneously. Native ecosystems where each user has multiple accounts, like off-chain authentication protocols such as EAS and Zupass, contribute to this goal. This represents a pragmatic vision for Ethereum privacy in the medium-term future. Although it can be achieved today, introducing some features at the L1 and L2 stages will make privacy-protecting transactions more efficient and reliable. Some privacy advocates argue that the only acceptable solution is to completely privatize everything and encrypt the entire EVM. However, I believe this may be a long-term ideal outcome that requires a more fundamental rethink of the programming model and is currently not mature enough to deploy on Ethereum. We do need 'default privacy' to achieve a sufficiently large anonymity. However, focusing on the privacy of transfers between accounts, as well as identity and identity-related use cases, is a pragmatic first step that is easier to realize and can be a starting point for building wallets at this stage.
Ethereum wallets also need to become data wallets.
Any effective privacy solution, whether for payments, identity verification, or other use cases, requires users to store off-chain data. This is clearly evident in Tornado Cash, which requires users to save each 'note' representing deposits of 0.1-100 ETH. More modern privacy protocols sometimes store encrypted data on-chain and use a single private key for decryption. However, this is risky because if the key is compromised, or if quantum computing becomes viable, all data would be exposed. At that point, off-chain authentication solutions like EAS and Zupass will highlight the need for off-chain data storage. Wallets need to not only act as software for storing on-chain access but also for storing private data. This recognition is increasing in the non-cryptocurrency world, as seen in Tim Berners-Lee's recent research on personal data storage. All the issues we need to address must strongly guarantee control over access rights while also ensuring data accessibility and non-disclosure. Perhaps these two solutions can be layered together; if you set up N multi-signers, you could use M-of-N secret sharing among these N signers to store data. Essentially, securing the data becomes more challenging because you cannot revoke others' data shares, but we should propose secure decentralized custody solutions whenever possible.
Secure blockchain access
Many wallets trust that RPC providers will tell them any information about the chain. There are vulnerabilities in this regard on two fronts. First, RPC providers may try to steal funds by providing false information (like market prices); second, RPC providers can extract private information about which applications and other accounts users interact with. Ideally, we need to prevent these two vulnerabilities from occurring. To prevent the first vulnerability, we need standardized L1 and L2 light clients that directly verify blockchain consensus. Helios has implemented this for L1 and has begun preliminary work to support some specific L2s. To adequately cover all L2s, we need a standard through which L2's configuration contracts (also used for specific chain addresses) can publish a function (perhaps in a manner similar to ERC-3668) that contains the logic for obtaining the latest state root and verifying state proofs and receipts based on those 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 method currently is to run your own full node. However, as L2s become more popular, running a full node that includes everything becomes increasingly difficult. In response to this issue, a solution comparable to the light client is Private Information Retrieval (PIR). PIR involves a server that holds all data copies and a client that sends encrypted requests to the server. The server performs calculations on all data and returns the data the client needs (encrypted with the client's keys), without revealing what data the client accessed to the server.
To keep the server honest, the individual database projects themselves need to be Merkle tree branches so that the client can verify them with its own light client. The computational cost of PIR is high, but there are several ways to address this problem:
Brute force: Improvements in algorithms or dedicated hardware may enable PIR to run fast enough. These techniques may rely on preprocessing, where the server stores encrypted and shuffled data for each client, allowing the client to query this data. In the Ethereum environment, the main challenge is how to adapt these techniques to rapidly changing data sets (such as state changes). This would reduce real-time computation costs but likely increase overall computational and storage costs.
Weakening privacy requirements: For example, there can only be 1 million 'mixins' per query, so the server will know the million possible values the client could access, but not the finer granularity.
Multi-server PIR: If multiple servers are used, and assuming their honesty is 1-of-N, the speed of the PIR algorithm can often be much faster.
Anonymity rather than confidentiality: Requests can be sent through a mixing network, hiding the request's sender rather than the request's content. However, this will inevitably increase latency and degrade user experience.
In the Ethereum environment, finding a technical combination that maximizes privacy while maintaining practicality is an open research topic, and cryptographers are encouraged to experiment.
Ideal key storage wallet
In addition to transfer and state access, another important workflow that needs to run smoothly in a cross-L2 environment is changing the account's verification configuration (whether changing keys or making deeper changes to the account's overall logic). Here are three layered solutions, increasing in difficulty:
Replay updates: When a user changes configuration, the message authorizing the change will be replayed on every chain where the user has assets, as detected by the wallet. The information format and verification rules may be chain agnostic, allowing for automatic replay on as many chains as possible.
Key storage on L1: Configuration information is stored on L1, and wallets on L2 read the configuration information via L1SLOAD or REMOTESTATICCALL. This way, configuration is automatically effective with just an update on L1.
Key storage on L2: Configuration information is stored on L2, and wallets on L2 read configuration information through ZK-SNARK. This is similar to the second case, but the cost of updating key storage is lower, while the cost of reading it is higher.
The third solution is particularly powerful because it stacks well with privacy. In a typical 'privacy solution', let’s assume the user has a secret s, and publishes a 'leaf value' L on-chain. The user proves that L = hash(s,1) and N = hash(s,2) is a certain (never publicly disclosed) secret that they control. N will be published to ensure future spending of the same Leaf does not fail and does not leak L. In a privacy solution that is friendly to account recovery, s is a location on-chain (like an address and storage slot), and the user must prove state queries, i.e., L = hash(sload(s), 1).
DApp security
The weakest link in user security often lies with DApps. Most of the time, users interact with applications by accessing websites, which download user interface code from servers in real-time and execute it in the browser. If the server is hacked or if the DNS is attacked, users receive a fake version of the interface, which can mislead them into doing arbitrary things. Wallet features like transaction simulation help reduce risk but are far from sufficient. Ideally, we need to transition the ecosystem to a chain-based content version, where users access DApps through their ENS name, which will contain the IPFS hash of the interface. To update the interface, on-chain transactions from multiple IDs or DAOs will be 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 indicate whether users are interacting with a secure blockchain (for example, stage 1+, multiple security audits). For privacy-conscious users, wallets can be stricter, requiring users to click to accept HTTP requests rather than just Web3 operations.
A more advanced approach is to go beyond HTML + Javascript and write the business logic of DApps in a dedicated language, such as overlaying a relatively lightweight language on Solidity or Vyper. This way, the browser can automatically generate a user interface for any needed functionality. OKContract has done this. Another direction is cryptoeconomic information defenses, where DApp developers, security firms, on-chain deployers, and others can set up a bond that will pay affected users after a DAO decision if the DApp is hacked or otherwise harms users through highly misleading means. Wallets can show users ratings based on the size of the bond.
Long-term future
All of the above is conducted in a traditional context, and we are currently on the brink of a profound change in paradigm:
Artificial intelligence (AI) may shift us from a 'click and type' model to a 'say and bot figures it out' model.
Brain-computer interfaces: Including relatively 'gentle' methods like eye tracking and more direct, even invasive technologies (like the first Neuralink patient).
Client participation in active defense: The Brave browser actively protects users from ads, trackers, and many other malicious entities. Many browsers, plugins, and cryptocurrency wallets have entire teams actively protecting users from various security and privacy threats. In the next decade, such 'active guardians' will become even more powerful.
These three trends combined will prompt deeper reflection on how wallets operate. Through natural language input, eye tracking, or finally more direct biometric interfaces (BCI), combined with an understanding of user history, 'wallets' will intuitively know what users want to do. Then, AI can translate this intuition into concrete 'action plans', such as a series of on-chain and off-chain interactions that realize user intent. This could greatly reduce the need for third-party user interfaces. If users do interact with third-party applications (or other users), AI should also engage in adversarial thinking on behalf of the user, identifying any threats and proposing action plans to avoid those threats. Ideally, these AIs would form an open ecosystem generated by different groups with varying biases and incentive structures. Of course, these more radical ideas rely on technologies that are currently immature, so I would not place my assets in a wallet dependent on these technologies. However, such technologies seem to be a trend for the future, making it worthwhile to start exploring this direction more actively.
Author: TechubNews; from the chain-deed content open platform 'Deed Number', this article only represents the author's viewpoint and does not represent the official position of Chain Deed. All contributions to 'Deed Number' guarantee originality and content authenticity. If the submission leads to legal consequences due to plagiarism, forgery, etc., the submitter will be responsible. Articles published by Deed Number will be taken offline immediately upon confirmation of infringement, violations, or other inappropriate content. For any issues with the article's content, please contact WeChat: chaindd123.
