
了解以太坊中的帳戶抽象化——它的含義及其重要性。

即便熊市持續肆虐,幾乎沒有人懷疑加密貨幣會就此消失——光是 MetaMask 這樣的錢包就已擁有數百萬用戶。然而,一個問題依然懸而未決:「我們該如何將下一個十億用戶帶入 web3?」
這個問題的答案因人而異,但所有人都認同一點——我們必須改善用戶與區塊鏈應用程式互動的體驗。若不讓 web3 變得更友善,人們就沒有動力放棄每天使用的 web2 應用程式。
「帳戶抽象化(Account Abstraction)」是一項旨在改善用戶與以太坊互動體驗的提案,近來在加密貨幣社群中引發了廣泛討論。不過,你可能正在想:「帳戶抽象化究竟是什麼?我為什麼要關心它?」
本文將帶你從過去、現在到未來,全面理解帳戶抽象化的脈絡,並回答你可能對這個主題的所有疑問——包括帳戶抽象化的「是誰、是什麼、為什麼、如何做,以及何時」。
以下是幾個核心重點的快速摘要:
可程式化的自我託管帳戶(「智能帳戶」)能降低新用戶加入 web3 生態系統的門檻。然而,以太坊設計上的限制阻礙了智能帳戶的廣泛採用。
帳戶抽象化帶來了重大變革,為無需信任、抗審查的智能帳戶的廣泛採用鋪平道路。目前有多種實作帳戶抽象化的方案正在討論中,各有其獨特的優勢與取捨。
MetaMask 正透過其無需許可的創新平台 MetaMask Snaps 推動帳戶抽象化的採用。透過 MetaMask Snaps,開發者可以擴展 MetaMask 的功能,將帳戶抽象化的優勢帶給全球的加密貨幣用戶。
和 web3 中的其他新概念一樣,帳戶抽象化並不容易定義。不過,我們可以先拆解與以太坊帳戶抽象化討論相關的各種術語,從而更好地理解它:
抽象化(Abstraction) (名詞):電腦科學中一個(相當複雜的)術語,大致意思是隱藏系統或應用程式的資訊,使其在對背景運作流程了解較少的情況下仍可使用。也可定義為*「透過提供一個介面來簡化系統操作,從而隱藏系統複雜性的過程。」*
帳戶(Account) (名詞):用戶在區塊鏈上的代表,可以發送或接收交易,並與其他鏈上帳戶互動。以太坊有兩種類型的帳戶:外部擁有帳戶(Externally Owned Accounts,EOA)和合約帳戶(又稱「智能合約」)。
2a. 外部擁有帳戶(EOA):使用錢包軟體(如 MetaMask)生成,並由一對加密公鑰和私鑰管理的以太坊帳戶。EOA 是「主動的」(可以發起交易並支付 EVM 執行的 gas 費用),但僅限於執行基本操作——例如發送以太幣或與合約互動。
2b. 合約帳戶:以智能合約形式部署的以太坊帳戶,由程式碼中的邏輯控制(而非私鑰)。合約帳戶是「被動的」:它只能在收到 EOA 的交易後才能發送交易,且無法支付 gas 費用。然而,它是可程式化的,可以根據儲存在該地址的程式碼執行任意邏輯。
錢包(Wallet) (名詞):管理以太坊帳戶資金的介面——錢包的運作方式取決於其連結的帳戶類型。像 MetaMask 這樣的 EOA 錢包需要私鑰來授權交易;而智能合約錢包則連結到合約帳戶,可以使用任意邏輯來授權交易(例如使用多重簽名機制)。
有了這些定義,我們現在可以正式定義帳戶抽象化了。
定義帳戶抽象化
帳戶抽象化是一項提案,旨在提高以太坊帳戶在管理和行為上的靈活性。我們透過引入帳戶合約來實現這一目標:這是一種特殊用途的智能合約,用於定義和管理用戶的以太坊帳戶(現稱為智能帳戶)。
透過帳戶抽象化,你可以使用智能合約錢包享有可程式化的資金存取方式,而不必完全依賴私鑰來保障安全。這是可行的,因為你的智能帳戶可以為花費代幣和轉移資產設定自訂規則。
那麼,「抽象化」在這一切中扮演什麼角色?
從網路層面來看,「帳戶抽象化」意味著帳戶類型的細節對以太坊協議是不可見的。每個帳戶(包括自我託管帳戶)都只是一個智能合約,用戶可以自由決定各個帳戶的管理和運作方式。
從用戶層面來看,「帳戶抽象化」意味著與以太坊帳戶互動的某些技術細節被隱藏在更高層次的介面之後。這改善了錢包設計,並大幅降低了使用 web3 應用程式的複雜性。
這樣的釐清是必要的,因為對帳戶抽象化的困惑往往源於不清楚(a)什麼被抽象化了,以及(b)抽象化發生在哪裡。帳戶不一定是從用戶那裡被抽象化的(即使它們是從協議中被抽象化的)。你仍然有一個錢包地址來接收資金,以及一個簽名金鑰來確保只有你才能使用這些資金。
從你的角度來看,帳戶抽象化更像是使用一個智能帳戶,它抽象化了與區塊鏈互動的某些細節。舉個例子,以下是一位初次使用者與 dapp 互動時的體驗:
透過帳戶抽象化,錢包開發者可以建立在背景處理這些流程的系統,簡化使用 web3 的體驗(簡而言之:錢包變得「隱形」)。一些使用案例(我們稍後會詳細說明)包括:無需儲存助記詞/私鑰、無需自行支付交易 gas 費用,甚至無需自行設定鏈上帳戶。
如前所述,帳戶抽象化消除了使用 web3 錢包和與 dapp 互動時的大部分阻力。這使 web3 更接近 web2 的理想狀態——無論是新手還是有經驗的用戶,都能享有同等程度的靈活性、安全性和易用性。
特別是,帳戶抽象化對自我託管的未來有著深遠的影響。透過帳戶合約提供的功能,使用 web3 錢包的感覺將如同使用銀行帳戶或應用程式,卻無需信任銀行。
在接下來的章節中,我們將探討帳戶抽象化的不同面向,並討論它們如何改善使用以太坊的體驗。具體來說,我們將談到簽名抽象化、費用抽象化和 nonce 抽象化。
目前,你的 EOA 發出的交易必須使用帳戶私鑰透過橢圓曲線數位簽章演算法(ECDSA)生成的簽名才能有效。這使大多數 EOA 具有簡單的安全模型:只要私鑰保持在用戶手中,資金就是安全的。但這也有幾個限制:
EOA 出了名地難以保護,尤其是惡意行為者不斷演化出新的方式來竊取私鑰。 在 MetaMask,我們親眼目睹了網路釣魚、社交工程、欺騙、惡意軟體注入等攻擊對 web3 用戶安全構成的挑戰。
自我託管可能感覺像是一項極限運動。 與一般銀行帳戶不同,如果助記詞/私鑰遺失,你無法「恢復」EOA 錢包。這對新用戶來說是一大挑戰,他們必須面對在毫無補救措施的情況下完全失去以太坊帳戶中資產的可能性。
簽名抽象化透過移除 ECDSA 簽名作為非託管帳戶的預設授權機制來解決這些問題。用戶可以自訂授權錢包發起交易的規則。換句話說,你可以決定什麼樣的交易才算有效。
實作簽名抽象化為更進階的授權方案開啟了可能性。如此一來,使用你的 web3 錢包的感覺將與 web2 銀行應用程式相似,甚至更好。以下是一些使用案例:
交易限額: 連結到你智能帳戶的錢包可以拒絕超過預設限額的交易(或要求額外授權)。聽起來很熟悉?應該是的——銀行早已這樣做,以保護你的帳戶和信用卡免受詐欺、未授權使用及其他安全相關問題。
多方審批: 你可以將帳戶的部分控制權委託給受信任的人,即「守護者(guardians)」。守護者可以是朋友、家人、服務提供商,甚至是你自己擁有的另一台設備(例如硬體錢包)。因此,你可以為錢包啟用 web2 風格的多重要素驗證(MFA),要求守護者批准從智能帳戶提款的交易。
金鑰輪換與撤銷: 使用智能帳戶,如果之前的金鑰遺失或被盜,你可以生成新的簽名金鑰。為了額外的安全保障,你可以讓守護者在恢復過程中凍結你的帳戶,並要求批准金鑰輪換/撤銷流程(即社交恢復)。這類似於信用卡遺失或被盜時,你可以凍結信用卡而不會失去對銀行帳戶的存取權。
受信任的工作階段: 你是否厭倦了在瀏覽器中與 dapp 互動時需要批准每一個操作?好消息!你可以用智能帳戶為 dapp 建立特殊的「工作階段金鑰(session keys)」,讓 dapp 在特定時間內自動簽署交易。這意味著你可以與 dapp 互動——例如玩區塊鏈遊戲——而不會被錢包彈出視窗不斷打擾。
從高層次來看,工作階段金鑰基於一個控制你帳戶與 dapp 之間互動的智能合約。你始終掌控工作階段金鑰,並可以規範 dapp 的簽名權限,例如它可以從你的餘額中扣除多少,或者它可以呼叫哪些函數。
自動付款: 類似於工作階段金鑰的概念,你可以授權服務提供商從你的智能帳戶「拉取」資金(受預定義規則約束)。這使得使用 web3 錢包設定定期付款和訂閱成為可能。你能想像用你的以太坊帳戶支付 Netflix 訂閱費或水電費嗎?
目前,每筆以太坊交易都必須包含「gas 費用」,表示發送 EOA 願意為執行支付多少費用。Gas 費用以以太坊的原生代幣以太幣(Ether)計價。這造成了問題,尤其對新用戶而言,他們需要先取得 ETH 才能發送交易。
帳戶抽象化並不消除支付 gas 費用的需求,但它抽象化了用戶選擇如何以及何時支付 gas 的細節(費用抽象化)。例如,帳戶抽象化支援「贊助交易」,由另一個帳戶代為支付用戶交易的 gas 費用。贊助交易的一些優勢:
非 ETH 的 gas 支付: 你是否曾希望可以用錢包中的 ERC-20 代幣支付交易費用?透過贊助交易,你可以讓擁有 ETH 的中繼者(relayer)預先支付你的交易費用,然後用其他代幣(如 DAI 或 USDC)償還。
免 gas 交易: Dapp 開發者可以贊助交易,為新以太坊用戶降低加入門檻。你基本上可以在對「gas」一無所知的情況下使用 web3 應用程式,享受與 web2 應用程式相同的一鍵式體驗。
社交登入:Dapp 可以代表你部署合約錢包,解決在發送鏈上交易前需要先設定錢包的痛點。最棒的是什麼?錢包可以使用身份驗證基礎設施(例如 Web3Auth 和 WebAuthn),讓用戶使用現有憑證(如電子郵件地址或 Facebook/Twitter 帳戶)建立 web3 帳戶。
以太坊上的智能帳戶還有另一個特殊功能:交易批次處理。透過批次交易,你可以將多個操作合併為一筆鏈上交易,降低與 dapp 互動的成本和複雜性。以下是交易批次處理重要的原因:
你的 EOA 儲存了一個稱為「nonce」的值,顯示你已發送了多少筆交易(可以把它想像成交易計數器)。新交易必須嚴格將 nonce 增加 1 才能有效——這條規則可以防止他人「重放」同一筆交易來竊取你的資金(是的,這是可能發生的)。
但這有一個問題。Nonce 迫使你以先進先出(FIFO)的方式處理交易。假設你有兩筆交易(A 和 B),nonce 分別為 0 和 1。在這種情況下,你需要先發送交易 A,等待確認(執行完成)後才能發送 B。
在 A 仍待處理時發送 B,只會導致後者被拒絕,因為 nonce 會超出規定範圍(EOA 當前 nonce + 1)。事實上,這也是你在使用錢包時出現「卡住的交易」的一大原因。
Nonce 抽象化允許你建立自訂的重放保護機制(而不是由以太坊協議強制執行嚴格的交易順序)。例如,你可以設計一種允許並行處理多筆交易的 nonce 方案。這將解決交易堵塞/卡住的問題,並大幅改善與 dapp 的互動體驗。
話雖如此,Nonce 抽象化在實作上相當困難,可能會破壞對安全性和用戶體驗至關重要的某些不變量(例如交易雜湊的唯一性)。這就是交易批次處理發揮作用的地方:
由於智能帳戶可以同時處理多筆交易,複雜 nonce 抽象化方案的需求在很大程度上就消失了。回到之前的例子,我們可以想像交易 A 和 B 只是單一假設操作的一部分,例如在 Uniswap 上交換資產:
交易 A:授權 Uniswap 合約存取你的代幣
交易 B:完成代幣交換
透過交易批次處理,你可以將授權和交換的工作流程合併為一筆交易。結果:更低的 gas 費用,以及使用 dapp 時更短的等待時間。很酷,對吧?
到目前為止,你已經知道帳戶抽象化允許我們為用戶帳戶添加自訂功能和授權策略。但我們還沒有真正討論這一切是如何實現的。本節將討論在以太坊上實作抽象化的不同方法(如果這聽起來不太吸引人,請隨時跳到下一節)。
實現帳戶抽象化有兩種普遍接受的方式:(a)讓 EOA 執行 EVM 程式碼,以及(b)允許智能合約發起交易。因此,你會發現許多帳戶抽象化提案要麼希望 EOA 表現得像智能合約,要麼希望合約帳戶表現得像 EOA。
這自然引出了一些問題:
「這些方法究竟有何不同?」
「我們採用哪種方法重要嗎?」
透過賦予 EOA 執行程式碼的能力,我們可以為用戶控制的帳戶添加複雜的功能。這大幅強化了 EOA,將其轉變為智能帳戶,為原生帳戶抽象化奠定基礎。重要的是,這種方法讓你無需承擔部署新合約帳戶的成本,即可享受可程式化錢包的優勢。
一些將 EOA 升級為合約帳戶的方法涉及將 EOA 交易的資料負載視為 EVM 位元組碼。其他方法則涉及將 EOA 的控制權委託給一個特殊的帳戶合約,由其代表 EOA 進行交易。在後一種情況下,同一個帳戶合約可以被不同的 EOA 重複使用,減少了需要不同合約錢包實作的需求。
以下是一張資訊圖,展示了「讓 EOA 可程式化」陣營中不同的帳戶抽象化提案,包括其主要特點和實作狀態:
透過這種方法,我們升級合約帳戶,使其能夠批准交易並支付 gas 費用(就像 EOA 一樣)。這透過引入能夠充當 EOA 的「超級合約」(即帳戶合約)提供了另一條實現帳戶抽象化的途徑。此外,它還解決了以太坊中一個迫切的問題:協議層面缺乏對合約錢包的支援。
你看——一些智能合約錢包今天已經存在,並提供了帳戶抽象化的許多優勢。但使用這些錢包可能極為困難,因為以太坊將智能合約視為「二等公民」,要求所有交易都必須從 EOA 發起。
這個限制也意味著智能合約錢包缺乏像 MetaMask 這樣的 EOA 錢包所具有的無需信任性和自我託管特性。為了說明這一點,讓我們考慮建立和使用智能合約錢包的流程:
部署一個新的合約帳戶
發送交易以呼叫錢包合約上的函數
問題已經顯而易見:你現在需要管理兩個錢包。為什麼?一個(預先充值 ETH 的)EOA 需要支付部署錢包和之後呼叫必要函數的費用。
這時中繼者(relayers)登場了:EOA 可以代為支付你的錢包交易費用,以換取手續費。智能合約錢包提供商通常會運行中繼者來為用戶補貼交易費用。也就是說,中繼者從其錢包中支付 ETH 來支付你的交易費用,並透過在其他地方向你收費來回收成本——也許是以法幣或其他代幣的形式。
這個系統在大多數情況下運作良好:你可以建立和使用合約錢包,而無需太擔心支付 gas 費用的複雜性。然而,它也需要信任中繼者不會審查或篡改你的交易。
但這是加密貨幣的世界,我們喜歡無需信任的系統。
透過讓合約帳戶批准交易並支付 gas 費用,帳戶抽象化使建立和使用智能合約錢包的過程更加無需信任。具體來說,它允許任何運行中繼者的人代表你執行交易。你只需簽署一條訊息,批准中繼者在執行交易後從你的錢包餘額中扣除費用:
現在,使用智能合約錢包的流程看起來有些不同:
部署錢包合約?透過使用反事實部署工作流程,你可以在部署合約帳戶之前向其發送資金,並從錢包餘額中支付中繼者 EOA 的部署費用。
與錢包合約互動?在鏈下簽署一條訊息,讓中繼者呼叫你的帳戶合約。該訊息將包含一條指令,要求帳戶合約退還中繼者的 gas 費用。
這種實現無需信任和抗審查智能帳戶的理念支撐著這一類別中的許多帳戶抽象化提案。例如,ERC-4337——迄今為止最受歡迎的帳戶抽象化提案——透過引入一個替代的記憶體池(mempool)來去中心化中繼者,用戶可以在其中提交合約錢包交易以供處理。
在這種情況下,中繼者(稱為「打包者(bundlers)」)可以競相執行智能帳戶交易,降低審查風險或對錢包提供商的過度依賴。以下是一張資訊圖,展示了「賦予智能合約 EOA 功能」陣營中不同的帳戶抽象化提案,包括其主要特點和實作狀態:
自 Vitalik Buterin 首次提出這個概念多年後,關於實作帳戶抽象化的最佳方式仍存在一些分歧。例如,實作 EIP-3074 和 EIP-5003 將使現有 EOA(包括 MetaMask 用戶)能夠升級到智能帳戶。但這些提案需要硬分叉,鑑於社群目前專注於更緊迫的升級,這在目前看來似乎不太可行。
相比之下,EIP-4337 獲得了廣泛支持,因為它無需對以太坊協議進行大規模更改即可實作帳戶抽象化。但對於目前使用 EOA 錢包的用戶來說,這意味著需要將資產從 EOA 轉移到新部署的合約帳戶——考慮到目前以太坊上高昂的 gas 費用,這是一個潛在複雜且昂貴的過程。
在 MetaMask,我們相信帳戶抽象化是為新 web3 用戶提供無縫加入體驗的關鍵。我們也清楚,EOA 無法保證加密貨幣的大規模採用(正如以太坊基金會研究員 Yoav Weiss 生動地說:「下一個十億用戶不會把 12 個單詞寫在紙上。」)。
因此,我們已開始思考如何在不影響 MetaMask 用戶所熟悉和喜愛的錢包體驗的情況下,提供帳戶抽象化的優勢。這項努力的一部分包括轉向 MetaMask Snaps——這個無需許可的創新平台允許開發者在現有 MetaMask 基礎設施之上建立自訂功能。
使用 Snaps,開發者可以擴展你的 MetaMask 錢包功能,以支援不同的帳戶抽象化使用案例。從工作階段金鑰到使用 MetaMask 建立的完整智能帳戶整合——全部透過 Snaps 建立——我們看到開發者勇於接受挑戰,利用 MetaMask 讓用戶能夠民主化地存取帳戶抽象化。
目前的帳戶抽象化提案——即便略有不足——也是在以太坊上實現無需信任、抗審查智能帳戶的一大步,值得充分支持。引用我們自己人 Taylor Monahan 的話:「一個已發布的半成品解決方案,仍然好過一個從未發布的完美解決方案。」
這就是為什麼我們關於帳戶抽象化主題的下一篇文章將深入探討 ERC-4337 的細節。重要的是,我們將討論 web3 開發者如何開始建構帳戶抽象化的未來,並透過 MetaMask 一行程式碼一行程式碼地引導下一個十億用戶加入。
敬請期待!
特別感謝 Patrick McCorry、Simon Brown、Mirko Garozzo、Christian Montoya、Oliver Renwick 和 Megan Dias 對本文早期草稿提供的反饋意見。同時感謝 Clarissa Watson 和 Francesco Andreoli 在專案早期階段提供的指導與支持。
AI 翻譯。可能包含錯誤。請務必核實資訊。