本文為SevenX 研究團隊原創，僅供交流學習，不構成任何投資參考。如需引用，請註明來源。
原版英文報告於2023 年9 月發表於SevenX 的Mirror 平台。更多中文投研內容，請關注公眾號【SevenXVentures】。
感謝Safe 的共同創始人Lukas、Alchemy 的工程主管Noam、Rhinestone 的共同創始人Kurt 和Konrad 以及HashKey Capital 的投資者Arnav。
編按：智慧合約帳戶（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）
在人們接觸區塊鏈的過程中，傳統的EOA 帶來了許多挑戰，如助記詞、Gas 費用、跨鏈操作和多重交易等。
帳戶抽象利用智慧合約帳戶，允許可程式驗證（validation）和執行（execution）。這意味著用戶將能夠一次批准一系列交易，而不再需要對每個交易都簽署和廣播。賬戶抽象化還可以實現更多功能，例如改善用戶體驗（如Gas 抽象和會話密鑰）、降低成本（如大量交易）和提高安全性（如社交復原、多重簽名）。目前，有兩種實現帳戶抽象化的方式：
協議層：一些協議本身提供了本地賬戶抽象支持，ZKSync 交易使用單個內存池和交易流程來支持AA；無論是來自EOA 還是SCA 都遵循相同的流程，而Starknet 已經移除了EOA，所有賬戶都是SCA，而且他們有像Argent 這樣的本地智慧合約錢包。
合約層：對於以太坊及類似的L2，ERC 4337 引入了一個單獨的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 那樣的私鑰。類似ERC 1271 的嘗試使之成為可能，但訊息簽名在第一筆交易之前不起作用的，這又對於使用反事實部署的錢包提出了挑戰。由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 代理
關於ERC 2535、 Diamond 代理商：
ERC 2535 標準化的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)
讓我們透過介紹ERC-6900 來進一步討論，這是Alchemy 團隊提出的、受Diamond 啟發、專門為ERC-4337 量身定制的標準。它通過提供通用介面來解決智慧帳戶模塊化的挑戰，並協調插件和錢包開發人員之間的工作。
說到AA 的交易流程，主要有三個流程：驗證、執行、掛鉤。正如我們前面所討論的，這些步驟都可以透過使用代理帳戶呼叫模組來管理。雖然不同的項目可能使用不同的名稱，但掌握相似的底層邏輯很重要。
不同設計中的函數名稱
驗證(Validator)：確保帳戶呼叫者的真實性和權限。
執行(Executor)：執行帳戶允許的任何自訂邏輯。
掛鉤(Hook)：充當在另一個函數之前或之後運行的模組。它可以修改狀態或撤銷整個呼叫。
ERC 6900
根據不同的邏輯來分離模組至關重要。標準化方法應該規定如何編寫智慧合約帳戶的驗證、執行和掛鉤函數。無論是Safe 還是ERC-6900 ，標準化都有助於減少特定於某些實施或生態系統的獨特開發工作的需求，並防止供應商鎖定。
模組發現和安全
如何以開放的方式找到和驗證模組：一個正在推進的解決方案涉及創建一個允許用戶發現可驗證模組的區域，可以將其稱為「註冊表」。此註冊表的功能類似於“應用商店”，旨在培育一個簡化但蓬勃發展的模塊化市場。
Safe{Core} 協議
Safe{Core} 協議是一種針對智慧合約帳戶的開源、可互通的協議，旨在增強各種供應商和開發人員的可訪問性，同時透過明確定義的標準和規則來保持強大的安全性。
帳戶：在Safe{Core} 協議中，帳戶的概念是靈活的，不受特定實現的約束。這使得不同的帳戶服務提供者能夠參與其中。
管理器：管理器可充當帳戶、註冊表和模組之間的協調員。它也作為許可層負責安全性。
註冊中心：註冊中心定義安全屬性並執行ERC 6900 等模組標準，旨在創建一個開放的「應用商店」環境，以實現可發現性和安全性。
模組：模組處理功能並具有各種初始類型，包括插件、掛鉤、簽名驗證器和函數處理程序。只要符合既定標準，開發人員就可以參與其中。
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）如何作為「基於意圖」交易的基礎層？讓我們拭目以待。
