自2022年至今，賬戶抽象一直都是被廣泛熱議的話題，以EIP-4337爲核心的賬號抽象領域的框架似乎已成爲業內普遍共識。而意圖概念的火熱促使人們加強了對此類低門檻用戶交互組件的重視。

但EIP-4337依然存在Smart Account賬號碎片化、跨鏈間賬戶抽象用戶體驗高度割裂的痛點。本文以Biconomy、Safe Core和Particle Network等項目爲例，探討如何在EIP-4337框架下進一步推動賬號抽象領域的髮展。

從交易流程抽象的角度理解”賬戶抽象“概念

關於賬戶抽象，Vitalik曾多次指出，它是降低以太坊用戶門檻、實現mass adoption的必要條件，其核心願景是讓用戶可以 自定義驗簽方式 + 享受gas代付、無任何資産就能在鏈上髮起交易（俗稱無gas交易）。隻有實現了這些前提，才能提高Web3應用的新用戶轉化率。以往的非賬戶抽象提案或智能合約錢包，雖然可以實現類似的體驗，但還遠不夠靈活和高效，比如Gnosis Safe還是需要EOA地址去觸髮交易，而且付出的Gas成本極高。而賬戶抽象打算從智能合約賬戶的結構底層進行優化，爲下一代智能化賬號體繫鋪平道路。但是我們從實際的賬戶抽象提案來看，會髮現他們的關註點不在賬號模型本身。比如EIP-86、EIP-4337和EIP-6900等賬戶抽象相關提案，關註的是一筆交易從髮起到被節點接收、驗簽、gas支付等整套處理流程的抽象/模塊化，併不是真正關註賬號結構的抽象。所以，把現在的各類提案稱爲“交易抽象”似乎要更貼切一些。如果我們從“交易處理流程的抽象”的角度去理解那些廣爲人知的賬戶抽象提案，就可以更輕鬆的理解到其要點：這種交易抽象，其實就是想把Web2級別的用戶進入和使用産品的體驗帶入到以太坊體繫內，比如黑名單/白名單、一段時間內髮起交易無需身份驗證、無Gas交易、法幣支付手續費等。

（圖片來源：Zengo）

但有人會問：這些東西在過去的智能合約錢包身上不就可以實現了嗎？EIP-4337這類賬戶抽象方案的價值又在哪裡？

EIP-4337的本質：賬戶抽象在以太坊生態落地的局部最優解

如上問題提到，過去的智能錢包雖然可以實現上麵談到的功能，但實現手法普遍比較粗糙，而且往往依賴於高度中心化的第三方設施。比如過去的Gas代付方案，要引入第三方的Relayer節點（EIP-2771）。而且，不衕的智能錢包之間缺乏統一的標準，不利於配套的組件開髮與鋪陳。而各類賬戶抽象相關EIP的核心訴求，是通過一套標準化的專爲智能合約錢包設計的框架，解決這些存在於不衕錢包項目身上的缺陷，推進以太坊生態內的賬戶結構從基礎的功能結構轉變爲上限更高的智能結構。

（圖片來源：Springer Link）

這就好比，在ERC-20或ERC-721出現前，很多Token的實現方式、具備的功能、對外提供的函數/接口都不一緻，而“不一緻”就不利於配套的第三方設施開髮，也不利於代碼審計（難以想象沒有ERC-20協議的話，Defi應用該怎麽髮展到如今的繁榮程度）。

標準化的協議/功能實現標準，是模塊化敘事的先決條件，而模塊化開髮方式則幾乎是每個領域想要蓬勃髮展的先決條件（分工是提高效率的第一原則）。

最終，EIP-4337脫穎而出。

EIP-4337是局部最優解，但其框架內有多個角度亟待優化

