賬戶抽象：改善區(qū)塊鏈交互體驗(yàn)的關(guān)鍵

發(fā)布時間 :

2025 年 2 月 16 日 12:41

為什么要有賬戶抽象？

當(dāng)前區(qū)塊鏈領(lǐng)域還有很多沒被解決的問題，其中區(qū)塊鏈的使用難度，也就是與鏈交互的用戶體驗(yàn)（UX）一定是被公眾詬病最多的一個領(lǐng)域。比如說，很多人認(rèn)為使用密鑰比使用郵箱管理賬戶要復(fù)雜；密鑰管理難度高不安全感強(qiáng)；每次轉(zhuǎn)賬（例如轉(zhuǎn) USDC）需要消耗 native token（例如 Ether 和 Sol）違反直覺。在這個背景下，越來越多的人把目光投向了賬戶抽象領(lǐng)域，以此改善鏈上交互的用戶體驗(yàn)，讓區(qū)塊鏈更容易被大范圍采用（mass adoption）。

在探索的過程中，Ethereum 提出了 ERC-4337、EIP-3074 和 EIP-7702 等賬戶抽象解決方案。而其他公鏈比如 Solana 則存在 Program Derived Addresses (PDA) 這種類似賬戶抽象的方案，Cosmos 也有 x/authz 這類相似設(shè)計。本文我們將介紹和對比上述幾種方案，梳理不同方案設(shè)計的精妙之處，并展示不同方案的取舍考量。

背景

EOA 賬戶與合約賬戶

EOA 賬戶（Externally Owned Account）和合約賬戶是定義在以太坊白皮書中的兩種賬戶類型。EOA 賬戶由私鑰控制，用戶可以通過私鑰簽名各類交易以控制賬戶內(nèi)的資產(chǎn)。合約賬戶由賬戶本身的代碼控制，其他賬戶可以通過調(diào)用合約賬戶的代碼來讓合約賬戶執(zhí)行特定邏輯。

賬戶抽象

賬戶抽象的概念最早可以追溯到 2016 年（https://github.com/ethereum/EIPs/issues/86 ），其意義是在目前以太坊兩種賬戶類型——EOA 賬戶、合約賬戶——之上抽象出一種統(tǒng)一的賬戶類型，也就是賬戶抽象。這將改善以太坊用戶的交互體驗(yàn)：

允許用戶使用多種簽名，比如 Schnorr, BLS, post-quantum 簽名等；
允許用戶使用 ERC20 代幣或者自定義付費(fèi)邏輯支付 gas fee；
允許用戶使用郵箱、社交等方法找回賬戶；
允許用戶采用細(xì)粒度權(quán)限管理自己賬戶的資金，比如設(shè)置每天提現(xiàn)上限；
允許一次原子交易中執(zhí)行多筆鏈上操作，比如用戶一次簽名就可以完成 DEX 交易中的 approve 和 swap 兩個操作。

以太坊路線圖

以太坊路線圖（https://ethereum.org/en/roadmap/）是以太坊未來的升級路線，目前以太坊社區(qū)的大多數(shù)研究都是圍繞著以太坊路線圖展開。賬戶抽象是其中的重要組成部分：

以太坊社區(qū)希望從接下來會介紹的 ERC-4337 出發(fā)，轉(zhuǎn)換 EOA 賬戶為賬戶抽象，并且實(shí)現(xiàn)協(xié)議內(nèi)的賬戶抽象方案（例如接下來會介紹的 EIP-3074 和 EIP-7702）最后達(dá)到 Endgame account abstraction。Endgame account abstraction 除了對用戶交互體驗(yàn)有重要意義外，同時也對以太坊的抗量子計算至關(guān)重要，因?yàn)槟壳暗?EOA 賬戶使用的 ECDSA 算法在量子計算時代是不安全的，可以通過 EOA 轉(zhuǎn)換為賬戶抽象的方法，讓以太坊賬戶支持 post-quantum 簽名。

EIP-3074 與 ERC-4337

要理解賬戶抽象，首先讓我們來了解一下以太坊目前最主流的 EOA 賬戶的工作流程，下圖是鏈上最常見的代幣買賣流程：

用戶在買賣時需要發(fā)出兩筆交易：先授權(quán) Uniswap 劃轉(zhuǎn)自己的 USDC，再向 Uniswap 發(fā)送交易請求，Uniswap 劃轉(zhuǎn)用戶賬戶的 USDC，并按照當(dāng)前價格發(fā)送對應(yīng)數(shù)量的 ETH 給用戶。ERC-4337 簡化了上述步驟：

