作者：Kong

編輯：Sherry

前言

以太坊即將迎來 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 哈希運算，從而得到待簽名的數據[1]。最後，使用授權者的私鑰對哈希後的數據進行簽名，進而獲得 y_parity, r, s 數據。其中，MAGIC (0x05) 是作爲域分隔符使用，其目的是確保不同類型簽名的結果不會產生衝突。

// Go-ethereum/core/types/tx_setcode.go#L109-L113func (a *SetCodeAuthorization) sigHash() common.Hash { return prefixedRlpHash(0x05, []any{ a.ChainID, a.Address, a.Nonce, })}

需要注意的是，當授權者授權的 chain_id 爲 0 時，則代表着授權者允許[2]在所有支持 EIP-7702 的 EVM 兼容鏈上重放授權（前提是 nonce 也剛好匹配）。

// Go-ethereum/core/state_transition.go#L562if !auth.ChainID.IsZero() && auth.ChainID.CmpBig(st.evm.ChainConfig().ChainID) != 0 { return authority, ErrAuthorizationWrongChainID}

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

// Go-ethereum/core/state_transition.go#L388-L390if msg.To == nil { return fmt.Errorf("%w (sender %v)", ErrSetCodeTxCreate, msg.From)}

同時，此類交易會強制要求交易中的 authorization_list 字段必須至少包含有一項授權條目，如果有多個授權條目都由同一個授權者簽署，那麼最終只有最後一個授權條目起效。

// Go-ethereum/core/state_transition.go#L391-L393if len(msg.SetCodeAuthorizations) == 0 { return fmt.Errorf("%w (sender %v)", ErrEmptyAuthList, msg.From)}

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

// Go-ethereum/core/state_transition.go#L489-L497func (st *stateTransition) execute() (*ExecutionResult, error) { ... st.state.SetNonce(msg.From, st.state.GetNonce(msg.From)+1, tracing.NonceChangeEoACall)

// Apply EIP-7702 authorizations. if msg.SetCodeAuthorizations != nil { for _, auth := range msg.SetCodeAuthorizations { // Note errors are ignored, we simply skip invalid authorizations here. st.applyAuthorization(&auth) } } ...}// Go-ethereum/core/state_transition.go#L604func (st *stateTransition) applyAuthorization(auth *types.SetCodeAuthorization) error { authority, err := st.validateAuthorization(auth) ... st.state.SetNonce(authority, auth.Nonce+1, tracing.NonceChangeAuthorization) ...}// Go-ethereum/core/state_transition.go#L566func (st *stateTransition) validateAuthorization(auth *types.SetCodeAuthorization) (authority common.Address, err error) { ... if auth.Nonce+1 < auth.Nonce { return authority, ErrAuthorizationNonceOverflow } ...}

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

// Go-ethereum/core/state_transition.go#L494for _, auth := range msg.SetCodeAuthorizations { // Note errors are ignored, we simply skip invalid authorizations here. st.applyAuthorization(&auth)}

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

// Go-ethereum/core/state_transition.go#L612st.state.SetCode(authority, types.AddressToDelegation(auth.Address))

// Go-ethereum/core/types/tx_setcode.go#L45var DelegationPrefix = []byte{0xef, 0x01, 0x00}

func AddressToDelegation(addr common.Address) []byte { return append(DelegationPrefix, addr.Bytes()...)}

授權完成後，授權者若要移除授權，只需將委託的目標地址設置爲 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 等，都面臨着諸多挑戰與機遇。本文所闡述的最佳實踐內容無法涵蓋所有的潛在風險，但仍值得各方在實際操作中借鑑應用。

示例

[Set EOA Account Code]

https://holesky.etherscan.io/tx/0x29252bf527155a29fc0df3a2eb7f5259564f5ee7a15792ba4e2ca59318080182

[Unset EOA Account Code]

https://holesky.etherscan.io/tx/0xd410d2d2a2ad19dc82a19435faa9c19279fa5b96985988daad5d40d1a8ee2269

相關鏈接

[1] https://github.com/ethereum/go-ethereum/blob/7fed9584b5426be5db6d7b0198acdec6515d9c81/core/types/tx_setcode.go#L109-L113

[2] https://github.com/ethereum/go-ethereum/blob/7fed9584b5426be5db6d7b0198acdec6515d9c81/core/state_transition.go#L562

[3] https://github.com/ethereum/go-ethereum/blob/7fed9584b5426be5db6d7b0198acdec6515d9c81/core/state_transition.go#L304

[4] https://github.com/ethereum/go-ethereum/blob/7fed9584b5426be5db6d7b0198acdec6515d9c81/core/state_transition.go#L388-L390

參考資料‍‍‍‍

[EIP-7702]https://eips.ethereum.org/EIPS/eip-7702

[EIP-4844]https://eips.ethereum.org/EIPS/eip-4844

[Go-ethereum]https://github.com/ethereum/go-ethereum/tree/7fed9584b5426be5db6d7b0198acdec6515d9c81

[EIP-3541]https://eips.ethereum.org/EIPS/eip-3541#backwards-compatibility

[Cobo: EIP-7702實用指南]  

https://mp.weixin.qq.com/s/ojh9uLw-sJNArQe-U73lHQ

[Viem]https://viem.sh/experimental/eip7702/signAuthorization

[ERC-7210]https://eips.ethereum.org/EIPS/eip-7201

[ERC-7779]https://eips.ethereum.org/EIPS/eip-7779