深入解讀模組化智慧合約帳戶架構和挑戰

作者：芮，SevenX Ventures投資人

編譯：Luccy，Joyce，BlockBeats

*編者按：智慧合約帳戶（SCA）的發展勢頭強勁，得到了包括Vitalik在內的許多核心創業者的支援，然而 SCA 的採用仍面臨諸多挑戰。 帳戶抽象（AA）的優勢在於使用代碼自定義功能，但其非互操作性帶來了集成和供應商鎖定問題。 模組化帳戶抽象旨在創建一個模組化結構，以開發具有多樣功能、安全且無縫集成的錢包。 *

SevenX Ventures 投資人 Rui 指出了採用 SCA 面臨的五大挑戰，即熊市影響、遷移難度、簽名問題、高昂的 Gas 成本和工程難題，並對工程難題做了更進一步的討論。 此外，在對模組化智慧合約帳戶的架構進行分析后指出，模組化 SCA 只是採用難題的一小部分。

為了充分發揮 SCA 的潛力，需要 Layer 2 解決方案提供額外的協定層支援，強大的 bundler 基礎設施和點對點記憶體池、更具成本效益和可行的 SCA 簽名機制、跨鏈 SCA 同步和管理機制，以及開發使用者友好的介面等。

在未來，目前的挑戰逐步解決，會有更多人採用 SCA，那麼接下來又會發生什麼？Rui 對此也提出了一些有趣的問題。 BlockBeats 將原文編譯如下：

從外部擁有帳戶（EOA）向智慧合約帳戶（SCA）的轉變勢頭強勁，並已經得到了包括 Vitalik 等許多核心創業者的支援。 儘管如此，SCA 的採用卻並不像 EOA 那樣廣泛。 這其中的主要問題包括熊市帶來的影響、eoa 到 sca 的遷移難度、簽名問題、Gas 成本過高以及最為關鍵的開發難題。

帳戶抽象（AA）的最顯著優勢是能夠使用代碼自定義功能。 然而，AA 功能的非互操作性帶來了主要挑戰，這種分散性會阻礙AA集成，並且加強了供應商鎖定。 除此之外，在可升級與可組合同時保障安全性也是重要挑戰。

模組化帳戶抽象的出現是AA發展趨勢中的一個細分領域，這種創新的方法可以將智慧帳戶與其自定義功能分離。 其目標是創建一個模組化結構，來開發具有多樣功能、安全、無縫集成的錢包。 未來，模組化帳戶抽象可以實現一個自由的智慧合約帳戶「應用商店」，使錢包和 dApp 專注於改進用戶體驗，而不必在構建功能上花費太多精力。

簡述帳戶抽象（AA）

! [深入解讀模組化智能合約帳戶架構和挑戰] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-e77dfd1eb3-dd1a6f-cd5cc0.webp)

在人們接觸區塊鏈的過程中，傳統的 EOA 帶來了許多挑戰，如助記詞、Gas 費用、跨鏈操作和多發交易等。

帳戶抽象利用智慧合約帳戶，允許可程式設計驗證（validation）和執行（ution）。 這意味著使用者將能夠一次性批准一系列交易，而不再需要對每個交易都簽名和廣播。 帳戶抽象還可以實現更多功能，如改進用戶體驗（如 Gas 抽象和會話密鑰）、降低成本（如批量交易）和提高安全性（如社交恢復、多重簽名）。 目前，有兩種實現帳戶抽象的方式：

· 協定層：一些協定本身提供了本地帳戶抽象支援，ZKSync 交易使用單個記憶體池和交易流程來支援 AA;無論是來自 EOA 還是 SCA 都遵循相同的流程，而 Starknet 已經移除了 EOA，所有帳戶都是 SCA，並且他們有像 Argent 這樣的本地智慧合約錢包。

· 合約層：對於乙太坊及類似的 L2，ERC4337 引入了一個單獨的 mempool，以在不改變共識層的情況下支援 AA。 像 Stackup、Alchemy、Etherspot、Biconomy、Candide 和 Plimico 正在構建 bundler 基礎設施，而像 Safe、Zerodev、Etherspot 和 Biconomy 正在構建 bundler 和 SDK。

採用 SCA 面臨的困境