從上圖可見，用戶需要做兩次簽名，授權(quán) bundler 操作用戶在鏈上托管在 4337 account（并非用戶的 EOA account ）里的資產(chǎn)。Bundler 獲得授權(quán)后將授權(quán)內(nèi)容合并為一個交易發(fā)出。同時，如果用戶沒有以太坊代幣當(dāng) gas fee 時，也可以引入 paymaster 的角色，讓 paymaster 支付 gas fee 并獲得用戶等價值的 ERC20 代幣。

EIP-3074 和 ERC-4337 有一些相似，但是 EIP-3074 的實(shí)現(xiàn)方法更加底層：

在 ERC-4337 中，我們通過簽名授權(quán) bundler 處理我們的鏈上智能合約錢包中的資產(chǎn)。在 EIP-3074 中則是通過簽名授權(quán) bundler 直接處理我們 EOA 錢包中的資產(chǎn)。為了做到這件事，以太坊社區(qū)需要在以太坊協(xié)議中加入兩個新的操作碼（op code）：AUTH 和 AUTHCALL。AUTH 用來驗(yàn)證 bundler 處理用戶 EOA 賬戶資產(chǎn)的行為是否得到授權(quán)，AUTHCALL 用來「騙過」用戶交互的智能合約（在我們的例子中是 USDC 和 Uniswap），讓智能合約以為是用戶的 EOA 賬戶發(fā)出的請求。這樣做的好處是 Uniswap 和 USDC 的維護(hù)者不需要升級已經(jīng)部署的智能合約，同時 EOA 賬戶又能享受到賬戶抽象的功能。

EIP-3074 與 ERC-4337 的比較

在以太坊社區(qū)，EIP 一般指需要以太坊升級才能支持的協(xié)議，ERC 則是不需要以太坊升級也能支持的協(xié)議。所以從兩個賬戶抽象方案的命名可以看出，ERC-4337 更容易被實(shí)現(xiàn)，因?yàn)樗恍枰卜植婢涂梢詫?shí)現(xiàn)。這也是 ERC-4337 已經(jīng)上線，并且在 polygon 和 base 上被越來越多使用，但是 EIP-3074 剛被 183 次 Ethereum All Core Developers Execution Call(ACDE) 接受的一個原因。

除此之外，ERC-4337 需要用戶將當(dāng)前賬戶遷移至新的合約賬戶，并且需要 DApp 支持 EIP-1271 才能使用 ERC-4337。 EIP-3074 則不需要這些額外支持。這是導(dǎo)致 ERC-4337 采用率不高的一大原因。同時 ERC-4337 在不引入中間 multi call 合約的情況下，無法支持一次簽名授權(quán)多次鏈上操作，但是 EIP-3074 可以，這也造成了 ERC-4337 的局限性。

不過 EIP-3074 也有自己的問題，最主要的就是操作碼 AUTH 權(quán)限太高，實(shí)施不當(dāng)，可能讓攻擊者完全控制用戶的 EOA 賬戶。畢竟只要黑客騙取了您的 AUTH 簽名，就可以處置您 EOA 錢包內(nèi)的資產(chǎn)。考慮到目前釣魚攻擊猖獗，而且大多是騙取用戶的簽名，當(dāng) EIP-3074 實(shí)施，這會變成一個比較嚴(yán)重的問題。對此，EIP-3074 的作者 lightclient 提出過緩解的辦法，通過錢包層面攔截惡意簽名，具體可參考：https://x.com/lightclients/status/1778823652584120497。ERC-4337 則不會有這個問題，雖然黑客也可以騙取用戶簽名惡意的 UserOp，但是一個 UserOp 一般很難得到用戶賬戶內(nèi)所有資產(chǎn)的處置權(quán)限。在撰寫本文時，ACDE 開發(fā)者們同意從 Pectra Devent 0 中移除 EIP-3704，并在下一個 Pectra Devnet 1 中包含 EIP-7702。

EIP-7702 又改進(jìn)了什么？

