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

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

近期以太坊錢包在改善用戶體驗、安全性和功能方面取得了重大進展。本文旨在闡述理想以太坊錢包應具備的一些特性。這並非一個完整列表,而是反映了作者的密碼朋克傾向,側重於安全和隱私,在用戶體驗方面可能有所不足。然而,相比簡單地根據反饋部署和迭代,願望清單在優化用戶體驗方面可能不太有效,因此聚焦安全和隱私屬性可能更有價值。

跨L2交易的用戶體驗

改善跨L2用戶體驗的路線圖已經越來越清晰,包括短期和長期部分。本文將討論短期可實施的想法。

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

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

• 如果目標鏈上已有足夠所需代幣,直接發送
• 如果其他鏈上有所需代幣,使用類似ERC-7683的跨鏈DEX協議發送
• 如果同鏈或其他鏈上有不同類型代幣,使用DEX轉換爲正確類型並發送,需要用戶明確許可

這適用於"復制粘貼地址付款"的場景。對於dapp請求存款的情況,理想做法是擴展web3 API,允許dapp發出鏈特定的支付請求。錢包可以靈活滿足該請求。爲實現良好用戶體驗,還需要標準化getAvailableBalance請求,錢包需要認真考慮用戶資產在哪些鏈上默認存儲,以平衡安全性和轉帳便利性。

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

另一個相關話題是gas支付。如果用戶在沒有ETH的L2上收到資產並需要發送交易,錢包應能自動使用協議(如RIP-7755)從其他有ETH的鏈支付gas。如果錢包預計用戶未來會在該L2上進行更多交易,也可以使用DEX發送足夠支付數百次gas的ETH,以便未來交易可以直接在L2上支付gas(因爲這樣更便宜)。

帳戶安全

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

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

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

監護人選擇

對於加密社區中有經驗的用戶,可以選擇朋友和家人的密鑰作爲監護人。如果要求每個人提供新地址,甚至不需要知道彼此身分。然而,這對大多數新用戶不適用。

第二種選擇是機構監護人:專門提供僅在收到用戶請求的其他確認信息(如確認碼或高價值用戶的視頻通話)時才簽署交易的服務。雖然長期以來一直有人嘗試建立這類服務,但目前還不是很成功。

第三種選擇是多個個人設備(如手機、臺式機、硬體錢包)。這可行但對新手用戶設置和管理較困難。還存在設備同時丟失或被盜的風險,尤其是當它們位於同一地點時。

最近,我們開始看到更多基於萬能密鑰的解決方案。密鑰可以只備份在設備上,成爲一種個人設備方案,也可以備份在雲端,安全性依賴於復雜的混合密碼安全、機構和可信硬件假設。雖然對普通用戶來說是寶貴的安全增益,但僅靠它們還不足以保護用戶的畢生積蓄。

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

ZK包裝的中心化ID具有獨特的"新手友好性"。爲此,需要通過簡化且集成的UI來實現:用戶只需指定想要"example@gmail.com"作爲監護人,它應該自動在後臺生成相應的zk-email以太坊地址。高級用戶應該能夠將他們的電子郵件(以及可能保存的隱私鹽值)輸入到開源第三方應用中,並確認生成的地址是正確的。對任何其他受支持的監護人類型也應如此。

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

新用戶和應用內錢包

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

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

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

除了帳戶安全,當今的錢包還做了很多工作來識別虛假地址、網絡釣魚、詐騙和其他外部威脅,並盡力保護用戶。同時,許多對策仍然相當原始:例如,要求點擊才能將ETH或其他代幣發送到任何新地址,無論發送金額大小。這裏沒有單一的靈丹妙藥,而是針對不同類別威脅的一系列持續改進。繼續努力改進這方面很有價值。

隱私

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

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

此外,錢包可以自動爲用戶參與的每個應用程序(如defi協議)生成一個新地址。存款將來自隱私池,提款將直接進入隱私池。這允許用戶在任何一個應用程序中的活動與其在其他應用程序中的活動取消連結。

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

這代表了中期內以太坊隱私的務實願景。盡管可以在L1和L2引入一些功能以使隱私保護傳輸更加高效和可靠,但它現在就可以實現。一些隱私倡導者認爲,唯一可以接受的事情是所有事物的完全隱私:加密整個EVM。這可能是理想的長期結果,但它需要對編程模型進行更根本的重新思考,