自 2015 年以來，帳戶抽象（AA）的話題一直被討論，並在今年由 ERC 4337 進一步將其推進人們的視線中。 然而，已部署的智慧合約賬戶數量仍然遠遠不及 EOA。

! [深入解讀模組化智能合約帳戶架構和挑戰] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-cd53d3972e-dd1a6f-cd5cc0.webp)

讓我們深入研究這個困境：

1、熊市的影響

儘管 AA 擁有了諸如無縫登錄和 Gas 抽象等優勢，在當下的熊市，所有使用者都是已被教育的 EOA 使用者，而沒有太多新使用者，因此 dApp 和錢包並沒有動力去採用 SCA。 即便如此，一些領先的 dApp 在逐步採用 AA，例如 Cyberconnect 通過引入他們的 AA 系統和無 Gas 解決方案，僅一個月就帶動了約 36 萬次 UserOps（AA 交易）。

2、遷移障礙

對於已經積累了使用者和資產的錢包和應用程序來說，安全、便捷地遷移資產仍然是一個挑戰。 不過，像 EIP-7377 這樣的方案可允許 EOA 發起一次性遷移交易。

3、簽名問題

智慧合約本身無法簽署消息，因為它沒有像 EOA 那樣的私鑰。 類似 ERC1271 的嘗試使之成為可能，但消息簽名在第一筆交易之前不起作用的，這又對於使用反事實部署的錢包提出了挑戰。 由 Ambire 提出的 ERC-6492 是 ERC-1271 向後相容的繼任者，也許能夠解決之前的問題。

4、Gas 成本

與標準 EOA 相比，部署、類比和執行 SCA 會產生更高的成本，這也成為了採用障礙之一。 不過，目前已經進行了一些測試，例如將帳戶創建與使用者操作分離、消除與某個帳戶相關的 「salt」 等。

5、工程難題

ERC-4337 團隊已經建立了 eth-infinitism repo，為開發人員提供了基礎實現。 然而，隨著開發者針對不同的用例擴展到更細緻和具體的功能時，集成和解碼會面臨更多挑戰。 在本文中，我們將深入探討工程難題。

! [深入解讀模組化智能合約帳戶架構和挑戰] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-b50e21334e-dd1a6f-cd5cc0.webp)

通過模組化智慧合約帳戶來解決工程難題

工程難題可進一步闡述為碎片化、安全性和可升級性三個方面。

· 碎片化：現在可以通過多種方式啟用功能，無論是通過特定的 SCA 還是通過獨立的外掛程式系統。 每個平臺和服務商都遵循自己的標準，促使開發者決定支援哪些平臺和服務商。 這可能導致潛在的平臺（供應商）鎖定或冗餘工作。

· 安全性：雖然帳戶和功能解耦帶來了靈活性的優勢，但也可能使安全問題更嚴重。 因為所有功能可能會被一同審核，而缺乏獨立評估可能會增加帳戶漏洞的風險。

· 可升級性：隨著賬戶的發展，保持添加、替換或刪除功能的能力非常重要，重新部署現有功能的每次更新都會引入複雜性。

為了應對這些問題，我們需要可升級的合約以確保安全高效的升級、可複用的核心以提高整體開發效率、以及標準化的介面來確保合約帳戶能夠在不同的前端之間平穩過渡。

這些術語彙聚於一個共同的概念：構建模組化帳戶抽象架構（模組化AA）。

模組化帳戶抽象是廣泛的AA發展中的一個細分領域，它設想將智慧帳戶模組化，以定製化地為使用者提供服務，並使開發者能夠在最小限制下無縫增強功能。

然而，在任何行業中建立和推廣新的標準都是一個巨大的挑戰。 在大家都接受同一標準之前，初始階段可能會出現許多不同的解決方案。 令人鼓舞的是看到那些致力於完善和推廣帳戶抽象的人們，無論是 4337 SDK、錢包、基礎設施團隊還是協定層設計師，他們都在共同努力加快這一進程。

模組化結構：主帳戶和模組

帳戶如何調用模組實現功能

委託調用（Delegate call）和代理合約（proxy contract）

外部呼叫和委託呼叫：

