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

以太坊基礎設施堆棧中的錢包層至關重要，但常常被核心研究人員和開發者低估。錢包是用戶與以太坊世界交互的窗口,只有當錢包本身具備相應屬性時,用戶才能真正享受到以太坊及其應用程序提供的去中心化、抗審查、安全和隱私等特性。

近期以太坊錢包在改善用戶體驗、安全性和功能方面取得了顯著進展。本文旨在探討理想以太坊錢包應具備的一些特性。這並非一份完整清單,而是反映了作者的密碼朋克傾向,聚焦於安全和隱私方面。雖然在用戶體驗方面可能不夠全面,但考慮到優化用戶體驗更適合通過部署和迭代來實現,因此本文將重點關注安全和隱私屬性。

跨L2交易的用戶體驗

目前已有一個日益詳細的路線圖來改善跨L2用戶體驗,包括短期和長期部分。這裏主要討論短期可實施的想法。

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

當用戶收到這種格式的地址時,只需將其粘貼到錢包的"收款人"欄並點擊"發送",錢包就會自動處理發送操作:

• 如果目標鏈上已有足夠所需代幣,直接發送
• 如果其他鏈上有所需代幣,使用跨鏈DEX協議發送
• 如果有其他類型代幣,使用DEX轉換後發送

對於dapp請求存款的場景,理想的流程是擴展web3 API,允許dapp發出鏈特定的支付請求。錢包可以靈活處理這些請求。爲了良好的用戶體驗,還需要標準化查詢可用餘額的請求,錢包也需要慎重考慮默認將用戶資產存儲在哪些鏈上。

鏈特定支付請求也可以放入二維碼中供移動錢包掃描。在面對面或在線支付場景中,接收方可以發出二維碼或web3 API調用,表明"我希望在X鏈上收到Y單位的Z代幣,參考ID爲W"。錢包可以自由選擇滿足該請求的方式。

另一個相關主題是gas費支付。如果用戶在某個L2上收到資產但沒有ETH支付gas,錢包應該能自動使用協議從其他有ETH的鏈上支付gas。如果錢包預計用戶未來會在該L2上進行更多交易,也可以只通過DEX發送足夠支付一定數量gas的ETH,以便未來直接在該鏈上支付gas(因爲這樣更便宜)。

帳戶安全

帳戶安全的一個概念化方式是,一個好的錢包應該同時在兩個方面發揮作用:(1)保護用戶免受錢包開發人員的攻擊或惡意行爲,(2)保護用戶免受自身錯誤的影響。

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

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

監護人的選擇

對於經驗豐富的加密用戶,一個可行的選擇是使用朋友和家人的密鑰作爲監護人。如果每個人提供一個新地址,甚至不需要知道彼此的身分,這降低了串通的可能性。但對大多數新用戶來說,這個選項不太可行。

第二種選擇是機構監護人:專門提供僅在收到額外確認信息(如確認碼或視頻通話)時才簽署交易的服務。這種嘗試由來已久,但目前還不是很成功。

第三種選擇是多個個人設備(如手機、電腦、硬體錢包)。這可行但對新手用戶來說設置和管理較困難,且存在設備同時丟失或被盜的風險。

近期出現了更多基於萬能密鑰的方案。密鑰可以只備份在設備上,也可以備份在雲端,安全性依賴於復雜的混合密碼、機構和可信硬件假設。雖然對普通用戶來說是寶貴的安全增益,但僅靠它們還不足以保護用戶的全部資產。

幸運的是,ZK-SNARK技術爲我們提供了第四種選擇:ZK包裝的中心化ID。這包括zk-email、Anon Aadhaar、Myna Wallet等。基本思路是將各種形式(公司或政府)的中心化ID轉換爲以太坊地址,用戶只能通過生成證明擁有該中心化ID的ZK-SNARK來發送交易。

這種方案需要通過簡化且集成的UI來實現:用戶應該能夠僅指定想要使用的郵箱地址作爲監護人,系統就會自動在後臺生成相應的zk-email以太坊地址。高級用戶應該能夠將郵箱(及可能保存的隱私鹽值)輸入到開源第三方應用中,並確認生成的地址是否正確。其他支持的監護人類型也應如此。

需要注意的是,目前zk-email面臨的一個實際挑戰是它依賴於每隔幾個月輪換一次的DKIM籤名密鑰,而這些密鑰本身並未由其他機構籤名。這意味着當前的zk-email在某種程度上需要信任提供商本身。如果在可信硬件內使用TLSNotary來驗證更新的密鑰,可以減少這種依賴,但仍不理想。希望郵件提供商能夠開始直接簽署其DKIM密鑰。目前建議將zk-email作爲監護人之一使用,但不建議大多數監護人都使用:不要將資金存儲在zk-email出現問題就無法使用資金的設置中。

新用戶和應用內錢包

新用戶實際上不希望在首次註冊時輸入大量監護人信息。因此,錢包應該爲他們提供一個非常簡單的選擇。一種自然的方式是使用郵箱地址的zk-email、本地存儲在用戶設備上的密鑰(可能是萬能密鑰)以及由提供商持有的備份密鑰,進行2-of-3的選擇。隨着用戶積累更多經驗或資產,應該在適當時機提示他們添加更多監護人。

將錢包集成到應用中是不可避免的,因爲面向非加密用戶的應用不希望用戶同時下載兩個新應用(應用本身加上以太坊錢包)而帶來混亂的用戶體驗。然而,許多應用內錢包的用戶應該能夠將所有錢包連結在一起,這樣就只需關注一個"訪問控制問題"。最簡單的方法是採用分層方案,通過一個快速的"連結"過程,允許用戶將主錢包設置爲所有應用內錢包的監護人。

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

除了帳戶安全,當今的錢包還在識別虛假地址、網絡釣魚、詐騙等外部威脅方面做了大量工作,並努力保護用戶免受這些威脅。同時,許多對策仍然相當原始,如無論發送100美元還是10萬美元都要求點擊確認。在這方面並不存在單一的完美解決方案,而是需要針對不同類別的威脅進行一系列持續的改進。繼續在這方面努力很有價值。

隱私

現在是時候更加認真地對待以太坊的隱私了。ZK-SNARK技術已經非常先進,不依賴後門來降低監管風險的隱私技術(如隱私池)越來越成熟,二層基礎設施如Waku和ERC-4337 mempools也逐漸穩定。然而,目前在以太坊上進行私密轉帳仍需用戶明確下載並使用"隱私錢包",這增加了不便並減少了願意進行私密轉帳的人數。解決方案是將私密轉帳直接集成到錢包中。

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

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

這種技術不僅是保護隱私資產轉移的自然途徑,也是保護隱私身分的自然途徑。身分已經發生在鏈上:任何使用身分證明門控的應用、代幣門控聊天、以太坊遵循協議等都是鏈上身分。我們希望這個生態系統也能保護隱私。這意味着用戶的鏈上活動不應集中在一處:每個項目都應單獨存儲,用戶的錢包應該是唯一具有"全局視圖"的地方,可以同時看到所有證明。每個用戶擁有多個帳戶的原生生態系統有助於實現這一目標,EAS和Zupass等鏈下證明協議也是如此。

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

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

任何有效的隱私解決方案都會產生用戶存儲鏈