以太坊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等,都面臨着諸多挑戰與機遇。本文所闡述的最佳實踐內容無法涵蓋所有的潛在風險,但仍值得各方在實際操作中借鑑應用。