! [深入解讀模組化智能合約帳戶架構和挑戰] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-26b1e8ab3b-dd1a6f-cd5cc0.webp)

關於委託調用

雖然「委託調用」與「調用」類似，但它不是在目標合約的context中執行，而是在調用合約的當前狀態的context執行它。 這意味著目標合約所做的任何狀態更改都會更改調用合約的存儲。

! [深入解讀模組化智能合約帳戶架構和挑戰] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-421fd8f0e1-dd1a6f-cd5cc0.webp)

代理合約和委託調用

**要實現可組合、可升級的結構，需要引入一個基礎概念「代理合約」。 **

代理合約：普通合約存儲其邏輯和狀態，部署后無法更新。 而代理合約使用委託調用（delegate call）部署到另一個合約。 通過引用實現函數，在代理合約的當前狀態下執行它。

使用案例：雖然代理合約保持不變，但您可以在代理後面部署新的實現。 代理合約實現了可升級性，且在公共區塊鏈上的部署和維護成本更低。

Safe 架構！ [深入解讀模組化智能合約帳戶架構和挑戰] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-4dc82c32d1-dd1a6f-cd5cc0.webp)

Safe 架構

什麼是 Safe ：Safe 是領先的模組化智慧帳戶基礎設施，旨在提供經過實戰考驗的安全性和靈活性，它使開發人員能夠創建多樣化的應用程式和錢包。 許多團隊正在Safe基礎上（或受Safe啟發）構建應用。 例如，Biconomy 在推出其智慧合約帳戶時，使用原生 4337 和 1/1 多重簽名來拓展 Safe。 Safe 見證了超過 164,000 份合約的部署並鎖定了超過 307 億美元的價值，毫無疑問是該領域的佼佼者。

Safe 的結構包括安全帳戶合約、單例合約、模組合約。

安全賬戶合約（proxy contract）：主代理合約（Stateful）

安全帳戶是一個代理合約，這是因為委託調用是一個單例合約。 安全帳戶包含擁有者、閾值和實現位址都設置為代理的變數，基於這些定義其狀態。

單例合約（singleton contract）：Integration Hub（無狀態）

單例合約服務於 Safe 帳戶，並定義了不同的模組合約集成，包括 Plugin、Hook、Function Handler 和 Signature Validator。

模組合約（modules）：自定義邏輯和功能

模組合約功能強大。 外掛程式作為模組化類型可以定義不同的功能，例如支付流、恢復機制和會話密鑰，並且可以通過獲取鏈外數據作為 Web2 和 Web3 之間的橋樑。 其他模組如作為安全防護的 Hook 和 Function Handler 可回應任何指令。

採用 Safe 後帶來的改變：

可升級合約：每當引入新外掛程式時都需要部署新的單例。 使用者保留將 Safe 升級到所需單例版本的自主權。

可組合、可重用的模組：外掛程式的模組化特性使開發人員能夠獨立地開發功能。 他們可以根據自己的用例自由選擇和組合這些外掛程式，從而形成高度可定製的方法。

ERC-2535 Diamond 代理

! [深入解讀模組化智能合約帳戶架構和挑戰] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-dfa51cc0ce-dd1a6f-cd5cc0.webp)

關於 ERC2535、 Diamond 代理：

ERC2535 標準化的 Diamond 模型，這是一種模組化智慧合約系統，可以在部署後升級/擴展，且幾乎沒有大小限制。 目前，很多團隊如 Zerodev 的 Kernel、Soul Wallet 的實驗都受到了 Diamond 結構的啟發。

什麼是 Diamond 結構：

Diamond 合約：主要代理合約（有狀態）Diamond 是一種代理合約，它使用 委託調用方法從其實現中調用函數。

模組/外掛程式/ Facet 合約：自定義邏輯和功能（無狀態）模組或所謂的 Facet 是一種無狀態合約，可以將其功能部署到一個或多個 Diamond。 它們是單獨的、獨立的合約，可以共用內部函數、庫和狀態變數。

採用 Diamond 後帶來的改變：

可升級合約：Diamond 提供了一種系統的方法來隔離不同的外掛程式並將它們連接在一起，在它們之間共享數據，還可以使用 diamondCut 功能直接添加/替換/刪除任何外掛程式。 隨著時間的推移，可以添加到 Diamond 的外掛程式數量將沒有限制。

