什么是模塊化账戶抽象？

2023-06-02 09:46 MarsBit

作者：Konrad Kopp，編譯：Lynn，MarsBit

在爲以太坊增加智能合約錢包（智能账戶）的原生支持的多個提案被拒絕或停滯後，ERC-4337 已被接受爲（臨時）標准，以實現账戶抽象（AA）而無需對 EVM 進行協議級別的修改。在過去的幾個月裏，AA 的一個子集的活動激增，它圍繞着這些智能账戶的模塊化，使它們對用戶和开發者來說更容易擴展。這種一般的方法被稱爲模塊化账戶抽象，下面的文章旨在概述這一生態系統在過去 3 個月中的發展以及事情的走向。

生態系統的組成部分

下面的部分將概述和討論模塊化 AA 生態系統的不同組件。這些組件是账戶、模塊、注冊表、UI 和开發者工具。這些組件可能不是使這個生態系統長期運作所需的唯一部分，但至少目前充分包含了各團隊集中研究和开發努力的不同領域。

模塊化账戶

模塊化账戶是指用戶可以輕松、安全地擴展的智能账戶，而不是只能由开發人員修改並需要重新部署的“靜態”账戶。這使得用戶可以在他們的智能账戶中即時切換出、添加或刪除功能。

實施方法

目前有兩種不同的模塊化智能账戶的方法，一種是由安全（Safe）架構創建或啓發的，另一種是由多面代理（又稱鑽石）標准（ERC-2535）啓發的。這兩種方法有不同的發展，可以沿着多個軸线進行對比。
Safe 账戶是從 Gnosis 建立的最初的 multisig 演變而來的，並且早於 ERC-4337. 該團隊非常強調安全性和可擴展性，而 ERC-4337 的支持在目前只能通過一個模塊來實現。然而，也有關於在未來的版本中實現本地支持的討論。

另一種方法是受 ERC-2535 的啓發，在過去的幾個月裏，不同的團隊已經進行了廣泛的討論和追求。這個標准的目的是使智能合約具有可擴展性，通過標准化的方式來存儲對模塊（稱爲面）的引用，並使用 delegatecall 操作碼來執行這些。雖然圍繞這個機會的討論已經持續了一段時間，但（據我們所知）第一個工作實現是由我們在ETHDenver建立的。從那時起，其他幾個團隊已經發布了不同階段的實施方案，例如 ZeroDev Kernel，這是一個最小和可擴展的智能账戶，從 ERC-2535 中獲得了一些靈感。此外，Alchemy 團隊已經寫出了一個階段性的 EIP 草案（ERC-6900），旨在從 ERC-2535 中獲取靈感，實現模塊化智能账戶的標准化。Soul Wallet 過去也曾試驗過 ERC-2535 账戶，盡管他們後來擱置了這些嘗試（我們無法鏈接到這些嘗試的任何代碼）。

如上所述，這兩種不同的方法可以沿着不同的軸线進行對比。其中之一是使用 delegatecall 來執行模塊，而不是使用外部調用。使用 delegatecall 允許從調用合約的上下文中執行外部代碼，這就意味着外部代碼可以修改調用合約的存儲，並進行來自調用账戶而不是模塊的外部調用。這不允許關注點的分離，這意味着一個模塊可以覆蓋账戶上的任何存儲槽，這引起了一個主要的攻擊媒介。雖然安全账戶目前確實允許使用 delegatecall 來調用模塊，但這在未來可能會改變，要么完全被刪除，要么爲模塊創建不同的權限級別。使用 delegatecall 來執行模塊的一個好處是，模塊可以是單子，大大降低了添加模塊的 gas 成本。

這些方法的另一個區別是模塊的存儲方式和交易的路由。ERC-2535 使用從函數選擇器到模塊地址的映射，這意味着沒有兩個活動模塊可以共享相同的函數名稱（選擇器是名稱和參數的散列）。使用這個路由器的事務流程是在這個映射中查找一個函數籤名，然後用這個籤名和參數用 delegatecall 調用相應的合同地址。另一方面，安全账戶只存儲對模塊地址的引用，從而使多個模塊使用同一個函數選擇器成爲可能。此外，交易流程可以由安全账戶或模塊觸發，然後模塊可以調用安全账戶，從那裏執行交易。

第三個主要區別是這些實現處理存儲的方式。由於 ERC-2535 調用模塊的方式，存儲不能像在普通智能合約中那樣處理。相反，开發人員通常選擇使用結構化或“鑽石”存儲，將數據存儲到存儲槽，這些存儲槽是唯一的、特定模塊的標識符的哈希值。這意味着不同的模塊不會覆蓋對方的存儲數據，並導致合同以意想不到的方式行事。雖然安全模塊可以使用 delegatecall 來調用，但它們並不要求以這種方式來調用，因此可以處理自己的存儲。這意味着存儲不需要以上述方式進行結構化，而是可以以 Solidity 存儲定位通常實現的常規（順序）方式或其他任何想要的方式來處理存儲。

