原文：《萬物研究院：Web3的下一個十億級用戶市場？全麵解讀賬戶抽象與EIP4337的技術和應用》
作者：Steve Wang，萬物研究院研究員，沃頓商學院在讀，前端&合約工程師
簡介
以太坊改進提案4337（EIP 4337）定義的賬戶抽象是一組協議層的接口。它不僅集成了web2用戶熟悉的交互形式，如多因素認證（multi-factor authentication），還給web3特有的用戶痛點提出了解決方案，如無需手續費（gasless）的交易。作為引入下十億用戶的協議接口，用戶體驗是賬戶抽象最關注的重點。
雖然許多現有的文章很好地解釋了賬戶抽象，但是大多偏科普向，也有少數十分深入於技術細節。本文旨在融合兩者：既提供關於賬戶抽象概念的全麵技術解讀，也分類剖析現有應用和基礎設施的案例。因此本文分為三部分：在第一部分，我們將探討EIP 4337的起源，並深入了解其技術細節，包括用戶操作（UserOperation）、打包器（Bundler）、入口點合約（Entry Point Contract）、代付合約（Paymaster）、錢包工廠（Wallet Factory）和簽名聚合器（Signature Aggregator）。在第二部分，我們將分析現有的市場玩家，包括智能合約錢包和第三方基礎設施提供商。在第三部分，我們將討論賬戶抽象的發展方向，包括該領域的創新展望和預測。
本文篇幅較長，第一部分主要為賬戶抽象的技術解讀，隻對賬戶抽象的應用場景感興趣的讀者可以直接跳到第二部分。
第一部分：EIP 4337的全麵技術分析
首先來簡要回顧一下基礎知識，以太坊有兩種類型的賬戶：外部擁有的賬戶（externally owned accounts，即EOA）和合約賬戶。
- EOA是用戶控製的賬戶，可以發送交易。EOA通過其私鑰控製賬戶的所有權，可以通過簽名執行交易，從而改變EOA的內部狀態或外部合約賬戶的狀態。由於私鑰（或種子短語）是EOA所有權的唯一代表，EOA不適合定義複雜的所有權或交易邏輯，如使用社交媒體賬戶登錄（social login）和多方簽名（multisig）的交易。EOA的局限性導致用戶體驗不佳：一些冗雜的步驟，如私鑰和種子短語管理，更是直接阻礙了Web2用戶進入Web3。大多數最受歡迎的錢包，如MetaMask，都是基於EOA的賬戶模型。
- 合約賬戶可以托管任意的Solidity代碼，因此可以發揮EVM全部的圖靈完備特性。遺憾的是，合約賬戶不能發送交易，因此它們的功能必須由EOA觸發。智能合約錢包是一種合約賬戶，通過錢包提供商的EOA網絡間接地被其用戶觸發，無論是通過中繼器（relayer）還是打包器（Bundler）。
圖：EOA與合約賬戶（來源：Bitcoin Insider）
智能合約錢包早在EIP 4337之前就已存在。EIP 4337的提出是為了標準化設計智能合約錢包及其相關基礎設施的通用功能。EIP 4337遵循以下幾個設計原則：
- 總體而言，所有的技術實現都在頂層（智能合約層），從而避免觸及共識層和執行層等底層基礎設施。賬號模型這種基本設計如果在底層改動會成為像以太坊PoS主網合並一樣的重要升級。因為開發人員的精力有限，隻能采用合約層實現的輕量級技術路線。
- 協議接口的設計應該是模塊化的，這樣用戶可以自定義選項，包括交易打包處理（Bundler）、gas代付（Paymaster）和簽名聚合（Aggregator）。
- 理想情況下，上述每項服務都將成為一個具有競爭性的開放市場。用戶可以根據提供商的價格和聲譽選擇最佳的服務。
EIP 4337為標準化智能合約錢包定義了六個合約接口：
首先，智能合約錢包本身，會通過打包器觸發入口合約來間接觸發，在鏈下驗證交易，然後在鏈上執行。
其次，打包器（Bundler），用於批量驗證和執行用戶操作（UserOperation，即EIP 4337定義的智能合約錢包的交易類型）。
第三，入口合約（Entry Point Contract）是在以太坊隻存在一份的全局合約，用於標準化交易執行並防止打包器受到惡意交易的DoS攻擊。
第四，代付合約（Paymaster），用於代表錢包用戶處理gas支付。
第五，合約工廠（Wallet Factory），用於標準化錢包創建的參數和流程。
第六，簽名聚合器（Signature Aggregator），用於將多個交易的簽名聚合為字節，以便更快地驗證和執行交易。
下麵我將詳細介紹用戶操作（UserOperation）和上述的六個合約接口，是對官方EIP 4337文檔和David Philipson@Alchemy賬戶抽象係列的解讀。
1. 賬戶操作（UserOperation）
UserOperation本質上和普通交易相同，隻是基於EIP 4337的合約接口定義了額外的參數。這裡回顧一下，一個EOA觸發的普通以太坊交易有交易目標地址、轉賬以太坊數量、gas數量和gas價格等參數。
此外，考慮到EIP 4337合約接口的模塊化設計，UserOperation包括以下主要參數用於定義接口的觸發：
- calldata：定義要在智能合約錢包上調用的函數簽名（function signature）和輸入參數，calldata在普通交易中也有
- signature：驗證交易確實來自某智能合約錢包地址，signature在普通交易中也有
- nonce：防止重放攻擊，在普通交易中也有
- sender：指定執行UserOperation的智能合約錢包地址
- paymasterAndData：用於交易手續費抽象（gas abstraction），包含代付合約（Paymaster）地址和gas支付的具體參數
- initCode：用於錢包創建，包含錢包工廠（Wallet Factory）合約地址和創建智能合約錢包的參數，如錢包的合約代碼
除了需要額外的參數以外，UserOperation的工作流程與普通交易類似：它們都被廣播到mempool中進行驗證、執行並最終完成出塊。UserOperation的驗證和執行由打包器（Bundlers）觸發，我將在下文中解釋。
圖：官方EIP 4337文檔對UserOperation參數的定義
2. 打包器（Bundler）
Bundler是一個外部賬戶（EOA），代表用戶在智能合約錢包上驗證和執行UserOperation交易，因為在以太坊上，所有交易都必須由EOA觸發。Bundler使用戶不用創建和記憶EOA的私鑰就可以觸發智能合約錢包交易，這也是智能合約錢包存在的初衷。
雖然Bundler具有很強的公共物品（public goods）屬性，他們也可以獲得經濟上的利益，因為：
- Bundler可以在執行UserOperation後將最大優先gas費（maximum priority fee）與實際gas花費之間的差額收入囊中
- 與普通交易的中繼器（Relayer）類似，Bundler可以通過排序捆綁交易（bundle）中的UserOperation來獲取MEV
儘管用戶付出了成本，但Bundlers對於節省gas是有好處的，因為每執行一筆交易都需要21,000 gas的固定成本，而執行捆綁交易可以把一筆交易的固定成本分攤給捆綁交易裡的多UserOperation，從而節省gas成本。此外，在同一筆交易中多次修改storage，每次額外操作的gas費都會邊際遞減。
需要注意的是，儘管以太坊上的交易是線性執行（非並行）以避免狀態衝突（state conflict），多個UserOperations可以放在一個捆綁交易裡執行，因為Bundlers可以設置同一智能合約錢包地址最多包含一個UserOperation，這樣捆綁交易在修改狀態時不會相互衝突。
除了這些差異之外，Bundlers與區塊構建者（Block Builder）類似，因為它們都將經過驗證的UserOperation廣播到公共或私有的mempool中。接下來，我們將介紹入口點合約（Entry Point Contract），Bundler需要與之交互來執行UserOperation。
3. 入口點合約（Entry Point Contract）
入口點合約是一個全局單例（global singleton）合約，所有Bundlers都需要調用它來執行UserOperation。它充當了Bundler與智能合約錢包之間的中間人：
- 一方麵，Bundlers調用入口點合約的handleOp函數，該函數接受一個UserOperation作為輸入參數。handleOp負責根據UserOperation的calldata驗證並執行智能合約錢包的函數
- handleOp首先在鏈上驗證UserOperation，檢查它是否由指定的智能合約錢包地址簽名，以及錢包是否擁有足夠的gas來補償Bundler
- 如果驗證成功，handleOp將根據UserOperation的calldata中定義的函數簽名和輸入參數執行智能合約錢包函數
- 另一方麵，智能合約錢包需要向入口點合約存入代幣用於支付gas費用給Bundlers。當Bundler使用EOA觸發handleOp函數時，會產生gas費用。
- 除此之外，智能合約錢包也可以用自己的賬戶餘額支付gas費用給Bundler，也可以請求代付合約（Paymaster）代為支付，我們稍後會詳細解釋
- 冇有足夠gas的UserOperation在目標智能合約錢包中無法通過驗證步驟，因此在執行之前就會失敗
- 即使有足夠的gas，UserOperation在執行步驟中仍可能失敗，例如runtime error
- 無論執行是否成功，入口點合約都將支付gas費用給Bundler觸發handleOp函數
- 入口點合約提供了智能合約錢包添加或提取代幣抵押的函數
圖：官方EIP 4337文檔中的入口點合約工作流程
4. 智能合約錢包主合約
智能合約錢包主合約將UserOperation的驗證和執行步驟分開：
- 驗證步驟在validateOp函數中定義。此函數會被調用兩次：第一次是Bundler在鏈下模擬驗證，驗簽UserOperation中的簽名，並確保智能合約錢包有足夠的gas餘額；第二次是入口點合約在執行UserOperation之前進行鏈上驗證
- 執行步驟在UserOperation的calldata中定義，用於指定智能合約錢包函數的簽名和輸入參數
通過分離UserOperation的驗證和執行，Bundler可以在鏈下驗證UserOperation，從而不需支付gas就可以過濾掉惡意交易。 因此validateOp函數也起到了鏈下debug API的作用。
5. 代付合約（Paymaster）
代付合約（Paymaster）定義了智能合約錢包的gas抽象的邏輯。Gas抽象的形式包括用ERC20同質化代幣支付以太坊gas和無需gas的交易，兩者都可以由Paymaster來實現。ERC-4337的模塊化設計允許UserOperation通過paymasterAndData參數指定任意的Paymaster地址和輸入參數。Paymaster具有以下功能和要求：
- 本質上，Paymaster是由dApp部署的智能合約，可以通過Bundler觸發Paymaster的validatePaymasterOp函數以任意邏輯有選擇性地為合約指定的UserOperation支付gas
- Paymaster需要在入口點合約上存入以太坊用於支付UserOperation的gas
- 除了存入gas外，Paymaster還需要在入口點合約上額外質押以太坊。這個質押不會被slash，但可以防止機器人惡意批量創建Paymaster
Paymaster（至少在官方的願景中）是一個充滿競爭的開放市場。雖然官方冇有定義Paymaster的鏈上信譽係統，Bundlers可以在鏈下記錄Paymaster的服務質量並停止使用質量較低的Paymaster，從而激勵Paymaster為UserOperation提供可靠的服務。
Paymaster接口定義了兩個函數：
- validatePaymasterOp：定義gas抽象邏輯。例如，在一個智能合約錢包以ERC20代幣支付gas的場景中，此函數將確保錢包具有足夠的餘額。validatePaymasterOp在執行UserOperation之前被調用，符合將驗證步驟和執行步驟分開的設計邏輯
- postOp：在智能合約錢包執行某一函數的最後一步被調用。如果錢包冇有足夠的ERC20餘額來支付gas費給Paymaster，postOp會取消函數執行。即使在此步驟中函數執行因為runtime error失敗，gas仍然會被扣除。
圖：官方EIP 4337文檔中的Paymaster工作流程
圖：官方EIP 4337文檔中的Paymaster接口
6. 錢包工廠（Wallet Factory）
Wallet Factory是一個創建智能合約錢包的合約。 回顧一下，UserOperation有一個可選的initCode字段。當initCode為空時，UserOperation隻是觸發智能合約錢包的功能。當initCode填充了Wallet Factory地址和新智能合約錢包的參數時，Bundler將觸發相應的Wallet Factory使用指定參數創建智能合約。
Wallet Factory在以下方麵有助於實現賬戶抽象：
- 用戶可以通過提交填充了initCode的UserOperation來請求Bundler創建智能合約錢包，而無需擁有EOA來自行創建
- 用戶可以通過選擇具有特定定製選項的Wallet Factory並傳入自己的參數來定製智能合約錢包。此外，因為Wallet Factory合約是公開的，而且受歡迎的Wallet Factory會經過全麵的代碼審計，所以使用Wallet Factory創建新錢包對用戶更安全
- 用戶可以選擇讓Paymaster代付創建錢包的gas或者用任意ERC20代幣支付gas，無需擁有以太坊。此外，Paymaster可以選擇隻為其信賴的Wallet Factory部署的智能合約錢包支付gas
- 用戶可以在創建錢包之前通過調用CREATE2函數獲取他們的智能合約錢包地址。該函數使用觸發智能合約錢包創建的EOA地址、一個salt和initCode確定性地生成智能合約地址。用戶在創建錢包時不需要支付gas，隻需要在用錢包進行第一筆交易時同時支付創建錢包和交易的gas，從而提高用戶體驗。
Wallet Factory還有其他職責。與Paymaster類似，它們需要在入口點合約上抵押ETH並持續性地為UserOperations提供良好的服務，以便從Bundler那裡獲得更多流量。
7. 簽名聚合器（Signature Aggregator）
因為不同的智能合約錢包使用不同的簽名算法，所以需要先將使用相同簽名算法的UserOperations聚合起來，然後分彆進行驗證。此外，由於鏈上密碼學計算會消耗大量gas，支持聚合的簽名方案（如BLS）可以在鏈上驗證過程中節省gas。因此我們需要一個名為簽名聚合器（Signature Aggregator）的EIP 4337智能合約接口。它可以通過實現以下兩個函數來支持特定的簽名算法：
- aggregateSignatures：輸入參數為一個UserOperations數組，並使用特定的簽名算法輸出一個聚合簽名
- validateSignatures：輸入參數為一個UserOperations數組和一個聚合簽名，用於對數組裡的所有UserOperation進行驗簽
與其一次驗證一個UserOperation，Bundler首先會使用多個簽名聚合器合約（每個簽名算法使用一個）生成多個聚合簽名（每個簽名算法生成一個）。之後，Bundler將UserOperation數組、聚合簽名和聚合器地址傳遞給入口點合約，每個UserOperation數組會調用其對應的簽名聚合器的validateSignature函數。驗證通過後，Bundler就會在智能合約錢包上執行這組UserOperations。
與Paymaster和Wallet Factory類似，聚合器也需要在入口點合約上質押以太坊並保持為UserOperations提供良好服務的記錄。
圖：官方EIP 4337文檔中的簽名聚合器接口
8. 整體工作流程總結
EIP 4337的模塊化設計將智能合約錢包的賬戶抽象功能分為多個接口。這些接口的功能合在一起可以總結為如下的工作流程：
- 用戶向Bundler發送UserOperation
- 如果UserOperation填寫了initCode參數，Bundler會觸發Wallet Factory來創建有確定地址的新錢包
- 如果UserOperation填寫了paymasterAndData參數，Bundler會收取Paymaster在入口點合約上質押的以太坊來支付gas。如果冇有填寫paymasterAndData，Bundler會收取智能合約錢包在入口點合約上質押的以太坊來支付gas
- Bundler可以選擇性地使用簽名聚合器
- Bundler會使用validateOp、validatePaymasterOp和validateSignatures函數在鏈下模擬驗證UserOperation，確保簽名正確且UserOperation有足夠的gas
- 如果鏈下模擬驗證通過，Bundler將使用上述函數在鏈上驗證UserOperation
- 如果鏈上驗證通過，Bundler將在鏈上執行UserOperation，無論執行是否成功，都會扣除gas
圖：冇有簽名聚合器的賬戶抽象工作流程（Alchemy提供）
圖：帶簽名聚合器的賬戶抽象工作流程（Alchemy提供）
9. 其他注意事項
UserOperation在鏈下和鏈上都會觸發validateOp等函數進行交易驗證。為了防止智能錢包合約外部的狀態變化（state change）導致鏈下和鏈上的驗證結果不一致，EIP 4337禁止驗證函數使用讀取合約外部storage和讀取全局狀態（如時間戳）的OpCodes。這種禁止適用於validateOp、validatePaymasterOp和validateSignatures這些驗證函數。
第二部分：賬戶抽象市場參與者
1. 智能合約錢包及配套SDK
智能合約錢包是賬戶抽象市場中最大的參與者。為了與EIP 4337兼容，它們通常會實現自己的打包器（Bundler）、代付合約（Paymaster）、錢包工廠（Wallet Factory）和簽名聚合器（Signature Aggregator）。這些錢包還配備了方便dApp集成錢包的SDK。智能合約錢包市場比較擁擠，既有老牌大玩家如多簽錢包Gnosis Safe在原有產品基礎上實現賬戶抽象功能，也有市場新人如Candide專注於構建完全兼容EIP 4337的智能合約錢包。本節將介紹這些錢包的共同特點以及每個特點中的差異化。
a. 社交登錄（social login）和社交恢複（social recovery）
社交登錄為智能合約錢包提供了Web2用戶非常熟悉的交互體驗，例如使用已有的Google帳戶創建和登錄錢包。同樣的邏輯也可以延伸到社交恢複上，例如使用郵箱重置智能合約錢包的密碼。社交登錄和社交恢複的邏輯一般在錢包的主合約中定義。
這裡我們引入守護者（Guardian）的概念。守護者是指可以授權用戶訪問某賬戶或幫助用戶重製恢複某帳戶的實體。守護者可以是Web2賬號也可以是郵箱地址。這個概念在Web2中已經有了很廣泛的應用，現在也可以通過賬戶抽象的概念在智能合約錢包中實現。
一個智能合約錢包可以有多個守護者。用戶需要在創建錢包過程中或之後設置守護者，並達到一定的守護者驗證閾值，例如3個守護者中的2個，以登錄或恢複錢包。這個過程通常被稱為多因素認證（multi factor authentication）。以下是常見的智能合約錢包守護者類型：
- Web2服務提供商：例如錢包用戶的社交媒體帳戶，通常通過實施OAuth（Open Authorization，即開放授權）標準來實現。該標準允許錢包獲取用戶授權來訪問由另一個Web2應用托管的用戶賬號信息
- 用戶設備：例如瀏覽器存儲和移動端存儲
- 電子郵件：例如通過點擊可以發送簽名的電子郵件鏈接進行授權
- 多簽名：用戶可以設置多個個人擁有的EOA或智能合約錢包作為守護者
- MPC：用戶可以將私鑰分割成多個份額，每個份額由MPC網絡中的一個節點控製，且不會泄露完整的密鑰
- SWIE（sign in with Ethereum，即用以太坊登錄）
讓我們看看一些市場上玩家對此功能的實現：
- Web3Auth是許多高流量智能合約錢包使用的社交登錄和MPC服務，這些錢包包括Biconomy、Etherspot和0xPass。Web3Auth把用戶密鑰分割成多份給社交登錄、用戶設備和其MPC節點網絡等守護者。產品邏輯實現完全在鏈下，且冇有任何一個守護者會存儲完整的私鑰。（請參見下圖。）
- BLS Wallet和Argent使用多簽技術（multisig）通過用戶指定的多個EOA地址進行密鑰恢複。
- UniPass實現了一種創新的方法，通過電子郵件進行社交恢複。用戶在鏈上提交守護者的郵箱，並通過智能合約在鏈上驗證郵箱的DKIM簽名。DKIM（Domain Keys Identified Mail，即域名密鑰識彆郵件）是一種電子郵件身份驗證協議，用於創建數字簽名。郵箱供應商可以使用該數字簽名驗證郵件發送者的身份。UniPass還使用零知識證明對鏈上的用戶信息進行脫敏處理。UniPass也支持郵件之外的社交恢複方法。
- Soul Wallet在鏈上驗證守護者的郵箱地址以進行社交恢複。
圖：Web3Auth社交登錄和社交恢複，此案例中有三個守護者
b. Gas Abstraction（gas抽象，gas即交易手續費）
Gas abstraction包含無gas交易和使用任意ERC20代幣支付gas。這些邏輯可以在代付合約（Paymaster）中實現，也可以通過中繼器（Relayer）實現。
許多智能合約錢包自己實現了與EIP 4337兼容的Paymaster合約，並在入口點合約上質押代幣，幫助用戶支付gas。
Relayer是在EIP 4337之前就存在的另一個gas abstraction的解決方案。 Relayer是用戶信任的交易轉發者，執行一種稱為“元交易”（meta-transaction）的特殊類型的無gas交易。元交易是一種以太坊交易，它在原始交易中插入另一個交易。用戶使用私鑰對元交易進行簽名，並將其發送給Relayer，後者對其進行驗證，將其提交給區塊鏈，並代付gas。Relayer隻是執行交易，而不改變交易本身。 Relayer會獲取經濟上的利益，因為它們會向執行交易的合約收取gas費用加上一小筆利潤。例如，Relayer可以向支持無gas交易的去中心化應用（dApp）收費。Relayer可以是中心化的可信第三方，也可以是去中心化的網絡。Relayer與代付合約（Paymasters）的區彆在於以下幾點：
- 除了支付gas外，Relayer還會對交易進行簽名，類似於EIP 4337中的Bundler所做的事情
- Relayer不隻處理UserOperations類型的交易
- Relayer不在入口點合約上質押gas
讓我們看看一些市場上玩家對此功能的實現：
- Biconomy不僅自行實現了與EIP 4337兼容的Paymaster，還有一個支持任意ERC20代幣支付gas的Relayer網絡。
- Argent使用第三方Relayer以元交易的形式支付gas。
- Candide自行實現了Paymaster。
- UniPass使用自己的Relayer節點支付gas，計劃在未來添加“觀看廣告免gas交易”模式並支持使用跨鏈橋（bridge）支付gas。
到目前為止，大多數ERC20支付gas的解決方案（如Candide和Soul Wallet）僅支持非常有限的代幣類型，主要是穩定幣，儘管我預見這在未來會發生變化。
圖：Biconomy 使用Paymaster支持無gas交易（基於EIP 4337的技術實現）
圖：Biconomy 通過Relayer使用任意ERC20支付gas（並非基於EIP 4337的技術實現）
c. 法幣出入金通道（ramps）和跨鏈橋（bridges）
許多現有的錢包，如MetaMask，已經通過和第三方供應商合作的方式把法幣出入金通道和跨鏈橋集合在錢包中。這些出入金通道和跨鏈橋可以進一步與gas abstraction中的代付合約（Paymaster）進行集合。
讓我們看看一些市場上玩家對此功能的實現：
- Biconomy和0xPass與Transak合作提供法幣通道。Biconomy還提供跨鏈橋和跨鏈通信服務。
- Argent Vault與Moonpay、Transak和Wyre合作提供法幣通道，並具有內置的DeFi協議聚合器。
- Etherspot、UniPass和Braavos支持法幣通道、swap和跨鏈橋。
d. 交易批處理（transaction batching）
交易批處理是智能合約錢包獨有的功能，允許錢包用戶在一個鏈上交易中執行多個交易。一種實現方法是調用一個multiCall函數，它接受兩個參數：一個calldata數組（每個calldata定義一個函數調用）和一個合約地址數組（每個函數調用的合約地址）。multiCall函數中有一個循環（loop）並在每次循環裡執行一個函數調用。交易批處理可以使多個交易分攤一個以太坊交易的固定gas費，從而減少成本。
請注意，交易批處理不同於簽名聚合（signature aggregation），後者接受一個UserOperations數組作為輸入參數並輸出一個聚合簽名字節以加快多個簽名驗證的速度。而這個數組中的每個UserOperation都可以調用一個multiCall來執行交易批處理。
在EIP 4337中實現交易批處理的方式如下：入口點合約調用handleOp函數，然後該函數再調用智能合約錢包主合約內定義的multiCall函數。
讓我們看看一些市場上玩家對此功能的實現：
- Biconomy設置了一個MultiCall合約，智能合約錢包可以調用這個合約來批量執行交易。
- Argent通過名為Transaction Manager的智能合約模塊來批量執行交易，該模塊支持multiCall和用戶會話密鑰（session key）。
- Etherspot、Candide、Openfort和0xpass都支持交易批處理。
圖：示例 MultiCall 合約（Solidity by Example提供）
e. 智能合約錢包的模塊化設計（modular design）
智能合約錢包相對於EOA的一個主要優勢是其模塊化設計。錢包的功能可以通過錢包提供商開發的合約模塊進行擴展。這些模塊提供了EIP 4337接口中未定義的功能，並可以由用戶自定義。模塊化設計下，智能合約錢包是可升級的。這種做法在EIP 4337發布之前就已經是行業標準，由諸如Gnosis Safe之類的產品率先推出。Gnosis Safe是一款主要針對商業用戶的多簽名錢包，提供一係列EIP 4337冇有定義的功能：
- 支出限製：限製有簽名權限的帳戶可以從錢包中提取的金額。
- 定期打款：根據自定義時間自動打款。
- 角色和授權：為錢包不同的交易和行為定義所需的角色和授權。
- 組織權限：基於組織內不同角色的權限設置。
- 白名單和黑名單
同樣的模塊化設計也被EIP 4337兼容的錢包繼承，包括Argent、Candide、Soul Wallet和zeroDev。
另一種擴展智能合約錢包功能的方法是在錢包裡原生地集成去中心化應用（dApps）。例如，Gnosis Safe為dApps提供了一個SDK。使用此SDK的dApp可以直接出現在錢包界麵中，等同於為錢包提供了一個內置的應用商店。其他類似解決方案包括WalletConnect。然而，這些前端解決方案並不是協議層的設計，因此超出了本文討論的範圍。
圖：Candide錢包的模塊化設計與Safe（即Gnosis Safe）類似（Candide錢包官網提供）
2. 基礎設施提供商
下麵將討論各種Layer 2對賬戶抽象的支持以及打包器（Bundlers）和代付合約（Paymasters）的第三方基礎設施提供商。
a. Layer 2上的賬戶抽象
鑒於最近L2的爆炸式增長，許多智能合約錢包已將開發重點轉向L2。許多L2都原生地支持與EIP 4337非常相似的賬戶抽象合約標準，本節將對此進行探討。
Optimism
Optimism的第一版通過引入三個EVM不支持的OVM OpCodes來實現賬戶抽象。在Optimism的技術實現中，智能合約是唯一的賬戶類型（不存在EOAs），因此所有用戶錢包都是智能合約錢包。智能合約錢包還可以通過調用upgrade函數升級合約代碼。
不幸的是，為了與EVM保持完全一致和出於安全方麵的考慮，Optimism的第二版移除了這三個OVM Opcodes和對賬戶抽象的支持。
雖然目前有少數智能合約錢包正在Optimism上構建，但是尚無關於支持賬戶抽象的官方聲明。
Arbitrum
雖然目前有少數智能合約錢包正在Arbitrum上構建，但是尚無關於支持賬戶抽象的官方聲明。
Starknet
與以太坊不同，Starknet不區分EOA和合約賬戶。因此，所有Starknet賬戶都是智能合約賬戶。Starknet的賬戶模型受到EIP 4337的很大影響，具體表現在以下方麵：
- 所有Starknet智能合約賬戶都必須包含validate和execution函數。validate是必需的函數，通過驗證簽名確保隻有賬戶所有者才能發起交易，同時保證交易執行者可以獲得足夠的gas費。用戶可以在validate和execute函數中實現任意邏輯，從而靈活擴展賬戶的各種功能。例如，用戶可以在validate函數中實現不同的驗簽算法。
- 為了防止交易通過驗證但無法執行，Starknet禁止validate函數調用外部合約的狀態（state）。
Starknet對賬戶抽象的實現和以太坊相比依舊存在顯著的差異：
- Starknet不區分常規交易和UserOperations，因為所有交易都是由合約賬戶觸發的。在以太坊中，Bundlers執行UserOperation交易，而在Starknet中，序列器（Sequencer）執行所有交易。
- Starknet尚未實現類似Paymaster的交易手續費抽象協議。
- Starknet要求有代幣餘額的賬戶通過調用一個專門的deploy_account函數來創建新的合約賬戶。而在EIP 4337中，Bundler通過執行initCode參數不為空的UserOperation交易來部署合約賬戶，部署過程不必須有代幣餘額的賬戶，因為gas費可以由Paymaster代付。
- 如果通過驗證的交易在執行步驟失敗，Starknet的序列器將無法抽取任何gas費，而以太坊冇有這個問題。
圖：Starknet冇有EOA賬戶類型，隻有合約賬戶（Starknet官網提供）
zkSync
zkSync也不區分EOA和合約賬戶，因此原生地支持賬戶抽象。zkSync的賬戶模型與EIP 4337十分類似，具體表現在以下方麵：
- 賬戶（智能合約錢包）接口也將validateTransaction和executeTransaction函數分開。
- 代付合約（Paymaster）接口也包括validateAndPayForPaymasterTransaction和postOp函數。前者定義了Paymaster代付交易的邏輯。後者可以確保在交易執行後，Paymaster能夠抽取gas費補償，儘管這部分功能尚未實現。
- 用戶也通過填寫交易中的paymaster地址和paymasterInput兩個參數來調用Paymaster，類似於EIP 4337中的UserOperation。
然而，zkSync實現的賬戶抽象和以太坊也存在顯著差異：
- zkSync允許validateTransaction函數調用已部署的外部合約，因為已部署的合約在zkSync中是不可更改的（immutable）。 以太坊禁止驗證函數調用外部合約，以防止狀態更改（state change）造成交易驗證通過而交易執行失敗。
- zkSync允許validateTransaction調用發出此交易合約賬戶的外部存儲，例如合約賬戶在外部合約上的代幣餘額，理由同上。
- 在交易驗證期間，Paymaster可以調用外部存儲，理由同上。
b. 第三方基礎設施提供商（非智能合約錢包）
如上所述，賬戶抽象基礎設施包括可以發送UserOperations的客戶端SDK、打包器（Bundlers）、代付合約（Paymasters）和簽名聚合器（Signature Aggregator）。這些基礎設施通常由智能合約錢包自身實現，從而更好地整合產業上下遊，但是大多數都不是為第三方使用而設計的。因此市場上需要第三方基礎設施提供商來提供模塊化和可定製的Bundler和Paymaster服務。一些知名的基礎設施玩家比如Alchemy也進入了這個市場。本節會深入探討這些第三方基礎設施提供商。
Stackup
Stackup是一個Bundler和Paymaster的提供商。其Bundler采用Go語言實現，通過了所有EIP 4377測試套件的要求，完全開源且免費使用。Stackup Bundler支持不同的模式：
- 私有模式（private mode）：UserOperations進入一個私有內存池（mempool），以更慢的交易執行速度換取更好的隱私。UserOperation不會顯示在公共內存池中，從而避免了MEV攻擊。
- 搜索模式（searcher mode）：由以太坊生態的機器人運營者（即bot operator，也稱為searcher，例如DeFi套利機器人）使用，並與諸如Flashbot之類的區塊構建者（block builder）集成，通過MEV-Boost發送UserOperations，允許searcher為特定的交易排序出價，以供block builder選取MEV最大的交易排序構建區塊。
Stackup還支持兩種類型的Paymaster：
- Verification Paymaster：提供需要鏈下交易（如法幣出入金）的gas抽象。例如，用戶可以選擇使用信用卡訂閱Paymaster服務來支付gas費。用戶也可以定製gas代付的邏輯。Stackup將通過“按需付費”（pay as you go）模式向用戶收費。
- Deposit Paymaster：允許用戶用ERC20代幣支付gas費。
圖：Stackup的基礎設施產品套件
Blocknative
Blocknative主要是一個內存池瀏覽器和可視化工具提供商。得益於其對於內存池較強的理解，Blocknative提供了具有獨特功能的打包器（Bundler）服務，例如：
- 使用EIP 4337交易瀏覽器（EIP 4337 UserOps Explorer）可視化內存池中UserOperations的狀態，方便錢包和dApp實時監控交易的狀態
- Blocknative的核心產品內存池瀏覽器也可以監聽入口點合約中待處理和已確認的Bundler交易
Alchemy
Alchemy目前正在開發其Bundler和Paymaster服務，潛在用戶可以加入waitlist。
圖：Alchemy的EIP 4337基礎設施服務還在開發中
eth-infinitism
eth-infinitism是以太坊基金會的官方團隊，目前已經實現了EIP 4337標準定義的Bundler和Paymaster。關於該團隊的文檔很少，但是根據Stackup的一篇文章，截至2023年2月，eth-infinitism是通過EIP 4337官方測試套件的唯一兩個Bundler之一（另一個是Stackup）。
第三部分：賬戶抽象的未來之路
1. 歸根結底，賬戶抽象市場的生死存亡取決於生態對EIP 4337的采用，而這個市場還非常早期
根據Web3Caff Research最近的一篇研報，以太坊中所有交易的發起地址（from參數）去重後的總數約為1.5億。然而，智能合約錢包的總數，以Gnosis Safe和Argent賬戶的總和來估算（這兩個產品的用戶最多），僅為15萬。
假設在終局，EOA和智能合約錢包的數量相等，我們可以預測智能合約錢包的市場規模有1000倍的潛力。 儘管如此，生態對智能合約錢包的采用並不會一帆風順。像MetaMask這樣的EOA錢包巨頭仍未宣布采用EIP 4337的計劃。儘管我們不知道他們的意圖，但也不難推斷，主流EOA錢包的巨大利潤並不足以支持其團隊內部采用一個基礎設施都不完善的新標準。UserOperation仍然不是dApps廣泛使用的主流交易類型。雖然如此，我依舊對智能合約錢包市場保持樂觀態度，也可以預見到智能合約錢包對用戶體驗的大幅改善會為賬戶抽象市場帶來的指數級的增長，儘管這種爆發可能還需要一兩年才發生。
2. EIP 4337尚未完成，同誌仍需努力
儘管EIP 4337定義了諸如打包器（Bundler）、代付合約（Paymaster）和簽名聚合器（Signature Aggregator）等基礎設施的合約接口，以太坊官方並冇有給出很多重要技術問題的解決方案，而這些問題需要項目方反複嘗試不同的技術實現，比如：
- 目前Bundler主要在私有內存池（private mempool）廣播交易，UserOperation被直接發送給指定的區塊構建者（block builder）。Bundler網絡是否有可能使用公共內存池（public mempool）？
- Bundler能否通過對UserOperations進行排序來抽取MEV？區塊構建者能否通過對捆綁交易（bundle）進行排序來抽取MEV？MEV將如何在Bundler和區塊構建者之間分配？我們是否應該將Bundler和區塊構建者分開？
- 考慮到Bundler需要完成大量的鏈下模擬和鏈上驗證，它們能否同時作為可靠的區塊構建者？
- UserOperation的內存池和常規交易的內存池應該如何協調以避免狀態衝突？
3. L2采用EIP 4337的速度各異
儘管zkSync和Starknet已經原生地支持賬戶抽象，但它們仍未實現所有的EIP 4337接口，並且在技術實現上與以太坊存在差異。儘管許多項目團隊正在為Optimism和Arbitrum構建智能合約錢包、打包器（Bundlers）和代付合約（Paymasters），但這些L2尚未宣布官方支持EIP 4337的計劃，賬戶抽象也並非他們的開發重點。
從純技術的角度來看，L2賬戶抽象基礎設施的實現比L1更為複雜。例如，在驗證步驟中，一個L2智能合約錢包需要同時估算L1和L2的gas費，並分攤給捆綁交易（bundle）裡的每個UserOperation。
4. 拋開技術細節，一個優秀的智能合約錢包需要有哪些特點？
儘管錢包市場上有許多創新的功能（如gas抽象、社交恢複、MPC等），大多數智能合約錢包都支持所有上述功能，因為這些功能的技術實現並不困難。因此，智能合約錢包的商業層麵與用戶體驗層麵同樣重要。重要的商業因素包括：
- 與dApps合作：與每個L1或L2鏈的流量入口級dApps合作，尤其是基礎設施類的dApps（如穩定幣或DeFi協議），是吸引用戶的主要途徑
- 實用功能：如錢包內部集成的NFT市場、launchpad或快速集合新的交易對
- 外部支持：如來自VC或以太坊基金會的官方支持，這些支持可以幫助錢包找到第一批用戶
5. 一個優秀的打包器（Bundler）需要有哪些特點？
無需許可（permissionless）且模塊化（modular）的Bundler服務是一種公共物品（public good）。絕大多數Bundler的開源性質決定它們是非排他性和非競爭性的。任何RPC端點都可以通過複製開源代碼來運行一個Bundler。即使運行Bundler的RPC端點通過API密鑰來收取服務使用費，Bundler服務也比其他基礎設施（如代付合約Paymaster）更難盈利，因為後者可以通過與第三方出入金或DeFi協議聚合器提供商合作輕鬆賺取費用差價。雖然更難商業化，但是Bundler是一種重要的公共物品，因為UserOperation的驗證和執行需要儘可能多的Bundler參與從而更好地去中心化。因為Stackup和eth-infinitism是目前唯二可用的第三方Bundler服務提供商，所以我們肯定需要更多這樣的Bundler服務提供商。
Bundler服務提供商需要克服許多技術難點：
- 對鏈下和鏈上的多個驗證步驟進行深入研究，從而確保UserOperation可以成功執行。技術難點包括理解多個UserOperations之間可能出現的狀態衝突（state conflict）。
- 理解驗證函數對某些OpCode的禁用：
- 由於讀取可變的外部狀態（external state）可能導致交易驗證成功但執行失敗，因此EIP 4337禁止驗證函數調用讀取外部狀態的OpCodes。
- 不同的L2對讀取外部狀態的OpCode有略微不同的禁用，會對多鏈開發造成挑戰。
- 正在構建Bundler的項目方需要通過traceCall函數來獲取每個函數調用的OpCodes。然而，大多數第三方RPC節點都不支持traceCall，因此Bundler項目方可能需要運行自己的節點，這也存在技術壁壘。
- 目前大多數Bundler項目方的開發重點都在L2，需要分彆計算L1和L2的gas費。
- 實現私有和公共內存池的P2P network。私有內存池需要為searcher和dApps提供定製化的服務，例如白名單。公共UserOperation內存池的行業標準尚未完成。
Bundler服務提供商的差異化在於：
- Bundler服務是專為錢包構建的，還是第三方基礎設施提供商構建的？
- Bundler隻是錢包項目方需要構建的眾多事物之一，因此他們更可能專注於為錢包構建一個最基礎的可用的Bundler。
- 第三方基礎設施提供商需要構建無需許可和模塊化的Bundler，並為不同的場景提供優質的服務。
- 類似於以太坊節點，Bundler服務采用不同的語言實現。這種語言多樣性可以防止單點故障，對以太坊生態有益。
- 對私有和公共內存池的支持以及對私有內存池進行定製的選項。
- 對L1和不同L2鏈的支持，每個鏈在接口實現上略有不同。
6. 讓我們聊聊創新
本節將列舉智能合約錢包和賬戶抽象基礎設施中最需要的創新。
無需許可和模塊化的EIP 4337基礎設施
讓我們首先設想一下EIP 4337基礎設施的終局：
- 許多打包器（Bundler）、代付合約（Paymaster）和簽名聚合器（Signature Aggregator）提供商會在一個開放市場上競爭。用戶可以用最低費用獲取高質量服務
- 市場上既存在無需許可的Bundler、Paymaster和Signature Aggregator公共端點，也存在專門為某個智能合約錢包或dApp部署的端點
- 智能合約錢包、dApp和個人用戶可以以無需許可（permissionless）、模塊化（modular）和用戶友好的方式部署上述的基礎設施。換句話說，第三方基礎設施提供商允許從任意地址快速且可定製地部署Bundler、Paymaster和Signature Aggregator
在當前市場狀態下，許多智能合約錢包已經構建了自己的基礎設施，但是這些基礎設施並未針對第三方的不同使用場景。諸如Stackup之類的第三方基礎設施提供商正在開發模塊化的Bundler和Paymaster，但是它們的部署過程仍然遠未達到無需許可。因為EIP 4337尚未完成，這些基礎設施的模塊化功能還冇有被全部定義。此外，由於UserOperation交易量依舊較低，啟用了簽名聚合的錢包（如BLS Wallet）仍然不是主流。
EIP 4337下遊基礎設施
這些包括EIP 4337未定義但實現EIP 4337基礎設施所需的下遊基建，比如可以集成到Paymaster的法幣出入金聚合器和DeFi聚合器。因為這些解決方案已經存在，所以創新最有可能在現有提供商內部發生，提供商隻需重新配置它們公開的接口。
dApp SDK和腳手架
儘管現有的智能合約錢包都為了方便dApp集成而構建了自己的客戶端SDK，但市場仍然缺少：
- 支持賬戶抽象功能的類似於ether.js的dApp開發標準庫，比如對如下功能的封裝：
- 使用Web2社交媒體賬戶和電子郵件創建錢包和恢複錢包地址
- UserOperations的創建、簽名、發送以及的事件監聽
- 快速部署Paymaster和Signature Aggregator
- 聚合所有主要智能合約錢包的SDK和UI工具
- 用於快速前端部署的腳手架工具，以便dApp開發人員可以專注於他們產品的業務邏輯
- 由賬戶抽象賦能的新型dApp的模板，例如支持gas抽象的遊戲
更激進的做法：將賬戶從智能合約錢包分離
EIP 4337的智能合約錢包接口隻需要一個validateOp函數，將所有的核心業務邏輯，如用戶注冊、權限控製和社交恢複等，留給錢包開發者自由決定。雖然這提供了更多的靈活性，但不同的智能合約錢包會更加割裂以太坊生態，因為一個錢包中的數據不能輕易地轉移到另一個錢包。dApp也可能通過支持某些智能合約錢包而不支持其他錢包加劇這種分裂。
此外，儘管用戶可以通過郵箱或其他在Web2常見的流程登錄智能合約錢包，他們仍需要通過“連接錢包”這類Web2用戶不熟悉的操作流程來登錄dApp。
解決這些問題的一個激進方案是通過創建新的賬戶標準，將賬戶與智能合約錢包分離，例如Hexlink倡導的EIP 6662。EIP 6662定義了一個IAccountMetadata的賬號接口，使用戶可以自定義自己賬號的認證方法（如Web2社交媒體賬號），從而將認證邏輯從錢包主合約轉移到單獨的賬戶接口。支持此接口的智能合約錢包可以允許用戶將其賬戶數據轉移到另一個錢包。支持此接口的dApp可以允許用戶使用賬戶接口中定義的Web2認證方法登錄他們的Web3賬戶。dApp可以驗證來自Web2認證方法的簽名，以此查詢Web3賬戶地址，向Web2賬戶推送通知，並連接到Web3賬戶。用戶不需要為不同的dApp創建其支持的不同的錢包。相反，dApp會自動連接到與用戶Web2認證方式關聯的Web3賬戶。用戶賬戶和錢包不再是一體也不再受製於錢包，錢包本質上成為了用戶可以登錄賬戶來進行資產管理的dApp。
結論
- EIP 4337將智能合約錢包及其相關基礎設施標準化為六個合約接口：智能合約錢包主合約、打包器（Bundler）、入口點合約（Entry Point Contract）、代付合約（Paymaster）、錢包工廠（Wallet Factory）和簽名聚合器（Signature Aggregator）。UserOperation是EIP 4337支持的新交易類型。
- 賬戶抽象市場有兩類參與者：
- 具有社交登錄、社交恢複、gas抽象、交易批處理，以及集成和聚合第三方服務（如法幣出入金和DeFi協議）等功能的智能合約錢包。
- 基礎設施（如Bundler或Paymaster）的第三方提供商，專注於模塊化設計。
- 我對賬戶抽象市場有如下預測：
- 智能合約錢包市場競爭激烈，因為競品的功能類似，技術壁壘也較低。
- Bundler是一種盈利較難但是生態十分需要的公共物品。
- 賬戶抽象仍然是一個非常早期的市場，因為采用率仍然很低，EIP 4337尚未完成，許多L2尚未實現對賬戶抽象的支持。
- 賬戶抽象市場需要許多創新，如：無需許可的模塊化基礎設施、與現有法幣和DeFi服務的集成、dApp SDK以及潛在的獨立帳戶層。
鳴謝與免責
在撰寫本文時向幾位行業專家和朋友進行了請教交流，特彆在此感謝陳劍Jason、PlanckerDAO的王奕翔Aaron、獨立研究員菠菜菠菜、Hexlink團隊、AntAlpha Ventures的Circle Fang、Skyhigh等各位的交流探討！
因本人認知有限，調研時間有限，可能會出現錯誤和疏忽。如有不同意見，歡迎交流指正，非常感謝！研究為個人興趣，與文章裡提到的所有項目都不存在經濟利益關係，但也不作為投資建議。
參考文獻
https://ethereum.org/en/roadmap/account-abstraction/
https://eips.ethereum.org/EIPS/eip-4337
https://antalphaventures.notion.site/2edc5e36f69a44fe9a27dad0ef6ac3fb?v=a0fad60e889a4b2f831a2349d92ca11b
https://www.stackup.sh/blog/a-guide-to-the-top-erc-4337-bundlers-features-performance-and-more
https://github.com/PaymagicXYZ/awesome-account-abstraction
https://camiinthisthang.substack.com/p/account-abstraction-for-everyone
https://research.web3caff.com/zh/archives/4660
https://research.web3caff.com/zh/archives/3212
https://www.alchemy.com/blog/account-abstraction
https://www.alchemy.com/blog/account-abstraction-paymasters
https://www.alchemy.com/blog/account-abstraction-wallet-creation
https://www.alchemy.com/blog/account-abstraction-aggregate-signatures
https://docs.starknet.io/documentation/architecture_and_concepts/Account_Abstraction/approach/
https://era.zksync.io/docs/dev/developer-guides/aa.html#example-of-using-the-library
https://www.alchemy.com/account-abstraction
https://docs.zerodev.app/
https://eips.ethereum.org/EIPS/eip-4361
https://beta-docs.0xpass.io/
https://braavos.notion.site/Public-Docs-d98f625edb2e4399acab2e30d060ef8e
https://github.com/proofofsoulprotocol/soul-wallet-contract
https://docs.wallet.unipass.id/introduction/intro
https://docs.blocknative.com/4337-tools/blocknative-bundler
https://docs.candidewallet.com/develop/getting-started
https://docs.stackup.sh/docs/packages/bundler/introduction
https://github.com/web3well/bls-wallet
https://docs.etherspot.dev/
https://biconomy.gitbook.io/sdk/introduction/overview
