昨天談智能合約的安全風險——重入、權限、預言機操控,一連串讓人心驚的攻擊面。今天談一個把「錢包本身變成智能合約」的方向:帳戶抽象(Account Abstraction)。它的核心主張很簡單——既然智能合約可以寫任意驗證邏輯,為什麼「你的錢包」還要停留在「一把私鑰簽名」這種一九一〇年代等級的門鎖?帳戶抽象要做的,就是用可程式化錢包同時改善使用者體驗與安全。
📖 學
EOA 的痛點:一把私鑰統治一切
以太坊上有兩種帳戶。一種是 EOA(Externally Owned Account,外部帳戶),由私鑰控制,就是你 MetaMask 裡那個 0x 開頭的地址;另一種是合約帳戶(Contract Account),由程式碼控制,但自己不能主動發起交易。我們日常用的錢包幾乎都是 EOA,而 EOA 的規則被硬編碼在協定裡,幾乎不可改:
- 只能用一種簽章驗證:ECDSA 曲線,一把私鑰。私鑰丟了,資產永遠鎖死;私鑰外洩,全部歸零。沒有「忘記密碼」,沒有「凍結帳戶」。
- 必須自己持有原生代幣付 gas:想在鏈上動一分錢,你得先有 ETH 付手續費。新手要先去交易所買 ETH、提幣、再操作,勸退了一大票人。
- 沒有批次、沒有規則:授權(approve)和交換(swap)是兩筆交易、簽兩次名;想設定「每天最多花 100 美元」「這個 app 只能碰這顆代幣」都做不到。
- 無社交恢復、無多簽的原生支援:要靠外掛合約才能繞出來。
一句話:EOA 把「安全」和「一把私鑰」死死綁在一起,而使用者體驗糟糕的根源,大半來自這個綁定。
帳戶抽象是什麼:把「誰能花錢」變成可程式邏輯
帳戶抽象的核心概念是——把「驗證一筆交易是否有效」這件事,從協定寫死的規則,抽象成一段可以自訂的合約程式碼。你的錢包不再是「一把私鑰=最高權限」,而是一個 smart account(智能合約錢包):它可以規定「需要兩把鑰匙其中兩把」「用指紋(passkey/WebAuthn)簽名」「這把臨時鑰匙只能在今天、只能玩這款遊戲」。
驗證邏輯一旦可程式化,前面那些痛點就全都能拆開處理:恢復、代付、批次、權限,都變成合約裡的一個函式。問題只剩一個——以太坊底層規定「交易必須由 EOA 發起並付費」,智能合約自己動不了。要怎麼繞過?這就是 ERC-4337 登場的地方。
ERC-4337 的元件:不改共識層,另建一條平行通道
ERC-4337 的聰明之處在於完全不動以太坊共識層,而是在協定「之上」搭一套平行的交易系統。它有四個關鍵角色:
- UserOperation(使用者操作):這是取代「交易」的新資料結構。它描述你「想做什麼」——包含 sender(你的 smart account 地址)、nonce、要執行的 calldata、驗證與執行的 gas 上限、費用參數、選用的 paymaster 欄位,以及一段簽章。注意:它不是一筆真正的鏈上交易,而是一個「意圖」物件。
- Bundler(打包者):因為以太坊最終還是需要 EOA 來發起真交易,bundler 就扮演這個角色。它們從一個獨立的替代記憶池(alt-mempool)收集許多人的 UserOperation,打包成一筆真正的交易,送上鏈。使用者不再需要自己持有 EOA,bundler 是唯一需要 EOA 的參與者。
- EntryPoint(入口合約):一個在各 EVM 網路上部署於相同地址的單例(singleton)合約,是所有 4337 操作的中央驗證與執行樞紐。它會逐一驗證每個 UserOperation、呼叫帳戶的
validateUserOp、檢查 paymaster、執行呼叫,最後退還未用完的 gas。把它想成整套系統的「守門員兼結算員」。 - Paymaster(代付者):選用的角色,可以替帳戶「贊助」gas 費,或讓使用者用 ERC-20 代幣(例如 USDC)付手續費,而不是非得用 ETH。gas 就像雲端伺服器的運算成本一樣,被抽象到使用者看不見的地方。
流程串起來:你簽一個 UserOperation → bundler 收集打包 → EntryPoint 驗證並透過你的 smart account 執行 → paymaster(若有)買單 gas。
能解鎖什麼 UX:把「錢包」變成真正好用的東西
帳戶抽象不是為了炫技,而是為了把幾個長年折磨使用者的體驗一次修好:
- 代付 gas(gasless):新手不用先買 ETH。app 可以幫你付 gas,或讓你直接用穩定幣付,onboarding 門檻大幅降低。
- 社交恢復(social recovery):私鑰不再是唯一的命門。可以設定「若我遺失鑰匙,3 位守護者中的 2 位可協助我更換簽名鑰匙」,同時完全不需託管你的資產。
- 批次交易(batching):approve + swap 合成「一次簽名、一次上鏈」,體驗接近 Web2 的一鍵完成。
- Session key(會話鑰匙):授權一把臨時、受限的鑰匙——例如「這款鏈遊,今天內、單筆上限 10 USDC、免每次彈窗簽名」。玩遊戲不再每個動作都打斷你。
- 自訂安全策略:花費上限、白名單、多簽門檻、passkey 生物辨識登入,全都是合約裡的邏輯。
EIP-7702 與展望:讓現有 EOA「暫時長出合約能力」
ERC-4337 很強,但有個現實摩擦:它預設你使用一個「全新的 smart account 地址」,而全世界數以億計的使用者、資產、身分,早就綁在既有的 EOA 上。要大家搬家,難。
EIP-7702 解決的正是這一點。它由 Vitalik Buterin、Sam Wilson 等人提出,並於 2025 年 5 月 7 日隨 Pectra 硬分叉上線。它引入了新的交易類型 0x04(SetCode 交易):讓一個 EOA 透過一段簽名授權,把某個實作合約的程式碼「暫時掛」到自己的地址上。結果是——你的地址、你的私鑰完全不變,但這個 EOA 瞬間獲得了智能帳戶的能力:批次、gas 贊助、session key、交易層級的簽名規則。
這是關鍵的一塊拼圖:7702 讓「既有 EOA」和「4337 的智能帳戶世界」接軌,不用換地址、不用搬資產。未來的方向,是 7702 負責讓存量帳戶升級、4337 提供豐富的智能帳戶基礎設施,兩者互補,共同把「可程式化錢包」變成預設而非例外。更遠處還有 EIP-7701 等原生帳戶抽象的討論,想把這套機制直接寫進協定層。
風險與取捨:方便的另一面
- 新的攻擊面:錢包變成合約,就繼承了智能合約的所有風險——實作 bug、升級邏輯漏洞、惡意的 paymaster 或 delegate 合約。昨天講的那些安全課題,現在直接搬到你的錢包裡了。
- 7702 的授權風險:把程式碼委派給一個惡意合約,等於把地址控制權拱手讓人。授權對象務必是經過審計、可信的實作。
- 中心化與審查疑慮:bundler、paymaster 這些基礎設施若過度集中,可能形成新的審查或單點故障。
- 簽名語意變複雜:使用者更難看懂自己到底簽了什麼,釣魚(尤其針對授權簽名)風險上升。
方便與風險是一體兩面——帳戶抽象把選擇權交還給使用者,但選擇權也意味著責任。
🧠 記
- EOA 的三大痛點:單一私鑰驗證(丟了就沒)、必須自持 ETH 付 gas、沒有批次與自訂規則;帳戶抽象就是要拆開這三個綁定。
- 帳戶抽象的本質:把「交易驗證邏輯」從協定寫死變成可程式化的合約程式碼,錢包從此可以自訂「誰、在什麼條件下能花錢」。
- ERC-4337 四元件:UserOperation(意圖物件)、Bundler(打包上鏈的 EOA)、EntryPoint(單例驗證/執行樞紐)、Paymaster(代付或用 ERC-20 付 gas),完全不改共識層。
- 解鎖的 UX:代付 gas、社交恢復、批次交易、session key、自訂花費上限與 passkey 登入。
- EIP-7702(Pectra,2025-05-07,交易類型 0x04)讓既有 EOA 暫時掛上合約程式碼,不換地址就長出智能帳戶能力,與 4337 互補。
✍️ 實踐
- 用支援 ERC-4337 或 EIP-7702 的錢包(如 Ambire、Safe、Coinbase Smart Wallet 等)在測試網跑一次:體驗「免持 ETH 付 gas」或「approve + swap 一次簽名」,親身感受和傳統 EOA 的差別。
- 拿一份 ERC-4337 的
validateUserOp範例合約(OpenZeppelin 有帳戶抽象模組),讀懂「一筆 UserOperation 從簽名到 EntryPoint 執行」的完整生命週期,並標出每個角色的職責。 - 檢視 EIP-7702 的授權安全:找一個委派實作合約,確認它是否經過審計、升級權限如何控制,寫下「你會授權它、以及不會授權它」的三個判斷依據。
🔗 延伸學習
- EIP-4337: Account Abstraction Using Alt Mempool(官方 EIP)
- ERC-4337 官方文件(元件與運作機制)
- Account Abstraction | OpenZeppelin Docs
- EIP-7702 Explained: Account Abstraction for EOAs
💬 問 AI
想真正搞懂一筆 UserOperation 怎麼走完全程,把下面的 prompt 丟給 AI,請它用一個具體情境帶你逐步拆解,並對照傳統 EOA 交易:
我想理解 ERC-4337 帳戶抽象的完整運作流程。請以「一位新手用智能合約錢包、
由 dApp 代付 gas,完成一次 approve + swap 批次交易」為情境,逐步說明:
1. UserOperation 這個物件包含哪些欄位、分別代表什麼意圖
2. Bundler、EntryPoint、Paymaster 各自在哪一步介入、做了什麼
3. smart account 的 validateUserOp 在驗證什麼
4. 整個流程和傳統 EOA 直接發交易,差在哪些關鍵環節
最後,請說明如果改用 EIP-7702 讓我「既有的 EOA」來做同一件事,
流程會有什麼不同、我需要注意哪些授權安全風險。