深入解讀以太坊帳戶抽象賽道的過去與未來

前言

本文分爲兩大模塊:

上半部分從2015年首個AA提案出發,系統梳理迄今爲止的EIP提案主要內容,探討AA歷史提案的演進歷程,並綜合評價各方案優劣。

下半部分重點對比EIP4337推出後面臨的市場冷淡反應,深入分析即將納入以太坊下一版本升級的EIP7702,該提案一旦合並將全面改變鏈上應用形態。

EIP-7702具有劃時代意義,讓我們詳細了解一下。

1. 帳戶抽象的背景

1.1 帳戶抽象的意義定位

以太坊創始人Vitalik在2023年底再次更新ETH路線圖,但對帳戶抽象的定位未做改動。目前主流模式正從EIP-4337邁向下一階段"自願轉換EOA帳戶"。

在EIP4337推出一年多以來(2023年3月1日在丹佛WalletCon上,以太坊基金會開發人員設計實現的ERC-4337核心合約通過OpenZeppelin審計,被認爲正式推出),始終得到用戶廣泛認可但未被廣泛使用。在這種矛盾的市場環境下,EIP-7702的進度大幅提前,已確認將在下次升級中合並。

1.2 帳戶抽象的市場現狀

一年半發展後,EIP4337在主流鏈上僅有1200萬地址,其中以太坊主網活躍地址僅6,764個,與EOA和CA地址數相差甚遠。以太坊主網獨立地址數已達2.7億,可以說EIP4337在主網上毫無實質性發展。

不過這並不影響AA的本質價值。EIP4337設計之初就注定難以解決主網向前兼容性問題。隨着各類L2原生嵌入AA,EIP4337地址數在L2上爆發,其中Base和Polygon鏈7月月活分別達100萬和300萬,頗爲可觀。

因此,並非EIP4337設計有誤,它有諸多優點。當前狀況源於主網與L2的差異,它們需要各自適合的方案。

2. 帳戶抽象是什麼?

帳戶抽象本質上解決產權分離問題。

EVM架構中有兩種帳戶:外部帳戶(EOA)和合約帳戶(Contract Account)。外部帳戶的所有權和籤名權由同一實體持有。持有私鑰的人不僅擁有帳戶"所有權",還可以"籤名轉移所有資產"。

這由以太坊帳戶交易結構決定。標準交易中實際沒有From字段,資金轉帳通過VRS參數(用戶籤名)反解析出From地址。這涉及ECDSA等非對稱加密,單向門限函數等概念,由密碼學保障安全性,也造成了如今EOA地址產權合並的窘境。

EIP4337核心效果是在交易字段中增加Sender Address,從而分離私鑰與被操作地址。

產權分離之所以重要,是因爲外部帳戶(EOA)設計衍生出更多問題:

1. 私鑰難保護:丟失私鑰意味着失去所有資產。
2. 籤名算法單一:原生協議驗證交易僅能使用ECDSA算法。
3. 籤名權限過高:無原生多籤,單籤即可執行任意操作。
4. 交易手續費只能用ETH支付,不支持批量交易。
5. 交易隱私泄露:一對一交易易分析帳戶持有者隱私信息。

這些限制導致普通用戶難以使用以太坊:

首先,使用任何以太坊應用都需持有ETH並承擔價格波動風險。

其次,用戶需處理復雜的費用邏輯,Gas price、Gas limit、交易阻塞(Nonce順序)等概念過於復雜。

最後,雖然許多區塊鏈錢包或應用試圖通過產品優化提升用戶體驗,但實際效果甚微。

因此,解決之道在於實現帳戶抽象,將所有權(Owner)和籤名權(Signer)解耦,從而逐個解決上述問題。

歷史上有多種方案,最終匯聚爲兩條路線。

3. AA歷史提案脈絡梳理

問題解法看似有多個EIP提案,但歸根結底只有兩種核心思路。每個未通過的EIP考慮的問題都匯聚成了現有方案的突破點。

3.1 第一種路線:將EOA地址變爲CA地址

2015年11月15日,Vitalik就在EIP-101中提出以合約作爲帳戶的新結構。將地址改爲只有代碼和存儲空間,改變手續費支持ERC20支付,通過預編譯合約將原生代幣改爲類ERC20存餘額(具備代扣授權等功能),將交易字段精簡爲to、startgas、data和code。

這是大躍進式變革,會大幅改動底層設計,讓每個帳戶地址都擁有自己的"代碼"邏輯(正是現在EIP-7702要實現的效果)。

還能衍生出其他功能,如:

1. 交易使用更多加密算法,各地址內部Code指定驗籤鑑權方法
2. 具備抗量子攻擊特性,代碼可升級
3. 以太幣具備ERC20合約一致功能,核心效果有代扣授權,無需原生幣損耗
4. 提升帳戶自定義空間,兼容社交恢復、SBT支持、密鑰找回等

未繼續推進原因很簡單,步伐太大,對當前交易哈希衝突問題、安全性隱患考慮不周而擱置,但每個優點理念都成爲後續EIP4337和EIP7702的核心功能之一。

後來還有一系列EIP試圖完善這種邏輯:

EIP-859:主鏈帳戶抽象(2018-01-30)

試圖解決Code部署問題,核心作用是若交易方合約未部署,則使用交易附帶code參數執行合約錢包部署。還提出新的PAYGAS操作碼,除支付gas外,也成爲交易參數中驗證部分與執行部分的分隔符。

