原文作者：SevenX Ventures 編譯：BlockBeats

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

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

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

簡述账戶抽象（AA）

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

账戶抽象利用智能合約账戶，允許可編程驗證（validation）和執行（execution）。這意味着用戶將能夠一次性批准一系列交易，而不再需要對每個交易都籤名和廣播。账戶抽象還可以實現更多功能，如改進用戶體驗（如 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。

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

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，為开發人員提供了基礎實現。然而，隨着开發者針對不同的用例擴展到更細致和具體的功能時，集成和解碼會面臨更多挑战。在本文中，我們將深入探討工程難題。

通過模塊化智能合約账戶來解決工程難題

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

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

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

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

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

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

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

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

模塊化結構：主账戶和模塊

账戶如何調用模塊實現功能

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

外部調用和委托調用：

關於委托調用

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

代理合約和委托調用

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

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

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

Safe 架構

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 代理

關於 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)、執行器 (Executor) 和掛鉤 (Hook)

讓我們通過介紹 ERC6900 來進一步討論，這是 Alchemy 團隊提出的、受 Diamond 啓發、專門為 ERC-4337 量身定制的標准。它通過提供通用接口來解決智能账戶模塊化的挑战，並協調插件和錢包开發人員之間的工作。

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

不同設計中的函數名稱

驗證 (Validator)：確保帳戶調用者的真實性和權限。

執行 (Executor)：執行帳戶允許的任何自定義邏輯。

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

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

模塊發現和安全

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

Safe{Core} 協議

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

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

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

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

· 模塊：模塊處理功能並具有各種初始類型，包括插件、掛鉤、籤名驗證器和函數處理程序。只要符合既定標准，开發人員就可以參與其中。

Rhinestone 設計

該過程展开如下：

· 創建架構定義（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）如何作為「基於意圖」交易的基礎層？讓我們拭目以待。