透過利用模組化的智慧合約帳戶堆疊，錢包提供者和dApp 可以擺脫技術維護的複雜性。

撰文：Rui

編譯：深潮TechFlow

原版英文報告於2023 年9 月發表

介紹

從外部擁有帳戶（EOA）轉向智慧合約帳戶（SCA）的轉變正在蓬勃發展，並得到了許多愛好者的支持，包括Vitalik 本人。儘管引起了人們的興奮，但SCA 的採用並不像EOA 那樣普及。其中的關鍵問題包括熊市帶來的挑戰、遷移的擔憂、簽名問題、Gas 開銷以及最關鍵的工程難題。

帳戶抽象化（AA）最重要的優勢之一是能夠使用程式碼自訂功能。然而，一個主要的工程挑戰是AA 功能的非互通性，而這種碎片化阻礙了集成，並為供應商鎖定打開了大門。此外，在同時升級和組合功能時確保安全性可能會很複雜。

模組化帳戶抽象的出現是更廣泛的AA 運動的子集，這種創新的方法可以將智慧帳戶與其自訂功能分開。其目標是創建一個模組化結構，以開發具有多樣化功能的安全、無縫整合的錢包。在未來，它可以實現一個自由的智慧合約帳戶「應用程式商店」，使錢包和dApp 不再專注於建立功能，而是專注於用戶體驗。

AA 簡述

傳統的EOA 引入了許多挑戰，如種子短語、Gas、跨鍊和多個交易。我們從未打算引入複雜性，但事實上，區塊鏈對大眾來說並不是一款簡單的遊戲。

帳戶抽象利用智慧合約帳戶，允許可程式驗證和執行，用戶能夠一次性批准一系列交易，而不是每個交易都要簽名和廣播，並實現更多功能。它為使用者體驗（例如，Gas 抽象化和會話金鑰）、成本（例如，批次交易）和安全性（例如，社交復原、多重簽署）帶來了好處。目前，有兩種實現帳戶抽象化的方式：

• 協議層：一些協議本身提供了本地帳戶抽象支持，ZKsync 交易無論是來自EOA 還是SCA，都遵循相同的流程，使用單個內存池和交易流程來支持AA，而Starknet 已經移除了EOA，所有賬戶都是SCA，而且他們有像Argent 這樣的本地智慧合約錢包。
• 合約層：對於以太坊及其等價的L2，ERC4337 引入了一個單獨的事務入口來支援AA，而不改變共識層。像Stackup、Alchemy、Etherspot、Biconomy、Candide 和Plimico 這樣的專案正在建造捆綁器基礎設施，而像Safe、Zerodev、Etherspot 和Biconomy 這樣的專案正在建造堆疊和SDK。

SCA 採用的困境

自2015 年以來，帳戶抽象（AA）的話題一直在討論中，並在今年由ERC4337 推動到了聚光燈下。然而，部署的智慧合約帳戶數量仍然遠遠不及EOA。

讓我們深入探討這個困境：

**熊市的影響：**儘管AA 引入了諸如無縫登錄和Gas 抽像等好處，但當前經歷熊市的人們主要由受過教育的EOA 用戶組成，而不是新用戶，因此對於dApp 和錢包來說並沒有激勵。即便如此，一些領先的應用程式仍在逐步採用AA，例如Cyberconnect 透過引入他們的AA 系統和無Gas 解決方案，僅一個月就帶動了約360,000 次UserOps（AA 交易）。

**遷移障礙：**對於已經累積了用戶和資產的錢包和應用程式來說，安全、便捷地遷移資產仍然是一個挑戰。然而，像EIP-7377 這樣的倡議允許EOA 發起一次性遷移交易。

**簽名問題：**智能合約本身自然無法簽署訊息，因為它沒有像EOA 那樣的私鑰。像ERC1271 這樣的努力使得這種簽名成為可能，但在第一筆交易之前，訊息簽名是不起作用的，這對於使用反事實部署的錢包提出了挑戰。而由Ambire 提出的ERC-6492 是ERC-1271 的向後相容的繼任者，可能解決了先前的問題。

