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

以太坊基礎設施堆棧中錢包是關鍵層,但常被核心L1研究人員和開發者低估。錢包是用戶與以太坊世界溝通的窗口,用戶只有在錢包具備相應屬性時,才能從以太坊及其應用程序提供的去中心化、抗審查、安全、隱私等特性中受益。

近期以太坊錢包在改善用戶體驗、安全性和功能方面取得了顯著進展。本文旨在分享對理想以太坊錢包應具備特性的看法。這並非完整列表,反映了作者的密碼朋克傾向,側重於安全和隱私,在用戶體驗方面可能不夠全面。然而,作者認爲在優化用戶體驗方面,簡單地根據反饋進行部署和迭代比願望清單更有效,因此認爲關注安全和隱私屬性最有價值。

跨L2交易的用戶體驗

現在有一個越來越詳細的改善跨L2用戶體驗的路線圖,包括短期和長期部分。這裏討論短期部分:理論上現在就可以實施的想法。

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

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

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

這適用於"復制粘貼地址付款"的場景。對於應用程序請求存款的情況,理想流程是擴展web3 API並允許應用發出鏈特定支付請求。錢包能以任何必要方式滿足該請求。爲實現良好用戶體驗,還需要標準化getAvailableBalance請求,錢包需要認真考慮默認將用戶資產存儲在哪些鏈上,以最大化安全性和轉帳便利性。

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

另一相關主題是gas支付。如在尚無ETH的L2上收到資產並需要發送交易,錢包應能自動使用協議(如RIP-7755)從有ETH的鏈支付gas。如錢包預期用戶未來在L2上進行更多交易,也應只使用DEX發送足夠數量的ETH,以便未來交易可直接在那裏支付gas(因爲更便宜)。

帳戶安全

對帳戶安全挑戰的概念化方式是,好的錢包應同時在兩方面發揮作用:(i)保護用戶免受錢包開發者的黑客攻擊或惡意行爲,(ii)保護用戶免受自身錯誤影響。

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

基本設計可進行擴展。會話密鑰和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具有超出提供商本身的某種程度信任要求;如在受信任硬件內使用TLSNotary驗證更新密鑰可減少這種情況,但不理想。希望郵件提供商能開始直接簽署DKIM密鑰。目前建議使用一位監護人採用zk-email,但不建議大多數監護人使用:不要將資金存儲在zk-email損壞意味着無法使用資金的設置中。

新用戶和應用內錢包

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

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

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

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

隱私

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

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

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

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

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

以太