EIP-7702 試圖融合 EIP-3074 和 ERC-4337 兩邊的成果，形成一條中間路線。用戶將簽名好的操作發(fā)給 bundler，bundler 上鏈交易時用戶的 EOA 賬戶會臨時變成智能合約賬戶（比如 4337 賬戶）。接下來和 EIP-3074 中的 AUTH 過程一樣，該智能合約賬戶會將用戶授權(quán) bundler 的操作標(biāo)記為合法。之后如同 AUTHCALL，執(zhí)行用戶授權(quán)的操作。執(zhí)行完交易后，用戶賬戶回滾會普通的 EOA 賬戶。

該方案的好處如下：

繼承了 EIP-3074 的所有優(yōu)點(diǎn)：不需要用戶從 EOA 賬戶切換至新地址的智能合約賬戶；能夠在一次原子交易中執(zhí)行多個操作；
可以復(fù)用 ERC-4337 的智能合約賬戶代碼以及基礎(chǔ)設(shè)施；
可以合并 ERC-4337 為代表的智能合約賬戶抽象和以 EIP-3074 為代表的 EOA 賬戶抽象方案，防止以太坊分裂出兩套不同的賬戶抽象系統(tǒng)，為以太坊路線圖中的 Endgame Abstraction Account 鋪路；
不會在以太坊的 EVM 里增加 AUTH 和 AUTHCALL 兩個 op code，考慮到以太坊路線圖，未來 EOA 賬戶會被轉(zhuǎn)換為賬戶抽象，屆時這兩個 op code 會變得多余。

除此之外，EIP-7702 繼承了來自 EIP-3074 的所有安全風(fēng)險。

目前 EIP-7702 已經(jīng)被 ACDE 放入了 2025 年的 Pectra 升級之中。如果實(shí)施將會極大改變以太坊生態(tài)，并且為當(dāng)前 ERC-4337 版本賬戶抽象的基礎(chǔ)設(shè)施帶來增量。

Solana 的程序派生地址

在 Solana 上的賬戶抽象

Solana 的賬戶抽象類似以太坊 ERC-4337，是由原始賬戶（類似 EOA 賬戶）派生出的賬戶（類似 4337 合約賬戶）。在了解 Solana 賬戶抽象前，我們有必要了解 Solana 使用的賬戶模型。

廣義上說，賬戶可以分為可執(zhí)行賬戶和不可執(zhí)行賬戶兩類。進(jìn)一步來說，在 Solana 上有三種類型的賬戶：本地程序賬戶（Native Program）、程序賬戶（Program Account）和數(shù)據(jù)賬戶（Data Account）。

本地程序是驗(yàn)證器實(shí)現(xiàn)的一部分，為 Solana 網(wǎng)絡(luò)提供核心功能，如創(chuàng)建新的數(shù)據(jù)賬戶和自定義程序。程序賬戶是包含可執(zhí)行代碼的自定義程序。數(shù)據(jù)賬戶可以存儲數(shù)據(jù)，并根據(jù)其所有者程序賬戶的定義管理程序狀態(tài)。

這種賬戶模型本地支持程序賬戶創(chuàng)建和管理特定賬戶，為開發(fā)人員提供了定義自定義規(guī)則和邏輯以管理它們的能力。借助這種賬戶模型，程序派生地址（PDA），一種數(shù)據(jù)賬戶類型，將 Solana 上的賬戶抽象能力擴(kuò)展到從增強(qiáng)用戶安全性（通過多簽錢包和兩步驗(yàn)證等方式）到啟用社交恢復(fù)機(jī)制等多個方面。

程序派生地址（PDA）

為了了解背景，所有賬戶都位于 Ed25519 曲線上，并具有公私鑰對。PDA 位于 Ed25519 曲線之外，是一個確定性派生的 32 字節(jié)字符串，看起來像一個公鑰，并且沒有相應(yīng)的私鑰。PDA 允許開發(fā)人員創(chuàng)建自定義規(guī)則和交易簽名機(jī)制，使得 PDA 的程序賬戶所有者能夠代表 PDA 自主進(jìn)行交易，也得到 Solana 網(wǎng)絡(luò)的支持。

PDA 和賬戶抽象

既然我們了解了 PDA 是如何派生的，您可能會想知道這些概念如何與賬戶抽象聯(lián)系起來。賬戶抽象通過名為跨程序調(diào)用（CPI）的函數(shù)在底層實(shí)現(xiàn)。CPI 是一種使一個程序能夠調(diào)用另一個程序的指令的函數(shù)，允許 Solana 程序的可組合性。當(dāng)一個程序通過 invoke_signed 發(fā)起 CPI 時，程序能夠代表其程序 ID 派生的 PDA 進(jìn)行簽名。

