🎉 攢成長值,抽華爲Mate三折疊!廣場第 1️⃣ 2️⃣ 期夏季成長值抽獎大狂歡開啓!
總獎池超 $10,000+,華爲Mate三折疊手機、F1紅牛賽車模型、Gate限量週邊、熱門代幣等你來抽!
立即抽獎 👉 https://www.gate.com/activities/pointprize?now_period=12
如何快速賺成長值?
1️⃣ 進入【廣場】,點擊頭像旁標識進入【社區中心】
2️⃣ 完成發帖、評論、點讚、發言等日常任務,成長值拿不停
100%有獎,抽到賺到,大獎等你抱走,趕緊試試手氣!
截止於 8月9日 24:00 (UTC+8)
詳情: https://www.gate.com/announcements/article/46384
#成长值抽奖12期开启#
以太坊帳戶抽象的演進:從EIP-4337到EIP-7702的突破性變革
深入解析以太坊帳戶抽象的演進與未來
前言
本文分爲兩大部分:
第一部分從2015年的首個帳戶抽象提案出發,系統梳理了至今爲止的主要EIP提案內容,回顧了帳戶抽象方案的歷史演進,並評價了各方案的優缺點。
第二部分重點對比了EIP4337推出後市場反應冷淡的情況,並深入分析了即將納入以太坊下一版本升級的EIP7702。該提案一旦合並,將從根本上改變鏈上應用的形態。
EIP-7702作爲劃時代的變革,讓我們詳細探討其內容。
1. 帳戶抽象的背景
1.1 帳戶抽象的定位
以太坊創始人Vitalik在2023年底再次更新了ETH發展路線圖,但對帳戶抽象的設定並未改變。目前主流發展路徑是從EIP-4337進入下一階段的自願EOA轉換(Voluntary EOA Conversion)。
1.2 帳戶抽象的市場現狀
經過一年半的發展,EIP4337在主流鏈上的地址總數僅有1200萬,其中以太坊主網上的活躍地址只有6,764個,與EOA和CA地址數相差甚遠。以太坊主網獨立地址數已達2.7億,可以說EIP4337在主網上幾乎沒有實質性發展。
不過,這並不影響AA的本質價值。EIP4337的設計初衷就是爲了解決主網的向前兼容性問題,因此在各類原生支持AA的L2鏈上獲得了爆發性增長。例如Base和Polygon鏈7月的月活用戶分別達到了100萬和300萬,表現不俗。
因此,EIP4337的設計並非有誤,它具有許多優點。目前的局面主要是由主網與L2之間的差異造成的,它們需要採用各自適合的方案。
2. 什麼是帳戶抽象?
帳戶抽象本質上是解決產權分離的問題。
以太坊虛擬機(EVM)架構中有兩種帳戶類型:外部帳戶(EOA)和合約帳戶(Contract Account)。在外部帳戶中,所有權和籤名權實際上由同一個實體持有。擁有私鑰的人不僅擁有帳戶的"所有權",同時還有權"籤名轉移所有資產"。
這是由以太坊帳戶交易結構決定的。從交易結構可以看出,以太坊的標準交易實際上沒有From字段。那麼一筆資金轉帳是如何確定支出地址的呢?實際上是通過VRS參數(即用戶籤名)反向推導出From地址。
這涉及ECDSA等非對稱加密和單向門限函數等概念,在此不做展開。總之,這種機制是通過密碼學來保障安全性的,但也導致了目前EOA地址產權合並的困境。
而EIP4337的核心作用,就是在交易字段中增加了Sender Address,從而實現私鑰與被操作地址的分離。
產權分離如此重要的原因在於,外部帳戶(EOA)的設計會衍生出更多問題:
私鑰難以保護:用戶丟失私鑰(遺失、被黑客攻擊、密碼學破解)就意味着失去所有資產。
籤名算法單一:原生協議在驗證交易時只能使用ECDSA籤名和驗籤算法。
籤名權限過高:不支持原生多重籤名(多重籤名只能通過智能合約實現),單個籤名即可執行任意操作。
交易手續費只能用ETH支付,不支持批量交易。
交易隱私泄露:一對一交易容易暴露帳戶持有者的隱私信息。
這些限制讓普通用戶很難使用以太坊:
首先,使用以太坊上的任何應用,用戶都必須持有以太幣(並承擔其價格波動風險)。
其次,用戶需要處理復雜的費用邏輯,Gas price、Gas limit、事務阻塞(Nonce順序)等概念對用戶來說過於復雜。
最後,盡管許多區塊鏈錢包或應用試圖通過產品優化提升用戶體驗,但效果有限。
因此,解決方案在於實現帳戶抽象,將所有權(Owner)和籤名權(Signer)解耦(Decoupling),從而逐步解決上述問題。
歷史上提出了多種方案,最終歸納爲兩種主要路線。
3. AA歷史提案脈絡梳理
問題的解決方案看似有多個EIP提案,但歸根結底只有兩種核心思路。每一個未被通過的EIP所考慮的問題,都匯聚成了現有方案的突破點。
3.1 第一種路線:將EOA地址轉變爲CA地址
早在2015年11月15日,圍繞EIP-101,Vitalik就提出了以合約作爲帳戶的新結構。主要改變包括:
這一方案可謂是革命性的變革,會大幅改動底層設計,使每個帳戶地址都擁有自己的"代碼"邏輯(這也正是現在EIP-7702要實現的效果)。
它還能衍生出其他功能,例如:
讓交易使用更多加密算法,可由各地址內部Code指定驗籤鑑權方法
具備抗量子攻擊特性,因爲代碼可以升級
讓以太幣具備與ERC20合約一致的功能特性,核心效果是實現代扣授權,無需消耗原生幣
提升帳戶的自定義空間,兼容社交恢復、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中加入兩個新的操作碼AUTH和AUTHCALL,讓EOA能通過這兩個操作碼授權合約代替EOA的身分去調用其他合約。
簡而言之,一個EOA可以將一個已籤名的消息(交易)發送到自己信任的合約(稱爲Invoker)上,此Invoker合約可以利用AUTH和AUTHCALL操作碼來代替這個EOA發送交易。
EIP-4337:用交易內存池實現帳戶抽象(2021-09-29)
該提案受到MEV的啓發而設計,其核心價值在於完全避免共識層協議的更改。
EIP4337提出了新的事務對象UserOperation,用戶將此對象發送到內存池中,由bundlers從礦工維度批量打包交付合約執行交易事務,本質上是將底層的交易與帳戶運作拉到合約層面執行。
EIP-5189:通過背書人來操作抽象帳戶(2022-06-29)
這可以看作是對EIP4337邏輯的優化,通過建立資金罰款背書(endorser)機制來防止惡意Bundler的DoS阻塞攻擊。
3.3 其他用於支持AA的提案
EIP-2718:新交易類型的包裝信封(2020-06-13)
這是一個已經最終確定的提案,它定義了一個新的交易類型,作爲未來新增交易類型的信封。
最終效果是,當引入新的交易類型時,通過特定編碼來區分不同交易,使其只需具備向後兼容性,而無需向前兼容。最常見的例子就是EIP1559,它區分了交易的手續費,使用了新的交易類型編碼,又不影響最初的legacy交易類型。
EIP-3607:禁止EOA地址部署合約(2021-06-10)
這是AA路徑上的補充方案,用於防止合約部署地址與EOA地址衝突的問題。它會控制合約生成方法,不允許系統將代碼部署到已經是EOA地址的地址上。這個風險其實很小,畢竟以太坊地址有160位長,雖然存在用私鑰碰撞出指定合約地址私鑰的方法,但以比特幣全網算力估算,也還需要一年的時間。
3.4 如何理解帳戶抽象發展歷程?
首先需要理解轉爲CA後的價值
基本上也就是EIP-4337的實際效果,它可以實現:
但是,EIP-4337的核心缺點是違背人性動機原則。
它看似更好,但陷入了一種市場發展的死循環:許多Dapp還不兼容,導致用戶不願使用CA地址。甚至使用CA會產生更高的交易成本(在普通轉帳場景下,交易費用可能翻倍),也過於依賴Dapp本身的兼容性。
因此,在以太坊主網上至今仍未得到普及。
成本是用戶最重要的衡量標準,必須降低成本。
但要真正降低GAS,就必須以太坊本身進行軟分叉升級,修改GAS計算或操作碼的GAS消耗等模塊。既然要軟分叉,何不直接考慮EIP-7702呢?
4. 全面解析EIP-7702
4.1 EIP-7702是什麼
它通過新的交易類型來區分,允許EOA在單筆交易中臨時具備智能合約的功能,進而支持業務上進行批量交易、無Gas交易和自定義權限管理等,且無需引入新的EVM操作碼(影響向前兼容性)。
它可以讓用戶在不部署智能合約的情況下,就能獲得大部分AA的能力,甚至可以提供第三方代用戶發起交易的能力,且不需要用戶提供私鑰,只需籤名授權信息。
4.2 數據結構
它定義了新的交易類型0x04,該交易類型的TransactionPayload是以下內容的RLP編碼序列化結果:
rlp([ chain_id, // 鏈ID,用於防止重放攻擊 nonce, // 交易計數器,確保交易唯一性 max_priority_fee_per_gas, // 1559交易費用 max_fee_per_gas, // 1559交易費用 gas_limit, destination, // 交易目標地址 value, data, access_list, // 訪問列表,用於EIP-2929中的Gas優化 authorization_list, signature_y_parity, // 3個籤名參數,用於驗證交易籤名 signature_r, signature_s ])
重要的是其中新增了authorization_list對象,存儲籤名者希望在其EOA中執行的代碼。用戶簽署交易的同時也簽署要執行的合約代碼,它作爲二維列表存在,說明可