Vitalik's new technical article: The vision of an ideal wallet - a comprehensive upgrade from cross-chain experience to privacy protection

Special thanks to Liraz Siri, Yoav Weiss, and the ImToken, Metamask, and OKX developers for their feedback and review.

A key layer of the Ethereum infrastructure stack iswallet，但经常被核心 L1 研究人员和开发人员低估。钱包是用户和以太坊世界之间的窗口，用户只能从以太坊及其应用程序提供的任何去中心化、审查阻力、Safety, privacy or other properties, provided that the wallet itself also has these properties.

Recently, we have seen Ethereum wallets improve their user experience,SafetyThe purpose of this post is to give my own take on some of the features that an ideal Ethereum wallet should have. This is not a comprehensive list; it reflects my cypherpunk tendencies and focuses onSafety和隐私，并且几乎可以肯定它在用户体验方面是不完整的。然而，我认为愿望清单在优化用户体验方面不如简单地根据反馈进行部署和迭代有效，因此我认为关注SafetyAnd privacy attributes are the most valuable.

CrossL2User experience of trading

There is now an increasingly detailed improvement acrossL2A roadmap for user experience, which has a short-term part and a long-term part. Here I will talk about the short-term part: ideas that are theoretically implementable even today.

The core idea is (i)内置跨L2发送, and (ii)Chain-specific addresses and payment requestsYour wallet should be able to provide you with an address (followingThis ERC Draftstyle), as follows:

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

• If you already have enough of the required type on the target chainToken,Please send directlyToken

• 如果您在另一条链上有所需类型的Token（或 多个其他链），使用ERC-7683Other agreements (Actually a cross-chain DEX) Send tokens

• If you have different types of tokens on the same chain or other chains, Use DecentralizationexchangeConvert themSend the correct type of currency to the correct chain. This should require explicit permission from the user: the user will see how much they paid in fees, and how much the recipient received in fees.

A mockup of a possible wallet interface with cross-chain address support

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

Chain-specific payment requests can also be put into a QR code, which can be scanned by mobile wallets. In a face-to-face (or online) consumer payment scenario, the recipient will send a QR code or web3 API call, saying “I want toXUnit TokenY Z , with a reference ID or callbackW ”, the wallet will be free to fulfill the request in any way. Another option isClaim linkProtocol where the user’s wallet generates a QR code or URL containing a claim authorization from their on-chaincontractThe recipient takes a certain amount of funds from a blockchain and it is the recipient’s job to figure out how to transfer those funds to their own wallet.

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

Account Security

One way I conceptualize the challenge of account security is that a good wallet should perform two functions simultaneously: (i) protect users from hacking or malicious attacks by wallet developers, and (ii) protect users from their own mistakes.

The "mistake" on the left was unintentional. However, when I saw it, I realized it fits perfectly with the top and bottomXiaobai NavigationSo I decided to keep it.

My preferred solution to this,ExceedOver the past decade, has always been a social recovery and multi-signature wallet with hierarchical access control.A user's account has two layers of keys: a master key and N guardians(e.g. N = 5). The master key is capable of low-value and non-financial operations. Most guardians need to perform (i) high-value operations, such as sending the full value of an account, or (ii) changing the master key or any guardian. If desired, the master key can be allowed to perform high-value operations via a time lock.

The above is the basic design and can be expanded. The session key andERC-7715Permission mechanisms such as these can help support different balances between convenience and security for different applications. More complex guardian architectures, such as with multiple time-lock durations at different thresholds, can help maximize the chances of successfully recovering legitimate accounts while minimizing the chances ofstealstealrisk.

The above is the basic design and can be expanded. The session key andERC-7715Permission mechanisms such as these can help support different balances between convenience and security for different applications. More complex guardian architectures, such as with multiple time-lock durations at different thresholds, can help maximize the chances of successfully recovering legitimate accounts while minimizing the chances ofstealTheft risk.

Who or what should the guardian be?

For experiencedcryptocurrencyuserCommunityFor experienced crypto users, a viable option isKeys for your friends and familyIf you ask everyone to provide you with a new address, then no one needs to know who they are – in fact, your guardians don’t even need to know who each other is. If they haven’t tipped you off, the chances of them colluding are slim. However, for most new users, this option is not available.