為了驗(yàn)證涉及 PDA 的交易的合法性，Solana 運(yùn)行時會在內(nèi)部使用簽名者種子和調(diào)用程序的程序 ID 調(diào)用 create_program_address。如果找到有效的 PDA，該地址將被添加為有效簽名者。運(yùn)行時還會使用授予調(diào)用程序的權(quán)限來確定可以擴(kuò)展到被調(diào)用程序的權(quán)限。

當(dāng)前 Squads 正在基于 PDA 開發(fā) Solana 上的賬戶抽象方案，不過目前 Squads 提供的產(chǎn)品更加類似于 Gnosis Safe 的智能合約賬戶方案，還沒有完善其賬戶抽象的功能。

PDA 的好處

自動化智能合約執(zhí)行：PDA 允許更復(fù)雜的智能合約設(shè)計，通過跨程序調(diào)用可以自主地代表用戶執(zhí)行多個操作。
增強(qiáng)用戶體驗(yàn)：用戶不需要管理多個交易或接觸技術(shù)復(fù)雜性。
增強(qiáng)的安全性和靈活性：沒有私鑰，這可以減少密鑰泄露的風(fēng)險。PDA 可以用于多簽名錢包或適應(yīng)其他靈活的治理模型，從而減少單點(diǎn)風(fēng)險，對于管理大量共享資源的組織特別有用。

程序派生地址的限制

盡管 PDA 在為賬戶抽象能力奠定基礎(chǔ)方面具有優(yōu)勢，但與密鑰對賬戶相比，其實(shí)現(xiàn)起來可能更為復(fù)雜。
和 ERC-4337 一樣，它需要用戶進(jìn)行賬戶遷移，這可能會抑制 Solana 賬戶抽象的使用率。

Cosmos 上的賬戶抽象 (Authz & Fee Grant)

Cosmos 上的 x/authz

隨著賬戶抽象越來越受到開發(fā)者的關(guān)注，Cosmos SDK 核心組建推出了 authz 模塊，以允許一個賬戶通過使用授權(quán)許可來代表另一個賬戶執(zhí)行某些操作，這種設(shè)計思路比較類似與 EIP-3074 和 EIP-7702。

Authz 提供了更全面的授權(quán)類型，開啟了抽象各種復(fù)雜性的可能性，這些復(fù)雜性以前導(dǎo)致了次優(yōu)的用戶體驗(yàn)。

通過 authz，可以給予三種類型的授權(quán)：

通用授權(quán)（GenericAuthorization）。這種授權(quán)許可給予受讓人無限制的權(quán)限，以代表授予人執(zhí)行消息。
發(fā)送授權(quán)（SendAuthorization）。這種授權(quán)旨在給予受讓人訪問授予人賬戶某一資產(chǎn)的最大數(shù)量。
質(zhì)押授權(quán)（StakeAuthorization）。這種授權(quán)允許受讓人代表授予人管理質(zhì)押操作，如委托、撤銷委托或重新委托。

一個授權(quán)包括授予人的地址字節(jié)、受讓人的地址字節(jié)和授權(quán)類型。還可以定義時間段以限制在特定時間段內(nèi)的權(quán)限。在每個區(qū)塊結(jié)束時，網(wǎng)絡(luò)將移除過期的授權(quán)。

理解操作框架

Authz 可用于授予各種操作的授權(quán)，但為了簡單起見，我們將看一下 authz 如何工作以啟用通用投票交易。

在執(zhí)行任何授權(quán)之前，需要實(shí)現(xiàn)授權(quán)接口。在此階段，還將定義消息類型，本例中為 MsgVote。在這里，我們看到 Alice 授予了對治理投票行動的授權(quán)。
Bob 生成未簽名的投票交易。
Bob 生成由 Alice 簽署并執(zhí)行的投票交易。如果授權(quán)已過期，交易將完成并且授權(quán)將被移除。

Authz 帶來的好處是什么？