EIP-4337定義了一整套的接口標準，明確了遵循4337協議的智能錢包至少要有哪些模塊，每個模塊應當實現哪些函數/接口，比如Bundler、EntryPoint、Paymaster這些組件應該對外提供哪些可調用的函數。將這些條條框框明確了之後，不衕組件之間的交互關繫更爲清晰，方便把模塊化的設計思路引入到賬戶抽象與智能錢包的設計中，錢包模塊的開髮者們也大大受益。當然，單純從用戶角度看，模塊化的智能錢包開髮範式帶來的價值還不明確，因爲短期內人們感受不到賬戶抽象錢包本身有多大變化。但從中長期來看，EIP-4337等協議的價值就類似於ERC-20和ERC-721，它爲賬戶抽象錢包的長期髮展奠定了基礎，是有畫時代意義的裡程碑。但EIP-4337還有許多問題沒有解決：比如：

1. 賬戶抽象的功能還不夠插件化，不衕的開髮者很容易重覆造輪子；

2. 賬戶模塊兼容度差，整個賬號體繫呈現生態呈現碎片化的狀態傾曏；3. 不衕鏈之間的賬戶抽象生態高度割裂，難以給終端用戶和開髮者提供統一且高質量的體驗實現較好的UX。而下文中，我們將探討這些問題的解決方案。

優化方曏一：賬戶抽象的功能插件化將成爲基礎配置

可以説，現在與賬戶抽象相關的核心討論點之一，就是如何更好的實現賬號抽象錢包的模塊化，將每個模塊的畫分粒度切的更細。比如Biconomy就基於EIP-4337（未來會引入粒度更細的EIP-6900），提出了賬戶抽象功能插件化的敘事，以進一步推動賬戶抽象生態的模塊化髮展。

（圖片來源：Biconomy）

所謂的賬戶抽象功能插件化，其實就是通過一套協議，對外明確智能合約錢包涉及的關鍵模塊都有哪些，這些模塊應當實現哪些接口/函數，這些接口的名稱和調用方式是怎樣的。然後，第三方開髮者會按照自己的想法，開髮出細節各異的組件，但這些組件都會符合協議中提出的要求。

Biconomy的V2版本以EIP-4337爲協議骨架，製定了更詳細的標準，增設了一批4337中沒有提及的接口。在聲明Bundler、Smart Contract Wallet、Paymaster這些模塊應該具備哪些功能的衕時，Biconomy允許第三方開髮者以不衕的代碼細節，實現特徵相衕、版本不衕的模塊，隻要遵循Biconomy事先聲明的協議細則即可（兼容EIP-4337）。

（Biconomy提出的接口標準，指明第三方模塊開髮者應在模塊內實現哪些函數供外部調用）衕時，Biconomy還提出了“Module商店”的口號，在身體力行推出賬戶抽象模塊SDK的衕時，鼓勵廣大開髮者提交自己設計的賬戶抽象模塊，展開“Module as a service”，讓所有遵循EIP-4337協議的錢包項目都可以直接採用這些由外人寫出來的賬戶抽象模塊。用戶通過前端頁麵創建智能賬戶時，對於採用哪些模塊也有了更多樣化的選擇。

模塊化在便於分工的衕時，也方便了用戶快捷的切換或添加、刪除智能錢包中的某些功能（説白了就是把粒度切分的更細）。Biconomy指出，智能合約錢包的模塊化程度越高，其更新或升級時所需要作出的改動越少（不需要更新用戶已有的Smart Contract Wallet合約或採用DelegateCall，隻需要更新某些外部模塊），方便不衕的用戶或開髮者替換掉某些組件。

而在Biconomy未來的新版賬戶抽象方案中，還將參考比EIP-4337更利於模塊化的EIP-6900提案。

優化方曏二：更細粒度的模塊切分，解決賬號碎片化問題

關於EIP-6900提案，Safe（前Gnosis Safe）其實在今年8月推出了一個與之相關聯的Safe Core Protocol白皮書，其中借鑒最多的就是EIP-6900。

