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

作者：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、籤名驗證器和函數處理程序。只要滿足既定的標准，开發人員就可以爲其做出貢獻。

Rhinestone Design

這個過程的展开如下：

• 創建模式定義：模式作爲預定義的數據結構，用於證明。企業可以根據其特定的用例自定義模式。

• 基於模式創建模塊：智能合約被注冊爲模塊，獲取字節碼並選擇模式 ID。這些數據隨後存儲在注冊表中。

• 獲取模塊的證明：證明者/審計員可以根據模式爲模塊提供證明。這些證明可以包括唯一標識符（UID）和其他證明的引用，用於鏈接。它們可以在鏈上傳播，並驗證目標鏈上是否滿足特定的閾值。

• 使用解析器實現復雜邏輯：解析器是可選設置在模式中的。它們可以在模塊創建、證明建立和撤銷過程中被調用。這些解析器允許开發人員在保持證明結構的同時，融入復雜多樣的邏輯。

• 用戶友好的查詢訪問：查詢提供了一種用戶從前端訪問安全信息的方式。在這裏可以找到 EIP。

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

• 證明者：可信任的實體，如 Safe，可以作爲內部模塊的證明者與 Rhinestone 合作。同時，獨立的證明者也可以加入進來。

• 模塊开發者：隨着一個开放市場的形成，模塊开發者有可能通過注冊表將他們的工作商業化。

• 用戶：通過用戶友好的界面，如錢包或 dApp，用戶可以查看模塊信息並將信任委托給不同的證明者。

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

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

總結

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

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

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

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播信息之目的，不構成任何投資建議，如有侵權行為，請第一時間聯絡我們修改或刪除，多謝。

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

地址：https://www.torrentbusiness.com/article/64936.html

標籤：智能合約