作者：Konrad Kopp 來源：medium

模組化智慧帳戶引入了智慧帳戶的新範例，可實現可擴展性和麵向未來的需求。然而，模組化帳戶比整體或整合帳戶更複雜，並且其安全性需要更多的關注，特別是在安裝第三方模組時。去年，有關模組化帳戶安全性的討論一直在進行，例如圍繞刪除delegatecall 的辯論。這場爭論是圍繞著ERC-2535 鑽石代理與智慧帳戶的使用以及相關的安全問題而產生的。除此之外，圍繞安全的公開辯論相對較少。

這篇部落格文章的目的是概述保護模組化帳戶的不同方法，並概述每種方法的潛在優點和缺點。

設定場景

模組化帳戶已經存在了一段時間，2023 年之前的主要例子是Safe。隨著時間的推移，不同的模組被建構和使用，例如Gnosis Guild 建構的Zodiac 模組集。這些模組大部分是由DAO 和機構建構的，例如Yearn。因此，主要方法是單一實體為其自己的用例建立和使用模組。

這樣做的好處是，除了由模組建構者選擇和簽約的模組審計員之外，不存在對外部各方的信任依賴。然而，在ETHDenver 2023 上，我們提出了可自訂錢包的想法，該錢包允許用戶在智慧帳戶模組的支援下輕鬆添加和刪除其帳戶中的功能。雖然這個產品願景已經發展到包括嵌入式錢包的興起以及使用模組構建更強大、更無縫產品的潛力，但仍然存在一個核心問題：為了加速模組化智慧帳戶創新，我們需要一種更具可擴展性和可組合性的建構和組合方式。使用模組。

一種想法是將模組建構者的角色與模組使用者的角色分開。這可能會將我們引向“模組商店”，類似於iOS、Android、Vscode 或Raycast 上的現有應用程式或擴充商店。這意味著開發人員或團隊可以建立一個或一組模組，其他開發人員可以使用這些模組來為其產品提供支持，或者用戶直接安裝在他們的帳戶上以啟用新穎的錢包功能。然而，這在模組的使用者和建構者之間引入了信任依賴。

因此，解決模組安全是加速智慧帳戶創新的主要解鎖點之一。關鍵問題是我們如何減少信任依賴，並允許使用者或開發人員在安裝或使用模組之前獲得模組安全性的保證。

到目前為止，有兩種新興的模組化帳戶安全方法：證明註冊表和模組授權系統。尚待進一步深入探索的替代方法包括基於鏈下監控的斷路器或交易共同簽名。後者的一個例子是Argent Shield，它提供了一種向您的帳戶添加可信任共同簽署者的方法。

在深入研究這些方法之前，我們將首先檢查哪些已知的安全問題，以便評估每種方法的優點。

安全問題

圍繞模組化帳戶安全性的討論特別圍繞著確保模組的完整性和允許的操作。雖然這種情況可能在安裝之前和使用期間發生，但需要注意的是，本部落格並不以帳戶本身的建構方式為中心，而是以模組（尤其是第三方）的使用方式為中心。可能出現的一些潛在安全問題是（大致按嚴重程度排列）：

• 允許代表帳戶執行的模組可以執行任意執行，例如將所有資金轉出帳戶

• 執行驗證的模組可以允許帳戶執行任何執行

• 使用delegatecall 呼叫的模組可能會自毀帳戶

• 對帳戶具有儲存存取權限的模組（使用delegatecall 呼叫時）可以接管帳戶或將其磚化

• 執行驗證的模組可以對帳戶發動拒絕服務攻擊

• 掛鉤其他程序的模組可以對帳戶發動拒絕服務攻擊

• 卸載期間，模組可能會恢復或導致OOG 恢復，從而可能導致模組“無法安裝”

• 在卸載期間，模組無法充分清理其配置，從而導致意外行為，甚至可能在重新安裝時失去對帳戶的存取權限

以上是模組可能出現的一些漏洞範例，但也可能出現許多其他漏洞。此類漏洞的一個例子發生在Yearn Treasury Safe 上。總而言之，Yearn 建立了一個自訂Hook（稱為Guard），但忘記正確初始化它。由於不幸的事件組合，攻擊者能夠從Hook 中刪除交易白名單，從而有效地拒絕對保險箱提供服務。幸運的是，Yearn 找到了一個聰明的方法來移除Hook，但這件事卻險些導致金庫永久堵塞。