雖然當時無疾而終,但成爲現在EIP7702的核心邏輯之一。EIP7702每筆交易結合特殊交易結構,可附帶一定代碼,讓EOA地址在本次交易中擁有合約能力。

EIP-7702:設置EOA帳戶代碼(2024-05-07)

這是本文後續討論機制的核心EIP,由Vitalik發表作爲EIP-3074的替代方案。因此EIP-3074被棄用,EIP-7702確定在即將到來的ETH Prague/Electra(Pectra)硬分叉中納入。

3.2 第二種路線:讓EOA地址驅動CA地址

EIP-3074:增加AUTH和AUTHCALL操作碼(2020-10-15)

在EVM中加入兩個新OpCodes:AUTH和AUTHCALL,讓EOA能通過這兩個opcode授權合約代替EOA身分調用其他合約。

概括來說,EOA可將已籤名的消息(交易)發送至信任的合約(稱作Invoker),此Invoker合約可利用AUTH和AUTHCALL操作碼代替EOA發出交易。

EIP-4337:用交易內存池實現帳戶抽象(2021-09-29)

受MEV啓發設計,核心價值是完全避免共識層協議更改。

EIP4337提出新的事務對象UserOperation,用戶將此對象發送到內存池,由bundlers從礦工維度批量打包交付合約執行交易事務,本質上是將底層交易與帳戶運作拉到合約層面執行。

EIP-5189:通過背書人操作抽象帳戶(2022-06-29)

優化了EIP4337邏輯,面對惡意Bundler通過建立資金罰款背書endorser機制防止DoS阻塞攻擊。

3.3 其他支持AA的提案

EIP-2718:新交易類型的包裝信封(2020-06-13)

已Final的提案,定義新交易類型作爲未來新增交易類型的信封。

最終效果是引入新交易類型時,通過特定編碼區分,只需向後兼容,無需往前兼容。最常見例子是EIP1559,區分了交易手續費,使用新交易類型編碼,不影響最初legacy交易類型。

EIP-3607:讓EOA地址不可部署合約(2021-06-10)

AA路徑上的補充方案,防止合約部署地址與EOA地址衝突。控制合約生成方法,系統不允許將代碼部署到已是EOA地址的地址上。這風險很小,以太坊地址有160位長,雖存在用私鑰碰撞出指定合約地址私鑰的方法,但以比特幣全算力投入估計也需一年時間。

3.4 如何理解帳號抽象發展歷程?

首先需理解轉爲CA後的價值

基本上就是EIP-4337的實際效果,可實現:

1. 任意代幣支付gas
2. 批量交易
3. 籤名的可編程性
4. 錢包邏輯可升級
5. 多籤和社交恢復
6. 無gas交易
7. 可編程的gas支付

但是,EIP-4337的核心缺點是違背人性動機原則。

看似更好,但陷入市場發展死循環。很多Dapp不兼容,用戶不願使用CA地址,使用CA甚至有更高交易成本(普通轉帳場景,交易費用翻倍),太依賴Dapp本身兼容性。

所以在以太坊主網上迄今始終未普及。

成本是用戶最重要衡量標準,必須降低成本。

但真正降低GAS,就必須以太坊本身做軟分叉升級,修改GAS計算或修改操作碼GAS消耗等模塊。既然要軟分叉,何不直接考慮EIP-7702?

4. 全面解析EIP-7702

4.1 EIP-7702是什麼

通過新交易類型區分,允許EOA在單筆交易中臨時具備智能合約功能,進而支持業務上批量交易、無Gas交易和自定義權限管理等,且無需引入新EVM opCode(影響往前兼容性)。

可讓用戶在不部署智能合約情況下,獲得大部分AA能力,甚至提供第三方代用戶發起交易的能力,且不需用戶提供私鑰,只需籤名授權信息。

4.2 數據結構

定義新交易類型0x04,該交易類型TransactionPayload是下列內容的RLP編碼序列化結果:

rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, value, data, access_list, authorization_list, signature_y_parity, signature_r, signature_s])

重要的是新增authorization_list對象,存儲籤名者希望在其EOA中執行的代碼。用戶簽署交易同時也簽署要執行的合約代碼,作爲二維列表存在,說明可批量存放多個操作信息,執行批量操作。

authorization_list = [[chain_id, address, nonce, y_parity, r, s], ...]

4.3 交易生命週期

4.3.1 驗證階段

執行交易開始階段,對每個authorization_list的[chain_id, address, nonce, y_parity, r, s]元組:

1. 從籤名r、s採用ecrecover恢復籤名者地址(以太坊本身機制,該EIP未改變籤名算法)。
2. 驗證鏈ID(防分叉鏈重放)。
3. 驗證authority籤名者代碼是否爲空或已委托(驗證交易是否爲有效7702交易,後續通過delegation機制代理執行交易)。
4. 驗證authority籤名者nonce(防authority籤名重放)。
5. 設置authority籤名者代碼爲0xef0100 || address(繞過EIP3607防碰撞策略)。
6. 增加authority籤名者nonce(防局部籤名重放)。
7. 將authority籤名者帳戶添加到已訪問地址列表(轉熱地址,降低查詢存儲gas費)。

4.3.2 執行操作階段