操作安全性：驗(yàn)證人和其他用戶可以授予單獨(dú)的賬戶權(quán)限，以投票支持治理提案或執(zhí)行特定操作，增強(qiáng)賬戶安全性并減輕安全負(fù)擔(dān)。
簡化操作：可以進(jìn)行交易而無需訪問驗(yàn)證人密鑰，多重簽名錢包交易也可以使用單個交易來向受讓人賬戶授予 authz 以簡化操作。
不需要遷移賬戶：和 EIP-3074、EIP-7702 類似，用戶可以在現(xiàn)有賬戶上使用 authz，不需要把資產(chǎn)遷移到新賬戶。
DAO 的操作效率和靈活性：可以為特定操作向個體 DAO 成員授予執(zhí)行權(quán)限的子集。
質(zhì)押獎勵復(fù)利：authz 促進(jìn)了對 restaing 和類似服務(wù)的使用，以實(shí)現(xiàn)質(zhì)押獎勵的自動復(fù)利。

Authz 的限制和風(fēng)險：

注意通過 authz 授權(quán)的交易類型。惡意的 MsgGrant 可以執(zhí)行各種類型的授權(quán)，可能對用戶造成損害。
通用授權(quán)：給予他人受讓人賬戶的無限授權(quán)，如果黑客利用釣魚攻擊騙取受讓人簽名，會導(dǎo)致受讓人賬戶資產(chǎn)被盜。有些錢包在簽署 authz 交易時可能不會提供警告。
發(fā)送授權(quán)：允許受讓人發(fā)送授予人未指定的最大數(shù)量的代幣。重要的是要驗(yàn)證 AllowList，該列表指定了受讓人可以將代幣發(fā)送到的具體地址。

Fee grant 模塊

另一個讓用戶體驗(yàn)受挫的障礙是區(qū)塊鏈用戶需要持有各種本地代幣才能與這些不同的生態(tài)系統(tǒng)互動。這對那些首次接觸 Cosmos 生態(tài)系統(tǒng)中眾多鏈條的非加密本地用戶來說，整體用戶體驗(yàn)受到了影響。然而，通過 fee grant 模塊的整合可以改善用戶體驗(yàn)。類似于在以太坊上實(shí)現(xiàn)賬戶抽象的 paymaster 合約，Cosmos 上的 fee grant 模塊允許授予者向受益者授予交易手續(xù)費(fèi)額度，支付部分或全部交易費(fèi)用。資金仍然由授予者控制，并且可以隨時撤銷授予的額度。

Fee grant 類型

手續(xù)費(fèi)津貼可以分為兩種類型：基本津貼（BasicAllowance）和定期津貼（PeriodicAllowance)。

基本津貼允許受讓人使用授予人賬戶中的費(fèi)用，直到達(dá)到消費(fèi)限額或到期時間。然后，該授權(quán)將從狀態(tài)中終止。需要注意的是，基本津貼實(shí)施的是一次性費(fèi)用授權(quán)。如果消費(fèi)限額和時間為空，則費(fèi)用津貼沒有到期和消費(fèi)上限。

定期津貼使費(fèi)用授權(quán)在每個指定的時間段后定期更新。period_spend_limit 指定了該期間內(nèi)可以花費(fèi)的最大金額。period_reset 跟蹤下一個期間應(yīng)該何時開始，period_can_spend 跟蹤新期間開始前剩余的可花費(fèi)金額。

理解操作框架

使用 AllowedMsgAllowance 可以為指定的消息類型創(chuàng)建津貼。津貼可以是基本津貼（BasicAllowance）或定期津貼（PeriodicAllowance）。如果設(shè)置了到期時間，F(xiàn)eeAllowance 將在狀態(tài)中排隊，并在授權(quán)后附加到期前綴，Endblocker 會檢查 FeeAllowanceQueue 狀態(tài)中是否有到期的授權(quán)，如果發(fā)現(xiàn)則將其剔除。除了 MsgGrantAllowance 之外，費(fèi)用額度也可以通過 MsgRevokeAllowance 撤銷。

總體而言，authz 和 Fee Grant 模塊解鎖了創(chuàng)新和多樣的用例，最終在 Cosmos 生態(tài)系統(tǒng)中打造了更好的用戶體驗(yàn)。

對比與總結(jié)

賬戶抽象

隨著現(xiàn)貨比特幣 ETF 和以太坊 ETF 的批準(zhǔn)，機(jī)構(gòu)和零售投資者的需求大幅增加，預(yù)示著將迎來一波尋求行業(yè)曝光的新用戶。隨著協(xié)議和 DApp 尋求創(chuàng)造無縫體驗(yàn)來擴(kuò)大其社區(qū)，賬戶抽象將成為今年重要的敘事。