安全方法概述

迄今為止已探索的兩種主要方法是證明註冊中心和模組授權系統。下面，我們將更深入地擴展這些內容並權衡它們的相對優點，特別是與不同類別的漏洞相關的優點。

認證登記處

模組化帳戶安全性的一個主要方法是使用鏈上的證明註冊表來允許帳戶獲得即將安裝或使用的模組的安全保證。這允許使用者或應用程式開發人員確定他們可信賴的證明者，例如某些審計員，並在鏈上驗證這種信任。從概念上講，這有點類似於驗證您將要互動和使用的合約的審計報告，但有兩個關鍵區別：1）非技術用戶可以使用此解決方案，2）驗證是在鏈上運行的，從而使其愚弄人們要困難得多，例如冒充審計員。

實際上，證明註冊表是受信任實體（例如審計員）做出的斷言的鏈上儲存。為了進行這樣的證明，審計人員將編譯一些數據，例如審計報告，並將其發佈到鏈上，將其連結到已證明的模組。然後，當使用者或開發人員想要安裝或使用模組時，該帳戶將查詢鏈上註冊表並確定受信任的實體是否已證明該模組是安全的。在實踐中，我們可以根據我們的用例、智慧帳戶模組自訂數據，並包含更多相關數據，例如標準化模組清單和風險評分。

在Rhinestone，我們一直在開發模組註冊表，這是一個無需許可的註冊表，我們獲得了以太坊基金會的資助，而Biconomy 等模組化帳戶建立器正在整合該註冊表。 Safe {Protocol}還包括在使用第三方模組時為用戶提供安全性的註冊表，並且Safe 團隊也一直在與不同的審計公司（例如OpenZeppelin、 OpenZeppelin、 Acee 區塊鏈安全和Hats 金融。

粗略地說，模組註冊表有兩個功能：首先，模組不會故意利用帳戶；其次，確保模組按其應有的方式運行，並且即使以不符合規定的方式使用，也不能用於利用帳戶。不是模組開發人員有意為之的。因此，模組註冊表可以解決所討論的所有潛在漏洞。儘管如此，這個解決方案也面臨一些挑戰。其中包括：建立和維護可以由任何帳戶安全使用的註冊表、調整激勵措施，以便充分激勵證明者以確保模組安全、選擇帳戶信任的適當默認證明者列表以及對用戶進行充分教育關於添加或刪除受信任實體的安全影響。

此外，使用者還可以在使用模組時透過查詢註冊表來獲得持續的安全保證。例如，如果在模組上發現錯誤或漏洞，證明者可以撤銷其在鏈上的證明，從而阻止模組的使用並阻止潛在的漏洞。使用註冊表來實現持續安全的一個挑戰是，證明者可以透過撤銷關鍵模組來拒絕向帳戶提供服務。雖然這是一個需要面對的重要挑戰，但一些解決方案包括針對證明者的信譽系統，或者對安全關鍵模組使用廣泛的獨立證明者，這樣只有在大多數證明者串通的情況下才能發起攻擊。

模組權限系統

模組權限系統最初由ERC-4337 的合著者Yoav 提出，並從作業系統權限中獲得了一些靈感。總的來說，這個想法是模組被授予在運行時強制執行的權限。例如，對帳戶具有執行權的模組可能只能在一段時間內從帳戶中轉出一定數量的價值。

ERC-6900標準化了帳戶的權限系統，並定義了具體的權限。例如，模組可以透過帳戶觸發執行來使用的函數選擇器和目標。模組在權限清單中聲明所需的權限，權限清單是模組字節碼的一部分。

最近，我們創建了一個權限掛鉤的原型，它可以安裝在ERC-7579帳戶上，以便在執行者在帳戶上建立執行時強制執行類似的附加權限。有關這兩個模組化帳戶標準的安全性的更詳細比較，請閱讀下文。

整體而言，權限系統是增強帳戶安全性的有用方法，但它的目的只是解決一組非常特定的漏洞，即模組可以在帳戶上觸發的執行。擴展這個想法以驗證更多種類的權限的問題在於，其中許多權限在鏈上運行時驗證是不可行的。例如，如果掛鉤執行恢復的模組，帳戶無法在運行時確定它是否因有效原因而恢復（不應執行執行），或者是否恢復以拒絕向帳戶提供服務（在這種情況下，應忽略該情況） ）。這只能在離線稽核程式碼時進行驗證。

