理想以太坊錢包的願景:從跨鏈體驗到隱私保護的全方位升級

以太坊基礎設施堆棧中錢包層至關重要,卻常被核心研究人員和開發者低估。作爲用戶與以太坊世界的窗口,錢包自身必須具備去中心化、抗審查、安全和隱私等特性,用戶才能真正享受到以太坊及其應用所提供的這些屬性。

近期以太坊錢包在用戶體驗、安全性和功能方面都有顯著進步。本文旨在分享我對理想以太坊錢包應具備特性的一些看法。這並非一個完整列表,更多反映了我的密碼朋克傾向,聚焦於安全和隱私,在用戶體驗方面可能不夠全面。不過我認爲,相比單純根據反饋部署和迭代來優化用戶體驗,關注安全和隱私屬性可能更有價值。

跨L2交易的用戶體驗

目前已有一個日趨完善的改善跨L2用戶體驗路線圖,包括短期和長期部分。這裏我將討論短期可實施的想法。

核心思路是:(1)內置跨L2發送功能,(2)鏈特定地址和支付請求。錢包應能爲用戶提供一個遵循ERC草案風格的地址。

當用戶收到這種格式的地址時,只需將其粘貼到錢包的"收件人"字段並點擊"發送",錢包就應自動處理發送:

• 如目標鏈上已有足夠代幣,直接發送
• 如其他鏈上有所需代幣,使用跨鏈DEX協議發送
• 如有不同類型代幣,使用DEX轉換爲正確類型後發送(需用戶確認)

對於dapp請求存款的場景,理想做法是擴展web3 API,允許dapp發出鏈特定的支付請求。錢包需要標準化getAvailableBalance請求,並認真考慮用戶資產默認存儲在哪些鏈上,以兼顧安全性和轉帳便利性。

鏈特定支付請求也可放入二維碼,供移動錢包掃描。在面對面或在線支付場景中,接收方發出的QR碼或API調用表明"我想要X鏈上Y單位的Z代幣,參考ID爲W",錢包可自由選擇滿足該請求的方式。另一種選擇是索賠連結協議,用戶錢包生成包含授權的QR碼或URL,接收方負責提取資金。

gas支付也是一個相關話題。如用戶在某個L2上收到資產但沒有ETH,錢包應能自動使用協議在用戶有ETH的鏈上支付gas。如錢包預計用戶未來會在該L2上進行更多交易,也可使用DEX發送一定數量ETH作爲gas儲備。

帳戶安全

我認爲帳戶安全的關鍵在於同時保護用戶免受錢包開發者的黑客攻擊或惡意行爲,以及用戶自身錯誤的影響。

我長期以來傾向的解決方案是具有分級訪問控制的社交恢復和多重籤名錢包。用戶帳戶有兩層密鑰:主密鑰和N個監護人(如N=5)。主密鑰可進行低價值和非財務操作。大多數監護人需要執行:(1)高價值操作,如發送帳戶全部資金,(2)更改主密鑰或任何監護人。必要時可允許主密鑰通過時間鎖執行高價值操作。

這一基本設計可進一步擴展。會話密鑰和權限機制可支持不同應用在便利性和安全性間取得平衡。更復雜的監護人架構,如在不同閾值下設置多個時間鎖定期,有助於在最大化恢復合法帳戶成功率的同時,最大限度降低盜竊風險。

對於監護人的選擇,有幾種方案:

1. 對有經驗的加密用戶,可以選擇朋友和家人的密鑰。
2. 機構監護人:專門提供籤名服務的公司,需要額外確認信息。
3. 多個個人設備(如手機、電腦、硬體錢包),但新用戶可能難以設置管理。
4. 基於密碼管理器的方案,可本地或雲端備份,但僅靠它們還不足以保護用戶全部資產。
5. ZK包裝的中心化ID:如zk-email、Anon Aadhaar等,可將中心化ID轉換爲以太坊地址。

ZK包裝的中心化ID對新用戶較爲友好。錢包應提供簡化集成的UI,允許用戶直接指定郵箱作爲監護人,自動生成相應的zk-email以太坊地址。高級用戶應能驗證生成地址的正確性。

對於新用戶,錢包可提供簡單選項,如基於zk-email、本地存儲密鑰和提供商備份密鑰的2-of-3方案。隨着用戶經驗增長或資產增加,應提示添加更多監護人。

應用內錢包集成是不可避免的,但用戶應能將所有錢包連結在一起,統一管理訪問控制。一種簡單方法是採用分層方案,允許用戶將主錢包設置爲所有應用內錢包的監護人。

保護用戶免受詐騙和其他外部威脅

