Smart Account 生態碎片化、全鏈帳戶抽象 UX 高度割裂 等問題該如何解決？
作者：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 的全鏈帳戶抽象系統要讓使用者在不同的 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）產品構建了一個基於簽名計算，面向開發者的帳戶抽象領域的開放生態，除了提供自研的帳戶抽象產品模組以外，整合了各類型的帳戶抽象產品與服務， 能夠快速推進整個帳戶抽象領域各個開發者的產品和服務的採納度。
免責聲明：本文內容僅用於資訊分享，均不構成任何投資建議及要約，並請您遵守所在國家或地區的相關法律法規。
