賬戶抽象：改善區塊鏈交互體驗的關鍵

發布時間 :

2025 年 2 月 16 日 12:41

為什么要有賬戶抽象？

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

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

背景

EOA 賬戶與合約賬戶

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

賬戶抽象

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

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

以太坊路線圖

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

以太坊社區希望從接下來會介紹的 ERC-4337 出發，轉換 EOA 賬戶為賬戶抽象，并且實現協議內的賬戶抽象方案（例如接下來會介紹的 EIP-3074 和 EIP-7702）最后達到 Endgame account abstraction。Endgame account abstraction 除了對用戶交互體驗有重要意義外，同時也對以太坊的抗量子計算至關重要，因為目前的 EOA 賬戶使用的 ECDSA 算法在量子計算時代是不安全的，可以通過 EOA 轉換為賬戶抽象的方法，讓以太坊賬戶支持 post-quantum 簽名。

EIP-3074 與 ERC-4337

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

用戶在買賣時需要發出兩筆交易：先授權 Uniswap 劃轉自己的 USDC，再向 Uniswap 發送交易請求，Uniswap 劃轉用戶賬戶的 USDC，并按照當前價格發送對應數量的 ETH 給用戶。ERC-4337 簡化了上述步驟：

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

EIP-3074 和 ERC-4337 有一些相似，但是 EIP-3074 的實現方法更加底層：

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

EIP-3074 與 ERC-4337 的比較

在以太坊社區，EIP 一般指需要以太坊升級才能支持的協議，ERC 則是不需要以太坊升級也能支持的協議。所以從兩個賬戶抽象方案的命名可以看出，ERC-4337 更容易被實現，因為它不需要硬分叉就可以實現。這也是 ERC-4337 已經上線，并且在 polygon 和 base 上被越來越多使用，但是 EIP-3074 剛被 183 次 Ethereum All Core Developers Execution Call(ACDE) 接受的一個原因。

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

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

EIP-7702 又改進了什么？

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

該方案的好處如下：

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

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

目前 EIP-7702 已經被 ACDE 放入了 2025 年的 Pectra 升級之中。如果實施將會極大改變以太坊生態，并且為當前 ERC-4337 版本賬戶抽象的基礎設施帶來增量。

Solana 的程序派生地址

在 Solana 上的賬戶抽象

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

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

本地程序是驗證器實現的一部分，為 Solana 網絡提供核心功能，如創建新的數據賬戶和自定義程序。程序賬戶是包含可執行代碼的自定義程序。數據賬戶可以存儲數據，并根據其所有者程序賬戶的定義管理程序狀態。

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

程序派生地址（PDA）

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

PDA 和賬戶抽象

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

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

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

PDA 的好處

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

程序派生地址的限制

盡管 PDA 在為賬戶抽象能力奠定基礎方面具有優勢，但與密鑰對賬戶相比，其實現起來可能更為復雜。
和 ERC-4337 一樣，它需要用戶進行賬戶遷移，這可能會抑制 Solana 賬戶抽象的使用率。

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

Cosmos 上的 x/authz

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

Authz 提供了更全面的授權類型，開啟了抽象各種復雜性的可能性，這些復雜性以前導致了次優的用戶體驗。

通過 authz，可以給予三種類型的授權：

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

一個授權包括授予人的地址字節、受讓人的地址字節和授權類型。還可以定義時間段以限制在特定時間段內的權限。在每個區塊結束時，網絡將移除過期的授權。

理解操作框架

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

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

Authz 帶來的好處是什么？

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

Authz 的限制和風險：

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

Fee grant 模塊

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

Fee grant 類型

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

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

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

理解操作框架

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

總體而言，authz 和 Fee Grant 模塊解鎖了創新和多樣的用例，最終在 Cosmos 生態系統中打造了更好的用戶體驗。

對比與總結

賬戶抽象

隨著現貨比特幣 ETF 和以太坊 ETF 的批準，機構和零售投資者的需求大幅增加，預示著將迎來一波尋求行業曝光的新用戶。隨著協議和 DApp 尋求創造無縫體驗來擴大其社區，賬戶抽象將成為今年重要的敘事。