以太坊Pectra升級:EIP-7702深度解析及最佳實踐

前言

以太坊即將迎來Pectra升級,這是一次意義重大的更新,多項重要的以太坊改進提案將被引入。其中,EIP-7702對以太坊外部帳戶(EOA)進行了變革性改造。該提案模糊了EOA與合約帳戶CA之間的界限,是繼EIP-4337之後,朝着原生帳戶抽象邁進的關鍵一步,爲以太坊生態系統帶來了全新的交互模式。

Pectra已在測試網絡完成部署,預計不久後將上線主網。本文將深入分析EIP-7702的實現機制,探討其可能帶來的機遇與挑戰,並爲不同參與者提供實用的操作指南。

協議分析

概述

EIP-7702引入了一種新的交易類型,允許EOA指定一個智能合約地址,爲其設置代碼。這使EOA能夠像智能合約一樣執行代碼,同時保留發起交易的能力。這一特性爲EOA賦予了可編程性與可組合性,用戶可以在EOA中實現社交恢復、權限控制、多籤管理、zk驗證、訂閱式支付、交易贊助以及交易批處理等功能。值得注意的是,EIP-7702能與EIP-4337實現的智能合約錢包完美兼容,二者的無縫集成大大簡化了新功能的開發與應用過程。

EIP-7702引入了交易類型爲SET_CODE_TX_TYPE (0x04)的交易,其數據結構定義如下:

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字段定義爲:

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

在新的交易結構中,除authorization_list字段外,其餘遵循與EIP-4844相同的語義。該字段是列表類型,可包含多個授權條目,每個授權條目中:

• chain_id表示此授權委托所生效的鏈
• address表示委托的目標地址
• nonce需與當前授權帳戶的nonce匹配
• y_parity, r, s是授權帳戶簽署授權的籤名數據

一筆交易內的authorization_list字段可包含多個不同授權帳戶(EOA)簽署的授權條目,即交易發起者可與授權者不同,以實現對授權者的授權操作進行gas代付。

實現

授權者簽署授權數據時,需先將chain_id, address, nonce進行RLP編碼。然後將編碼後的數據與MAGIC數一起進行keccak256哈希運算,得到待籤名的數據。最後,使用授權者的私鑰對哈希後的數據籤名,獲得y_parity, r, s數據。MAGIC (0x05)作爲域分隔符使用,目的是確保不同類型籤名的結果不會衝突。

當授權者授權的chain_id爲0時,表示授權者允許在所有支持EIP-7702的EVM兼容鏈上重放授權(前提是nonce也剛好匹配)。

授權者簽署完授權數據後,交易發起者會將其匯聚在authorization_list字段中進行籤名並通過RPC廣播交易。在交易被包含在區塊中執行前,Proposer會先對交易進行預檢查,其中對to地址進行強制檢查以確保此交易不是合約創建交易,即發送EIP-7702類型的交易時,交易的to地址不能爲空。

同時,此類交易要求authorization_list字段必須至少包含一項授權條目,如有多個授權條目都由同一個授權者簽署,最終只有最後一個授權條目起效。

交易執行過程中,節點會先增加交易發起者的nonce數值,再對authorization_list中的每個授權條目進行applyAuthorization操作。在applyAuthorization操作中,節點會先檢查授權者的nonce,然後再增加授權者的nonce。這意味着如果交易發起者與授權者爲同一用戶(EOA)時,在簽署授權交易時nonce的數值應該再加1。

節點應用某個授權條目時,如遇任何錯誤,該條授權條目將被跳過,交易不會失敗,其他授權條目會繼續應用,以此確保在批量授權場景中不會出現DoS風險。

授權應用完成後,授權者地址的code字段將被設置爲0xef0100 || address,其中0xef0100是固定標識,address是委托的目標地址。由於EIP-3541的限制,用戶無法通過常規方式部署0xef字節開頭的合約代碼,這保證了此類標識只能由SET_CODE_TX_TYPE (0x04)類型的交易才能部署。

授權完成後,授權者若要移除授權,只需將委托的目標地址設置爲0地址即可。

通過EIP-7702引入的新交易類型,使授權者(EOA)既可像智能合約一樣執行代碼,也同時保留了發起交易的能力。相較於EIP-4337,這爲用戶帶來了更接近原生帳戶抽象(Native AA)的體驗,極大降低了用戶的使用門檻。

最佳實踐

盡管EIP-7702爲以太坊生態注入了新活力,但新的應用場景也會帶來新的風險。以下是生態參與者在實踐過程中需要警惕的方面:

私鑰存儲

即便EOA在委托後可借助智能合約內置的社交恢復等手段解決因私鑰丟失導致的資金損失問題,但它仍無法避免EOA私鑰被泄露的風險。需要明確的是,執行委托後,EOA私鑰依舊對帳戶擁有最高控制權,持有私鑰便能隨意處置帳戶中的資產。用戶或錢包服務商在爲EOA完成委托後,即便完全刪除存儲在本地的私鑰,也不能完全杜絕私鑰泄露風險,尤其是處於存在供應鏈攻擊風險的場景中。

