Web3新手系列:點擊MetaMask誤喚起其他錢包?錢包衝突解決方案現狀

錢包喚起時的混亂

連結錢包是進入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 就可以拿到錢包對象引用,也就可以與錢包互動了。

Web3新手系列:點擊MetaMask誤喚起其他錢包?錢包衝突解決方案現狀

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 行:

Web3新手系列:點擊MetaMask誤喚起其他錢包?錢包衝突解決方案現狀

而如果你是Solana 生態的DApp 開發者,方式也是類似的。它提供了autoAddRegisteredWallets 屬性:

Web3新手系列:點擊MetaMask誤喚起其他錢包?錢包衝突解決方案現狀

總結

EIP-6963 和Wallet Standard 可大幅改善用戶連接錢包的體驗,並降低新錢包供應商的進入門檻。希望以後能有更多鏈平台以及錢包、DApp 開發者可以提供或實現相關標準,這有利於Web3 朝向更好的方向發展。

本文由ZAN Team(X 官方帳號@zan_team) 的gin-lsl 撰寫。

Total
0
Shares
Related Posts