其他方法

其他模組化帳戶安全方法的探索相對較少。一些可能受到更多關注的安全帳戶或模組措施的範例包括模組斷路器或受信任的鏈下監控方的交易共同簽署。對於剛接觸該領域的人來說，這是一個很好的參與領域，如果您研究過任何這些或其他方法，我們很樂意與您聊天！

不同的模組化帳戶標準和安全性

目前，模組化帳戶有兩個標準：ERC-7579和ERC-6900。 ERC-7579 採用最小的方法來標準化模組化帳戶，允許帳戶具有互通性，而不會抑制帳戶建構者的創新，包括引入新的安全方法。 ERC-6900 對帳戶架構更具規範性和固執己見，特別規定了帳戶的大部分工作。

ERC-6900也代表帳戶建構者做出一些安全選擇，例如引入權限系統。該系統整合到帳戶中，需要模組來實現權限清單。安裝時，模組的權限儲存在帳戶中並在執行時進行驗證。

相較之下，ERC-7579僅尋求解決模組互通性，並未強制帳戶實施特定的安全解決方案。這並不是因為安全性不重要，而是因為安全性是多方面的，任何單一解決方案都有非常具體的權衡。例如，如上所述，權限系統對於在某些流（特別是在帳戶上排隊執行的模組）添加安全保證很有用，但在其他情況下（例如當模組嘗試拒絕向帳戶提供服務時）則沒有用。

這兩個標準經常在安全方面進行討論和比較。然而，這是一個有缺陷的比較點。安全性對於這兩個標準的實施至關重要，而不僅僅是標準本身。然而，ERC-7579 不會代表帳戶建構者做出固執己見的安全選擇，因為上述安全系統尚未在生產中使用。因此，在致力於建立特定的安全系統之前，我們認為我們應該先促進創新和實驗，以便我們以後可以在需要時標準化具體的實施。在ERC-7579 的背景下，這將透過擴展來完成。 ERC-7484就是一個例子，這是ERC-7579 的註冊表擴展，帳戶可以選擇遵守該擴展以利用證明註冊表。此外，目前正在開發許多許可掛鉤，可以將其安裝在任何ERC-7579 帳戶上以獲得額外的安全性。考慮到安全方面的創新和未來標準化，ERC-7579 可以只專注於一件事：解決供應商鎖定和生態系統碎片化問題的基本互通性，而不會扼殺模組化帳戶創新。

由於這種可選性，ERC-7579 帳戶可以輕鬆實現權限系統，無論是直接在帳戶中還是作為掛鉤模組。 ZeroDev Kernel v3 是一個（至少部分）追求前者的帳戶範例。後者通常更適合未來，因為它允許對權限系統進行更改和新增（例如新的權限類型），而不需要更改帳戶（並且可能需要更改標準）。在這方面，Safe v1.5引入了模組回調掛鉤，使權限系統能夠監管哪些執行模組可以在帳戶上觸發。最後，將安全解決方案建構成模組還允許外部開發人員（而不僅僅是帳戶建構者）貢獻和建構安全解決方案，從而帶來更多的選擇。

值得注意的一點是，ERC-7579 引入了模組類型：驗證器、執行器、鉤子、回退處理程序，未來的擴充可能會引入新類型。這本身就是一個非常原始的許可系統。原因是不同的模組類型被授予不同的存取權限，這些權限由帳戶強制執行。例如，只有執行者可以呼叫帳戶來觸發執行。這意味著在ERC-7579 的上下文中，驗證器聲明其執行權限是毫無意義的，因為它無法建立執行。因此，在ERC-7579 上，僅在鉤子中建立複雜的模組安全系統也變得更加可行，因為這些系統總是在執行器呼叫帳戶時被呼叫。雖然這有額外執行成本的缺點，

結論

模組化帳戶的安全性是一個多方面的挑戰，我們才剛開始觸及可能解決方案的表面。迄今為止探索的兩個主要解決方案是證明註冊中心和模組授權系統。前者允許在鏈上驗證鏈下安全審查，例如手動審計、模糊測試、靜態分析、形式驗證等。後者允許帳戶定義模組具有哪些執行權限，並在模組觸發執行時驗證這些權限。然而，這兩種方法都需要在安全覆蓋範圍、效能、面向未來、去中心化等之間進行微妙的權衡。