除帳戶安全外,當前錢包在識別虛假地址、網絡釣魚、詐騙等方面做了大量工作。但許多對策仍較爲原始,如統一要求點擊確認才能向新地址發送代幣,無論金額大小。這需要針對不同類別威脅持續改進,沒有一勞永逸的解決方案。

隱私

是時候更認真地對待以太坊的隱私了。ZK-SNARK技術已相當先進,不依賴後門的隱私技術(如隱私池)日漸成熟,二級基礎設施如Waku和ERC-4337 mempools也逐步穩定。但目前進行私密轉帳仍需用戶明確下載使用"隱私錢包",這增加了不便並減少了使用人數。解決方案是將私密轉帳直接集成到錢包中。

一種簡單實現是:錢包將用戶部分資產作爲"私密餘額"存儲在隱私池中。轉帳時自動退出隱私池,接收資金時自動生成隱形地址。

此外,錢包可爲用戶參與的每個應用自動生成新地址。存款來自隱私池,提款直接進入隱私池。這允許用戶將在不同應用中的活動解耦。

這不僅是保護資產轉移隱私的自然途徑,也是保護身分隱私的方式。鏈上身分已經存在,如使用身分證明的應用、代幣門控聊天等。我們希望這個生態系統也能保護隱私,即用戶的鏈上活動不應集中在一處:每個項目應單獨存儲,只有用戶錢包能同時看到所有證明。原生支持每用戶多帳戶的生態系統有助於實現這一目標,鏈下證明協議如EAS和Zupass也是如此。

這代表了以太坊隱私的中期務實願景。雖然可以在L1和L2引入一些功能使隱私保護傳輸更高效可靠,但現在就可以實現。一些隱私倡導者認爲只有完全隱私才可接受,如加密整個EVM。這可能是理想的長期結果,但需要對編程模型進行更根本的重新思考,目前尚未達到可部署成熟度。我們確實需要默認隱私以獲得足夠大的匿名集。然而,首先關注(1)帳戶間轉帳,(2)身分和相關用例(如私密證明)是務實的第一步,更易實現,錢包現在就可以開始使用。

以太坊錢包也需要成爲數據錢包

任何有效的隱私解決方案都會產生用戶存儲鏈下數據的需求,無論是用於支付、身分還是其他用例。現代隱私協議有時在鏈上保存加密數據,使用單個私鑰解密。這有風險,因爲如果密鑰泄露或量子計算機可行,所有數據都會公開。鏈下證明更顯著地需要鏈下數據存儲。

錢包不僅需要存儲鏈上訪問權限,還需要存儲用戶私人數據。非加密世界也越來越認識到這一點。我們需要圍繞數據的可訪問性和防泄漏構建穩健保證。也許可以將這些解決方案疊加:如果有N個監護人,就在這N個監護人之間使用M-of-N祕密共享來存儲數據。數據本質上更難保護,因爲無法撤銷某人的數據份額,但我們應該提出盡可能安全的去中心化托管解決方案。

安全的鏈訪問

目前錢包依賴RPC提供商獲取鏈信息,這存在兩個漏洞:

1. RPC提供商可能通過提供虛假信息(如市場價格)來竊取資金。
2. RPC提供商可以獲取用戶與應用程序交互的私密信息。

理想情況下,我們希望堵住這兩個漏洞。解決第一個問題需要L1和L2的標準化輕客戶端,直接驗證區塊鏈共識。Helios已爲L1實現,並開始支持一些L2。爲覆蓋所有L2,我們需要一個標準,通過代表L2的配置合約聲明獲取最近狀態根並驗證狀態和收據證明的邏輯。這樣就可以有一個通用輕客戶端,允許錢包安全驗證L1和L2上的任何狀態或事件。

對於隱私,目前唯一現實的方法是運行自己的完整節點。但隨着L2的普及,運行所有內容的完整節點變得越來越困難。這裏的輕客戶端等價物是私有信息檢索(PIR)。PIR涉及保存所有數據副本的服務器和向服務器發送加密請求的客戶端。服務器對所有數據執行計算,返回客戶端所需的加密數據,而不知道客戶端訪問了哪條數據。

爲保證服務器誠實,各個數據庫項本身就是Merkle分支,客戶端可用輕客戶端驗證。

PIR計算量很大。解決方案包括:

• 蠻力:算法或專用硬件改進可能使PIR運行足夠快。
• 削弱隱私要求:如每次查找只有100萬個"mixins"。
• 多服務器PIR:使用多個服務器,假設1-of-N誠實,PIR算法通常更快。
• 匿名而非機密性:通過混合網路發送請求,隱藏發送者而非內容。但這會增加延遲。

在以太坊環境中找出正確的技術組合來最大化隱私同時保持實用性是一個開放的研究問題。

理想的密鑰庫錢包

在跨L2上下文中,另一個需要順暢工作的重要流程是更改帳戶驗證