為什麼說全鏈帳戶抽象化是EIP-4337的最後一塊拚圖？

本文以Biconomy、Safe Core和Particle Network等項目為例，探討如何在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交易、法幣支付手續費等。

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

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

如上問題提到，過去的智慧錢包雖然可以實現上面談到的功能，但實現手法普遍比較粗糙，而且往往依賴高度中心化的第三方設施。例如過去的Gas代付方案，要引入第三方的Relayer節點（EIP-2771）。而且，不同的智慧錢包之間缺乏統一的標準，不利於配套的組件開發與鋪陳。

而各類帳戶抽象相關EIP的核心訴求，是透過一套標準化的專為智能合約錢包設計的框架，解決這些存在於不同錢包項目身上的缺陷，推進以太坊生態內的帳戶結構從基礎的功能結構轉變為上限更高的智慧結構。

這就好比，在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的V2版本以EIP-4337為協定骨架，製定了更詳細的標準，增設了一批4337中沒有提及的介面。在聲明Bundler、Smart Contract Wallet、Paymaster這些模組應該具備哪些功能的同時， Biconomy允許第三方開發者以不同的程式碼細節，實現特徵相同、版本不同的模組，隻要遵循Biconomy事先聲明的協議細則即可（相容EIP-4337）。

同時， 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指出，目前模組化帳戶抽象的一個問題在於帳號的“碎片化”，或者說孤島問題。例如不同的帳戶抽像模組供應商，或不同的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合約中存放的全域金鑰。

但這個方案成本極高，就是每當來源鏈上的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) 產品：

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

除了上述開發者友善的功能以外，最重要的特點是Particle Network的模組化帳戶抽象錢包即服務（Modular Smart Wallet-as-as-Service)產品建構了一個基於簽章運算，面向開發者的帳戶抽象領域的開放生態，除了提供自研的帳戶抽象產品模組以外，整合了各類型的帳戶抽象產品與服務，能夠快速推進整個帳戶抽象領域各個開發者的產品和服務的採納度。

讓技術服務於需求，在解決了ERC-4337框架的各個角度的限製之後，開發者體驗的提升將促使更多擁有優秀用戶體驗的產品產生，加速Web3 行業從加密朋克友好的金融行業轉變為大眾友善的消費級產業。