The second option isInstitutional Guardian: Companies that specialize in services that sign transactions only upon receiving additional confirmation of your request: eg. a confirmation code, or a video call for high-value users. People have long tried to make these, eg.I covered CryptoCorp in 2013However, so far, these companies have not been very successful.

The third option is multiplePersonal 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 at the same time, especially if they are in the same location.

Recently, we have begun to see more Master key.The keys can only be backed up on your device, making it a personal device solution, or in the cloud, making its security dependent onComplexmix Cryptographic security, institutions, and trusted hardware assumptions. In reality, keys are a valuable security gain for the average user, but they alone are not enough to protect a user’s life savings.

Fortunately, with ZK-SNARKs, we have a fourth option: Centralized ID of ZK package This type includeszk-email , Anon Aadhaar , Myna WalletEtc. Basically, you can take a centralized ID in many forms (corporate or government) and convert it into an Ethereum address, and you can only send transactions to it by generating a ZK-SNARK that proves you own the centralized ID.

With this addition, we now have a wide range of choices and the unique “newbie-friendliness” of centralized IDs for ZK wrappers.

To do this, it needs to be done through a simplified and integrated UI: you should be able to just specify that you want "example@gmail.com" as a guardian, and it should automatically generate a corresponding zk-email Ethereum address under the hood. Advanced users should be able to enter their email (and a privacy salt that might be saved with that email) into an open source third-party application and confirm that the generated address is correct. The same should be true for any other supported guardian type.

Note that a practical challenge facing zk-email today is that it relies onDKIM Signature, the signature uses keys that are rotated every few months, and the keys themselves are not signed by any other authority. This means that today’s zk-email has some level of trust requirements beyond the provider itself; if zk-email is used within trusted hardwareTLSNotaryThis can be mitigated by using a secure key validation mechanism to verify updated keys, but it’s not ideal. Hopefully email providers will start signing their DKIM keys directly. Today, I recommend zk-email to one guardian, but I wouldn’t recommend it to most guardians: don’t store funds in a setup where a breakage of zk-email means you can’t access your funds.

New Users and In-App Wallet

New users don't actually want toFirst time registrationTherefore, wallets should offer them a very simple option. A natural path is to do a 2-of-3 selection using zk-email on their email address, a key stored locally on the user's device (perhaps a master key), and a backup key held by the provider. As users become more experienced or accumulate more assets, they should be prompted to add more guardians at some point.

Wallet integrated into the appThis is unavoidable, as applications trying to attract non-crypto users don’t want users to download two new applications at the same time (the application itself, plus the Ethereum wallet) which creates a confusing user experience. However, users of many application wallets should be able to link all of their wallets together so that they only have to worry about one “access control problem”. The simplest way to do this is to have a tiered scheme where there is a quick “linking” process that allows users to set their main wallet as the guardian of 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.

Protect users from scams and other external threats

Beyond account security, today's wallets do a lot to identify fake addresses, phishing, scams, and other external threats, and do their best to protect users from such threats. At the same time, many countermeasures are still fairly primitive: for example, requiring a click to send ETH or other tokens to any new address, regardless of whether you're sending $100 or $100,000. There's no single silver bullet here. It's a slow, ongoing series of fixes and improvements for different categories of threats. However, there's a lot of value in continuing to work on improvements here.

privacy

It’s time to start taking privacy on Ethereum more seriously. ZK-SNARK technology is now advanced enough that privacy technologies that don’t rely on backdoors to reduce regulatory risk (such asPrivacy Pool) is becoming more mature, and likeWakuand ERC-4337 mempoolSecondary infrastructure such as s is also slowly becoming more stable. However, until now, making private transfers on Ethereum has required users to explicitly download and use a “privacy wallet” such asRailway (or forStealth AddressUmbra ). This adds a great deal of inconvenience and reduces the number of people willing to make private transfers. The solution is Private transfers need to be integrated directly into the wallet.