**Gas 開銷：**部署、模擬和執行SCA 相比標準EOA 會產生更高的成本。這成為了採用的障礙。然而，已經進行了一些測試，例如將帳戶建立與使用者操作解耦，並考慮消除帳戶鹽和存在性檢查，以減少這些成本。

**工程難題：**ERC-4337 團隊已經建立了eth-infinitism 儲存庫，為開發人員提供了基礎實作。然而，隨著我們在不同的用例中分支出更細緻或特定的功能，整合和解碼變得具有挑戰性。

在本文中，我們將深入探討第五個問題：工程難題。

模組化智慧合約帳戶以解決工程難題

對於工程難題的進一步闡述如下：

• 分散化：現在各種功能都以不同的方式啟用，無論是透過特定的SCA 或獨立的插件系統。每個都遵循自己的標準，迫使開發者決定要支援哪些平台。這可能導致平台鎖定或重複努力。
• 安全性：雖然帳戶和功能之間的靈活性帶來了優勢，但也可能加劇安全問題。功能可能會被集體審計，但缺乏獨立評估可能會增加帳戶漏洞的風險。
• 可升級性：隨著功能的發展，保留新增、取代或刪除功能的能力非常重要。每次更新都重新部署現有功能會引入複雜性。

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

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

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

然而，在任何行業中，建立和推廣新的標準都是一個巨大的挑戰。在大家都接受主要解決方案之前，初始階段可能會出現許多不同的解決方案。然而，令人鼓舞的是，無論是4337 SDK、錢包開發者、基礎設施團隊或協議設計師，都在共同努力加快這個過程。

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

委託呼叫和代理合約

外部呼叫和委託調用：

雖然delegatecall 與call 類似，但它不是在自己的背景中執行目標合約，而是在調用合約的當前狀態下執行目標合約。這意味著目標合約所做的任何狀態變更都會套用到呼叫合約的儲存中。

為了實現可組合和可升級的結構，需要一種基本的知識，稱為「代理合約」。

• 代理合約：普通合約儲存其邏輯和狀態，部署後無法更新。代理合約使用委託呼叫（delegatecall）另一個合約。透過引用實現函數，它在代理合約的當前狀態下執行。
• 使用案例：雖然代理合約保持不變，但您可以在代理程式後面部署新的實作。代理合約用於可升級性，並且在公共區塊鏈上部署和維護成本更低。

Safe 架構

Safe 是一種領先的模組化智慧帳戶基礎架構，旨在提供經過實戰驗證的安全性和靈活性，使開發人員能夠創建多樣化的應用程式和錢包。值得注意的是，許多團隊正在建立在Safe 之上或受其啟發。 Biconomy 透過在Safe 上擴展原生4337 和1/1 多重簽名來推出其帳戶。 Safe 已經部署了超過164,000 個合約，並鎖定了超過307 億的價值，毫無疑問，Safe 是該領域的首選。

Safe 的結構

• Safe 帳戶合約：主代理合約（有狀態）

Safe 帳戶是一個代理合約，因為它透過委託調用（delegatecall）一個單例合約。 Safe 帳戶包含所有者、閾值和實現地址，這些都被設定為代理的變量，從而定義了其狀態。

• 單例合約：整合中心（無狀態）

單例為Safe 帳戶提供服務，並整合和定義了不同的集成，包括插件、Hook、函數處理器和簽名驗證器。

• 模組合約：自訂邏輯與功能

模組非常強大。作為一種模組化類型，插件可以定義不同的功能，如支付流、復原機制和會話金鑰，並透過取得鏈外資料作為Web2 和Web3 之間的跨鏈橋。其他模組，如Hook 作為安全保護，以及函數處理器回應任何指令。

當我們採用Safe 時會發生什麼