這些是這些方法之間最大的一些差異。

模塊

模塊，有時稱爲插件或面，是旨在擴展智能账戶功能的智能合約。例如，一個模塊可能允許所有者使用不同的籤名方案來控制他們的錢包，或者在每次代幣被轉移到另一個账戶時觸發某個動作。與到目前爲止存在的、上面已經討論過的模塊化账戶的不同實現方式有關，有不同的構建和執行模塊的方式。因此，今天存在的模塊要么是爲安全架構建立的，如這些或這些，要么是爲鑽石啓發的架構建立的，如 ZeroDev 的內核或我們在 ETHDenver 建立的一些演示模塊。

正如上文詳細解釋的那樣，一個模塊的結構取決於它所要使用的账戶實現。一個主要的區別是，爲安全基礎設施構建的模塊需要（除非通過委托調用）回調到安全账戶，以便從账戶的上下文中初始化一個函數調用。相比之下，爲鑽石啓發账戶建立的模塊不需要這樣做，因爲它的代碼是從智能账戶本身中執行的。在此基礎上，還存在一個標准，建立在安全架構之上的模塊可以使用，稱爲 Zodiac 標准。該標准旨在將模塊化账戶的不同組成部分分开，稱爲頭像、護衛和模塊，因此旨在爲構建智能账戶模塊創建一個通用框架。一些使用該標准的模塊的例子可以在這裏找到。

Permissive 是一個正在爲智能账戶構建公共模塊的團隊的一個例子。到目前爲止，他們的重點是爲智能账戶建立一個授權框架，主要集中在允許更細化的訪問控制，即用戶可以給不同的實體以具體的權限來執行账戶的特定動作。他們已經發布了一個 Safe 账戶的模塊，並正在努力將其移植到不同的模塊實現上。

注冊表

到目前爲止，許多智能合約和智能账戶的模塊實現都是在用戶和模塊开發者之間建立了強大的信任假設。這就是 ERC-2535 今天幾乎完全被使用的方式，允許开發者團隊管理大型和復雜的代碼庫。然而，智能账戶生態系統的更大愿景是消除這種信任假設，允許第三方开發者建立非技術用戶可以安全地添加到他們的錢包的模塊。雖然信任假設不能完全取消（畢竟有人需要證明一個模塊的安全性），但我們可以將單個用戶和模塊开發者之間的所有信任假設捆綁到一個單一的實體，即模塊注冊表。這意味着，用戶現在只需要信任這個單一的實體，而不是需要信任他們想要使用的模塊的每一個开發者。

雖然這種思路導致了中心化登記處的結論，但這遠遠不是我們所追求的愿景。相反，我們目前正在設計一個類似於超結構的注冊中心的原型，這意味着它是开放的、不可阻擋的，而且最重要的是，沒有許可。這意味着具有不同安全假設的各方可以坐在這個注冊表之上，由用戶來選擇在什么情況下信任哪一方。目前，我們正在對不同的實現方式進行原型設計，並得到了不同團隊的有益投入和合作，例如 Safe 和 EF 的 4337 團隊成員。一旦我們有了關於不同實現方式和激勵設計的更多具體細節，我們將开始更公开地分享這些細節，並开放基礎代碼。

用戶接口

正如 Yoav 之前所指出的，模塊化 AA 的一個較少被探索的方面是類似的模塊化前端設計。這是必要的，因爲 UI 組件需要通過了解函數選擇器、參數編碼和（潛在的）執行何種前端或後端邏輯來專門構建以觸發某些鏈上功能。到目前爲止，我們還不知道有哪個團隊在這個問題上取得了重大進展，盡管我們正慢慢开始探索建立在上面討論的注冊表之上的參考實現。從我們的初步研究來看，一個允許外部模塊开發者的模塊化前端的安全設計是不難的。

开發者工具

雖然存在开發者工具，供 dapp 或錢包开發者將模塊化的 AA 集成到他們的應用程序中，但很少有指南或工具來幫助开發者構建模塊。Safe 有一個指南在這裏，ZeroDev 有一個在這裏，但除了這些，我們不知道有什么更實質性的東西可以讓开發者輕松了解如何建立一個模塊。隨着這個領域的成熟，我們相信會有更多的指南和實際的工具出現，大大降低模塊开發者的門檻。

結論

模塊化 AA 是更廣泛的 AA 運動的一個子集，其目的是將智能账戶模塊化，以使其可以爲用戶定制，並允許开發人員輕松建立獨立的智能账戶功能，而不是需要建立一個完整的账戶。上述文章的目的是對這一領域的現狀做一個廣泛的概述，以及強調正在取得進展的地方。