撰文：Vitalik Buterin
編輯：Yangz，Techub News
錢包是以太坊基礎架構堆疊中的關鍵層，但它往往不被核心L1 研究者和開發人員所重視。錢包是用戶與以太坊世界之間的窗口，用戶只有在錢包本身也具有去中心化、抗審查、安全、隱私或以太坊及其應用提供的其他特性的情況下，才能從中獲益。
近年來，我們看到了以太坊生態錢包在改善用戶體驗、安全性和功能方面取得了巨大進展。本文的目的是就理想的以太坊錢包應具備的一些屬性發表我個人的看法。這份清單不會是完備的，但反映了我的加密龐克傾向。對於錢包，我更重視安全性和隱私性，因為在用戶體驗方面幾乎不會有完美的錢包存在。我認為，願望清單對於優化使用者體驗的效果不如簡單地根據回饋進行部署和迭代，在我看來，關注安全和隱私屬性是最有價值的。
跨L2 交易的使用者體驗
目前改善跨L2 使用者體驗的路線已越來越詳盡，其中有短期部分，也有長期部分。在此，我想談談短期部分，也就是即使在今天，理論上也可以實現的想法。
這部分的核心理念是內建跨L2 交易以及特定鏈地址和支付請求。錢包應該提供這樣一種地址：
當某人（或某個應用程式）向你提供這種格式的地址時，你應該可以將其貼到錢包的“to”欄位中，然後點擊“send”，錢包就會自動處理：
如果目標鏈上已有足夠的所需類型的代幣，則直接發送；
如果你在另一條鏈（或多條鏈）上有所需類型的代幣，則可以使用類似ERC-7683的協議（實際上是跨鏈DEX）發送代幣；
如果你在同一條鍊或其他鏈上擁有不同類型的代幣，則可使用DEX 將其轉換為正確鏈上的正確類型代幣並發送。當然，這也需要用戶的明確許可，也就是說，用戶將看到自己支付了多少錢，而接收者又收到了多少錢。
以上是「複製貼上地址（或ENS，例如vitalik.eth@optimism.eth）讓別人付款給您」的用例。如果是向DApp 進行存款（請參閱Polymarket 範例），那麼理想的流程是擴展Web3 API，允許DApp 提出特定鏈的付款請求。這樣，用戶錢包就能以任何方式滿足該請求。要讓用戶體驗良好，還需要對getAvailableBalance 請求進行標準化，而且錢包需要考慮將用戶的資產預設儲存在哪條鏈上，以最大限度地提高安全性和轉帳的便利性。
針對特定鏈的支付請求也可以置於二維碼中，方便手機錢包直接掃描。在當面（或線上）消費支付場景中，收款人可以透過二維碼或Web3 API 呼叫「我想要Z 鏈上X 單位的Y 代幣，並附帶參考ID 或回調W」 ，而錢包則可以自由地以任何方式滿足該請求。另一個方案是申領連結協議，即用戶錢包可以產生一個二維碼或URL，其中包含從其鏈上合約中申領一定數量資金的授權，而收款人的工作就是想辦法把這些資金轉到自己的錢包。
另一個相關的話題是gas 支付。如果你在一個尚未擁有ETH 的L2 上收到資產，並且需要在該L2 上發送一筆交易，那麼錢包應該能夠自動使用一個協議（例如RIP-7755 ）在你擁有ETH 的鏈上支付gas。如果錢包預計你將來會在該L2 上進行更多交易，那麼它也應該使用DEX 發送價值數百萬gas 的ETH，以便未來的交易可以直接在使用gas（這樣也更便宜）。
帳戶安全
我對帳戶安全挑戰的理解是，一個好的錢包應該既能保護用戶免受錢包開發者的駭客攻擊或惡意攻擊，也能保護用戶免受自身錯誤的傷害。
縱軸上的錯字“mistakles”是無心之失。我覺得這錯誤很符合上下文，所以並沒有進行修改。
十多年來，我首選的解決方案一直是社交恢復和多簽錢包，並採用分級存取控制。單一使用者帳戶設定兩層金鑰，包括一個主金鑰和N 個簽署者（例如N = 5）。主密鑰可以進行低價值和非財務操作。但要進行高價值操作，例如發送帳戶中的全部資產，或更改主密鑰或任何簽署者，則需要大多數簽署者的參與。如果需要，可以允許主密鑰進行具有時間鎖的高價值操作。
以上只是基礎的設計，我們還可以擴充。例如，會話金鑰和權限機制（如ERC-7715 ）可以幫助支援不同應用在便利性和安全性之間取得不同的平衡。更複雜的簽署者架構，如在不同閾值下設定多個時間鎖持續時間，有助於最大限度地提高成功找回合法帳戶的幾率，同時最大限度地降低被盜風險。
多簽錢包的簽名者該選誰？
對於經驗豐富的加密貨幣用戶來說，一個可行的選擇是你的朋友和家人。事實上，你的多簽錢包簽名者甚至不需要知道彼此是誰。在你不知情的情況下，他們串通一氣的可能性微乎其微。然而，對於大多數新用戶來說，這種選擇是不可行的。
第二種選擇是機構，也就是那些專門提供服務的公司。這類簽章者只有在獲得其他確認資訊（如確認碼，或高淨值用戶的視訊通話）後才會簽署交易。很長一段時間以來，人們一直在嘗試創立這樣的公司，例如，我曾在2013 年介紹過CryptoCorp 。不過，到目前為止，這類公司還沒有很成功的代表。
第三種選擇是使用多個個人裝置（如手機、桌上型電腦、硬體錢包）。這種方法可以奏效，但對於缺乏經驗的使用者來說，也很難設定和管理。此外，還存在設備同時遺失或被盜的風險，尤其是當它們處於同一地點時。
最近，我們開始看到更多基於passkey 的錢包出現。 Passkey 可以只在裝置上備份，使其成為一種個人到裝置的解決方案，也可以在雲端備份，使其安全性依賴於密碼安全、機構和可信任硬體假設的複雜混合體。實際上，passkey 對一般使用者來說是一種寶貴的安全增益，但光靠它還不足以保護使用者的畢生積蓄。
幸運的是，有了ZK-SNARK，我們有了第四種選擇，即經ZK 處理的中心化ID。這一類型包括zk-email 、 Anon Aadhaar 、 Myna Wallet等。基本上，你可以使用多種形式的（企業或政府）中心化ID，並將其轉換為以太坊地址，只有產生ZK-SNARK 證明擁有該ID，你才能從該地址發送交易。
有了這個新功能，我們就有了多種選擇，而且經ZK 處理的中心化ID 對新手非常友善。
要實現這一點，我們需要使用精簡的整合式使用者介面。用戶只需指定「example@gmail.com」為簽署者，錢包就會在自動產生對應的zk-email 以太坊地址。此外，進階使用者應能在開源第三方應用程式中輸入自己的電子郵件（以及可能會儲存在電子郵件中的隱私鹽值），並確認產生的位址正確無誤。任何其他受支援的簽署者類型也應如此。
需要注意的是，zk-email 目前面臨的一個實際挑戰是，它依賴DKIM 簽名，而DKIM 簽章使用的金鑰每幾個月輪換一次，而且這些金鑰本身沒有任何其他機構的簽章。這意味著除了提供者本身之外還有一定程度的信任要求；如果zk-email 在受信任的硬體中使用TLSNotary來驗證更新的金鑰，則可以降低信任要求，但這並不理想。希望電子郵件提供者能開始直接簽署DKIM 金鑰。此外，我建議只在一個簽名者身上使用zk-email，而不是大多數簽名者。這樣，即使zk-email 崩潰，也不會失去資金存取權。
新用戶和應用程式內錢包
現實中，新用戶不會希望在首次註冊時就輸入大量多簽錢包簽名者的資訊。因此，錢包們應該提供一個非常簡單的選擇。一個自然的方法是3 個簽章中有2 個使用zk-email，也就是使用者裝置上本機儲存的金鑰（可以是passkey）和提供者持有的備份金鑰。而隨著使用者經驗的增加或資產的累積，在某些情況下，他們會被提示加入更多的簽署者。
將錢包整合到應用程式中是不可避免的，因為試圖吸引非加密貨幣用戶的應用程式不會希望讓用戶同時下載兩個新的應用程式（應用程式本身和以太坊錢包），從而造成不好的用戶體驗。使用多個錢包的用戶也應該能夠將所有錢包連接在一起，這樣他們就只需要擔心「存取控制問題」。最簡單的方法是採用分層方案，透過快速的「連結」過程，使用者可將自己的主錢包設定為所有應用程式內錢包的簽署者。目前，Farcaster 用戶端Warpcast 已支援這種方式。
預設情況下， Warpcast 帳戶的恢復由Warpcast 團隊控制。但用戶可以「接管」 Farcaster 帳戶，並將其改成自己的地址。
保護用戶免受詐欺和其他外部威脅
除了帳戶安全之外，如今的錢包在識別虛假地址、網路釣魚、詐騙和其他外部威脅方面也做了很多工作，並努力保護用戶免受此類威脅。然而，許多反制措施仍然相當原始。例如，向任何新地址發送ETH 或其他代幣都只需點擊就行，無論發送的是100 美元還是10 萬美元。在這方面，沒有單一的解決方案，而是針對不同類別的威脅進行一系列緩慢的持續修復和改進。但是，繼續努力改進是有很大價值的。
隱私
ZK-SNARK 技術已非常先進，而隱私池（ Privacy Pools ）等不依賴後門就能降低監管風險的隱私技術也越來越成熟， Waku和ERC-4337 等二級基礎設施也慢慢變得更加穩定。然而，到目前為止，在以太坊上進行私密性的轉賬仍舊需要用戶明確下載並使用“隱私錢包”，如Railway （或用於隱身地址的Umbra ）。這給用戶帶來了極大的不便，也減少了這類用戶的數量。對於這個問題，解決方法是將這類轉帳直接整合到錢包中。
一個簡單的實作方法是，錢包可以將用戶的部分資產作為「私人餘額」儲存在隱私池中。當使用者進行轉帳時，會自動先從隱私池中提取。如果用戶需要接收資金，錢包會自動產生一個隱身地址。此外，錢包還能為用戶參與的每個應用程式（如DeFi 協定）自動產生一個新位址。存款來自隱私池，提款直接進入隱私池。這樣，使用者在任何一個應用程式中的活動都與他們在其他應用程式中的活動無關。
這種技術的一個優點是，它不僅實現了資產轉移的隱私性，也實現了身分識別的隱私性。目前，識別已在鏈上實現，任何使用proof-of-personhood 的應用（如Gitcoin Grants）、任何需要特定代幣才能進行聊天、以及Ethereum Follow 協議等都是鏈上識別。我們希望這個生態也能具有隱私性，也就是說，用戶在鏈上的活動不應該被收集在一個地方，每個項目都應該單獨存儲，用戶的錢包也應該是唯一具有“全局視圖”的東西，可以同時看到你的所有證明。與EAS和Zupass等鏈外認證協議一樣，每個用戶擁有多個帳戶的原生生態有助於實現這一目標。
這代表了以太坊隱私在中期未來的務實願景。儘管它可以在今天實現，但在L1 和L2 階段引入一些功能，將使保護隱私的交易更有效率、更可靠。一些隱私保護倡導者認為，唯一可以接受的是一切都完全隱私化，對整個EVM 進行加密。但我認為，這可能是長期的理想結果，需要對程式設計模型進行更根本的重新思考，而且它目前還沒有成熟到可以在以太坊上部署的程度。我們確實需要「預設隱私」（privacy-by-default）來獲得足夠大的匿名性。然而，專注於帳戶之間的轉賬，以及身份和與身份相關的用例）的隱私性是務實的第一步，它更容易實現，可為錢包現階段著手建設。
以太坊錢包也需要成為數據錢包
任何有效的隱私解決方案，無論是用於支付、識別還是其他用例，都會導致用戶需要儲存鏈下資料。這一點在Tornado Cash 中就很明顯，它要求用戶保存代表0.1-100 ETH 存款的每張「note」。而更現代的隱私協議有時會保存鏈上加密的數據，並使用單一私鑰進行解密。然而，這是有風險的，因為如果密鑰洩露，或者量子電腦成為可能，資料就會全部公開。屆時，像EAS 和Zupass 這樣的鏈下認證對鏈下資料儲存的需求就會更為明顯。
錢包不僅需要成為儲存鏈上存取權限的軟體，還需要成為儲存私密資料的軟體。這一點在非加密貨幣世界中也得到了越來越多的認可，具體可參閱Tim Berners-Lee最近在個人資料儲存方面所做的研究。我們需要解決的所有問題，不僅要有力地保證存取權限的控制，還要有力地保證資料的可存取性和不洩漏。也許這兩種解決方案可以疊加在一起，假設你設定了N 個多簽簽章者，那麼可以在這N 個簽章者之間使用M-of-N 秘密共享來儲存資料。從本質上講，資料是更難確保安全的，因為你無法撤銷別人的資料份額，但我們應該盡可能地提出安全的去中心化託管解決方案。
安全的區塊鏈訪問
許多錢包相信RPC 提供者會告訴它們有關鏈的任何資訊。這在兩個方面存在漏洞。首先，RPC 提供者可能試圖透過提供虛假資訊（如市場價格）來竊取資金；其次，RPC 提供者可以提取用戶與哪些應用程式和其他帳戶互動的私人資訊。
理想情況下，我們需要要防止這兩個漏洞的出現。要防止第一個漏洞，我們需要標準化的L1 和L2 輕客戶端，直接驗證區塊鏈共識。 Helios已為L1 實現了這項功能，並且已經開展了一些初步工作來支援一些特定的L2。為了適當地涵蓋所有L2，我們需要一個標準，透過該標準，代表L2 的配置合約（也用於特定鏈位址）可以發布一個函數（也許採用類似於ERC-3668的方式），其中包含取得最近狀態根的邏輯，並根據這些狀態根驗證狀態證明和收據。這樣，我們就可以擁有一個通用的輕客戶端，讓錢包安全地驗證L1 和L2 上的任何狀態或事件。
至於第二個漏洞，目前唯一可行的方法就是運行自己的全節點。然而，隨著L2 的普及，運行一個包含所有內容的完整節點變得越來越困難。針對這個問題，與輕客戶端這項解決方案相當的是私人資訊檢索(PIR)。 PIR 涉及一個持有所有資料副本的伺服器，以及一個向伺服器發送加密請求的用戶端。伺服器對所有資料執行計算，傳回客戶端所需的資料（使用客戶端的金鑰加密），而不會向伺服器透露客戶端存取了哪些資料。
為了讓伺服器保持誠實，單一資料庫專案本身需要是默克爾樹分支，因此客戶端可以使用自己的輕客戶端對其進行驗證。
PIR 的計算成本很高，但有幾種方法可以解決這個問題：
蠻力：演算法或專用硬體的改進有可能使PIR 的運作速度夠快。這些技術可能依賴預處理，即伺服器為每個客戶端儲存經過加密和洗牌的數據，客戶端可以查詢這些數據。在以太坊環境中，主要的挑戰在於如何使這些技術適應快速變化（如狀態變化）的資料集。這將降低即時計算成本，但很可能會提高總計算和儲存成本。
削弱隱私要求：例如，每次查詢只能有100 萬個“mixins”，因此伺服器會知道客戶端可能存取的100 萬個可能值，但不會知道更細的粒度。
多伺服器PIR：如果使用多個伺服器，並假設這些伺服器之間的誠實度為1-of-N，那麼PIR 演算法的速度通常會快很多。
匿名性而非保密性：可以透過混合網路發送請求，隱藏請求的發送者，而不是隱藏請求的內容。然而，這樣做會不可避免地增加延遲，使用戶體驗惡化。
在以太坊環境下，找出既能最大限度保護隱私又能保持實用性的技術組合是一個開放性的研究課題，歡迎密碼學家們踴躍嘗試。
理想的密鑰儲存錢包
除了傳輸和狀態存取外，在跨L2 環境下需要順利運行的另一個重要工作流程是更改帳戶的驗證配置（無論是更改金鑰，還是對帳戶的整個邏輯進行更深層的更改）。以下是三層解決方案，難度依序遞增：
重播更新：當使用者變更配置時，授權變更的訊息會在錢包偵測到使用者擁有資產的每條鏈上重播。資訊格式和驗證規則可能與鏈無關，因此可以在盡可能多的鏈上自動重播。
L1 上的金鑰儲存：設定資訊保存在L1 上，L2 上的錢包透過L1SLOAD或REMOTESTATICCALL讀取設定資訊。這樣，只需在L1 上更新配置，配置就會自動生效。
L2 上的金鑰儲存：設定資訊保存在L2 上，L2 上的錢包透過ZK-SNARK 讀取設定資訊。這與第（2）種情況相同，只是密鑰儲存更新的成本更低，而讀取的成本則更高。
第三種解決方案特別強大，因為它能很好地與隱私堆疊。在普通的「隱私解決方案」中，假設用戶有一個秘密s，在鏈上發布了一個「leaf value」L ，用戶證明L = hash(s,1)以及N = hash(s,2) 是其控制的某個（從未公開的）秘密。 N 會被公佈，以確保未來對同一Leaf 的花費不會失敗，且不會洩露L。而在對帳戶恢復友好的隱私解決方案中，s 是鏈上的一個位置（如地址和存儲slot），用戶必須證明狀態查詢，即L = hash(sload(s), 1) 。
DApp 安全
用戶安全中最薄弱的環節往往是DApp。大多數情況下，使用者透過造訪網站與應用程式進行交互，網站會從伺服器即時下載使用者介面程式碼，然後在瀏覽器中執行。如果伺服器被駭客攻擊，或者DNS 被駭客攻擊，用戶就會得到一個假的介面副本，誘使用戶做一些任意事情。交易模擬等錢包功能對降低風險很有幫助，但還遠遠不夠。
理想情況下，我們需要將生態轉移到鏈上內容版本，使用者將透過其ENS 名稱存取DApp，該名稱將包含介面的IPFS 雜湊值。要更新接口，就需要來自多ID 或DAO 的鏈上交易。錢包會向用戶顯示，他們是在與安全性更高的鏈上介面交互，還是在與安全性較低的Web2 介面交互。錢包還可以向用戶顯示他們是否正在與安全的區塊鏈（例如，stage 1+，多重安全審計）進行互動。
對於注重隱私的用戶，錢包還可以更強硬一些，要求用戶點擊接受HTTP 請求，而不僅僅是Web3 操作。
更先進的方法是超越HTML + Javascript，用專用語言編寫DApp 的業務邏輯，例如在Solidity 或Vyper 上覆蓋一種相對輕型的語言。這樣，瀏覽器就可以自動為任何需要的功能產生使用者介面。 OKContract已經這麼做了。另一個方向是加密經濟資訊防禦，即DApp 開發者、安全公司、鏈上部署者和其他人可以設立一個保證金，如果DApp 被駭客攻擊或以其他透過高度誤導的方式損害了用戶，該保證金將在鏈上裁決DAO做出決定後，支付給受影響的用戶。錢包可以向用戶顯示基於保證金大小的評分。
更長遠的未來
以上所述都是在傳統的背景下進行的，目前的我們也正處於模式發生深刻變化的邊緣：
人工智慧（AI）或將使我們從「click and type」的模式轉變為「say and bot figures it out 」的模式。
腦機介面：既包括眼動追蹤等相對「溫和」的方法，也包括更直接、甚至侵入性的技術（如首位Neuralink 患者）
用戶端參與主動防禦： Brave 瀏覽器主動保護使用者免受廣告、追蹤器和許多其他不良物件的侵害。許多瀏覽器、插件和加密貨幣錢包都有整個團隊在積極保護用戶免受各種安全和隱私威脅。未來十年，這類「主動守護者」將變得更加強大。
這三種趨勢加在一起，將促使人們對錢包的工作方式進行更深入的反思。透過自然語言輸入、眼球追蹤或最終更直接的生物辨識（BCI），再加上對使用者歷史記錄的了解，「錢包」就能憑直覺清楚知道使用者想做什麼。然後，AI 可以將這種直覺轉化為具體的「行動計劃」，例如一系列鏈上和鏈下的交互，從而實現用戶意圖。這可以大大減少對第三方使用者介面的需求。如果用戶確實與第三方應用程式（或其他用戶）進行了交互，AI 也應該代表用戶進行對抗性思考，識別任何威脅並提出避免威脅的行動計劃。理想情況下，這些AI 將形成一個開放的生態，由具有不同偏見和激勵結構的不同團體產生。
當然，這些更激進的想法依賴於目前還極不成熟的技術，因此我不會把我的資產放在依賴這些技術的錢包裡。不過，這類技術似乎是未來的趨勢，因此值得我們開始朝這個方向進行更積極的探索。