• 可升級合約：

每當引入新的插件時，需要部署一個新的單例。使用者保留了升級Safe 到所需單例版本的自主權，以符合其偏好和要求。

• 可組合且可重複使用的模組：

插件的模組化特性使開發人員能夠獨立地建立功能。然後，他們可以根據自己的用例自由選擇和組合這些插件，促進高度可自訂的方法。

ERC-2535 Diamond 代理

關於ERC2535 和Diamond 代理

ERC2535 標準化了Diamond 代理，這是一種模組化的智慧合約系統，可以在部署後進行升級/ 擴展，幾乎沒有大小限制。到目前為止，許多團隊都受到了它的啟發，例如Zerodev 的Kernel 和Soul Wallet 的實驗。

**Diamond 結構是什麼？ **

• Diamond 合約：主代理合約（有狀態）Diamond 是一個代理合約，透過委託呼叫（delegatecall）從其實作中呼叫函數。
• 模組/ 插件/ 分面合約：自訂邏輯和功能（無狀態）模組或所謂的分面是一個無狀態合約，可以將其功能部署到一個或多個Diamond 中。它們是獨立的合約，可以共享內部函數、函式庫和狀態變數。

**當我們採用Diamond 時會發生什麼？ **

• 可升級合約：Diamond 提供了一種系統化的方法來隔離不同的插件並將它們連接在一起，並透過diamondCut 函數直接新增/ 替換/ 刪除任何插件。隨著時間的推移，可以向Diamond 添加的插件數量沒有限制。
• 模組化和可重複使用的插件：一個已部署的插件可以被任意數量的Diamond 使用，從而大大降低部署成本。

Safe 智慧帳戶和Diamond 方法之間的區別

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

然而，主要區別在於邏輯合約的處理。以下是更詳細的說明：

• **靈活性：**在啟用新插件的情況下，Safe 需要重新部署其單例合約以在其代理中實現變更。相比之下，Diamond 透過其代理中的diamondCut 函數直接實現這一點。這種方法上的差異意味著Safe 保留了更高程度的控制，而Diamond 引入了更強大的靈活性和模組化。
• **安全性：**目前，兩種結構中都使用了delegatecall，它可以允許外部程式碼操縱主合約的儲存。在Safe 架構中，delegatecall 指向一個單一的邏輯合約，而Diamond 則在多個模組合約（插件）之間使用delegatecall。因此，惡意插件有可能覆蓋另一個插件，從而引入儲存衝突的風險，可能損害代理的完整性。
• **成本：**Diamond 方法中固有的靈活性與增加的安全性問題相伴而生。這增加了成本因素，需要在每次新增外掛程式時進行全面審計。關鍵是確保這些外掛程式不會幹擾彼此的功能，這對於努力維護強大安全標準的中小型企業來說是一個挑戰。

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

模組順序：驗證器、執行器和Hook

讓我們透過介紹Alchemy 團隊提出的標準ERC6900 來擴展我們的討論，該標準受到Diamond 的啟發，專門針對ERC-4337 進行了調整。它透過提供常見介面並協調插件和錢包開發人員之間的工作，解決了智慧帳戶中的模組化挑戰。

當涉及到AA 的交易過程時，有三個主要流程：驗證、執行和Hook。正如我們之前討論的那樣，透過使用代理帳戶呼叫模組，可以管理這些步驟。雖然不同的項目可能使用不同的名稱，但掌握相似的基本邏輯是很重要的。

• 驗證：確保呼叫者對帳戶的真實性和權限。
• 執行：執行帳戶允許的任何自訂邏輯。
• Hook：作為在另一個函數之前或之後運行的模組。它可以修改狀態或導致整個呼叫被撤銷。

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

模組的發現與安全性

一個正在蓬勃發展的解決方案涉及創建一個允許用戶發現可驗證模組的地方，我們可以稱之為「註冊表」。這個註冊表類似於一個“應用商店”，旨在促進一個簡化但繁榮的模組化市場。

