A wallet is the window between users and the Ethereum world, and I believe that focusing on security and privacy attributes is the most valuable.
Special thanks to Liraz Siri, Yoav Weiss, and the feedback and reviews from developers at ImToken, Metamask, and OKX.
A key layer of the Ethereum infrastructure stack is the wallet, which is often underestimated by core L1 researchers and developers. The wallet is the window between users and the Ethereum world, and users can only benefit from any decentralized, censorship-resistant, secure, private, or other attributes offered by Ethereum and its applications, provided that the wallet itself also possesses these attributes.
Recently, we have seen significant progress in Ethereum wallets in terms of improving user experience, security, and functionality. The purpose of this article is to provide my own views on some characteristics that an ideal Ethereum wallet should have. This is not an exhaustive list; it reflects my crypto-punk tendencies, focusing on security and privacy, and it is almost certainly incomplete in terms of user experience. However, I believe that a wish list is less effective in optimizing user experience than simply deploying and iterating based on feedback, so I think focusing on security and privacy attributes is the most valuable.
User Experience for Cross-L2 Transactions
There is now an increasingly detailed roadmap for improving the cross-L2 user experience, which has both short-term and long-term components. Here, I will discuss the short-term component: ideas that can theoretically still be implemented today.
The core idea is (i) built-in cross-L2 sending, and (ii) chain-specific addresses and payment requests. Your wallet should be able to provide you with an address (following the style of this ERC draft), as shown below:
When someone (or some application) provides you with an address in this format, you should be able to paste it into the wallet's "recipient" field and then click "send." The wallet should automatically handle the sending data in any possible way:
If you already have enough of the required type of token on the target chain, send the token directly.
If you have the required type of token on another chain (or multiple other chains), use protocols like ERC-7683 (essentially a cross-chain DEX) to send the token.
If you have different types of tokens on the same chain or other chains, use a decentralized exchange to convert them into the correct type of currency on the correct chain and send it. This should require explicit permission from the user: the user will see how much they are paying in fees and how much the recipient receives.
A model of a possible wallet interface with cross-chain address support
The above applies to the use case of "you copy and paste an address (or ENS, e.g., vitalik.eth @ optimism.eth) for someone to pay you." If a dapp requests a deposit (for example, see this Polymarket example), then the ideal flow is to extend the web3 API and allow the dapp to issue chain-specific payment requests. Then, your wallet will be able to fulfill that request in any needed way. To ensure a good user experience, it is also necessary to standardize the getAvailableBalance request, and the wallet needs to seriously consider which chains to default to for storing user assets to maximize security and transfer convenience.
Chain-specific payment requests can also be embedded in QR codes, which mobile wallets can scan. In face-to-face (or online) consumer payment scenarios, the recipient will issue a QR code or web3 API call indicating "I want X units of token Y Z on-chain, with reference ID or callback W," and the wallet will be free to fulfill that request in any way. Another option is the claim link protocol, where the user's wallet generates a QR code or URL containing a claim authorization to retrieve a certain amount of funds from their chain contract, and the recipient's job is to figure out how to transfer those funds to their own wallet.
Another related topic is gas payment. If you receive assets on an L2 where you do not have ETH and need to send a transaction on that L2, the wallet should be able to automatically use protocols (like RIP-7755) to pay for gas on the chain where you have ETH. If the wallet wants you to conduct more transactions on L2 in the future, it should also use DEX to send, for example, ETH worth millions of gas so that future transactions can spend gas directly there (as it is cheaper).
Account Security
One way I conceptualize the challenges of account security is that a good wallet should serve two functions: (i) protect users from hacks or malicious attacks by wallet developers, and (ii) protect users from the consequences of their own mistakes.
The "mistake" on the left is unintentional. However, when I saw it, I realized it fit the context very well, so I decided to keep it.
My preferred solution to this, for over a decade, has been social recovery and multi-signature wallets with hierarchical access control. User accounts have two layers of keys: a master key and N guardians (e.g., N = 5). The master key is capable of performing low-value and non-financial operations. Most guardians need to execute (i) high-value operations, such as sending the entire value in the account, or (ii) changing the master key or any guardian. If necessary, the master key can be allowed to perform high-value operations through a time lock.
The above is a basic design that can be expanded. Session keys and permission mechanisms like ERC-7715 can help support different balances between convenience and security for various applications. More complex guardian architectures, such as having multiple time lock durations at different thresholds, can help maximize the chances of successfully recovering a legitimate account while minimizing the risk of theft.
Who or what should the guardians be?
For experienced users in the cryptocurrency community, a viable option is the keys of your friends and family. If you ask everyone to provide you with a new address, then no one needs to know who they are - in fact, your guardians do not even need to know each other. If they do not leak information to you, the likelihood of them colluding is very low. However, this option is not available for most new users.
The second option is institutional guardians: companies that provide services that only sign transactions upon receiving additional confirmation information from you, such as a confirmation code or a video call for high-value users. People have long tried to create these, for example, I introduced CryptoCorp in 2013. However, so far, these companies have not been very successful.
The third option is multiple personal devices (e.g., phone, desktop, hardware wallet). This 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 simultaneously, especially if they are located in the same place.
Recently, we have begun to see more based on master keys. Keys can only be backed up on your device, making it a personal device solution, and can also be backed up in the cloud, making its security rely on complex hybrid password security, institutional, and trusted hardware assumptions. In practice, keys provide a valuable security gain for ordinary users, but relying solely on them is still insufficient to protect users' life savings.
Fortunately, with ZK-SNARKs, we have a fourth option: ZK-wrapped centralized ID. This type includes zk-email, Anon Aadhaar, Myna Wallet, and so on. Essentially, you can take various forms of centralized ID (from companies or governments) and convert them into Ethereum addresses, allowing you to send transactions only by generating a proof of ownership of the centralized ID using ZK-SNARKs.
With this addition, we now have a wide range of options, and ZK-wrapped centralized IDs have a unique "newbie-friendliness."
To achieve this, it needs to be implemented through a simplified and integrated UI: you should be able to specify that you want "example@gmail.com" as a guardian, and it should automatically generate the corresponding zk-email Ethereum address under the hood. Advanced users should be able to input their email (and possibly the privacy salt stored in that email) into an open-source third-party application and confirm that the generated address is correct. This should also apply to any other supported guardian types.
Note that a practical challenge zk-email faces today is its reliance on DKIM signatures, which use keys that rotate every few months, and these keys themselves are not signed by any other authority. This means that today's zk-email has a level of trust requirement that extends beyond the provider itself; if zk-email were to use TLSNotary to verify updated keys within trusted hardware, this could mitigate the issue, but it is not ideal. It is hoped that email providers will begin to directly sign their DKIM keys. Today, I recommend using zk-email as a guardian, but I do not recommend it for most guardians: do not store funds in zk-email as a failure means you cannot access the funds.
New Users and In-App Wallets
New users do not actually want to input a large number of guardians at first registration. Therefore, the wallet should provide them with a very simple option. A natural approach is to use zk-email on their email address, a key stored locally on the user's device (possibly a master key), and a backup key held by the provider, creating a 2-of-3 choice. As users become more experienced or accumulate more assets, they should be prompted at some point to add more guardians.
Wallet integration into applications is inevitable, as applications trying to attract non-crypto users do not want users to download two new applications (the application itself, plus the Ethereum wallet), which creates a confusing user experience. However, many app wallet users should be able to link all their wallets together, so they only have to worry about one "access control issue." The simplest way is to adopt a hierarchical scheme where there is a quick "link" process that allows users to set their main wallet as a guardian for all in-app wallets. The Farcaster client Warpcast already supports this:
By default, the recovery of your Warpcast account is controlled by the Warpcast team. However, you can "take over" your Farcaster account and change the recovery to your own address.
Protecting Users from Scams and Other External Threats
In addition to account security, today's wallets do a lot of work to identify fake addresses, phishing, scams, and other external threats, and strive to protect users from such threats. Meanwhile, many countermeasures are still quite primitive: for example, requiring a click to send ETH or other tokens to any new address, regardless of whether you are sending $100 or $100,000. There is no single silver bullet here. It is a series of slow, ongoing fixes and improvements aimed at different categories of threats. However, continuing to work on improvements here has a lot of value.
Privacy
It is now time to start taking Ethereum's privacy more seriously. The ZK-SNARK technology is now very advanced, and privacy technologies that do not rely on backdoors to reduce regulatory risks (such as privacy pools) are becoming increasingly mature, while secondary infrastructures like Waku and ERC-4337 mempools are slowly becoming more stable. However, so far, conducting private transfers on Ethereum requires users to explicitly download and use "privacy wallets," such as Railway (or for stealth addresses like Umbra). This adds significant inconvenience and reduces the number of people willing to conduct private transfers. The solution is that private transfers need to be directly integrated into wallets.
A simple implementation is as follows. The wallet can store a portion of the user's assets as a "private balance" in a privacy pool. When users conduct transfers, they will automatically exit the privacy pool first. If users need to receive funds, the wallet can automatically generate a stealth address.
Additionally, the wallet can automatically generate a new address for each application the user participates in (e.g., DeFi protocols). Deposits will come from the privacy pool, and withdrawals will go directly into the privacy pool. This allows the user's activities in any one application to be unlinkable from their activities in other applications.
One advantage of this technology is that it is not only a natural way to protect the privacy of asset transfers but also a natural way to protect the privacy of identity. Identities are already occurring on-chain: any application that uses identity proof gating (e.g., Gitcoin Grants), any token-gated chat, Ethereum follow protocols, etc., are all on-chain identities. We hope this ecosystem can also protect privacy. This means that users' on-chain activities should not be collected in one place: each project should store data separately, and the user's wallet should be the only thing with a "global view" that can see all of your proofs simultaneously. A native ecosystem where each user has multiple accounts helps achieve this, as do off-chain proof protocols like EAS and Zupass.
This represents a pragmatic vision for Ethereum privacy in the medium term. While some features can be introduced on L1 and L2 to make privacy-preserving transfers more efficient and reliable, it can be achieved right now. Some privacy advocates argue that the only acceptable thing is complete privacy for everything: encrypting the entire EVM. I think this may be the ideal long-term outcome, but it requires a more fundamental rethinking of the programming model, and we are not yet at a level of maturity ready to deploy on Ethereum. We do need default privacy to achieve a sufficiently large anonymous set. However, focusing first on (i) transfers between accounts, and (ii) identity and identity-related use cases (such as private proofs) is a pragmatic first step that is easier to implement, and wallets can start using it now.
Ethereum Wallets Also Need to Become Data Wallets
One consequence of any effective privacy solution is that, whether for payments, identity, or other use cases, it creates a demand for users to store off-chain data. This is evident in Tornado Cash, which requires users to keep a "receipt" for each deposit representing 0.1-100 ETH. More modern privacy protocols sometimes store encrypted data on-chain and use a single private key to decrypt it. This is risky because if the key is leaked, or if quantum computers become viable, the data will be fully exposed. The demand for off-chain data storage is even more apparent with off-chain proof protocols like EAS and Zupass.
Wallets need to become not only software for storing on-chain access rights but also software for storing your private data. The non-crypto world is increasingly recognizing this, for example, see Tim Berners-Lee's recent work on personal data storage. All the issues we need to solve around robust guarantees of access control, we also need to solve around robust guarantees of data accessibility and non-leakage. Perhaps these solutions can stack together: if you have N guardians, use M-of-N secret sharing among these N guardians to store your data. Data is inherently harder to protect because you cannot revoke someone's data share, but we should propose the most secure decentralized custody solutions possible.
Secure Chain Access
Today, wallets trust their RPC providers to tell them any information about the chain. This is a vulnerability with two aspects:
RPC providers may attempt to steal money by providing them with false information, e.g., about market prices.
RPC providers can extract private information about the applications and other accounts the user is interacting with.
Ideally, we want to close these two vulnerabilities. To address the first issue, we need standardized light clients for L1 and L2 that can directly verify blockchain consensus. Helios has already done this for L1 and has been doing some preliminary work to support specific L2s. To properly cover all L2s, we need a standard through which the configuration contract representing L2 (also used for chain-specific addresses) can declare a function, possibly in a manner similar to ERC-3668, that includes the logic for obtaining the latest state root and verifying proofs of state and receipts for 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.
For privacy, the only practical method today is to run your own full node. However, as L2s come into the spotlight, running full nodes for everything becomes increasingly difficult. The equivalent of a light client here is Private Information Retrieval (PIR). PIR involves servers that hold copies of all data and clients that send encrypted requests to the servers. The server performs computations on all data and returns the requested data to the client, encrypted with the client's key, without revealing which data the client accessed.
To keep the server honest, various database projects themselves are Merkle trees, allowing clients to use light clients to verify them.
The computational load of PIR is quite high. There are several ways to address this issue:
Brute Force: Improvements in algorithms or dedicated hardware may allow PIR to run fast enough. These techniques may rely on preprocessing: the server can store encrypted and shuffled data for each client, and the client can query that data. The main challenge in the Ethereum environment is adapting these techniques to rapidly changing datasets (like national data). This reduces the cost of real-time computation but likely increases the total computation and storage costs.
Relaxing Privacy Requirements: For example, each lookup can only have 1 million "mixins," so the server will know the million possible values the client can access but will not know any finer granularity.
Multi-Server PIR: If you use multiple servers and the honesty assumption between these servers is 1-of-N, then the PIR algorithm is generally faster.
Anonymity Instead of Confidentiality: Requests can be sent through mixing networks, thereby hiding the sender of the request rather than hiding the content of the request. However, doing this effectively will inevitably increase latency, worsening the user experience.
Finding the right combination of technologies in the Ethereum environment to maximize privacy while maintaining practicality is an open research question, and I welcome cryptographers to attempt this.
Ideal Key Vault Wallet
In addition to transfer and state access, another important workflow that needs to work smoothly across L2 contexts is changing the verification configuration of an account: whether changing its keys (e.g., recovery) or making deeper changes to the account's entire logic. Here are three layered solutions, arranged in increasing order of difficulty:
Replay Updates: When a user changes their configuration, the message authorizing this change will be replayed on every chain where the wallet detects the user has assets. It is possible that the message format and verification rules can be independent of the chain, allowing for automatic replay on as many chains as possible.
Key Vault on L1: Configuration information is located on L1, and wallets on L2 use L1SLOAD to read it or remote static calls. This way, only the configuration needs to be updated on L1, and it will automatically take effect.
Key Vault on L2: Configuration information exists on L2, and wallets on L2 use ZK-SNARK to read it. This is similar to (2), except that updating the key vault may be cheaper, while reading it is more expensive on the other hand.
Solution (3) is particularly powerful because it aligns well with privacy. In a typical "privacy solution," the user has a secret s, publishes a "leaf value" L on-chain, and the user proves that L = hash(s, 1) and N = hash(s, 2) for some (never revealed) secret they control. The invalid symbol N is published, ensuring that future spending of the same leaf will fail without revealing L, which depends on the user's security of s. A recovery-friendly privacy solution would state that s is a location (e.g., address and storage slot) on-chain, and the user must prove the state query: L = hash(sload(s), 1).
Dapp Security
The weakest link in user security is often the dapp. Most of the time, users interact with applications by accessing websites, which implicitly download user interface code from servers in real-time and execute it in the browser. If the server is hacked or the DNS is compromised, users will receive a false copy of the interface, which may trick them into performing arbitrary actions. Wallet features like transaction simulation are very helpful in reducing risks, but they are far from perfect.
Ideally, we would shift the ecosystem to on-chain content version control: users would access dapps through their ENS names, which would contain the IPFS hash of the interface. Updating the interface would require on-chain transactions from multisig or DAOs. Wallets would show users whether they are interacting with a more secure on-chain interface or a less secure Web2 interface. Wallets could also indicate whether users are interacting with a secure chain (e.g., Stage 1+, multiple security audits).
For privacy-conscious users, wallets could also add a paranoid mode, requiring users to click to accept HTTP requests, rather than just web3 operations:
Possible interface model for paranoid mode
A more advanced approach is to go beyond HTML + Javascript and write the business logic of the dapp in a dedicated language (possibly a relatively thin overlay on Solidity or Vyper). Then, the browser can automatically generate the UI for any required functionality. OKContract is already doing this.
Another direction is cryptoeconomic information defense: dapp developers, security companies, chain deployers, and others can establish a bond that pays affected users (as determined by some on-chain adjudication DAO) if the dapp is hacked or harms users in a highly misleading way. Wallets can show users a score based on the size of the bond.
Long-Term Future
All of the above occurs in the context of traditional interfaces, which involve pointing and clicking on things and entering things into text fields. However, we are also at the cusp of a more profound shift in paradigms:
Artificial Intelligence, which may lead us from a click-and-type paradigm to a "say what you want to do, and the robot will figure it out" paradigm.
Brain-Computer Interfaces, with both "gentle" methods like eye tracking and more direct or even invasive technologies (see: the first Neuralink patient this year).
Client-Side Active Defense: The Brave browser actively protects users from ads, trackers, and many other malicious entities. Many browsers, plugins, and crypto wallets have entire teams actively dedicated to protecting users from various security and privacy threats. These "active guardians" will only become stronger in the next decade.
These three trends together will lead to a deeper rethinking of how interfaces work. With natural language input, eye tracking, or ultimately more direct brain-computer interfaces, combined with your history (perhaps including text messages, as long as all data is processed locally), a "wallet" can clearly and intuitively understand what you want to do. Then, AI can translate this intuition into a concrete "action plan": a series of on-chain and off-chain interactions to accomplish what you want. This could significantly reduce the need for third-party user interfaces. If users do interact with third-party applications (or other users), AI should engage in adversarial thinking on behalf of the user, identifying any threats and proposing action plans to avoid those threats. Ideally, these AIs should have an open ecosystem generated by different groups with varying biases and incentive structures.
These more radical ideas depend on technologies that are very immature today, so I would not put my assets in wallets that rely on them today. However, similar things seem to be clearly the trend of the future, so it is worth starting to explore this direction more actively.
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