模組化且可複用的外掛程式：已部署的外掛程式可以被任意數量的 Diamond 使用，從而極大地降低部署成本。

Safe 智能帳戶與 Diamond 方式的區別：

Safe 和 Diamond 架構之間存在很多相似之處，兩者都依賴於其核心的代理合約並引用邏輯合約來實現可升級性和模組化。

兩者的主要區別在於邏輯契約的處理。 具體來說：

· 靈活性：在啟用新外掛程式的情況下，Safe 需要重新部署其單例合約（Singleton）以實現其代理中的更改。 相比之下，Diamond 直接通過其代理合約中的 diamondCut 函數來實現這一點。 這種方法上的差異意味著 Safe 保留了更高程度的控制，而 Diamond 則引入了增強的靈活性和模組化。

· 安全：目前在兩種結構中使用的，可以允許外部代碼操縱主合約的存儲。 在 Safe 架構中，委託調用指向單個邏輯合約，而 Diamond 則在多個模組合約-外掛程式中使用委託調用。 因此，惡意外掛程式有可能覆蓋另一個外掛程式，從而引入存儲衝突的風險，損害代理的完整性。

· 成本：Diamond 方法中，靈活性與安全隱患同時存在。 這增加了成本，每次添加新外掛程式都需要進行全面審核。 關鍵是要確保這些外掛程式不會干擾彼此的功能，這一目的具有挑戰性，特別是對於努力維持高安全標準的中小型企業而言。

「Safe 智慧帳戶方法」和「Diamond 方法」是涉及代理和模組的不同結構的範例。 如何平衡靈活性和安全性至關重要，這兩種方法未來也將會不斷演變、相互補充。

模組順序：驗證器（Validator）、執行器 （utor） 和挂鉤 （Hook）

讓我們通過介紹 ERC6900 來進一步討論，這是 Alchemy 團隊提出的、受 Diamond 啟發、專門為 ERC-4337 量身定製的標準。 它通過提供通用介面來解決智慧帳戶模組化的挑戰，並協調外掛程式和錢包開發人員之間的工作。

說到 AA 的交易流程，主要有三個流程：驗證、執行、挂鉤。 正如我們前面所討論的，這些步驟都可以通過使用代理帳戶調用模組來管理。 雖然不同的專案可能使用不同的名稱，但掌握相似的底層邏輯很重要。

! [深入解讀模組化智能合約帳戶架構和挑戰] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-b01f250655-dd1a6f-cd5cc0.webp)

不同設計中的函數名稱

驗證 （Validator）：確保帳戶調用者的真實性和許可權。

執行 （utor）：執行帳戶允許的任何自定義邏輯。

挂鉤 （Hook）：充當在另一個函數之前或之後運行的模組。 它可以修改狀態或撤銷整個調用。

! [深入解讀模組化智能合約帳戶架構和挑戰] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-42db1d92a0-dd1a6f-cd5cc0.webp)

根據不同的邏輯來分離模組至關重要。 標準化方法應該規定如何編寫智慧合約帳戶的驗證、執行和挂鉤函數。 無論是 Safe 還是 ERC6900，標準化都有助於減少特定於某些實施或生態系統的獨特開發工作的需求，並防止供應商鎖定。

模組發現和安全

如何以開放的方式查找和驗證模組：一個正在推進的解決方案涉及創建一個允許用戶發現可驗證模組的區域，可以將其稱為「註冊表」。 該註冊表的功能類似於「應用程式商店」，旨在培育一個簡化但蓬勃發展的模組化市場。

Safe{Core} 協定

! [深入解讀模組化智能合約帳戶架構和挑戰] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-4ff8171cf4-dd1a6f-cd5cc0.webp)

Safe{Core} 協定是一種針對智慧合約帳戶的開源、可互操作的協定，旨在增強各種供應商和開發人員的可訪問性，同時通過明確定義的標準和規則來保持強大的安全性。

· 帳戶：在Safe{Core} 協定中，帳戶的概念是靈活的，不受特定實現的約束。 這使得不同的帳戶服務提供者能夠參與其中。

