深入探討模塊化智能合約賬戶設計：解決落地技術難題

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

原文作者：Rui S，SevenX Ventures

原文編譯：深潮TechFlow

介紹

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

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

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

AA 簡述

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

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

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

SCA 採用的困境

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

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

• 熊市的影響：

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

• 遷移障礙：

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

• 簽名問題：

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

• Gas 開銷：

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

• 工程難題：

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

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

模塊化智能合約賬戶以解決工程難題

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

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

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

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

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

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

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

委託調用和代理合約

外部調用和委託調用：

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

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

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

安全架構

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

關於ERC 2535 和Diamond 代理

ERC 2535 標準化了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 團隊提出的標準ERC 6900 來擴展我們的討論，該標準受到Diamond 的啟發，專門針對ERC-4337 進行了調整。它通過提供常見接口並協調插件和錢包開發人員之間的工作，解決了智能賬戶中的模塊化挑戰。

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

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

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

模塊的發現和安全性

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

Safe{Core}協議

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

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

水鑽設計

這個過程的展開如下：

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

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

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

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

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

總結

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

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

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