A simple implementation is as follows. The wallet can store part of the user's assets as a "private balance" in the privacy pool. When the user transfers money, it will automatically exit the privacy pool first. If the user needs 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 Protocol). Deposits will come from the privacy pool and withdrawals will go directly into the privacy pool. This allows a user’s activity in any one app to be unlinked from their activity in the other apps.

One of the advantages of this technology is that it is a natural path not only for privacy-preserving asset transfers, but also for privacy-preserving identity. Identity already happens on-chain: any application that uses identity-gated tokens (e.g. Gitcoin Grants), any token-gated chat,Ethereum follows the protocolAnd so on are all on-chain identities. We want this ecosystem to also preserve privacy. This means that a user's on-chain activity should not be collected in one place: each item should be stored separately, and the user's wallet should be the only thing with a "global view" that can see all your proofs at once. A native ecosystem with multiple accounts per user helps achieve this goal, EASandZupassThe same is true for off-chain proof protocols.

This represents a pragmatic vision for privacy on Ethereum in the medium term. It is achievable today, although some features could be introduced at L1 and L2 to make privacy-preserving transfers more efficient and reliable. Some privacy advocates argue that the only acceptable thing is complete privacy for everything: encrypting the entire EVM. I think this is likely the ideal long-term outcome, but it requires a more fundamental rethinking of the programming model, and it is not yet at a level of maturity that is ready for deployment on Ethereum. We do need privacy by default to get a sufficiently large anonymity set. However, focusing first on (i) transfers between accounts, and (ii) identity and identity-related use cases (e.g. private proofs) is a pragmatic first step that is easier to implement, and wallets can start using today.

Ethereum wallets also need to be data wallets

One consequence of any effective privacy solution, whether for payments, identity, or other use cases, is that it creates a need for users to store data off-chain. This is evident in Tornado Cash, which requires users to keep “notes” that each represent a deposit of 0.1-100 ETH. More modern privacy protocols sometimes keep encrypted data on-chain and decrypt it using a single private key. This is risky because if the key is compromised, or quantum computers become feasible, the data becomes public. The need for off-chain data storage is even more evident in off-chain proofs such as EAS and Zupass.

Wallets need to be software that not only stores on-chain access rights, but also stores your private data.. This is also increasingly recognized in the non-crypto world, e.g. see Tim Berners-LeeRecent work in personal data storage. All the problems we need to solve around robust access control, we also need to solve around robust accessibility and non-leakage of data. Perhaps these solutions can be stacked together: if you have N guardians, use M-of-N secret sharing between those N guardians to store your data. The data is inherently harder to protect because you can't revoke someone's share of the data, but we should come up with decentralized custody solutions that are as secure as possible.

Secure chain access

Today, wallets trust their RPC providers to tell them anything about the chain. This is a vulnerability in two ways:

1. RPC providers may try to trick you by providing them with false information.Stealing money, for example. About market prices.

2. RPC providers canExtracting private information About the applications and other accounts the user is interacting with.

Ideally, we would like to close both of these loopholes. To solve the first problem, we need standardized light clients for L1 and L2 that can directly verifyBlockchainconsensus. HeliosThis has been done for L1, and there has been some preliminary work to support some specific L2s. In order to properly cover all L2s, we need a standard by which to represent the L2Configurationcontract(Also used for chain-specific addresses) A function can be declared, perhaps with a name similar toERC-3668The approach involves getting the most recent state root and verifying the logical state of the proof and the receipt against 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 realistic approach today is to run your own full node. However, now that L2 is coming into the picture, it is becoming increasingly difficult to run a full node for everything. The equivalent of a light client here isPrivate Information Retrieval (PIR) PIR involves a server that keeps a copy of all data and a client that sends encryption requests to the server. The server performs computations on all the data and returns the data the client needs, encrypted to the client's key, without revealing to the server which piece of data the client accessed.

To keep the server honest, the individual database entries are themselves Merkle branches, so clients can verify them using a light client.

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

• Use brute force: Improvements in algorithms or specialized hardware may allow PIR to run fast enough. These techniques may depend onPreprocessing: The server can store encrypted and scrambled data for each client, and the client can query that data. The main challenge in the Ethereum environment is to adapt these techniques to rapidly changing data sets (like countries). This makes real-time computation cheaper, but will likely make total computation and storage costs higher.

