作者 | Billy Rennekamp
在論壇帖子《作為通用錢包的Cosmos Hub》中，我提出了用戶和區塊鏈之間的未來主義關係，這涉及到當前Cosmos-SDK 和即將到來的功能的組合。 「子私鑰」（或Msg 授權）被稱為Interchain Accounts （ICS-27）的標準以及Cosmos Hub 本身的安全性。 https://www.albrow.com/things
這是一種充滿想像力提案，但它讓我思考我們需要進入一個安全且易與許多區塊鏈交互的未來。不過這到底需要哪些步驟，我提出了一條前進的道路，其結果是將關注點分離，並建立一類新的錢包，創立賬戶協調功能。
當前的錢包狀況
到目前為止，我們已經看到了很多錢包解決方案，它們試圖同時做很多事情。到目前為止，錢包的功能還不完備，但隨著我們進入一個用戶希望與許多網絡交互的世界，當前無法擴展的架構尚無法滿足這一需求。在一個高層次上，錢包的各種職責包括：
私鑰管理
應用界面
交易管理
Ethereum 已經經歷了一些這樣的成長之痛，因為像EVM 這樣的圖靈完整的虛擬機幾乎允許任何種類的應用存在，而且它們都期望從一個錢包中工作。雖然Ethereum 錢包已經提出了協議和巧妙的解決方案，為各種各樣的應用提供接口，但他們仍然期望這些應用是來自一個通用的EVM 基礎設施。隨著我們看到特定應用區塊鏈的模式成為現實，通過IBC 連接，Ethereum 如何處理各種應用的界限將被打破。
切實可行的方法是將關注點分離。讓這三個任務作為獨立的解決方案存在，每個都可以專注於做好自己的唯一任務。這將揭示出對一種新型服務的需求，我一直稱之為賬戶協調功能。
私鑰管理
密碼學是很難的。如果你不是專家，犯錯誤的機率很高，後果可能是災難性的。期望所有錢包和dApp 開發者都在內部擁有這種專業知識是不公平的。傳統的應用程序已經認識到了這一點，並且經常通過將認證委託給使用oAuth 標準的第三方來解決。
你可能認為這是錢包唯一的真正責任是保證你的私鑰安全。但當我介紹其他常見的功能時，你會發現這遠非如此。事實上，這往往是錢包建設者最不具備的能力。密碼學和安全專家應該負責開發行業標準的解決方案，並實施私鑰存儲的最佳實踐。這應該是他們的全部業務，然而相反，我們看到現在的錢包在安全性方面做的不錯--但當涉及到密碼學時，這並不夠好。
如果將私鑰存儲的責任從錢包中移除，可能會導致更多種類的安全解決方案，這些解決方案依賴於不同的假設並提供不同的功能。目前已經有很多超越傳統軟件存儲的私鑰解決方案：像Ledger中的硬件安全模塊，或者其他加密技術，比如Torus 使用的shamir 秘密共享，像ZenGo 使用的閾值方案，多方計算，或者新穎的零知識技術。鄭重聲明，我認為保管私鑰管理的共同責任空間也完全沒有被開發出來。
不管私鑰到底是如何存儲的，存儲方案的責任其實應該止於此。其只做一件事，而且要做好--存儲私鑰。對私鑰的訪問應該由類似的安全授權技術來處理。
WalletConnect ，或者類似的用於在私鑰管理器和應用程序之間傳輸數據的協議是進一步授權應該發生的地方。
應用界面
如今，一個錢包對應用接口的範圍相當廣泛。一方面，一些錢包提供了對應用功能的深度集成訪問。 Argent 和Gnosis Safe 都在每個應用的基礎上支持越來越多的自定義接口。這也是大多數Cosmos 錢包的路線，網絡期望最低限度的stake 和治理接口。直接在錢包內提供自定義接口意味著你可以確保更好的用戶體驗，但它限制了錢包可以訪問的應用數量，也限制了錢包變成新的應用。
在另一端，是試圖將大部分接口責任推給應用開發者的錢包。一般來說，錢包使用web3.js 或cosmJS 將一個API 或接口接入到應用程序中。或者，錢包可能包含它自己的瀏覽器，並已經集成了API （Mist、Metamask Mobile、Status 和Coinbase Wallet）。它們也可以利用瀏覽器擴展來接入API （Metamask，Keplr）。 WalletConnect 允許接口在移動和桌面瀏覽器之間以及移動和移動之間傳輸。無論哪種方式，都要由應用開發者來訪問和利用錢包API，以便為用戶提供簽名功能。這條路徑消除了錢包作為訪問應用的瓶頸，但也帶來了自身的挑戰--即安全性和流暢的用戶體驗。
應該考慮一種安全的授權技術，以確保應用程序能夠訪問簽名功能，而不會因為確認的界面而勸退用戶同時也不會使用戶陷入不小心簽名的境地。 MetaMask 一直在嘗試解決這個問題，它創建了一個可組合的安全接口，用於私鑰與應用程序的通信，稱為「Snaps」。它在很大程度上借鑒了Agoric 的首席科學家Mark Miller 在對象能力方面的工作，對象能力對可以跨環境傳輸的精確對象級控制進行編碼。 Snaps 提供了連接應用程序和私鑰管理器所需的安全性和標準化，但我認為Metamask 在這個架構上走得還不夠遠，因為所有三個錢包功能都可能被隔離並使用這個模型組成。
交易管理
雖然我們已經看到很多錢包承擔了提供應用接口的重任，但我還是認為，到目前為止，錢包的主要職責是私鑰管理。這使得錢包的第三個職責--交易管理的資源嚴重不足。我希望看到這成為錢包的主要職責，因為應用接口和私鑰管理成為指定第三方的責任。
交易管理可以被認為是應用和簽名解決方案之間的實際接口。這是一些操作的請求被解析成可以被私鑰簽名的格式的步驟。它包括與應用的通信以及與私鑰管理的通信。在這兩者之間，需要簽署的數據應該被解析，並以一種用戶可以理解他們正在簽署的內容和原因的方式顯示給用戶。此外，這些簽名請求的歷史和狀態應該被記錄下來並提供給用戶。
當使用Ethereum 時，交易管理是很棘手的，因為基本上只有一種交易類型（eth_send），但它包括一個數據字段，當針對智能合約時，可以引用任何數量的方法。如果你很幸運，錢包能夠訪問與它交互的特定合約的ABI 文件，允許將數據字段轉換為函數名和參數。 ABI 文件還可以讓錢包顯示交易成功處理後發出的事件。這就進入了區塊瀏覽器的領域，它是一個完整的服務，基本上專門用於賬戶歷史--以及整個網絡的歷史。然而到目前為止，區塊瀏覽器在網絡方面大多是單一的。
在這空間中，有許多不同的消息可以包含在交易中。這些消息中的每一個都有不同的功能，但傳統上都是自行運行的，所以不需要外部的ABI 文件。隨著向protobuf 的遷移，我們看到正在進行的討論是如何保留這些性質，同時確保protobuf 帶來的所有性能的提高。一個選擇將是在protobuf 文件中像ABI 一樣使用，但還有許多其他解決方案仍在探索中。
無論網絡架構如何，這都是一個棘手的問題，但對於確保用戶能夠驗證他們到底在做什麼是至關重要的。當額外的私鑰被添加到這個組合中時，這個問題會變得更加複雜。一些錢包已經允許你創建許多賬戶，這些賬戶都來自於一個共同的助記詞與私鑰派生路徑。這對於那些不想把自己的DeFi 賬戶和遊戲賬戶混在一起的用戶來說，是一個很有用的功能。通過私鑰派生可以在網絡之間進行切換，儘管我不知道有哪個Ethereum 錢包允許你通過支持多個助記詞和私鑰來合併賬戶（不過Keplr 有）。這就給用戶帶來了負擔，要跟踪哪個身份與哪個私鑰相關聯。
賬戶協調功能
交易管理一直沒有得到充分的服務，隨著網絡的增加和相應私鑰的增多，這個問題只會越來越嚴重。隨著子私鑰將賬戶能力分配給特定私鑰的能力的增加，這一問題將成倍增加。職責範圍的擴大，值得為這個角色起一個新的名字。我想為一種新型的錢包提出一個理由，它主要關注的是成為一個賬戶協調服務。
賬戶協調功能的主要目標是跟踪哪些私鑰在哪些網絡上具有哪些功能--以及如何使用WalletConnect 等協議訪問這些私鑰的簽名功能。雖然它應該努力實現外部的隱私和匿名性，但從用戶的角度來看，它應該對所有dApp、私鑰存儲和網絡的活動進行完整的概述。它可能會要求一個私鑰助記詞的主公鑰，以便得出所有可能的公鑰。這將允許賬戶協調功能檢查所有可能的網絡上的所有可能的賬戶，看看你是否曾經在那裡進行過交互。它將檢測私鑰是否是多簽名、基於合同的錢包、組模塊或子私鑰的一部分。隨著您的確認，它將開始為您跟踪所有這些賬戶，記住您的偏好，以便在何時使用哪個私鑰。
賬戶協調功能應該允許你審計你在每個應用程序上的互動，同時保留一個連貫的歷史-想想谷歌的oAuth 告訴你當前登錄了哪些服務和設備。最終，這應該看起來像一個以用戶為中心的多網絡區塊瀏覽器，跟踪你自己的所有私鑰並代表你協調它們。這將需要大量關於你使用過的或未來可能與之交互的眾多網絡的資料。這種資料可以從不同的來源收集，並將取決於你所面對的到底是哪種應用。我想像大多數信息應該是來自應用程序本身，通過像WalletConnect 這樣的界面。
賬戶協調功能將牢牢地站在你的私鑰和應用程序之間，它將作為雙方之間的中介，並將加入你在基於區塊鏈的網絡上的所有互動。它的建立將只為你服務，所以雖然它將擁有你的信息寶庫，但只能由你自行決定是否訪問。
