以太坊 Pectra 升級：EIP-7702 深度解析與最佳實踐指南

前言

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

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 相同的語義。authorization_list 是列表類型，可包含多個授權條目。每個授權條目中：

• 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 會先進行預檢查，確保此交易不是合約創建交易，即發送 EIP-7702 類型交易時，交易的 to 地址不能爲空。

此類交易要求 authorization_list 字段至少包含一項授權條目。如果多個授權條目由同一授權者簽署，最終只有最後一個授權條目生效。

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

節點應用授權條目時，如遇任何錯誤，該條目將被跳過，交易不會失敗，其他授權條目繼續應用，以避免批量授權場景中的 DoS 風險。

授權應用完成後，授權者地址的 code 字段將被設置爲 0xef0100 || address，其中 0xef0100 是固定標識，address 是委托的目標地址。EIP-3541 的限制確保此類標識只能由 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 等，都面臨着諸多挑戰與機遇。本文所闡述的最佳實踐內容無法涵蓋所有潛在風險，但仍值得各方在實際操作中借鑑應用。