· 管理員：管理器充當帳戶、註冊表和模組之間的協調員。 它還作為許可層負責安全性。

· 註冊中心：註冊中心定義安全屬性並執行 ERC6900 等模塊標準，旨在創建一個開放的「應用程式商店」環境，以實現可發現性和安全性。

· 模組：模組處理功能並具有各種初始類型，包括外掛程式、挂鉤、簽名驗證器和函數處理程式。 只要符合既定標準，開發人員就可以參與其中。

Rhinestone 設計

! [深入解讀模組化智能合約帳戶架構和挑戰] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-96de12199c-dd1a6f-cd5cc0.webp)

該過程展開如下：

· 創建架構定義（schema）：架構提供預定義數據結構。 人們可以對其進行定製，以符合其特定的用例。

· 基於架構創建模組（modules）：註冊為模組的智慧合約獲取位元元組碼並選擇架構ID，資料就會被存儲在註冊表中。

· 獲得模組的證明（attestation）：證明者/審核員可以基於架構為模組提供證明。 這些證明可包括唯一標識碼 （UID） 以及對用於連結的其他證明的引用。 它們可以跨鏈傳播並驗證目標鏈是否滿足特定閾值。

· 使用解析器（resolver）實現複雜邏輯：解析器（可選設置）開始發揮作用。 它們可以在模組創建、證明建立和撤銷期間被調用。 這些解析器允許開發人員整合複雜且多樣化的邏輯，同時維護證明結構。

使用者友好的查詢訪問（query）：查詢為使用者提供了一種從前端訪問安全資訊的方法。

雖然該模式還處於早期階段，但它具有以分散和協作的方式建立標準的潛力。 註冊表使開發人員能夠註冊他們的模組，審計員能夠驗證其安全性，錢包能夠進行集成，並使用戶能夠輕鬆找到模組並驗證其證明資訊。 未來的幾種用途可能是：

· 證明者（attestor）：像Safe這樣值得信賴的實體可以與 Rhinestone 合作，共同作為內部模組的證明者。 同時，獨立證明者也可以加入。

· 模塊開發人員（module developer）：隨著開放市場的形成，模組開發人員有可能通過註冊表將他們的工作貨幣化。

· 用戶：通過使用者友好的介面（例如錢包或 dApp）進行參與，使用者可以檢查模組資訊並將信任委託給不同的證明者。

「模組註冊表」的概念為外掛程式和模塊開發人員開闢了盈利途徑。 它可以進一步為「模組市場」鋪平道路。 某些方面可能由Safe團隊監督，而其他方面可能表現為去中心化市場，邀請所有人做出貢獻並提供透明的審計記錄。 整合這一點可以避免供應商鎖定，並通過添加能夠吸引更廣泛受眾的增強用戶體驗來支援EVM的擴展。

雖然這些方法能保證單個模組的安全，但在更廣泛的安全性方面，智慧合約帳戶並不是萬無一失的。 與合規模組結合並證明它們沒有存儲衝突可能是一個挑戰，這凸顯了錢包或 AA 基礎設施在解決此類問題方面的重要性。

總結

通過利用模組化智慧合約帳戶堆疊，錢包供應商和 dApp 可以從技術維護的複雜性中解放出來。 同時，外部模塊開發人員有機會提供個人化的專業服務。 然而，需要解決的挑戰包括在靈活性和安全性之間取得平衡，推動模組化標準，以及實施標準化介面，使用戶能夠輕鬆升級和修改其智慧帳戶。

此外，模組化智慧合約帳戶（SCA）只是採用難題的一小部分。 為了充分發揮 SCA 的潛力，需要 Layer 2 解決方案提供額外的協定層支援，例如強壯的 bundler 基礎設施和點對點記憶體池、更具成本效益和可行的 SCA 簽名機制、跨鏈 SCA 同步和管理機制，以及開發使用者友好的介面。

未來，將會有更多人採用 SCA，但也會引發一些有趣的問題：一旦 SCA 訂單流變得有足夠利益可圖，傳統的礦工可提取價值 （MEV） 機制將如何進入該領域構建捆綁器並獲取價值？當基礎設施成熟後，帳戶抽象（AA）如何作為「基於意圖」交易的基礎層？讓我們拭目以待。