Safe{Core}協議

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

• 帳戶：在Safe{Core}協議中，帳戶的概念是靈活的，不受特定實現的限制。這使得各種帳戶服務提供者可以參與其中。
• 管理器：管理員在帳戶、註冊表和模組之間充當協調者。它也負責安全性，作為權限層。
• 註冊表：註冊表定義安全屬性，並強制執行諸如ERC6900 之類的模組標準，旨在為發現和安全性創造一個開放的「應用商店」環境。
• 模組：模組處理功能，並以各種初始類型提供，包括插件、Hook、簽名驗證器和函數處理程序。只要滿足既定的標準，開發人員就可以為其做出貢獻。

水鑽設計

這個過程的展開如下：

• 建立模式定義：模式作為預先定義的資料結構，用於證明。企業可以根據其特定的用例自訂模式。
• 基於模式建立模組：智慧合約被註冊為模組，取得字節碼並選擇模式ID。這些數據隨後儲存在註冊表中。
• 取得模組的證明：證明者/ 審計員可以根據模式為模組提供證明。這些證明可以包括唯一識別碼（UID）和其他證明的引用，用於連結。它們可以在鏈上傳播，並驗證目標鏈上是否滿足特定的閾值。
• 使用解析器實作複雜邏輯：解析器是可選設定在模式中的。它們可以在模組創建、證明建立和撤銷過程中被呼叫。這些解析器讓開發人員在保持證明結構的同時，融入複雜多樣的邏輯。
• 使用者友善的查詢存取：查詢提供了一種使用者從前端存取安全資訊的方式。在這裡可以找到EIP。

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

• 證明者：可信任的實體，如Safe，可以作為內部模組的證明者與Rhinestone 合作。同時，獨立的證明者也可以加入。
• 模組開發者：隨著一個開放市場的形成，模組開發者有可能透過註冊表將他們的工作商業化。
• 使用者：透過使用者友善的介面，如錢包或dApp，使用者可以查看模組資訊並將信任委託給不同的證明者。

「模組註冊表」的概念為外掛程式和模組開發者提供了獲利的機會。它還可能為“模組市場”鋪平道路。其中一些方面可能由Safe 團隊監督，而其他方面可能表現為去中心化市場，邀請所有人進行貢獻並提供透明的審計記錄。透過採用這種方式，我們可以避免供應商鎖定，並透過提供更好的用戶體驗吸引更廣泛的受眾來支持EVM 的擴展。

雖然這些方法保證了單一模組的安全性，但智慧合約帳戶的整體安全性並非絕對可靠。結合合法模組和證明它們沒有儲存衝突可能是一個挑戰，強調了錢包或AA 基礎設施在解決此類問題中的重要性。

總結

透過利用模組化的智慧合約帳戶堆疊，錢包提供者和dApp 可以擺脫技術維護的複雜性。同時，外部模組開發者有機會提供針對個人需求量身訂製的專業服務。然而，需要解決的挑戰包括在靈活性和安全性之間取得平衡，推動模組化標準的進步，並實施標準化的接口，使用戶能夠輕鬆升級和修改他們的智慧帳戶。

然而，模組化智慧合約帳戶（SCA）只是採用的拼圖中的一部分。要充分實現SCA 的潛力，還需要來自第二層解決方案的協議層支持，以及強大的捆綁器基礎設施和點對點內存池、更具成本效益和可行性的SCA 簽名機制、跨鏈SCA 同步和管理，以及開發用戶友好的介面。

我們設想一個廣泛參與的未來，引發了一些有趣的問題：一旦SCA 訂單流程變得足夠有利可圖，傳統的礦工可提取價值（MEV）機制將如何進入領域，建立捆綁器並捕獲價值？當基礎設施成熟時，如何讓帳戶抽象化（AA）成為「基於意圖」的交易的基礎層？請持續關注，這個領域正在不斷發展變化。