• Weakening privacy requirements: For example, there can only be 1 million "mixins" per lookup, so the server will know about the million possible values that the client can access, but not any finer granularity.

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

• Anonymity rather than confidentiality: It is possible to send requests over a mix network, thereby hiding the sender of the request, rather than hiding the content of the request. However, doing so effectively inevitably increases latency, thereby worsening the user experience.

Figuring out the right combination of techniques to maximize privacy while maintaining practicality in the Ethereum context is an open research problem, and I welcome cryptographers to try to do so.

Ideal Keystore Wallet

In addition to transfers and state access, another important workflow that needs to work smoothly in a cross-L2 context is changing the verification configuration of an account: whether it is changing its keys (such as recovery), or making deeper changes to the entire logic of the account. There are three tiers of solutions here, arranged in order of increasing difficulty:

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

2. Keystore on L1：Configuration information is located on L1, and wallets on L2 useL1SLOADRead it orRemote static callIn this way, you only need to update the configuration on L1, and the configuration will automatically take effect.

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

Solution (3) is particularly powerful because it works well with privacyIn a normal “privacy solution”, the user has a secrets , publish “leaf value” on the chain L , user proofL = hash(s, 1)and N = hash(s, 2)For some secrets they control (never revealed).Nis published, making it possible to ensure that future expenditures from the same leaf will fail without revealing LIt depends on the usersSecurity. A recovery-friendly privacy solution would say: sis a location (e.g. address and storage slot) onchain, users must prove state queries: L = hash(sload(s), 1).

Dapp Security

The weakest link in user security is often a dapp. Most of the time, users interact with an application by visiting a website, which implicitly downloads the user interface 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 will get a fake copy of the interface, which could trick the user into performing arbitrary actions. Wallet features such as transaction simulation are very helpful in reducing risk, but they are far from perfect.

Ideally, we will move the ecosystem to on-chain content versioning: users will access dapps by their ENS name, which will contain the IPFS hash of the interface. Updating the interface will require a multisig or DAO The wallet will show the user if they are interacting with a more secure on-chain interface or a less secure Web2 interface. The wallet can also show the user if they are interacting with a secure chain (e.g. Phase 1+, multi-security audit).

对于注重隐私的用户，钱包还可以添加偏执模式（paranoid mode），要求用户点击接受HTTP请求，而不仅仅是web3操作：

Possible interface models for paranoid mode

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

Another direction isCryptoeconomic Information Defense: Dapp developers, security firms, chain deployers, and others can set up a bond that will pay out to affected users (as determined by some on-chain adjudication) if the dapp is hacked or otherwise harms users in a highly misleading manner DAOThe wallet can display a score based on the size of the bond to the user.

The Longer Future

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

• AI, which could lead us to move away from a point-and-click typing paradigm to a "say what you want to do and the robot will figure it out" paradigm

• Brain-computer interface, ranging from “gentle” methods such as eye tracking to more direct and even invasive techniques (see:First Neuralink patient this year)

• Client-side active defense: Brave BrowserProactively protects users from ads, trackers, and many other bad actorsMany browsers, plugins, and crypto wallets have entire teams actively working to protect users from a variety of security and privacy threats. These “active guardians” will only become more powerful over the next decade.

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

These more radical ideas depend on technology that is very immature today, so I wouldn’t put my assets into a wallet that relies on them today. However, it seems clear that things like this are the trend of the future, so it’s worth starting to explore more actively in this direction.

The article comes from the Internet:Vitalik's new technical article: The vision of an ideal wallet - a comprehensive upgrade from cross-chain experience to privacy protection

Related recommendations: Stablecoin supply reaches 160 billion USD, a near record high, and upstream and downstream payment becomes a new value depression

The operation of stablecoins is inseparable fromBlockchain. Author: Andrew Van Aken & Jon Ma Translator: Xiaobai Navigation Coderworld Summary Stripe acquired Bridge.XYZ for $1.1 billion, and the company just acquired Bridge.XYZ from Sequoia, Ribbit Cap…