EIP-4337 的最後一塊拼圖：全鏈帳戶抽象

作者： Peter Pan, Co-founder and CTO of Particle Network \& Faust，極客Web3

自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 行業從加密朋克友好的金融行業轉變為大眾友好的消費級行業。