從抽象帳戶到 ERC4337
從使用者角度，看 ERC4337 對合約錢包帶來的變化
特別感謝 Cyan Ho, NIC Lin, ChiHaoLu, Chang-Wu Chen 幫忙 review！
前言
抽象帳戶 (Account Abstraction)，俗稱 AA 錢包，可能是以太坊想要解決的大問題中，最古老的問題之一了。有在追蹤台北以太坊期刊的各位，對於抽象帳戶的概念或許已經滾瓜爛熟，其中一定聽過大名鼎鼎、由 V 神主導提案的 ERC4337。
但我個人認為，大部分關於 ERC4337 的介紹對於一般大眾並不是很好理解，因為一般人並不了解「以太坊中帳戶的定義」，我們在意的只有錢包以及交易流程而已，因此容易混淆 ERC4337 與「用戶體驗問題」之間的相互關係，這在我自己理解的過程中這成為很大的障礙。
因此希望能透過這篇文章，以一般使用者的角度，著墨於 ERC4337 的定位，讓大家以一個錢包使用者的角度，理解這個提案的核心理念、到底規範了什麼、理由為何。最後面也補充了現在有什麼現有的工具已經被實作出來，還有最後我對於整個未來走勢的想法。
如果是對於提案的前因後果十分熟悉，想要直接理解細節的人，推薦直接跳轉到 ChiHaoLu 之前寫過的幾篇介紹，不過也是可以看一下我最後的一些進度更新跟想法啦～
本文將包括以下幾個章節：
- 抽象帳戶 (Account Abstraction) 的各種定義
- ERC 4337 的定位與格局
- ERC 4337 的細節介紹
- 現有專案與進度
- 我的整體感想：問題以及突破方向
正文開始前，先分享一個冷知識：有些人會把 ERC 跟 EIP 當成兩個可以互換的詞，但實際上常常會因為不同的上下文而變換語意。
廣義上來說，所有公開發佈在 EIPs (Ethereum Improvement Proposal) 裏面的提案，都可以拿到一個 EIP 編號，因此任何提案能稱為「EIP」都沒有問題。不過細看會發現每個提案其實都有類別這欄，則再細分為以下4種：Core, Networking, Interface, ERC。其中 Core 指的就是會動到共識層的更新。例如加入新的 OPCode, EIP1559 手續費調整、The Merge 等等，這些提議必須要所有的客戶端同意後，一起安排進入硬分叉的升級。在許多情境下，大家也只會把這類別的提案稱為 EIP。
而 ERC (Ethereum Request for Comment) 則是一些在應用程式層的標準與規範，例如新的 Token 介面、新的 Proxy Pattern。這些提議不需要改動共識層，只要大家共同協商出一個好的標準就可以開始各自實作。
因此，儘管嚴謹上 ERC 屬於 EIP 的一種，但在很多地方我們還是會聽到有人說：「ERC4337 is an ERC not an EIP」這類的話，這是因為許多人習慣用 EIP 來形容核心共識層的改動、而用 ERC 來表示應用層的規範。為了因應大眾，很多人也會開始區分兩個縮寫免得造成混淆，這也是大為什麼許多文章都會使用 ERC4337 而非 EIP4337。
好啦不重要，正文開始：
抽象帳戶 (Account Abstraction) 的定義
關於抽象帳戶的定義，會依照所使用的情境有所不同。我在這裡把它分為兩種：(1) 廣義的定義：從用戶體驗的角度出發，對於一般錢包使用者比較好理解的定義； (2) 狹義的定義：以以太坊為出發點，比較嚴謹的定義。
（想要看這篇文章只要看得懂 (1) 廣義的定義就好 😂）
廣義的 Account Abstraction
在現今的以太坊中，任何人只要安裝一個簡單的錢包，就可以產生一把私鑰，並產生相對應的公鑰，再推導出帳號地址。如此被產生的帳號被稱為 EOA (External Owned Account)，就是透過一把私鑰可以控制的帳號。如果需要進行任何的鏈上交易（轉帳、合約交易等等），都必須要付一筆以太為手續費，交易才會被收入區塊中。
所謂的廣義抽象帳戶，就是優化了現有的使用者體驗中的以下兩個重大問題的解決方法：
- 簽章方法不彈性：現有的簽名方法被固定為 ECDSA，對一般人來說管理困難或是沒有彈性、無法使用多簽或其他演算法。
- 付費方式不彈性：所有人產生錢包之後，都一定要先有以太，才有辦法進行第一筆交易，這使得要使用以太坊的門檻大大增加。
基本上解決了這兩個問題的錢包都可以自稱 AA 錢包了，我覺得這也是大家口語上普遍在說「AA」時所隱含的標準。我這篇文章也會用這個 AA 定義，泛指所有達成上述兩個條件的 Solution ，並以這個定義來解釋 ERC4337 跟其他 AA Solution 的差異。
狹義的 Account Abstraction
但上述的定義其實是不嚴謹的，所以你可能看完了，還不懂到底抽象帳戶的抽象是個什麼概念。想要了解真正比較精確的定義，則可以參考 Safe 發表的文章: Account Abstraction is NOT coming，文中頗精準地定義了 AA：
“Account Abstraction is the idea of reducing the number of account types from 2 (EOA and smart contract) to 1 (just smart contract) in order to improve usability and flexibility in Web3.
This is achieved by moving the validity conditions of a transaction (signature verification, gas payment, replay protection) out of the core protocol level (consensus layer) and into the EVM smart contract level (execution layer).”
由上文可以看出，真正嚴謹的 Account Abstraction 定義，是以「以太坊協議」為出發點看待「帳戶」：未來以太坊將不再硬性規定什麼是一個「帳戶」，例如如何進行驗章、付手續費、檢查重送交易等等，也不再在意 EOA 與 Smart Contract Wallet 的區別。相反的，以太坊作為一個 Protocol，只需要固定一系列的流程，包含上述的幾種驗證程序，剩下的「定義」完全保留彈性給各個不同的帳戶提供商，因此被「抽象」掉了。
我把這樣的定義稱為「狹義的 AA」，因為這對於一般不了解共識層或是程式中抽象概念的讀者是比較難以理解的。值得一提的是，在狹義的定義下，後面會提到的 Safe 或是 Argent 也不算符合 AA 標準，因為「以太坊」還是把他們都視為合約，沒有任何新標準可言。
解決方法
話說回來，假設我們先把視角固定在「廣義的 AA」，也就是純粹以 UX 的角度來定義問題 。那麼我們可以先討論，想要解決使用者遇到上述兩大彈性問題（驗證彈性以及付費彈性）的話，大概可以分成兩個方向：
- 在共識層解決：透過以太坊共識層的硬分叉升級，加入新的 OPCode 或升級驗章程序。這方面已經被提出來的提案有 EIP-2938 跟 EIP-3074 等等。缺點是不知道什麼時候才討論的出定案，並且要等增加以太客戶端團隊們已經龐大的工作量。
- 在合約層解決：仰賴智能合約錢包 (SCW, Smart Contract Wallet)，利用合約層以 EVM 程式碼實現客製邏輯，因此可以把簽章、其他人代為付費上鏈等功能都用智能合完成。
其中 (2) 的方向，過去者幾年就已經有許多產品給出解決方案。比較有名的有 Argent 錢包、Safe Wallet + Gelato 的解決方案等等，兩者在開發上都已經提供上述兩個核心問題的解法：利用多簽等方法滿足驗證的彈性、以及可用代幣支付手續費完成支付的彈性。以 Safe + Gelato 組合拳為例，在合約層實作多簽驗章程序，跟 Gelato 網路的 Relayer 合作，讓任何人都能夠 Relay 成交易並送上鏈。
因此，很大程度上，我們可以說：AA 錢包早就已經被許多團隊實現了。
ERC4337 的特別之處
ERC4337 也是透過「只改動合約層」來達成使用者體驗提升的終極目標，因此我們可以把他歸類為上述的 (2) 。既然在 ERC4337 之前，已經有成熟的 AA Solution ，那麼 ERC4337 到底帶來了什麼改變呢？
這就需要我們稍微退一步，想像一個完美的 AA 達成的世界，並比較一下上述這些現有的 AA 合約錢包，還有什麼阻止我們邁向 mass adoption 的疑慮。以下是兩個重點：
- 鏈下架構 (Offchain Infra) 的中心化：這些現有錢包雖然也有不錯的錢包體驗，在合約層也可能達成去中心化（任何人都可以提交交易），但是其實現有產品們背後都必須仰賴中心化的服務，例如仰賴單一伺服器來完成用戶與打包者之間的溝通媒合、代幣手續費報價簽章等。由於過度仰賴一些後端服務幫忙溝通並進行交易上鏈，這些角色可以在整個網路中扮演決裁者的角色，使所有人對「AA 服務」的信任假設增加。
- 鏈下架構的互不相容：現在的錢包生態系中，各家錢包各做各的，就算假設大家都做到全面且去中心化，只要這些鏈下架構不相容，就會造成只有最大的一家 AA 錢包有足夠的利益誘因吸引大家加入他的鏈下網路，讓大者恆大。這除了迫使所有錢包商必須競爭鏈下架構的開發，無法專心開發錢包之外，還會因為沒有標準化造成開發能量分散，減少這些鏈下服務的多樣性，這將進一步增加網路整體因一個 bug 而集體失靈的機率。
以上兩個重點，大概就是「符合 ERC4337 規定的 AA 錢包」與「傳統 AA 錢包」最大的差異：透過一套 ERC4337 規範，我們想要復刻出跟以太坊現有交易一樣的去中心化程度的新系統。我們也可以進一步條列出 ERC4337 能達到的幾個目標：
- 支援上述 AA 錢包的兩大功能：彈性的驗章、彈性的手續費支付
- 確保鏈下架構跟以太坊節點一樣去中心化，無任何信任假設
- 讓合約錢包開發者與鏈下服務開發者能夠各司其職，促進錢包、鏈下架構的多樣性
- 確保上述所有「參與者」都有足夠經濟誘因使網路更趨向「去中心化」
因此，以用戶角度而言，ERC4337 不是為了解決使用者體驗問題，而是將消除現有的 AA 錢包面對的可拓展性與中心化疑慮。
所以，如果 ERC4337 被實現了，跟現有的 AA 合約錢包相比，其實對於大部分一般用戶的體驗不會有太大的影響，一樣所有人都可以只靠著簽章還有一些後端服務，達到最一開始說的 AA 的兩大彈性優化。但 ERC4337 會讓整個合約錢包體系更健康：用戶將得到最好的報價、不再仰賴單一伺服器不要壞掉、不會因為太多人使用而失靈，並且透過好的角色分工，讓開發錢包的開發者專心開發並推廣更安全、高效的錢包，而所有人也都可以運行一些鏈下節點來獲取收益。
因此我們可以說，ERC4337 的出現將統整現有的 AA 錢包。在此 ERC 被提出之後，各個團隊可以共同遵循一套相容的模式開發這個體系中不同的角色，
P.S. 其實如果用上述「狹義的 AA定義」來看的話，ERC4337 的其實就是「在合約層實作新的交易驗證、付費流程規範」這麼簡單。而在狹義的 AA 定義下，只要 AA 被實現了，不論是在合約層還是共識層，上章節提到的去中心化特質都應該被涵蓋在內。
ERC 4337 細節介紹
這裡我會著重介紹一下大致流程、各角色之間的關係，還有為什麼需要一些特殊的機制設計。希望對於想要看程式碼的人有一點幫助：
名詞介紹
- Bundler （綑綁者）: 指的是負責接收用戶想要做的交易，經過驗證後負責打包成以太坊交易、支付手續費送上鏈的角色。他們會以類似節點的方法存在，並且理想上要能夠直接參與出塊、並跟其他 Bundler 節點利用P2P 的方式溝通。Bundler 將不只為特定合約錢包工作，且任何合約錢包的使用者都可以自由使用、切換各個不同的 Bundler 服務。
- UserOperation （用戶操作）: 為了避免混淆，我們不再使用「交易」這個詞。用戶想要進行一個鏈上行為時必須簽署這個「操作」，並統一丟給 bundler，由他們代為打包上鏈。這裡的操作會跟一般的原生交易很類似，擁有
to,data等等細節來描述要跟哪個合約互動。在 gas 方面比較特別，會分為「驗證」與「執行」兩階段分別限制 gas 用量，這個待會會細說。 - Mempool：在這個提案中，同樣用 mempool 這個詞來描述所有
UserOperations會存在的候選池。Bundler 會從裡面選取多筆操作，打包成一筆交易，並送上鏈。這也是為什麼 ERC4337 的標題叫做：Account Abstraction Using Alt Mempool。理想上，所有 bundler 將形成一個 P2P 網路，共同維繫並分享使用者提交的的操作池 (實際實作進度可參考最後面的更新)。
主要目標
要達成「整合所有 AA 合約錢包」這個目的，就必須達成以下兩大點：
- 建立一套流程讓所有 Bundler 能夠統一所有錢包驗證、打包的流程，並確保 bundler 網路不受攻擊。
- 保留合約錢包有完整的彈性，實現任意的驗證與手續費支付方法
ERC4337 提議，這套流程的執行，將會被統一實作在一個叫做 EntryPoint 的合約中（入口合約），並讓所有人共享。這個合約目前由 Ethereum Fundation 主導開發，項目名為 Infinitism，可在這裡檢視程式碼。任何一個 EVM 合規的鏈，想要支援 ERC4337 的，第一步就是要部署這個合約。
我們可以在上圖中看到，有了 EntryPoint 這個入口合約之後，後面有三個不同的合約角色，分別是
- Contract Account: 合約帳戶
- Aggregators: 聚合器合約
- Paymaster
上述三種角色中，唯一一定會用到的是「合約帳戶」。這裡的合約帳戶就是像傳統的合約錢包一樣，每個使用者自己部署的智能合約，最基本的功能就是要驗證傳進來的 UserOperation 指令是否經過「正確授權」（可以是簽章、多簽、或其他密碼學簽章，呼應我們前面說到的把驗證這步驟抽象化）。驗證無誤之後就可以直接照著指令呼叫外部合約，進行任意交易功能。
EntryPoint 流程大綱
EntryPoint 有一個特別的地方，就是強迫所有 ERC4337 錢包，把「驗證（Validation）」跟「執行（Execution）」分成兩個的步驟，也就是所有錢包把執行函式跟驗證分開，不能夠合在一起。下面是一段非常簡化的 pseudo-code，描述了 EntryPoint 主要會被呼叫的函示 handleOps 的大致架構:
// contract EntryPoint.sol
/// @dev the function that bundlers call to execute UserOperations
function handleOps(UserOperations calldata opts) external {
// 1. validation loop
for (opt in opts) {
// 呼叫合約帳戶地址 進行驗證
IAccount(opt.sender).validateUserOp(opt);
}
// 2. execution loop
for (opt in opts) {
// 執行時直接呼叫合約地址，失敗交易也不會 revert
try {
address(opt.sender).call(opt.callData);
} catch {...}
// ...postOpts, PayMaster logic
}
}
你或許會覺得奇怪：為什麼要強制兩次呼叫合約帳戶呢？為什麼不能只定義一個函式就好，可以叫做 validateAndExecute 之類的，這樣應該可以省下一些 gas 吧？這就要回歸到上面介紹的重點，這其實是為了達成「去中心化」必須的一步。
驗證的意義
我們不妨回頭想想這裡的「驗證」要做的是什麼：說白了就是對應到以太坊上「ECDSA驗章」的功能。這個驗證手續是一個「所有節點」都必經的動作：如果你的交易附帶了不合法的簽名，根本不用傳到礦工手上，隨便一個節點都會拒絕你提交的交易，根本廣播不出去。除此之外，節點還會驗證你是否是把已經用過的交易進行重送，因此加入了「nonce」這個元素的驗證，確保一樣的交易不能重複被執行。
當驗證只是簡單的 ECDSA 的簽章與 nonce 兩步驟，並不會造成很大的計算負擔，因此以前的節點沒有很擔心你送了一萬筆交易，然後驗證這關卡住了過不了，造成節點掛掉的狀況。
但是如果現在「驗證」這步可以執行任意的合約程式碼，這對每個節點（或是 ERC4337 的 bundler）來說，就有可能會超過負荷，例如一個合約簽包可以要求驗證流程需要去讀取大量的磁碟讀取（SLOAD）。因此我們可以發現 ERC4337 有一半以上的篇幅都在討論鏈下驗證（Validation）的方式，就是要規定一套所有 bundler 跟錢包都同意的規範，確保對 bundler 來說可以有效率的檢驗避免 DDoS 攻擊、對錢包來說卻能保留大部分的彈性。例如，提案中有規定 bundler 應該在收到交易時，使用 IEntryPoint.simulateValidation 模擬驗證結果，它就會再去呼叫每個錢包實作的驗證邏輯，其中，所有錢包的對於這個「驗證邏輯」都要符合類似以下的規定：
- 禁止使用跟環境相關的 OPCode：例如時間（timestamp）、區塊高度等等。理由是，不能讓一筆本來驗證成功的交易，會隨著時間、或真正被打包的區塊編號不同，而自動變為驗證不成功。因為如果驗證不成功，交易是會整筆 revert ，這樣的情況會變成 bundler 白白支付一筆失敗的交易手續費，而沒有拿到任何補償。
- 禁止讀取合約帳戶以外的 storage ：如果驗證成不成功會因為外部合約狀況改變，那很高機率跟上述一樣，可能因為其他交易被收入區塊鏈，讓你上鏈時驗證過不了。所以你不能實作「如果 ETH Price > 1000 就成功」這種奇怪的規則，這不屬於「驗證用戶授權有沒有效」的範疇。
這些規定將會被 bundler 節點們實作在自己的驗證邏輯中，如果你的錢包實作的 validateUserOp 程式碼碰到這幾個 OPCode ，整筆交易就會直接被忽略。上述只是舉兩個好理解的例子，關於更多這方面的規定細節，可以參考提案原文中的 Simulation 章節。
下圖很好地總結了從用戶簽署操作開始，到 EntryPoint 定義的流程：我們可以發現 Validation Loop 跟 Execution Loop 是被分開的，這就是呼應到了我們強制每個錢包實作驗證邏輯、在鏈下可以簡單通過呼叫來驗證；到真正上鏈時我們則是先做完所有驗證才會進行後續的實際交易執行。理論上上鏈時的驗證步驟不應該失敗，否則 bundler 就需要承擔損失。
因此要實作一個與 ERC4337 合規的合約帳戶，僅需完成以下幾點
- 實作
validateUserOp一個函式，在不違背上面規則的前提下，實作任意驗證邏輯，並且支付gas費用 - 執行時，只須確保呼叫者是
EntryPoint，不必再進行上述驗證。基本上邏輯就是簡單的做對外呼叫。
對於合約本身有興趣的話，可以看一下 Infinitism 的 SimpleAccount 模板。
Global Entities
除了帳戶合約本身以外，前面有提到的聚合器 (Aggregator) 跟 Paymaster 兩者都是可選的，只有在用戶帶上特別參數、或是合約帳戶錢包指派時才會被引用。在提案中，他們有時候被稱為「Global Entities」，因為他們都是所有用戶操作都可能用到的合約。
Aggregator 聚合器
如果合約帳戶需要，可以略除驗證部分，把簽章依照任意邏輯聚合再一起，再一起由一個合約驗證。有設計這樣的流程是為了保留錢包驗證簽章的彈性，但是目前我還沒有看過有合約帳戶用到這個功能，這邊的邏輯也比較複雜，之後有更新會再補在比較深入的文章裡。
Paymaster
Paymaster 指的是負責處理付款的合約。在驗證的環節中， EntryPoint 會計算這筆交易最多需要消耗的 gas，並要求帳戶有足夠的 deposit 能夠付款給 bundler 。合約帳戶需要在執行驗證結束後付這些 gas，或是事先 deposit 一筆錢到 EntryPoint 裡面。（這部分運算在程式碼中被稱為 preFund ）。
如果一個操作有使用 paymaster 的話，EntryPoint 則是會檢查 paymaster 的 deposit 是否足夠（簡單說就是從 Paymaster 存的錢裡面扣款）。當然，是否要幫忙付款要經過 paymaster 的同意，因此 paymaster 需要實作 validatePaymasterUserOp 來判斷是否是合法授權的用戶操作。因此不難想像，Paymaster可以實作類似「只代付某特定交易」、「有上限的代付 gas」、「收取用戶 ERC20，代付 gas」等等邏輯，來達到手續費支付的抽象化。
在細節上，ERC4337還有設計一個叫做 postOp 的 hook，可以讓整筆交易做完的時候，再次通知 Paymaster 交易實際執行是否成功、剩下多少 gas 沒用完等等，讓 Paymaster 決定要不要採取 refund 之類的行動。
在整個 ERC4337 當中，paymaster 佔了非常重要的角色，並且在未來可能成為非常專業的服務提供者。這些角色的現況我們後面會在著重介紹。
考量到這兩個角色之後，可以把整個 EntryPoint 合約的流程（也就是ERC4337 規定的流程）整合成下圖。非常推薦想要深入 EntryPoint 合約的人可以配著這張圖對比一下實際實作：
Global Entity 限制
由於 Aggregator 和 Paymaster 這兩種合約都是「任意合約」，並且被多個 User Operations 共享，它們的實作方式都可能在執行時，影響其他用戶操作的「驗證階段」是否順利完成。因此在 ERC4337 中也有特別強調，該如何避免惡意的用戶利用這兩種合約造成 綑綁者計算資源的浪費。其中包含兩大方向：
- 強制 staking 機制：所有的聚合器或是 paymaster 如果除了用戶帳戶合約以外，還要使用聚合器或 paymaster 自身 storage 就必須質押 (stake) 一定數量的以太在
EntryPoint合約中。這能確保就算要透過外過合約本身state 更動，也不能毫無成本引發 bundler 做白工來進行女巫攻擊。注意這裡的 stake 跟上面提到用來手續費的deposit是不同的兩筆錢、會被分開使用，但是一率都由StakeManager這個父合約來實作。 - Reputation 的機制：如果一個 global entity 不斷造成其他
UserOp驗證失敗，即透過一些規則把他們的 reputation 降低。這方面會被實作在 bundler 節點上，也是一個可以比較彈性的地方。
這部分細節可以詳閱 ERC4337 的 Reputation scoring and throttling/banning for global entities 的章節。
ERC4337 的短板
介紹完了這些細節之後，我們可以再次快速帶過一些 ERC4337 這樣的架構，容易面臨的一些風險。這些可能是決定是否使用 ERC4337 錢包時要考慮的：
合約風險：EntryPoint 會承擔巨大的合約風險，如果裡面真的存在 bug，可能會造成最高所有錢包總額的損失。如果我們真的想要用這套模式架構提供使用者AA體驗，必定需要先想辦法確保這個合約的安全性。這方面必須引入更高效的 formal verification等等安全技術。
不過以另一個角度來說，EntryPoint 其實很大程度的承擔了每個錢包原本需要自行承受的合約風險。因為程序、付費等邏輯已經被 EntryPoint 實作掉了，帳戶合約的開發反而變得簡單，會比自己開發一個AA錢包要承擔的合約風險要小很多。這點對於促進合約錢包開發是有好處的。
DDoS 風險：這個提案的核心就是為了解決 bundler 們的 DDoS 風險，但他們還是承擔了很多沒有被 compensate 的運算量，而也是這個架構中最容易被攻擊的一環。經過上面的介紹，現在應該對於這個 attack surface 有比較多認識。關於更多為了達到去中心化 mempool 的細節，可以參考這篇文章文章：
關於 ERC4337 比較細部的介紹就到這裡了。剩下就是一些進度更新，以及比較多我自己的感想。
現有 ERC4337 相關專案與進度
EntryPoint 實作
初代 EntryPoint 已經於今年(2023)三月部署到各大網路上。目前還有一些優化在進行，可以預期今年還會有新的迭代版本出現。
捆綁節點 Bundler實作
目前有幾家比較大的團隊在實作 bundler 的節點，都還沒有實現 P2P mempool 的功能，也就是現在的捆綁者們不是互通的，可以視為還是十分中心化的後端服務（Trusted Providers）：
- Infinitism: JS 實作的 bundler
- StackUp: Golang 實作的 bundler。支援 searcher mode 就是直接與 mev-boost溝通。
- Pimlico: Typescript 實作的 bundler: Alto
- Etherspot: Typescript 實作的 bundler: skandha
合約（帳戶 + Paymaster） 開發
- Infinitism: 前面提過，官方的
SimpleAccount的模板，有經過審計，因為非常簡潔，可以算是 production-ready。 - ZeroDev: 實作名為 Kernel 的合約帳戶，目前在AA界名聲非常好的一家公司（遇到兩個團隊說看好他們會稱霸 ERC4337 錢包），有著非常彈性的架構，和大量難懂的 assembly 。
- Biconomy: 是最早開始實作4337的團隊之一，在此標準提出之前，也一直在 UX 這塊許多耕耘，之前有名的是他們的 meta-tx solution。實作自己的 SmartAccount，自稱最近有多方整合要上線
- *Safe: 最新版本v1.4 中，已經移除以前無法與 ERC4337 合規的部分，未來可以透過增加 Module的方式變成 ERC4337 compatible（關於之前的問題可以看這個 issue）。但目前 Safe 官方沒有實作，也不打算在其 V2 原生支援 ERC4337。
現有服務
簡單來說，目前大部分 AA 團隊，無論主打錢包還是捆綁者實作，都還是大幅賴提供一條龍的服務給專案方，包含節點營運、錢包選擇、Paymaster API 控管等等，我們把它稱為「AA As a Service」。以下我依照各家給出的整合方式來分類：
High Level SDK:
- Biconomy, ZeroDev, 都有提供非常 High level 的 AA SDK, 可以簡單地讓一個想要提供AA 流程的專案，可以在client端輕鬆整合。這方面必須包括了使用他們自家的錢包，並必須仰賴其後端 API server、以及固定的 paymaster 流程，因此缺乏彈性。
Low Level SDK
- Stackup: StakUp 提出的 userop.js sdk 裡面給予用戶更大的自由度，可以自由組合帳戶合約，並且沒有強制將 API 服務強制包含到 sdk中，因此進階用戶能透過這套 sdk 直接與 bundler url溝通，包含自由決定 paymaster ，因此能透過自架一些備援 bundler 的方式來最小化後端壞掉的機率。
- Alchemy: Alchemy 算是非常努力在支援4337的大團隊之一，Alchemy AA SDK 也算是客製化很高的 SDK，一個小缺點是強制 bundler 跟 RPC client 要是同一個節點（因為 Alchemy 現在的節點就有支援 ERC4337 的 RPC 接口)，如果想要分開的話要自己實作一個 viem client。也一樣可以選擇自己的 paymaster 或是使用 Alchemy 的服務。
值得一提的是，上述兩大種類其實在 paymaster 這塊都是差不多的解決方式，如果要用 ERC20 支付手續費，都還是需要仰賴他們後端自製的 API Server，用 API Key 等等方法驗證支付授權，因此更中心化。
ERC4337現在面對的客觀瓶頸
彈性是否足夠：上面在提到 Safe 的時候，我們有埋了一個小小的伏筆：Safe團隊已經表示他們未來不會成為原生 ERC4337 的錢包，而是會主打自己的V2的設計。理由是 ERC4337 為了防範 DDoS，造成太多設計上的限制，其中就影響了他們 V2 想要做的一個大功能：Nested Safe（由Safe管理另一個 Safe）的設計。這看得出 ERC4337 的提案中確實是限制了一些彈性。
仍是中心化後端架構：現在儘管有 bundler 的實作，在他們不能互相溝通的情況下，其實就還是要仰賴這個節點的正確運作。這其實就回到我們一開始講的，對於現有產品而言，ERC4337 尚未擁有去中心化的特性。
安全性考驗：現在公認最安全的 AA Solution，仍然是使用 Safe 多簽錢包為合約，配合一些如 Gelato 的上鏈服務。身為被部署過最多次的合約，大家對Safe 的信心都比較充足，對於大部分的專案來說，在「驗證」這一層多簽可以說是綽綽有餘，因此沒有必要冒太大的合約風險嘗試新的合約錢包。
ERC4337 的優勢
更健康的生態系：我們可以從上面進度看出，目前整個4337的生態系已經有很多多方合作在進行，這是因為錢包、 bundler 以及 Paymaster 都可以由不同的團隊進行實作、並且互相搭配使用。這除了給各個整合團隊很大的自由外，理論上用戶也已經可以自己搭配出自己理想的合約錢包。
個人感想
我個人很看好 ERC4337，因為這是要在非共識層，系統性解決用戶體驗問題的最佳法則，目前也正慢慢被社群接受。但在此我想提出除了上述比較客觀的障礙之外，其他在這次 research 中體會到的發展困境。
TLDR: 還沒有人做出好用的 「 AA錢包」，只有零星的 「AA-Dapp」。
困難 (1)：ERC4337 AA as a Service 服務對象的矛盾
上面我們說到，上述這些在實作 ERC4337 的團隊，都只有提供類似 AA as a Service 的服務，並且都是主打以「專案整合」為出發點：「如果一個專案想要給用戶提供 AA 的體驗，可以設定為使用者代付手續費，開放使用 ERC20 付款」… 這樣的邏輯。簡單的說，就是把一個 Dapp，透過他們得服務改造成為 AA-Dapp。這些 SDK 都能讓我們可以銜接任意的用戶錢包（不論瀏覽器錢包、硬體錢包或是手機錢包）讓我們在用戶不知情的情況下，為他們部署一個合約錢包，並支援上述所有功能。
最近這一篇文章很紅，描述了最近 ERC4337 為何最近開始起飛，會發現這符合我上面的敘述：現在所謂的「ERC4337表現好」大部分來自「某個提供 AA 體驗的專案起飛」，或是用上面的詞，某個「AA-Dapp」，例如 Polygon 上面的 CyberConnect，一次帶來了應該所有交易量的 80%：
但我為什麼說這存在矛盾呢？因為我認為 AA 最大的好處之一，是它不仰賴各智能合約（或是開發這能合約的團隊）來解決 UX 問題。以往你需要在 Dapp 合約層考慮使用者體驗的話，你可能會利用 meta-transaction 等技巧，天生支援 relayer 的角色來製造好的使用者體驗。但是 AA 的理想是：未來各種 Defi Team寫合約的時候，不用再特別去遵循什麼標準了，一律就用 msg.sender 到底，不用再考慮 meta-transaction 還是 MultiCall；相反的，我們可以讓「錢包層」來做使用者體驗的優化。
但目前既有的「與專案團隊合作把 Dapp 變成 AA-Dapp」的推廣路線跟上述理想是相矛盾的：如果我是一個考慮用戶體驗的團隊，其實我大可在我設計智能合約時，就能實作 meta-transaction ，尤其現在 ERC2771 成熟，在整合上是更安全、更快、也更省gas的。反之如果我是一個不太考慮用戶體驗的團隊，我也不太可能會多花很多時間多整合一套 sdk。
困難 (2)：升級困難：現有專案難以整合這些AA服務
除了剛剛說的「角色衝突」這個理由之外，對於一些已經有產品、既有用戶的Dapp而言，如果要「升級為 AA-Dapp」，就必須要把這個體驗套用在所有人用戶身上。這對於大部分繼有 Dapp 團隊來說很不方便，因為他們可能有一半的用戶都已經是熟練的 EOA 錢包使用者、甚至硬體錢包使用者，並不是所有人都樂見這樣的「升級」。
如下圖所示：通常在一般Dapp的前端實作上，大家都比較偏好 BYOW — Bring your own wallet 的模式：即我整合一個如 rainbow-kit, blocknative onboarding 之類的套件，它可以再去支援任何錢包，這樣用戶就可以選擇要用哪個錢包跟我的前端溝通。這基本上已經成為所有 Dapp 的起手式：除了更容易支援更種軟體、硬體錢包外，也外包很多關於後端節點、gas 等等的設定，讓各個團隊可以更專注的在開發前端的需要的各種功能，明顯是一般前端團隊的首選。
如果把這些「AA as a Service」的 sdk 畫在這個關係圖中，它現在處於 BYOW 模型的右側：也就是 Dapp 範疇之內，因為他的主要接口在於整合任何 “錢包” ，並多包一層 AA 的功能。一家 Dapp Team 要馬選擇做一個一般 Dapp，要馬會選擇使用這個服務，升級成為一個黃框框的 「AA-Dapp」：
如果你已經有許多 EOA 的用戶，那麼強制所有人升級肯定會造成混亂，如果真的要納入 AA，勢必要自己實作兩份流程（即改變自己的 Dapp 與 BYOW solution 之間的關係）：
- 使用 AA 錢包的用戶: Dapp -> AA SDK -> BYOW SDK (簽章)
- 一般 EOA 用戶：Dapp -> BYOW SDK (簽章)
這無疑是個膨大的工作量、並且不可避免地引發其他混亂（例如一個用戶能否同時是EOA用戶，也擁有AA錢包呢？）這是很多「現有 Dapp 」遲遲沒有做這些整合的重大原因。
困難 (3)：所有 AA-Dapp 的選擇將互不相容，最終讓使用者體驗更差
除了麻煩、角色衝突、難以搬遷既有用戶等上述問題之外，更大的一個問題是，所有 Dapp team 做出來的決策將互不相容：例如上圖中，假設 Cyber Connect 使用 Biconomy 作為所有用戶的錢包選擇，那用戶就要先在使用前打錢進入這個合約錢包；而用戶想要轉換到另外一個青蛙 Pepe Dapp 上，如果他們選擇使用 ZeroDev Wallet 的話，用戶就需要把錢轉到另一個合約錢包裡才能使用。這就是這種模型不合理之處。
因此我認為，要求每個 Dapp team 去做出「是否要提供AA服務」這樣的決定是不合理的；這種與團隊合作的推廣方式也不會將「AA錢包」推展至他們的極致。
我的感想與預測
就是上面的這句話的相反：
是否使用 AA 錢包應該是使用者的決定
在一條EVM有許多 Dapp 的假設下，我自己覺得比較合理的升級軌跡應該是讓用戶自行選擇 AA 錢包，也就是讓用戶自己做「要不要從 EOA 升級成 AA錢包」的這個決定。而 Dapp 應該保持不變，也無需做出任何流程上的變動。這樣既符合每個人自己管理自己錢包的原則，也不會出現因為 Dapp 做出不同決定而打架的行為。
好的 ERC4337 AA 錢包將成為關鍵
因此如果能夠有一個很好的瀏覽器插件 AA 錢包，已經整合進主流的 BYOW 套件中，可能會讓更多的 Dapp 願意支援。我們老字號 Argent + WalletConnect 可能從 2020 年就已經打出這套組合拳，但我覺得要透過手機的使用者體驗不是很好，無法媲美瀏覽器插件的體驗。
因此我自己的猜想是，這個生態系中，最缺的是一個好用的AA 錢包。我也在這邊大膽預測，如果能有有人做出一個好用的 AA 錢包，我們可以馬上看到大量的現有 Dapp 接通 AA 體驗（包括 Uniswap / Aave 這種最高等級的應用），直到那一天我們才能讓大量現有 Crypto 用戶升級，也才會真正迎來 ERC4337 大熱、交易量激增的 AA Summer。
目前我有聽到在做「ERC4337 錢包」的產品有：
- SoulWallet：比較有名的瀏覽器插件錢包，但是產品還沒釋出，而且打算自己開發自己的「錢包合約」
- Candide wallet： 手機錢包，現在還再 waitlist 階段
也很期待 Rabby 之類的 UX 大品牌趕緊整合推出自己的 AA 版錢包。（如果知道其他有潛力的品牌歡迎分享）
小結：未來的期待
總結來說，ERC4337 還有非常長一段路要走。現階段來說，還沒有達到理想上的去中心化，但是已經可以從開發社群中觀察到，這樣的架構帶來大家各司其職、實作不同角色的成果已經被慢慢體現出來。各家給出的時間軸都很不一樣，但我覺得最樂觀我們也需要到明年才可能體驗到真正比較去中心化的效果，或許到那時候才會真正在技術上體現他的優勢。
由於 ERC4337 一直到幾個月前才算是進入比較 production — ready 的階段，因此其實妄想要馬上看到其他可用「錢包」也是有點不切實際。但我個人還是很期待中短期內的兩大看點：
- 「AA As A Service 」可能隨著 app-chain 的崛起而短暫崛起，因為在新的 app-chain 上，一個團隊比較有動機全面升級並掌控所有使用者的錢包體驗。但我覺得這些案例可能只是短期的曇花一現，而且並不能夠最大化 ERC4337 的價值，因為這些 app-chain rollup 目前幾乎都是中心化的，使用 ERC4337 其實浪費了其中捆綁者能夠「去中心化」的效果，但是這是讓大眾接納 ERC4337 的第一步。
- 真正 AA 的落地會隨著更多的 AA 錢包被做出來，而快速被一般 Dapp 接納。只要有一個 UX 好的錢包被實作出來，現有 EOA 用戶的轉移可能是非常快速的，畢竟 EOA 真的有諸多不便。（不過這也可能只發生在 L2 上，畢竟主網還是貴）
當然，也很希望看到又有人想出 ERC4337 還有什麼新玩法，可能半路會殺出一個新的服務角色也說不定。
Account Abstraction 其實是所有以太坊用戶的相同願景。 ERC4337 只會是一個中期的解決方法，長期來看我們還是需要共識層的改動。無論如何 ERC4337 都是一個很好的學習機會，也是在長期這個願景達成以前唯一能在應用層增加體驗、並且開始試著實作的方法。這個時期大家的努力嘗試，都有助未來共識層改動提案前，我們最大幅度探索所有想要的 usecase。
希望這篇文章有讓大家對於 ERC4337 跟 Account Abstraction這個願景之間的聯繫有更深刻的認識。感謝 MidJourney 當插畫師，也再次感謝各位審稿老師給的寶貴意見！
推薦教材：
列出推薦教材前先謝謝贊助商！TEM Medium 2023 有獎徵稿 TEM Medium 目前正在進行有獎徵稿！詳情請參考：
以下是一些推薦的進階閱讀！
1. Alchemy 系列 ERC4337 解析：
這真的是⭐極推⭐。我對這系列真的是相見很晚，如果早點看到的話可以理解很多設計脈絡。整個系列會由最簡單的設計開始慢慢進化，一步一步了解為何 ERC4337 走到今天這副模樣。以下附上Part 1：
2. 上面介紹過的：Unified ERC-4337 mempool
這算是比較深入的針對理想 ERC4337-mempool 狀態，完整的敘述我們需要哪些對於 bundler 的保護、以及所有 bundler 都需要遵守規定的原因。
3. ETHTaipei Workshop!
想要實作 ERC4337 怎麼能不看最強團隊 imToken 的教學呢？以下附上教學影片以及一直有在更新的 repo。
