钱包唤起时的混乱
连接钱包是进入 Web3 世界的关键一步,Web3 用户经常需要在一些 DApp 网站上连接钱包。但是,仅仅是这个简单的动作,也可能对用户造成严重的不便。
连接钱包
想象一下这样一个场景:一位新入门的 Web3 用户(出于好奇,他安装了许多个插件钱包),访问了某个 DApp 网站,并且想要使用自己的浏览器插件钱包来连接它,但是当他们点击网站提供的“Connect Wallet”按钮,并选择某个钱包以便想使用它来连接 DApp 时,可能会发现弹出的钱包并不是自己选择的。这很可能会让他感到慌乱和窒息,以为是自己的电脑中了病毒,所以才执行了自己意料之外的操作。
区块链钱包是连接区块链的重要入口,而为了占据这个入口,各个钱包使用了它们能想到的各种方式。其中最让 DApp 开发者以及 DApp 用户头疼的要数各钱包对全局变量的篡改。
在当前的浏览器钱包实现逻辑中,都有通过向浏览器注入全局变量来暴露钱包提供的功能(例如以太坊平台的钱包会将其提供的功能注入到「window.ethereum」上),以便 DApp 可以调用钱包提供的方法来与之交互。
只是,由于很多钱包都会将自己注入到同一个 window.ethereum 变量上,就导致在后面注册的钱包会覆盖之前注册的钱包,以至于只能通过这种方式只能唤起最后注册的那个。
有时候 DApp 用户为了可以正常使用自己想要用的钱包,不得不临时将其他钱包插件禁用,或者直接只安装某一个钱包。这样一来,反而与钱包开发者最初的想法大相径庭了。并且新钱包哪怕做的更出色,也很难吸引到已经使用其他钱包的用户。
有朋友可能奇怪,为什么一定要注入到同一个变量中呢?假设有两个钱包:A 和 B,其实只要 A 将自己注入到「window.a 」,B 将自己注入到「window.b 」,想要唤起哪个钱包,就调用其对应的对象中提供的方法,就不会发生上述想要调用 A 却反而将 B 唤起的问题。这样确实可以解决竞争问题,但是,问题在于,如此以来,假如 DApp 将要支持多个钱包连接,就必须将开发者想要适配的所有钱包名称全部预先定义在代码中,并且在用户选中某个钱包时,调用该钱包的相关方法。导致相关代码维护起来相当麻烦。而统一将钱包注入到同一个对象上,则可以免于这个麻烦。
解决方案
为了脱离上述的两难困境,社区中有两个相似的标准。
以太坊的解决方案:EIP-6963
以太坊社区在 2023 年 5 月份提出了 EIP-6963 提案。
其中的基本逻辑很简单,就是舍弃全局变量,转而使用约定的事件,来解决钱包注册与发现的问题。
具体来说,插件钱包加载成功后,触发统一的「eip6963:announceProvider」事件,通知 DApp 有新的钱包可用。而 DApp 则通过监听此事件,来得知自己目前可用的钱包有哪些。
这样,通过一套抽象的事件监听逻辑,避免了直接使用全局变量所造成的问题,且能够自动发现目前用户环境中可用的钱包。如此一来,两难自解。
社区标准:Wallet Standard
EIP-6963 是以太坊生态标准,但是不止以太坊,其他链平台也会有类似的问题。例如 Solana 链的钱包,普遍会将自己注入到「window.solana」变量上,同样会造成竞争情况。
那么可否让 Solana 生态也实现这个标准呢?虽然 EIP-6963 只是为了解决以太坊生态中的钱包发现问题,但是其中所蕴含的思路其实可以套用在所有链平台。那么,我们能否再进一步,提供一套通用的标准,让所有区块链平台的钱包和 DApp 实现,让所有链平台的开发者和用户都能享受到 EIP-6963 所提供的便利?理论上是完全没有问题的,而且已经有开发者在这么做了,也就是 Wallet Standard。
Wallet Standard 所做的核心工作,在于提供了两个函数:「 registerWallet」和「getWallets 」,前者用于钱包,后者用于 DApp。
钱包调用「registerWallet 」,传入一个钱包对象,这个对象上封装了钱包提供的功能(例如 Connect 方法,用于连接钱包)。函数内部会先触发一个 RegisterWalletEvent 事件,事件的参数其实是一个回调函数,用于让 DApp 监听到 RegisterWalletEvent 事件时调用,而这个回调函数实际上会将 wallet 对象传入,于是 DApp 就可以拿到钱包对象引用,也就可以与钱包进行交互了。
DApp 开发者没有必要自己来写监听、接收钱包对象的代码,这部分也已经被 Wallet Standard 内置到「getWallets」当中。但是,getWallets 只是监听了事件,具体要怎样处理事件,还是需要开发者考虑。例如获取到的 Wallets 放到哪里?有些钱包在 DApp 加载前就已经加载,而另一些钱包可能在之后才加载,这些钱包的状态如何维护?Wallet Standard 针对以上细节问题,同时提供了「@wallet-standard/react」包,开发者直接使用它提供的 React Hooks 就可以获取到想要的数据,包括钱包列表、当前连接的钱包、钱包提供的方法等。
Wallet Standard Features
除了最基本的获取 Wallet 对象外,Wallet Standard 也定义了一些 Features 格式。
实际上,钱包都具有一些最基本的功能,例如连接、监听钱包事件等。Wallet Standard 提供了「 standard:connect 」、「 standard:events」等 features,钱包供应商实现这些特性后,DApp 可以直接根据这些值来判断钱包是否支持某些操作。
上面提到的 "standard:*" 是它内置定义的特性,实际上它们的值并没有特别强硬的要求,所以可以随意扩展。不同的链平台也会有其独特的特性,例如 Solana,直接约定 "solana:*" 即可。Solana 平台常见的 features 包括「solana:signTransaction 」,「 solana:signMessage」等。
Wallet Standard 现状
目前实现了 Wallet Standard 标准的项目实际上并不多,值得一提的有 Solana 和 Sui。
在 Ant Design Web3 的 Solana 适配器中,也支持适配了 Wallet Standard 的钱包的自动检测,开发者基本只需要通过一个「autoAddRegisteredWallets」开启即可,不需要配置一大堆的钱包元数据,开发体验和用户使用体验直线上升。
ZAN.TOP 连接钱包的逻辑在早期同样遇到相同的问题,不过现在,得益于 Ant Design Web3 提供的配置,很轻松就适配了 EIP-6963 标准。大家在https://zan.top/personal/account?chInfo=ch_wxdyh绑定地址时应该已经体验到这一点了。
各区块链生态的实现
目前各个区块链平台对 Wallet Standard(或 EIP-6963)标准的态度并不相同,这里举几个例子:
Bitcoin
比特币目前为止似乎没有类似的标准,有一个实现了 Wallet Standard 标准的项目,但是并没有引起太多关注,现在也很久没有提交新的代码。
目前开发者只能手动维护状态,或者使用一些开发包来辅助工作。例如在 Ant Design Web3 中的 Bitcoin 适配器实现中,针对不同的钱包,会从不同的全局变量上获取,并存到统一的状态中。这其实是等于库开发者将繁琐的状态维护工作接手了。而且,这仅仅解决了钱包冲突问题,无法自动感知可用钱包的问题依然存在。
Ethereum
以太坊平台已经有了 EIP-6963 标准,相关库和钱包也大多提供了支持。
Solana
如上文,官方提供了实现:https://github.com/solana-labs/wallet-standard
Sui
Sui 目前已经对 Wallet Standard 提供了实现,在官方文档上可以找到使用方法:https://docs.sui.io/standards/wallet-standard
DApps 开发库的支持
wagmi
wagmi 通过 mipd (https://github.com/wevm/mipd) 库对 EIP-6963 提供了支持,具体方式可以查看 wagmi 的文档。
RainbowKit
RainbowKit(https://www.rainbowkit.com/)内部逻辑基于 wagmi,所以也已经对 EIP-6963 提供了内置支持。
Ant Design Web3
Ant Design Web3(https://web3.ant.design/) 的 Ethereum 和 Solana 适配器对这两个标准都进行了非常好的支持,并且开发者开启起来非常便携。
对以太坊 DApp 开发者而言,只需要添加 eip6963 配置即可,注意其中与 EIP-6963 相关的在 23-25 行:
而如果你是 Solana 生态的 DApp 开发者,方式也是类似的。它提供了 autoAddRegisteredWallets 属性:
总结
EIP-6963 和 Wallet Standard 可以极大改善用户连接钱包的体验,降低新钱包供应商的准入门槛。希望以后能有更多链平台以及钱包、DApp 开发者可以提供或实现相关标准,这有利于 Web3 向着更好的方向发展。
查看更多