如何在不暴露恢復短語的情況下將 Trust Wallet 連接到 Web3 dApp？

了解 Trust 錢包整合機制

1. Trust Wallet 作為非託管行動錢包運行，原生實作 WalletConnect v2 協定。它不像桌面擴充功能那樣依賴瀏覽器注入。

2. 連線流從 dApp 前端發起，產生一個會話提案，其中包含鏈 ID、請求的權限以及應用程式名稱和徽標等元資料。

3. QR 碼或深層連結攜帶範圍為特定中繼伺服器的加密會話 URI。此 URI 不包含私鑰材料或恢復短語資料。

4. 掃描後，Trust Wallet 使用其本機儲存的配對金鑰解密會話請求，並透過中繼簽章驗證網域完整性。

5. 一旦獲得批准，錢包將透過中繼與 dApp 建立端對端加密通道，從而實現安全的 JSON-RPC 訊息交換，而不會暴露種子短語。

WalletConnect v2 會話安全架構

1. 每個會話都使用源自 dApp 和錢包之間 ECDH 金鑰交換的臨時對稱金鑰。這些密鑰在會話終止後將被丟棄。

2. 中繼伺服器永遠不會看到解密的有效負載 - 所有訊息在傳輸前均經過 AES-256-GCM 加密。

3. 會話提案包括強制對等元資料欄位： appUrl 、 appIcon和appDescription ，防止網域欺騙。

4. Trust Wallet 強制執行嚴格的來源驗證：它根據會話啟動期間註冊的redirectUri交叉檢查 dApp 的網域。

5. 連線期間不會發生涉及復原短語的加密操作。簽名請求僅在批准後在錢包的安全飛地內處理。

有暴露風險的常見錯誤配置

1. 使用已棄用的 WalletConnect v1 橋接器會引入未加密的握手漏洞，並且缺乏域綁定實作。

2. 硬編碼特定於錢包的 URI（例如trust:// ）會繞過 WalletConnect 的標準化發現層，並可能在 Android 上觸發不安全的意圖處理。

3. 未能驗證sessionNamespaces物件會導致權限升級 - 例如，在連接到 Solana 鏈時接受以太坊方法。

4. 將會話密鑰儲存在 localStorage 而不是僅記憶體上下文中允許惡意腳本劫持活動會話。

5. 在 Trust Wallet 官方 SDK 之外實現自訂 QR 掃描器會增加 URI 解析期間中間人攔截的風險。

客戶端實施保障措施

1. 請務必使用與您在 WalletConnect 雲端儀表板上經過驗證的 dApp 身分綁定的projectId來初始化 WalletConnect。

2. 強制實作requiredNamespaces來限制 RPC 方法－例如，明確拒絕eth_signTypedData_v4，除非合約互動得到確認。

3. web3wallet SDK僅用於錢包發起的配對；避免在禁用 iframe 沙箱的上下文中嵌入@walletconnect/modal 。

4. 在分派任何交易請求之前，先驗證sessionEvent負載和web3.eth.getChainId()之間的鏈 ID 一致性。

5. 每個會話切勿多次呼叫eth_requestAccounts — 重複呼叫可能會觸發多餘的簽章提示並增加 UI 混亂。

常見問題解答

Q：如果我批准惡意 dApp，Trust Wallet 會洩漏我的復原短語嗎？答：不會。在 WalletConnect 會話期間絕對不會傳輸、處理或引用恢復短語。批准僅授予範圍內的簽名權限。

Q：掃描 WalletConnect 二維碼是否可以讓 dApp 存取我錢包的交易記錄？答：僅當透過eth_getLogs或類似的讀取方法明確請求時 - 即使這樣，結果也會根據請求中定義的區塊範圍和合約位址進行過濾。

Q：為什麼 Trust Wallet 在連線時有時會顯示「Unknown dApp」？答：當 dApp 未能在會話提案中提供有效的appUrl或appIcon時，會發生這種情況，從而觸發 Trust Wallet 的後備安全警告。

Q：將 Trust Wallet 連接到本機上執行的 dApp 是否安全？答：是的，只要本機伺服器使用 HTTPS 或透過啟用 WalletConnect 開發模式的127.0.0.1提供服務 — 兩者都可以防止會話 URI 的外部網路洩漏。