（EIP-6900原理圖）EIP-6900指出，目前模塊化賬戶抽象的一個問題在於賬號的“碎片化”，或者説孤島問題。比如不衕的賬戶抽象模塊供應商，或者不衕的DAPP應用程序雖然會兼容EIP-4337，但EIP-4337對不衕模塊的抽象程度不夠高，畫分粒度比較粗糙，給Smart Account模塊開髮者留下了“過高”的自由度（smart account就是存放用戶信息，記録自定義的交易驗證、gas支付邏輯 的最核心的部分）。這樣一來，不衕的錢包項目方傾曏於設計出具有獨特屬性的smart account模塊。長此以往，其他的賬戶抽象模塊供應商就必鬚優先考慮與誰提供的Smart Account模塊兼容，慢慢會産生固定的上下游供應鏈，這必然會導緻賬戶抽象模塊生態的碎片化和彼此割裂。（這就好比在計算機行業早期，操作繫統開髮商要先考慮兼容哪家電腦硬件廠商提供的設備）要解決生態的碎片化問題，提高不衕供應商開髮的賬戶抽象模塊的兼容度，最佳的辦法就是把智能合約錢包賬戶進一步抽象化，把模塊切分粒度變得更細。在借鑒了EIP-6900的思路後，Safe Core協議白皮書對Smart Account（用戶的智能錢包賬戶）做出了更細緻的優化。Safe Core協議把每個智能錢包賬戶可調用的Module拆分爲Plugin插件、Hooks、簽名驗證器、函數處理器等多種類別。而智能賬戶模塊盡可能輕量化，賬戶合約隻存儲最基本的數據和函數，能挪到外麵去的函數就統統甩給“函數處理器”或“Plugin”這些細分模塊去實現。這正應了所謂的奧卡姆剃刀原則——“若無必要，勿增實體”。如果smart account本身足夠輕量化，不涉及太繁瑣的細節，不衕廠商開髮的smart account在內部構造上就會更接近，兼容度也會更高。

Safe Core協議裡還引入了註冊錶，類似於iPhone的應用商店，包含了所有被批準的可用模塊。用戶可以選擇激活哪些模塊，且每次激活新模塊時，都要經由Manger合約去處理。

一般情況下，UserOperation會先觸髮某個插件Plugin，然後Manger合約會檢查該插件的狀態是否正常（註冊錶裡有記録），若正常則會放行該插件的請求。如果有必要的話，Plugin插件會調用某些Hook提供的功能，或者不調用。之後會對UserOperation涉及的smart account的狀態進行更改。

通過上述細粒度的模塊切分方式與調度流程，Safe Core Protocol嘗試推行一套開源的賬戶抽象模塊互操作協議，其核心思路是把Smart Account輕量化，盡可能像EOA賬戶一樣簡單，以便於提高不衕廠商提高的Smart Account模塊的兼容度。

優化方曏三：全鏈賬戶抽象，在不衕鏈上實現統一賬戶

但即便有了前述解決方案，目前還有一個大問題沒有解決：不衕的鏈和不衕Layer2都在推進細節各異的賬戶抽象實現方案，而且很多採用了與EIP-4337有衝突的形式，比如zkSync Era、Starknet、Flow等。這給用戶帶來了錢包UX上的割裂，比如用戶在Starknet上的智能錢包地址與Arbitrum上的智能錢包地址壓根無法統一。而且，在多鏈環境下，用戶在不衕鏈上有獨立部署的Smart Account，對應的用戶數據往往分散存儲在這些合約中。如果用戶數據如密鑰等需要更新，則需要在多鏈重覆髮起交易，很難保證 Smart Account 的一緻性。Vitalik本人此前曾提出過一套全鏈統一且易於管理的智能賬戶方案，該方案把以太坊或某個安全性極高的ZKRollup作爲源鏈，部署Keystore合約，存儲用戶的全局密鑰，然後用戶在L2上的全部智能合約賬戶，共享Keystore合約中存放的全局密鑰。

（圖片來源：https://vitalik.ca/general/2023/06/20/deeperdive.html）

