原文標題：《Modular Smart Contract Account Architecture and Challenges》

原文作者：Rui，Investor of SevenX Ventures

原文編譯：Luccy，Joyce，BlockBeats

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

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

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

簡述帳號抽象（AA）

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

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

透過模組化智慧合約帳號來解決工程問題

h1>

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

· 分散化：現在可以透過多種方式啟用功能，無論是透過特定的 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）

< br>

安全帳戶是一個代理合約，這是因為委託呼叫是一個單例合約。安全帳戶包含所有者、閾值和實現地址都設定為代理的變量，基於這些定義其狀態。

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

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

模組合約（modules）：自訂邏輯與功能

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

採用Safe 後帶來的改變：

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

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

ERC-2535 Diamond 代理

< img src="https://image.blockbeats.cn/upload/2023-10-31/c843b8cc12ada61b260a27de9b52c08b5f5e86e4.png?x-oss-process=image/quality,webpqp.

關於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，標準化都有助於減少特定於某些實施或生態系統的獨特開發工作的需求，並防止供應商鎖定。

< p>

模組發現和安全性

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

Safe{Core} 協議

。 /p>

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

https://t.me/theblockbeats

Telegram 交流群：https://t.me/BlockBeats_App

Twitter 官方帳號：https://twitter.com/BlockBeatsAsia