對於用戶來說,在使用委托後的帳戶時,仍應將私鑰保護放在首位,時刻注意:Not your keys, not your coins。

多鏈重放

用戶在簽署委托授權時,能通過chainId選擇委托可以生效的鏈,當然用戶也可以選擇使用chainId爲0進行委托,這使得委托可以在多鏈上重放生效,以方便用戶一次籤名即可在多鏈上進行委托。但需注意的是,在多鏈上委托的同一合約地址中,也可能存在不同的實現代碼。

對於錢包服務商來說,在用戶進行委托時,應檢查委托生效鏈與當前連接的網路是否相符,並提醒用戶簽署chainId爲0的委托可能帶來的風險。

用戶也應注意,在不同鏈上的相同合約地址,其合約代碼並不總是相同,應先了解清楚委托的目標。

無法初始化

當前主流的智能合約錢包大多採用代理模型,錢包代理在部署時,會通過DELEGATECALL調用實現合約的初始化函數,以此達成錢包初始化與代理錢包部署的原子化操作,避免被搶先初始化的問題。但用戶在使用EIP-7702進行委托時,僅會更新其地址的code字段,無法通過調用委托地址進行初始化。這就使得EIP-7702無法像常見的ERC-1967代理合約一樣能在合約部署的交易中調用初始化函數進行錢包初始化。

對於開發者來說,在將EIP-7702與現有的EIP-4337錢包進行組合適配時,應注意在錢包的初始化操作中進行權限檢查(例如通過ecrecover恢復籤名地址進行權限檢查),以避免錢包初始化操作被搶跑的風險。

存儲管理

用戶在使用EIP-7702委托功能時,可能會因功能需求變更、錢包升級等原因,需要重新委托到不同的合約地址。但不同合約的存儲結構可能存在差異(比如不同合約的slot0插槽可能代表不同類型的數據),在重新委托的情況下,有可能導致新合約意外復用舊合約的數據,進而引發帳戶鎖定、資金損失等不良後果。

對於用戶來說,應謹慎處理重新委托的狀況。

對於開發者來說,在開發過程中應遵循ERC-7201提出的Namespace Formula,將變量分配到指定的獨立存儲位置,以緩解存儲衝突的風險。此外ERC-7779 (draft)還專爲EIP-7702提供了重新委托的標準流程:包括使用ERC-7201防止存儲衝突,並在重新委托之前驗證存儲兼容性,以及調用舊委托的接口清理存儲的舊數據。

假充值

用戶進行委托後,EOA也將可以作爲智能合約使用,因此中心化交易所(CEX)可能會面臨智能合約充值普遍化的情況。

CEX應通過trace檢查每筆充值交易的狀態,防範智能合約假充值風險。

帳戶轉換

實施EIP-7702委托後,用戶的帳戶類型可以在EOA與SC之間自由轉換,這使得帳戶既可以發起交易,也可以被調用。意味着當帳戶調用本身並進行外部調用時,其msg.sender也將是tx.origin,這會打破一些僅限EOA參與項目的安全假設。

對於合約開發者來說,假設tx.origin始終是EOA將不再可行。同樣地,通過msg.sender == tx.origin檢查來防御重入攻擊也將失效。

開發者在開發過程中理應假設未來的參與者可能都爲智能合約。

合約兼容性

現有的ERC-721,ERC-777代幣在對合約進行轉帳時都具有Hook功能,這意味着接收者必須實現相應的回調函數以成功接收代幣。

對於開發者來說,用戶委托的目標合約理應實現相應的回調函數,以確保能夠和主流代幣兼容。

釣魚檢查

實施EIP-7702委托後,用戶帳戶中的資產可能都將由智能合約控制,一旦用戶將帳戶委托到了惡意的合約,攻擊者竊取資金將變得輕而易舉。

對於錢包服務商來說,盡快支持EIP-7702類型的交易尤爲重要,並且在用戶進行委托籤名時,應向用戶着重展示委托的目標合約,以緩解用戶可能遭受釣魚攻擊的風險。

此外,對帳戶委托的目標合約進行更深入的自動分析(開源檢查,權限檢查等)可以更好地幫助用戶避免此類風險。

總結

本文圍繞以太坊即將到來的Pectra升級中的EIP-7702提案展開探討。EIP-7702通過引入新的交易類型,使EOA具備可編程性與可組合性,模糊了EOA與合約帳戶的界限。由於目前還沒有一個經過實戰考驗的兼容EIP-7702類型的智能合約標準,因而在實際應用中,不同的生態參與者,如用戶、錢包服務商、開發者、CEX等,都面臨着諸多挑戰與機遇。本文所闡述的最佳實踐內容無法涵蓋所有的潛在風險,但仍值得各方在實際操作中借鑑應用。