但這個方案成本極高，就是每當源鏈上的Keystore合約記録的全局密鑰髮生變更時，L2/目標鏈上的每個賬戶都需要通過跨鏈交互的方式來衕步新的密鑰。而以太坊到L2之間的跨鏈交互開銷太高，用戶根本承擔不起。而且需要註意的是，智能合約賬戶不衕於EOA賬戶，後者因其獨特的地址生成方式，天生就是多鏈統一的（EVM鏈之間統一），但智能合約賬戶則完全不衕，很難讓用戶在不衕的鏈上穫得地址相衕的智能合約賬戶。對此，Particle Network提出了自己的一種方法。雖然大體思路和Vitalik的想法一緻，也是把智能賬戶的Storage和Code分離，但Particle Network打算以一個獨立的鏈—Particle Network Chain作爲智能賬戶的全鏈Storage數據庫，通過第三方的跨鏈消息傳遞方案（LayerZero、CCIP、Axelar、Connext 等）將某個用戶對賬戶Storage的變更衕步到其他鏈上的Account本地。

(Particle Network的多鏈賬戶抽象結構）

具體而言，Particle Network的全鏈賬戶抽象繫統要讓用戶在不衕的EVM鏈上有一個統一的智能合約賬戶地址，這要在不衕鏈上都部署一套Deployer Contract；用戶必鬚在Particle Network Chain上觸髮新賬戶的生成，之後Particle Chain會觸髮所有鏈上的Deployer Contract，保證在不衕鏈上爲用戶生成的智能合約賬戶地址是統一的，或者用戶可以在對其他鏈無感知的情況下，通過Particle chain上的合約完成多鏈交互過程，併且可以用 Unified Gas Token 作爲統一的手續費支付方式。

全鏈賬戶抽象也讓Cross-Chain的User Operation成爲可能，通過源鏈的User Operation和支付對應的Gas，來觸髮目標鏈的Transaction，比如可以實現使用Polygon的USDC購買Base上的NFT。

但Particle Network的方案需要 Deployer Contract 和跨鏈消息傳遞組件高度協衕，來實現多鏈Account和源鏈Storage的衕步，這其實就對其採用的預言機或者跨鏈消息橋有較高要求（這個問題似乎在所有和全鏈互操作有關的方案身上都會存在）。不過用戶的跨鏈賬號衕步可以靈活配置不衕Message Bridge的組合，而不僅僅依賴某一個Bridge，比如可以配置爲2/3的策略，依賴 LayerZero、Axelar、Connext任意兩個的確認才在目標鏈上確認 Storage 的變更，可以近似解決這種單點依賴問題。

橫跨EVM和非EVM的全鏈無縫互操作是以太坊生態內的全鏈賬戶抽象的更進一步

盡管有橫跨EVM鏈的密鑰管理和統一賬戶，但全鏈賬戶抽象依然有優化空間：不兼容EVM的鏈，比如Aptos和Solana、Sui等，無法保證用戶生成的智能合約賬戶地址，與EVM鏈上的一緻；衕時非EVM鏈如果沒有用等價的方案實現EIP-4337協議，就難以沿用前文中Vitalik和Particle Network提出的全鏈賬戶抽象的構想。此外，兼容EIP-4337的錢包項目本身也存在進步的空間。大多數智能錢包使用的Bundler節點，都是官方獨立運行的，彼此甚至都不互通，很多智能錢包項目實際自成一條鏈，這就會帶來很多風險（抗審查性、可用性）。構建一個統一的橫跨絶大多數鏈的單一前端界麵，但這會非常睏難。有一個解決思路是引入以意圖爲中心的設計，在全鏈賬戶抽象之上增設一層，把以太坊的EIP-4337生態或其他鏈的原生賬戶抽象設施（例如zkSync），統統視作Solver/Reactor類型下的具體實例，而如何選擇合適的Solver是更上層的任務。僅以Particle Network爲例，它提出了一套簡潔的抽象化的Intent-Centric實現方案，而不衕的賬戶抽象項目隻是Intent方案中，被包含進Solver範疇內的一類實例。首先，用戶前端會負責將自然語言化的請求或者任意的用戶交互，轉變爲具體的程式化描述，其中包含輸入約束和輸出約束（説白了就是能讓符合用戶要求的輸入條件和輸出結果區間），隨後Solver網絡中的某個或某些Solver，會將包含具體輸入輸出約束的Transaction，轉髮給部署在鏈上的Solver合約（Solver不隻有節點設施，還會有鏈上合約部分）。Solver合約會將Intent指令傳送給Reactor合約（管理用戶在鏈上的賬戶），交由後者去調用其他模塊完成最終交互。用戶的請求最先被Solver網絡所穫知，這樣用戶不需要過多的感知底層鏈或者不衕賬戶抽象方案的構造，這一部分交由Solver去構造具體的解決方案即可。當然這些構想目前還隻是一個理論框架，而後麵的實現細節還有待Particle Network官方的鋪陳。目前比較明確的是，未來必定會衍生出一個充滿競爭的Solver市場，而用戶可以髮起競拍，讓多個Solver出不衕的解決方案，通過本地模擬交易的形式，可以評選出最優的解決方案，併給予對應的Solver以激勵。至於激勵的形式，就要看Solver網絡的協議設計者的考量（Particle Network 打算以PNT代幣作爲其Solver拍賣市場的激勵代幣）。目前的Intent實質將下層的覆雜細節屏蔽，抽象出了更高的一層，這樣的一種帶有TCP/IP協議性質的分層式設計，對於全鏈無縫互操作下的用戶體驗和開髮者體驗都是必要條件。

迎接賬號抽象的大規模採用

當我們把以太坊生態內的4337框架從各個角度優化之後，衕時也推進了橫跨以太坊和非以太坊生態全鏈無縫互操作，爲了支持賬號抽象的大規模採用，我們覺得依然需要一個橫跨供給側和需求側的産品。能夠降低終端用戶使用各類Web3産品服務的衕時，聚焦服務開髮者，降低開髮者門檻。這裡麵扮演這個角色的最佳産品之一是Particle Network的模塊化的賬戶抽象錢包即服務（Modular Smart Wallet-as-as-Service) 産品：

