Web3新手系列点击MetaMask时是否会意外唤起其他钱包解决钱包冲突的现状

Chaos When Opening Wallets
Connecting a wallet is a crucial step in entering the Web3 world, as Web3 users often need to connect their wallets on various DApp websites. However, this seemingly simple action can sometimes cause significant inconvenience to users.
Imagine a scenario where a newcomer to Web3, out of curiosity, has installed multiple wallet plug-ins and visits a DApp website, wanting to use their browser plug-in wallet to connect to it. However, when they click on the “Connect Wallet” button provided by the website and select a wallet to use for connecting to the DApp, they may find that the popped-up wallet is not the one they selected. This can lead to confusion and panic, making them think their computer may be infected with a virus, causing them to perform unexpected actions.
Blockchain wallets serve as the gateway to the blockchain, and to dominate this gateway, each wallet employs various methods. One of the most headache-inducing aspects for DApp developers and users is the manipulation of global variables by different wallets.
In the current logic of browser wallet implementations, wallets expose their functionality by injecting global variables into the browser (for example, Ethereum platform wallets inject their functions into “window.ethereum”), allowing DApps to interact with the wallet’s provided methods.
However, since many wallets inject themselves into the same “window.ethereum” variable, the wallet registered later will overwrite the previously registered one, meaning that only the last registered wallet can be invoked in this manner.
Sometimes, DApp users are forced to temporarily disable other wallet plugins or only install a single wallet to be able to use the wallet they prefer. This goes against the initial intentions of wallet developers and even if a new wallet is superior, it is challenging to attract users who are already using other wallets.
One might wonder why wallets must be injected into the same variable. Suppose there are two wallets, A and B. If A injects itself into “window.a” and B injects itself into “window.b,” then calling the corresponding methods in the object to invoke the desired wallet would prevent the issue of calling A but ending up invoking B. While this approach can solve competition issues, the problem arises when DApps need to support multiple wallet connections as developers must predefine all wallet names they want to adapt to in the code and call the relevant wallet’s methods when a user selects a specific wallet, making code maintenance quite cumbersome. Injecting all wallets into the same object eliminates this hassle.
Solution
To break free from this dilemma, there are two similar standards in the community.
Ethereum’s Solution: EIP-6963
In May 2023, the Ethereum community proposed EIP-6963.
The basic logic is simple: abandon global variables and instead use agreed-upon events to address wallet registration and discovery issues.
Specifically, after a plug-in wallet successfully loads, it triggers a unified “eip6963:announceProvider” event to inform DApps of new available wallets. DApps, in turn, listen to this event to learn about the wallets currently available to them.
By employing an abstract event listening logic, the direct use of global variables’ issues is avoided, and the automatic discovery of wallets in the user’s environment is enabled, resolving the dilemma.
Community Standard: Wallet Standard
While EIP-6963 is an Ethereum ecosystem standard, other chain platforms face similar issues. For example, Solana chain wallets commonly inject themselves into the “window.solana” variable, leading to competition scenarios.
Can the Solana ecosystem also implement this standard? Although EIP-6963 is specifically designed to address wallet discovery issues in the Ethereum ecosystem, the underlying concept can be applied to all chain platforms. Therefore, a universal standard could be developed to allow wallets and DApps on all chain platforms to enjoy the convenience provided by EIP-6963. In practice, this is entirely feasible, and some developers have already started doing so, known as the Wallet Standard.
The core work of the Wallet Standard involves providing two functions: “registerWallet” and “getWallets,” the former for wallets and the latter for DApps.
When a wallet calls “registerWallet” and passes a wallet object containing its provided functions (e.g., the Connect method for connecting the wallet), the function first triggers a RegisterWalletEvent event. The event’s parameter is a callback function for DApps to listen for the event and call the wallet object into the callback function, enabling DApps to obtain a reference to the wallet object and interact with it.
DApp developers do not need to write code to listen for and receive wallet objects as this functionality is already built into the Wallet Standard’s “getWallets.” However, how to handle events still requires developer consideration. For example, where should the obtained wallets be stored? Some wallets may load before the DApp, while others may load later, raising questions about how to maintain the state of these wallets. To address these details, the Wallet Standard also provides the “@wallet-standard/react” package, allowing developers to use its React Hooks to access the desired data, including wallet lists, the currently connected wallet, and the wallet’s provided methods.
Wallet Standard Features
In addition to the basic retrieval of wallet objects, the Wallet Standard also defines various “Features” formats.
In reality, wallets have some fundamental functions such as connecting and monitoring wallet events. The Wallet Standard offers features like “standard:connect” and “standard:events,” which, when implemented by wallet providers, allow DApps to determine if a wallet supports certain operations based on these values.
The “standard:*” mentioned earlier are internally defined features of the Wallet Standard, and their values are flexible, allowing for extensions. Different chain platforms may have unique features, with Solana, for instance, agreeing upon “solana:*” conventions. Common features in the Solana platform include “solana:signTransaction” and “solana:signMessage.”
Current Status of Wallet Standard Implementation
Currently, there are not many projects that have implemented the Wallet Standard. Notable implementations include Solana and Sui.
In the Solana adapter of Ant Design Web3, support for automatically detecting wallets compliant with the Wallet Standard is provided. Developers simply need to enable “autoAddRegisteredWallets,” without having to configure a plethora of wallet metadata, greatly enhancing the development and user experience.
Similarly, ZAN.TOP’s wallet connection logic faced similar challenges early on, but thanks to the configurations provided by Ant Design Web3, easily adapted to the EIP-6963 standard. Users should have already experienced this when binding addresses at https://zan.top/personal/account?chInfo=ch_wxdyh.
Implementation Across Various Blockchain Ecosystems
Different blockchain platforms have varying attitudes towards the Wallet Standard (or EIP-6963) standard. Here are a few examples:
Bitcoin
Bitcoin currently lacks a similar standard. While there are projects that have implemented the Wallet Standard, they have not garnered much attention, with little new code being submitted. Developers must manually maintain the state or use development packages to assist. For example, in the Bitcoin adapter implementation of Ant Design Web3, different wallets are accessed from different global variables and stored in a unified state. While this addresses wallet conflict issues, the problem of automatically sensing available wallets remains.
Ethereum
The Ethereum platform has embraced the EIP-6963 standard, with many libraries and wallets offering support.
Solana
As mentioned earlier, the official Solana implementation can be found at https://github.com/solana-labs/wallet-standard.
Sui
Sui has already implemented the Wallet Standard, with usage instructions available on their official documentation: https://docs.sui.io/standards/wallet-standard.
Support from DApp Development Libraries
wagmi
wagmi supports EIP-6963 through the mipd library (https://github.com/wevm/mipd), with details available in wagmi’s documentation.
RainbowKit
RainbowKit’s internal logic is based on wagmi, hence providing built-in support for EIP-6963.
Ant Design Web3
The Ethereum and Solana adapters of Ant Design Web3 offer excellent support for both standards, making it convenient for developers to enable these features. For Ethereum DApp developers, adding the eip6963 configuration is all that is required, focusing on lines 23-25 relating to EIP-6963.
For Solana ecosystem DApp developers, the process is similar, with the provision of the autoAddRegisteredWallets property.
Conclusion
EIP-6963 and the Wallet Standard greatly enhance the user experience in connecting wallets and reduce the barriers for new wallet providers. It is hoped that more chain platforms, wallets, and DApp developers will offer or implement relevant standards, aiding Web3 in progressing towards a better future.