錢包是用戶和以太坊世界之間的連結視窗。
原文：What I would love to see in a wallet (vitalik.eth)
作者： Vitalik
編譯： imToken
本文編譯自 Vitalik 博客，原文連結請參考：https://vitalik.eth.limo/general/2024/12/03/wallets.html
特別感謝 Liraz Siri、Yoav Weiss 以及 imToken 、Metamask 和 OKX 開發人員的回饋和審查。
以太坊基礎設施堆疊的一個關鍵層是錢包，但這經常被專注於 Layer1 的研究人員和開發人員所低估。實質上，錢包是用戶和以太坊世界之間的連接窗口，而且，當用戶只能從以太坊和其相關應用程式所提供的去中心化、抗審查、安全、隱私等屬性中受益時，其實錢包本身也具備了這些屬性。
最近，我們看到以太坊錢包在改善用戶體驗、安全性和功能方面取得了巨大進展。撰寫這篇文章的目的是針對「理想的以太坊錢包應該具備怎樣的特性」提出我的看法。我的看法並不全面，會專注在闡釋有關錢包安全和隱私的屬性，這反映了我的密碼朋克（Cypherpunk）傾向。
此外，雖然錢包在使用者體驗方面的特性肯定是不完整的，但我認為透過「願望清單」的形式去優化使用者體驗不如依據回饋進行部署和迭代的實踐操作有效，因此，我認為我的看法聚焦在探討錢包的安全和隱私屬性上是最有價值的。
「全文速覽」
- Layer2 跨鏈交易的使用者體驗
- 錢包如何應對帳戶安全
- 錢包如何實現隱私保護
- 如何進行安全的鏈訪問
- 對 DApp 安全性的探討
- 理想的 Keystore 錢包
- 與 AI 等新範式技術結合的更長遠未來
跨 Layer2 交易的使用者體驗
現在有一個越來越詳細的改善跨 Layer2 用戶體驗的路線圖，該路線圖有短期部分和長期部分。在這裡，我將談論短期部分：即使在今天理論上仍然可以實施的想法。
這份短期路線圖的核心思想是：（i）內建 Layer2 跨鏈發送，以及（ii）鏈特定地址和支付請求。你的錢包應該能夠為你提供一個地址（遵循本 ERC 草案的風格），如下圖所示：
當某人（或某些應用程式）向你提供這種格式的地址時，你應該能夠將其貼到錢包的「收件人」欄位中，然後點擊「發送」。錢包應該以任何可能的方式自動處理發送的資料：
- 如果你在目標鏈上已經有足夠的所需類型的資產，請直接發送。
- 如果你在另一條鏈上有所需類型的資產（或多個其他鏈），使用 ERC-7683 等協議（實際上是一個跨鏈 DEX）發送。
- 如果你在同一鍊或其他鏈上有不同類型的資產， 使用去中心化交易所將它們轉換為正確鏈上正確類型的資產並發送。這應該需要用戶的明確許可：用戶將看到他們支付了多少費用、接收者收到了多少費用。
具有跨鏈位址支援的可能錢包介面的模型上面的內容適用於「你複製貼上位址（或 ENS，例如 vitalik.eth @ optimism.eth）有人向你付款」的用例。
如果 DApp 請求押金（可參閱 Polymarket 案例： https://x.com/VitalikButerin/status/1810633473750683974 ），那麼理想的流程是擴展 Web3 API 並允許 DApp 發出特定於鏈的支付請求。然後，你的錢包將能夠以任何需要的方式滿足該請求。
同時，如果追求用戶體驗良好，還需要標準化 getAvailableBalance 請求，並且錢包需要認真考慮預設將用戶資產儲存在哪些鏈上，以最大程度地提高安全性和資產轉移的便利性。
特定於鏈的支付請求也可以放入二維碼中，行動錢包可以掃描二維碼。在面對面（或線上）消費者支付場景中，接收者將發出 QR 碼或 Web3 API 調用，表示「我想要 Z 鏈上 X 數量的的資產 Y ，帶有參考 ID 或回調 W”，錢包將可以以任何方式自由滿足該請求。
另一種選擇是 claim link 協議，其中用戶的錢包生成包含索賠授權的 QR 代碼或 URL 從他們的鏈上合約中獲取一定數量的資產，接收者的工作就是弄清楚如何將這些資產轉移到他們自己的錢包中。
另一個相關主題是 Gas 費用的支付。如果你在 Layer2 上收到資產，但你在這個 Layer2 上尚未擁有 ETH，同時你需要在該 Layer2 上發送交易，錢包應該能夠自動使用協議（例如 RIP-7755）在你擁有 ETH 的鏈上支付 Gas 費用。
如果錢包希望你將來能在這個 Layer2 上進行更多的交易，它也應該直接通過去中心化交易所（DEX）轉移例如需要數百萬 Gas 費用的 ETH，這樣未來的交易可以直接在該 Layer2 上支付 Gas 費用（因為這樣會比較便宜）。
帳戶安全
我對帳戶安全挑戰的概念化的一種方式是：一個好的錢包應該同時在兩個方面發揮作用： （i）保護用戶免受錢包開發人員的黑客攻擊或惡意攻擊，以及（ii）保護用戶免受自己的錯誤的影響。
左邊的「錯誤」是無意的。然而，當我看到它時，我意識到它非常適合上下文，所以我決定保留它。
十餘年來，我對此的首選解決方案一直是社交恢復和多重簽名錢包，具有分級存取控制。通常，使用者的帳戶有兩層金鑰：一個主金鑰（Primary key）和 N 個監護人（Guardians)（例如 N = 5）。主密鑰是能夠進行低價值和非財務操作。大多數監護人需要執行 (i) 高價值操作，例如發送帳戶中的全部價值，或 (ii) 更改主金鑰或任何監護人。如果需要，可以允許主密鑰透過時間鎖執行高價值操作。
以上是基本設計，可以進行擴充。會話金鑰和 ERC-7715 等權限機制可以幫助支援不同應用程式的便利性和安全性之間的不同平衡。更複雜的監護人架構，例如在不同閾值下具有多個時間鎖定持續時間，可以幫助最大限度地提高成功恢復合法帳戶的機會，同時最大限度地降低盜竊風險。
監護人是什麼？
對於經驗豐富的加密用戶，如社群中的經驗豐富的加密用戶來說，一個可行的選擇是你朋友和家人的金鑰。如果你要求每個人為你提供一個新的地址，那麼沒有人需要知道他們是誰——事實上，你的監護人甚至不需要知道彼此是誰。如果他們沒有向你通風報信，他們串通一氣的可能性很小。然而，對於大多數新用戶來說，此選項不可用。
第二個選項是機構監護人：這種機構監護人是能夠提供僅在收到你的請求的其他確認訊息時（如確認碼或針對高價值用戶的視訊通話）才簽署交易的服務的實體機構。例如。我在 2013 年對 CryptoCorp 進行了介紹。然而，到目前為止，這些實體機構還不是很成功。
第三種選擇是多個個人設備（例如電話、桌上型電腦、硬體錢包）。雖然這也是可以實踐操作的，但對於沒有經驗的用戶來說也很難設定和管理，同時還存在設備同時丟失或被盜的風險，尤其是當它們位於同一位置時。
最近，我們開始看到越來越多基於密鑰（Passkey）設計的錢包。金鑰只能備份在你的裝置上，使其成為一種個人設備解決方案，也可以備份在雲端中，使其安全性依賴複雜的混合密碼安全、機構和可信任硬體假設。實際上，金鑰對一般使用者來說是一種寶貴的安全增益， 但僅靠它們還不足以保護使用者的畢生積蓄。
幸運的是，有了 ZK-SNARK，我們還有第四種選擇： ZK 包裹的中心化 ID 。這種類型包括 zk-email 、 Anon Aadhaar 、 Myna Wallet 等等。基本上，你可以採用多種形式（公司或政府）中心化 ID，並將其轉換為以太坊地址，你只能透過產生證明擁有中心化 ID 的 ZK-SNARK 來發送交易。
有了這個補充，我們現在有了廣泛的選擇，並且 ZK 包裝的中心化 ID 具有獨特的 “新手友好性”。
為了實現這一點，需要透過一個簡化且整合的使用者介面（UI）來實施：你應該能夠直接指定「example@gmail.com」作為監護人，並且系統應在後台自動產生對應的 zk-email 以太坊地址。高級用戶應能夠將自己的電子郵件（以及可能用於隱私保護的 Salt Value）輸入到開源的第三方應用程式中，並確認生成的地址是正確的。對於任何其他支援的監護人類型，也應該如此。
請注意，目前 zk-email 的一個實際挑戰是它依賴 DKIM 簽名，而這些簽名使用的金鑰每隔幾個月就會更換一次，而這些金鑰本身並未由其他權威機構簽署。這意味著目前的 zk-email 需要在提供者之外附加一定程度的信任。如果 zk-email 使用可信任硬體中的 TLSNotary 來驗證更新後的金鑰，這種信任需求可以減少，但這並非理想的解決方案。希望未來電子郵件提供者能夠直接簽署他們的 DKIM 金鑰。目前，我建議將 zk-email 用於一個監護人，但不要讓它佔多數監護人份額：不要在一個依賴 zk-email 的設置中存儲資金，因為如果 zk-email 出現問題，你可能會因此失去資金的存取權限。
新用戶和應用程式內建錢包
新用戶實際上不希望在第一次註冊時輸入大量監護人。因此，錢包應該為他們提供一個非常簡單的選擇。一種自然的途徑是在其電子郵件地址上使用 zk-email、本地儲存在用戶設備上的金鑰和提供者持有的備份金鑰，進行 2-of-3 的選擇。隨著使用者變得更有經驗或累積更多資產，在某些時候應該提示他們增加更多監護人。
錢包整合到應用程式中是不可避免的，因為試圖吸引非加密用戶的應用程式不希望用戶同時下載兩個新應用程式（應用程式本身，加上以太坊錢包）帶來混亂的用戶體驗。然而，許多應用程式錢包的用戶應該能夠將他們的所有錢包連結在一起，這樣他們就只需擔心一個「存取控制問題」。最簡單的方法是採用分層方案，其中有一個快速的「連結」流程，允許用戶將其主錢包設定為所有應用程式內錢包的監護人。 Farcaster 用戶端 Warpcast 已經支援這一點：
保護用戶免受詐騙和其他外部威脅
除了帳戶安全之外，當今的錢包還做了很多工作來識別虛假地址、網路釣魚、詐騙和其他外部威脅，並盡力保護用戶免受此類威脅。但是，許多對策仍然相當原始：例如，要求點擊才能將 ETH 或其他資產發送到任何新地址，無論你發送的是 100 美元還是 100,000 美元。在這裡，不存在單一的靈丹妙藥——這是針對不同類別威脅的一系列緩慢的持續修復和改進。然而，繼續努力改進這裡有很多價值。
隱私
現在是時候開始更認真地對待以太坊的隱私了。 ZK-SNARK 技術現在已經非常先進，不依賴後門來降低監管風險的隱私技術（例如隱私池）越來越成熟，而像 Waku 和 ERC-4337 mempools 這樣的二級基礎設施也慢慢變得更加穩定。
然而，到目前為止，在以太坊上進行私人資產轉移需要用戶明確下載並使用 “隱私錢包”，例如 Railway（或用於隱形地址的 Umbra），這增加了不便並減少了願意進行私人資產轉移的用戶數量，而這一切的解決方案是將私人資產轉移需要直接整合到錢包中。
一個簡單的實作方案如下：錢包可以將使用者部分資產儲存為隱私池中的「私人餘額」。當使用者進行資產轉移時，系統會優先從隱私池中自動提取資金。如果用戶需要接收資金，錢包可以自動產生一個隱密地址。
此外，錢包還可以為用戶參與的每個應用程式（例如一個 DeFi 協定）自動產生一個新的位址。存款將來自隱私池，而提款則直接進入隱私池。這種方式能夠使用戶在某一應用程式中的活動與他們在其他應用程式中的活動相互隔離，避免關聯。
這項技術的一個優點是：它不僅是保護隱私的資產轉移的自然路徑，也為隱私保護身分提供了路徑。
識別已經在鏈上實現：任何使用「身份認證」門檻的應用（例如 Gitcoin Grants）、任何基於 Token 的聊天功能、Ethereum Follow Protocol 等，都是鏈上的身份識別，我們希望這個生態系統也能實現隱私保護。
這意味著用戶的鏈上活動不應該集中存儲在一個地方：每項數據都應該單獨存儲，而用戶的錢包應該是唯一能夠「全局查看」所有認證資訊的工具。能夠支援每個用戶擁有多個帳戶的原生生態系統，以及像 EAS 和 Zupass 這樣的鏈下認證協議，都有助於實現這一目標。
這代表了以太坊在中期未來實現隱私保護的務實願景。雖然目前就可以實施，但在 Layer1 和 Layer2 還可以引入一些功能，以使隱私保護更加高效和可靠。
一些隱私倡導者認為，唯一可以接受的方案是實現全面隱私：例如對整個 EVM 進行加密。我認為，儘管這可能是長期理想的目標，但它需要對程式設計模型進行更根本性的重新設計，目前尚未成熟到可以在整個以太坊上部署的程度。
我們確實需要預設隱私來建立足夠大的匿名資料集。不過，我們可以先關注以下兩個方面，這是相對而言更加務實、更加容易實現的初步措施，並且錢包從現在就可以著手：
- 實現帳戶之間資產操作的隱私保護。
- 為身分和與身分相關的用例（如認證）提供隱私保護。
以太坊錢包也需要成為數據錢包
任何有效的隱私解決方案，無論是針對支付、身分還是其他用例，都不可避免地需要用戶儲存鏈下資料。這在 Tornado Cash 中表現的尤其明顯—— 它要求用戶保存下每筆獨立的、代表存入了 ETH（存入範圍：0.1 ETH ~ 100 ETH）的「備註憑證」。
一些更現代的隱私協議有時會將資料加密儲存在鏈上，並使用單一私鑰進行解密。這也是有風險的，因為如果密鑰洩露，或者量子電腦變得可行，資料就會全部公開。 EAS 和 Zupass 這樣的鏈下證明協定對鏈下資料儲存的需求更為明顯。
錢包不僅需要成為一個能夠儲存鏈上存取權限的軟體，還需要成為一個能夠儲存私人資料的工具。非加密的世界也越來越意識到這個需求的重要性。例如，可以參考 Tim Berners Lee 最近在研究的有關個人資料儲存方面的工作。
這些亟待解決的問題其實都圍繞在要設計有穩健的、能保障訪問權限控制的方案和穩健的、保障數據可訪問，同時防止數據防洩露的方案。
或許這些解決方案可以疊加在一起：如果你有 N 個監護人，可以在這 N 個監護人之間使用 M-of-N 秘密共享方案來儲存你的資料。資料的安全性本質上更難保障，因為你無法撤銷某人對資料的份額，但我們應努力設計出盡可能安全的去中心化託管解決方案。
安全的鏈訪問
如今，錢包服務商信任他們的區塊鏈遠端呼叫介面服務商（RPC Provider) 會告知有關鏈的任何資訊。但這種情況存在漏洞，漏洞包括以下兩個面向：
- RPC 服務商可能會嘗試透過提供虛假資訊來竊取金錢，例如虛假的市場價格。
- RPC 服務商可能會提取有關使用者在與哪些應用程式或帳戶互動的私人資訊。
理想情況下，我們希望堵住這兩個漏洞。為了解決第一個問題，我們需要 Layer1 和 Layer2 的標準化輕客戶端，它們可以直接驗證區塊鏈共識。
Helios 在 Layer1 上這樣實踐了，並在支援某些特定的 Layer2 專案上也進行了一些初步工作。
而為了正確涵蓋所有 Layer2 的需求，我們需要一個標準，例如透過配置合約來表示一個 Layer2（這也可用於表示某個鏈的特定位址），該合約可以聲明一個函數（類似於 ERC-3668 的方式），用於取得最近的狀態根（State root），並根據這些狀態根驗證狀態（States）和記錄（Recipits）的證明。
透過這種方式，我們可以實作一個通用的輕客戶端，使錢包能夠安全地驗證 Layer1 和 Layer2 上的任何狀態或事件。
對於隱私保護，目前唯一現實的做法是運行自己的完整節點。然而，隨著 Layer2 的出現，運行所有內容的完整節點變得越來越困難。在這種情況下，與輕客戶端對應的解決方案是私密資訊檢索（Private Information Retrieval, 簡稱 PIR） 。
私密資訊檢索的工作原理是由伺服器持有所有資料的副本，而客戶端向伺服器發送加密的請求。伺服器對所有數據進行計算，並傳回客戶端所需的數據，這些數據會被加密成客戶端的金鑰，而伺服器不會得知客戶端存取了哪部分數據。
為了保持伺服器的可信任性，各個獨立的客戶端可以將它們本身作為 Merkle 分支，如此一來，客戶端可以使用輕客戶端來驗證資料完整性。
私密資訊檢索技術（PIR）的算量很大、計算成本非常高。針對此問題，有以下幾種可能的解決途徑：
- 暴力方法：演算法改進或專用硬體可能能夠使私密資訊檢索技術的速度足夠快以投入實際使用。這些技術可能依賴預處理，例如伺服器為每個客戶端儲存加密和打亂的數據，客戶端查詢這些預處理後的資料。在以太坊的場景下，這個解決方案的主要挑戰在於將這些技術適配於快速變化的資料集（如狀態資料）。此外，雖然這種解決方案可以降低即時運算成本，但可能會顯著提高總運算和儲存成本。
- 弱化隱私需求：例如，每次查找只能有 100 萬個混合項資料（Mixins），因此伺服器雖然可以知道客戶端可以存取的 100 萬個資料中的某一個，但無法精確定位到具體的資料值。
- 多伺服器私密資訊檢索：使用多個伺服器，並在這些伺服器之間採用「1-of-N 誠實性假設」，可以顯著提升私密資訊檢索演算法的速度。
- 使用匿名性代替保密性：透過混合網路（mixnet）發送請求，從而隱藏請求發送者的身份，透過此解決方法取代隱藏請求的內容。然而，這種解決方案不可避免地會增加延遲，從而降低用戶體驗。
在以太坊環境下，找到能夠在隱私性和實用性之間取得最佳平衡的技術組合仍然是一個未解決的研究問題。我歡迎密碼學領域的研究人員嘗試解決這個難題。
理想的 Keystore 錢包
除了資產轉移和狀態存取之外，在 Layer2 跨鏈環境中，還有一個需要順暢運作的重要流程便是更改帳戶的驗證配置：無論是更改其密鑰（例如恢復密鑰），還是更深層次地更改帳戶的整個邏輯。在這個問題上，有三個不同難度等級的解決方案：
- 更新回放：當使用者變更其配置時，授權此變更的訊息會在錢包偵測到使用者擁有資產的每個鏈上進行回放。潛在地，訊息格式和驗證規則可以設計為與鏈無關的訊息，從而使得訊息能夠在盡可能多的鏈上自動回放。
- Layer1 上的 Keystore：設定資訊位於 Layer1 上，Layer2 上的錢包使用 L1SLOAD 或 REMOTESTATICCALL 讀取。這樣一來，只需要在 Layer1 上更新配置，配置就會自動生效。
- Layer2 上的 Keystore：設定資訊存在於 Layer2 上，Layer2 上的錢包使用 ZK-SNARK 讀取。這與上述第 2 個解決方案的實作原理相同，只是金鑰儲存的更新成本可能相對較便宜，但讀取需要花費的成本較高。
在上述解決方案中，第 3 個解決方案特別強大，因為它與隱私保護非常契合。在正常的「隱私解決方案」中，使用者有一個秘密 s，一個「leaf value」中的 L 被發佈到鏈上，用戶證明 L = hash(s, 1) 和 N = hash(s, 2)，其中 s 是一個從未透露的秘密，由使用者控制。
當 N 被發布，確保未來使用相同 “leaf” 的支出失敗，但從未透露 L。這依賴於用戶保護好了 s。
而一個更適合恢復的隱私解決方案則會說：s 是鏈上的一個位置（例如位址和儲存槽），使用者必須證明一個狀態查詢：L = hash(sload(s), 1)。
DApp 安全用戶安全中最薄弱的環節通常是 DApp。
大多數時候，使用者透過造訪網站與應用程式互動，網站會即時從伺服器下載使用者介面程式碼，並在瀏覽器中執行。如果伺服器被駭客攻擊，或者 DNS 被篡改，使用者將看到一個假的介面副本，這可能會誘使用戶執行任意操作。像交易模擬這樣的錢包功能對於減輕這些風險非常有幫助，但它們遠遠不完美。
理想情況下，我們應該將生態系統遷移到鏈上的內容版本控制：使用者將透過其 ENS 名稱存取 DApp，該名稱包含介面的 IPFS 雜湊值。更新介面需要透過多簽或 DAO 發起的鏈上交易。錢包會向用戶顯示他們是否在與更安全的鏈上介面互動，還是與不太安全的 Web2 介面互動。錢包還可以顯示用戶是否在與安全性較高的鏈（例如階段 1+、經過多次安全審計的鏈）互動。
對於注重隱私的用戶，錢包還可以添加一個偏執模式（Paranoid Mode），要求用戶點擊接受 HTTP 請求，而不僅僅是 Web3 操作。
偏執模式可能的介面模型一種超越 HTML + Javascript 的、更先進的方法是使用專有語言編寫 DApp 的業務邏輯（這種語言不一定是一個複雜的全新語言或者框架，可以是在 Solidity 或 Vyper 之上建立一個相對簡單、輕量的附加層）。瀏覽器可以自動產生任何所需功能的使用者互動介面。 OKContract 已經在實踐這個方法。
另一個方向是加密經濟資訊防禦： DApp 開發人員、安全公司、鏈部署者和其他人可以設立一筆保證金，如果 DApp 被駭客攻擊或以高度誤導性的方式傷害用戶，則該保證金將支付給受影響的用戶，賠償的具體標準由某個鏈上仲裁 DAO 決定。錢包可以向用戶顯示一個基於保證金大小的分數。
更長遠的未來以上內容是有關傳統介面的討論，這些介面涉及 “點擊 ” “指向 ” 和在文字方塊中輸入內容。然而，我們也正處在典範發生更深刻變化的邊緣：
- 人工智慧：讓我們從 “點擊和輸入” 範式轉向 “說出你想做什麼，機器人幫你搞定” 的範式。
- 腦機介面：既有眼動追蹤等「溫和」的方法，也有更直接、甚至侵入性的技術。
Neuralink 首次病患訪談：https: //www.wired.com/story/neuralink-first-patent-interview-noland-arbaugh-elon-musk/ - 用戶端主動防禦：可參考事件如 Brave 瀏覽器主動保護使用者免受廣告、追蹤器和許多其他不良物件的侵害。許多瀏覽器、插件和加密錢包都有整個團隊積極致力於保護用戶免受各種安全和隱私威脅。這些「積極的守護者」在未來十年只會變得更加強大。
了解 Brave 瀏覽器主動防禦，詳情查閱：https://brave.com/shields/
這三種趨勢的結合將促使我們對介面的工作方式進行更深刻的重新思考。透過自然語言輸入、眼動追踪，或最終更直接的腦機接口，加上對你的使用歷史的了解（可能包括文字訊息，只要所有資料都在本地處理），一個「錢包」可以直觀地理解你想做什麼。然後，人工智慧技術可以將這種直覺轉化為一個具體的 “行動計劃 ”：一系列鏈上和鏈下的交互，以實現你想要的目標。
如此這般，將大大減少完全依賴第三方使用者介面的需求。如果用戶確實與第三方應用程式（或其他用戶）互動，人工智慧技術應該代表用戶採取對抗性思維，識別任何威脅並提出避免這些威脅的行動計劃。理想情況下，會有一個由不同團體、具有不同偏見和激勵結構的人工智慧開發者所構成的開放生態系統。
這些更激進的想法依賴目前非常不成熟的技術，因此我不會將我的資產放入依賴這些技術的錢包中。然而，這樣的事情顯然是未來的趨勢，因此值得開始更積極地朝著這個方向探索。
免責聲明：作為區塊鏈資訊平台，本站所發布文章僅代表作者及來賓個人觀點，與 Web3Caff 立場無關。文章內的資訊僅供參考，均不構成任何投資建議及要約，並請您遵守所在國家或地區的相關法律法規。