（Particle Network’s Smart Wallet-as-a-Service Architecture）

• 該服務提供一套易於使用的API，使開髮者能夠輕鬆地在其應用程序中集成模塊化的賬戶抽象功能；
• 開髮者可以使用該服務創建和管理全鏈賬戶，進行跨鏈交互，併使用統一的手續費支付方式；
• 這樣的服務將爲開髮者提供更靈活和便捷的方式來構建多鏈應用程序，併促進賬號抽象的廣泛採用。

除了以上開髮者友好的特性以外，最重要的特點是Particle Network的模塊化賬戶抽象錢包即服務（Modular Smart Wallet-as-as-Service) 産品構建了一個基於簽名計算，麵曏開髮者的賬戶抽象領域的開放生態，除了提供自研的賬戶抽象産品模塊以外，整合了各類型的賬戶抽象産品與服務，能夠快速推進整個賬戶抽象領域各個開髮者的産品和服務的採納度。

（Modular Design of Particle Network’s Smart Wallet-as-a-Service）讓技術服務於需求，在解決了ERC-4337框架的各個角度的限製之後，開髮者體驗的提升將促使更多擁有優秀用戶體驗的産品産生，加速 Web3 行業從加密朋剋友好的金融行業轉變爲大衆友好的消費級行業。

聲明：

1. 本文轉載自[極客 Web3]，著作權歸屬原作者[Peter Pan, Co-founder and CTO of Particle Network & Faust，極客Web3]，如對轉載有異議，請聯繫Gate Learn團隊，團隊會根據相關流程盡速處理。
2. 免責聲明：本文所錶達的觀點和意見僅代錶作者個人觀點，不構成任何投資建議。
3. 文章其他語言版本由Gate Learn團隊翻譯， 在未提及Gate.io的情況下不得覆製、傳播或抄襲經翻譯文章。