Beosin：EIP-7702與下一代AA錢包安全審計分析

賬戶抽象（Account Abstraction, AA）是以太坊生態中長期探索的重要方向，旨在打破外部賬戶（EOA）和合約賬戶的界限，使錢包具備更強的可編程性、安全性和可升級性。EIP-4337 作為目前最主流的 AA 實現方案，已被廣泛應用於一批基於 EntryPoint 的智能合約錢包（如 Safe、Stacks、Argent）中。然而，EIP-4337 因其引入了獨立的交易池和入口合約機制，在鏈上原生性、操作複雜度和生態兼容性方面仍存在一定限制。

為進一步降低賬戶抽象的使用門檻、增強其原生性支持，Vitalik 於 2024 年提出了 EIP-7702 ，並在 Pectra 升級中納入該提案。EIP-7702 的核心思想是：允許一個原本的 EOA 在發起交易時，允許執行指定地址的合約代碼（contract_code），以此代碼定義該交易的執行邏輯。

EIP-7702 引入了“交易級代碼注入”的新機制，使用戶賬戶在每筆交易中可以動態指定執行邏輯，而非依賴預部署的合約代碼。這打破了傳統基於靜態 code 的權限模型，帶來了更強的靈活性，也引入了新的安全挑戰：原本依賴 isContract、extcodehash 等判斷邏輯的合約可能失效，一些假設調用方為純 EOA 的系統也可能被繞過。對於審計人員而言，不僅要驗證注入代碼本身的安全性，還需評估其在動態上下文下對其他合約系統帶來的潛在影響。

本文 Beosin 安全團隊將圍繞 EIP-7702 的設計原理與關鍵特性，系統梳理基於其構建的 AA 錢包在審計中可能面臨的安全風險，並結合實戰視角提出審計流程與建議，幫助安全研究者更好地應對這一全新範式下的技術挑戰。

一、EIP-7702 簡介

1. EIP-7702 技術概述

EIP-7702 引入了一種新的交易類型0x 04 （SetCode），它允許 EOA 通過此交易授權需要執行的合約代碼，其交易結構如下：

1. rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit，

2. destination, value, data, access_list, authorization_list, signature_y_parity, signature_r, signature_s])

其中 authorization_list 包含了多個授權列表，也可包含非交易發起者的授權行為，內部結構是：

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

其中，chain_id 表示用戶授權生效的鏈，要求其值必須等於執行鏈的鏈 ID 或為 0 。當 chain_id 為 0 時，表示授權對所有支持 EIP-7702 的 EVM 鏈生效，但前提是其他參數（如 nonce）需匹配。address 則表示用戶授權的目標合約地址。

授權完成後，系統會將授權用戶的 code 字段修改為0x ef 0100 || address，其中 address 即為授權的合約地址。如果想要取消授權，只需發起一筆 SetCode 交易將 address 設置為 0 地址。

2. EIP 7702 的優勢

( 1) 靈活性與自定義

抽象賬戶通過將賬戶邏輯寫入智能合約，可以根據需求靈活定製功能。例如，用戶可以配置多重簽名、社交恢復、限額控制等，滿足個人或企業的不同場景需求。這種設計大幅提升了賬戶的功能擴展性，突破了傳統外部賬戶（EOA）的限制。

( 2) 增強安全性

抽象賬戶提供了多層安全保障機制，包括多重認證、交易限額和社交恢復等。即使用戶丟失了私鑰，也能通過可信聯繫人或多重驗證恢復賬戶，避免了傳統賬戶因私鑰丟失而導致的資產永久損失。同時，限額控制等功能還能防止大額資金被惡意盜取。

( 3) Gas 優化

抽象賬戶支持靈活的 Gas 抽象機制，允許用戶通過第三方支付 Gas，甚至直接使用其它代幣支付交易費用。這種機制不僅降低了用戶的操作成本，還進一步簡化了區塊鏈的使用流程，尤其適合小白用戶或複雜的多步交易場景。

( 4) 助推Web3普及

通過優化體驗和安全性，抽象賬戶將區塊鏈的複雜性隱藏在用戶看不到的地方，提供更接近Web2的便捷操作。這種設計降低了普通用戶的學習成本，讓更多人能夠無障礙參與Web3應用，推動了去中心化技術的普及。

二、EIP-7702 實踐中的安全風險解析

儘管 EIP-7702 為以太坊生態注入了新的動力，並拓展了豐富的應用場景，但與此同時，它也不可避免地引入了一些新的安全隱患：

1. 授權重放攻擊

在 EIP-7702 模型下，如果用戶將授權中的 chain_id 字段設置為 0 ，則表示該授權在多個鏈上均可生效。這種“跨鏈泛用授權”的設計雖然在某些場景下提升了靈活性，但同時也引入了明顯的安全隱患。

需要特別注意的是，即便同一地址在不同鏈上的賬戶標識相同，其背後的合約實現可能完全不同。這意味著，攻擊者可能在另一條鏈上部署一個惡意版本的合約，利用鏈上相同地址的授權行為執行非預期操作，從而對用戶資產造成風險。

因此，對於錢包服務商或前端交互平臺而言，在用戶進行此類授權操作時，應明確校驗用戶授權中聲明的 chainId 與當前連接網絡是否一致；若檢測到用戶將 chainId 設置為 0 ，應給予清晰的風險提示，提醒用戶該授權將在所有 EVM 兼容鏈上生效，並可能被惡意合約濫用。

此外，服務方還應評估是否在 UI 層默認限制或禁止 chainId 為 0 的授權，以降低誤操作或釣魚攻擊風險。

2. 合約兼容性問題

( 1) 合約回調兼容性

現有 ERC-721、ERC-777、ERC 1155 等代幣合約在向合約地址轉賬時，會調用標準回調接口（如 onERC 721 Received、tokensReceived）以完成轉賬操作。如果接收地址未實現相應接口，轉賬會失敗甚至導致資產鎖定。

在 EIP-7702 中，用戶地址可以通過"set_code"操作被賦予合約代碼，從而轉變為合約賬戶。此時：

• 用戶地址會被視為合約；

• 若該合約未實現必要的回調接口，將導致代幣轉賬失敗；

• 用戶可能在不知情的情況下無法接收主流代幣。

因此，開發者應確保用戶委託的目標合約實現相關回調接口，以保障與主流代幣的兼容性。

( 2) "tx.origin"校驗失效

傳統合約中，"tx.origin"常被用來判斷交易是否由用戶直接發起，用於防止合約調用等安全控制。

但在 EIP-7702 場景下：

• 用戶簽署授權交易，實際由中繼器或捆綁服務（bundler）代為廣播；交易執行時，"tx.origin"是中繼器地址，而非用戶地址。

• "msg.sender"是代表用戶身份的錢包合約。

因此，基於"tx.origin == msg.sender"的權限校驗將導致合法用戶操作被拒絕，失去可靠性，同樣使用"tx.origin == user"這類限制合約調用的也將失效。建議棄用"tx.origin"作為安全判斷依據，轉而使用簽名驗證或授權機制。

( 3) "isContract"誤判

許多合約通過"isContract(address)"（檢查地址代碼長度）來防止合約賬戶參與某些操作，例如空投、搶購等：

require(!isContract(msg.sender), "Contracts not allowed")

在 EIP-7702 機制下，用戶地址可以通過"set_code"交易變為合約賬戶，"isContract"返回 true，合約將誤判合法用戶為合約賬戶，拒絕其參與操作，導致用戶無法使用某些服務，體驗受阻。

隨著合約錢包逐漸普及，依賴"isContract"判斷“是否為人類用戶”的設計已不再安全，推薦採用簽名驗證等更精準的用戶識別方式。

3. 釣魚攻擊

在實施EIP-7702 的委託機制後，用戶賬戶中的資產將完全受所委託的智能合約控制。一旦用戶授權給惡意合約，攻擊者可能藉此獲取對賬戶資產的完全控制權限，導致資金被迅速轉移或盜取，安全風險極高。

因此，對於錢包服務商而言，儘早支持 EIP-7702 類型的交易解析與風險識別機制至關重要。在用戶簽署委託交易時，前端應明確且突出地展示目標合約地址，並結合合約來源、部署信息等輔助信息，幫助用戶識別潛在的釣魚或欺詐行為，從而降低誤籤風險。進一步而言，錢包服務應集成對目標合約的自動化安全分析能力，例如合約代碼開源狀態檢查、權限模型分析、潛在危險操作識別等手段，協助用戶在授權前做出更安全的判斷。

特別需要注意的是，EIP-7702 引入的委託簽名格式，與現有的 EIP-191 和 EIP-712 簽名標準並不兼容。其簽名極易繞過錢包原有的簽名警示與交互提示，進一步提升了用戶被欺騙簽署惡意操作的風險。因此，在錢包實現中引入對該簽名結構的識別與處理機制，將是保障用戶安全的關鍵環節。

4. 錢包合約風險

( 1) 錢包合約權限管理

許多 EIP-7702 錢包合約採用代理架構(或內置管理權限)，以支持邏輯升級。然而，這也帶來了更高的權限管理風險。如果升級權限未被嚴格限制，攻擊者可能替換實現合約並注入惡意代碼，導致用戶賬戶被篡改或資金被盜。

安全建議：

• 採用多重簽名、多因子認證或時間鎖機制來控制升級權限。

• 代碼和權限變更須經過嚴格審計和安全驗證。

• 公開透明升級流程，保證用戶知情權和參與權。

( 2) 存儲衝突風險及數據隔離

錢包合約版本或不同錢包服務商可能複用相同的存儲槽（storage slot）。用戶若更換錢包服務商或升級錢包邏輯時，複用存儲槽將導致狀態變量衝突，出現數據覆蓋、讀取異常等問題。這不僅可能破壞錢包的正常功能，還可能導致資金丟失或權限異常。

安全建議：

• 使用專門的存儲隔離方案（如 EIP-1967 標準）或利用唯一的命名空間管理存儲槽。

• 升級合約時，確保存儲佈局兼容，避免變量重疊。

• 嚴格測試升級流程中存儲狀態的合理性。

( 3) 錢包內部的 nonce 管理

錢包合約通常內部設置了 nonce，並進行自行管理，以保證用戶操作的執行順序和防止重放攻擊。如果 nonce 使用不當，將導致用戶操作不能正常執行。

安全建議：

• nonce 必須強檢等值（或遞增），不可跳過。

• 禁止函數直接修改 nonce，必須是用戶操作執行時才會同步更新 nonce。

• 對 nonce 異常情況設計容錯和恢復機制，避免 nonce 死鎖。

( 4) 函數調用者權限檢查

為了確保安全，錢包合約必須確保關鍵函數的調用者是錢包的所有者賬戶。常見的兩種方式包括：

• 鏈下簽名授權

用戶通過私鑰對一組操作進行簽名，錢包合約在鏈上驗證簽名是否合法、是否過期、是否滿足對應 nonce。此方式適用於 EIP-7702 提倡的中繼交易模式（用戶離線簽名 + 中繼器代發交易）。

• 調用約束（msg.sender == address(this)）

用戶操作函數僅允許由合約自身調用觸發，本質上是一種調用路徑控制機制，確保外部發起者必須是該賬戶本身。這實際上等價於要求調用者是原始的 EOA，因為此時的合約地址就是 EOA 地址。

三、展望：EIP-7702 與未來的 AA 錢包標準

EIP-7702 的提出，不僅是對傳統賬戶模型的一次革新，也是對賬戶抽象（Account Abstraction）生態的一次重大推動。其引入的用戶加載合約代碼的能力，為未來錢包設計與合約體系帶來了廣闊的探索空間，也對安全審計標準提出了新的要求。

1. 與 EIP-4337 的協同演進：走向雙模兼容

雖然 EIP-7702 與 EIP-4337 在設計上目標不同，前者重構的是賬戶的代碼加載機制，後者構建的是完整的交易入口與打包生態。但兩者並不衝突，反而具有很強的互補性：

● EIP-4337 提供的是“通用交易通道”和“抽象賬戶執行接口”；

● EIP-7702 允許用戶賬戶在不改變地址的前提下，動態賦予合約邏輯能力；

因此，未來錢包可能採用“雙模支持架構”：在不支持 EIP-4337 的鏈上使用 EIP-7702 作為輕量化替代，而在需要鏈下打包、多用戶聚合的場景下繼續依賴 EIP-4337 的完整協議棧。

這種雙模機制還將促使錢包在內核層支持更靈活的賬戶權限模型、降級機制與回滾方案。

2. 對 MPC、ZK 等新型錢包邏輯的支持與啟發

EIP-7702 所倡導的賬戶合約化機制，與當下熱門的 MPC 錢包、ZK 錢包、模塊化錢包等新架構存在天然的融合潛力：

● MPC 模式中，簽名行為已不依賴單一私鑰，而是多方協同決策。通過 EIP-7702 和 MPC 融合生成的簽名可控制動態載入的合約邏輯，從而實現更靈活的執行策略。

● ZK 錢包通過零知識證明驗證用戶身份或授權，無需暴露私鑰信息。結合 EIP-7702 後，ZK 錢包可以在驗證完成後臨時注入特定邏輯合約，從而實現隱私計算後的個性化行為部署，如只在滿足某些隱私條件後自動執行某邏輯。

● 模塊化錢包（Modular Wallets）則可藉助 EIP-7702 將賬戶邏輯拆解為多個模塊，在需要時動態裝載。

因此，EIP-7702 為上述先進錢包提供了更加原生的“執行容器”：用戶地址保持不變即可注入不同合約邏輯，規避傳統合約部署過程中的地址依賴問題，也無需預部署，大幅提升賬戶行為的靈活性與組合能力。

3. 對合約開發者與審計者的啟示

EIP-7702 將推動開發範式的深刻變革。合約開發者不再是簡單地將調用方視為傳統的 EOA 或固定的合約賬戶，而必須適應一種全新的機制：調用方身份在交易過程中可在 EOA 和合約狀態之間動態切換，賬戶行為邏輯不再靜態固化，而是能夠根據需求靈活變更。這要求開發者與審計人員需具備：

• 引入更嚴格的 caller 驗證與權限判斷邏輯；

• 檢查調用路徑是否受動態合約邏輯影響；

• 識別依賴 msg.sender.code.length == 0、isContract()等行為的潛在脆弱點；

• 明確合約邏輯的“上下文依賴”，例如靜態調用、delegatecall 的邊界控制；

• 在工具鏈層面支持對 setCode 場景的模擬與還原分析。

換句話說，代碼的安全性不再只是“部署前的問題”，而變成了“調用中、交易中也必須驗證的動態過程”。

四、總結

EIP-7702 為賬戶抽象（AA）引入了一種更輕量、原生且靈活的實現方式，使得普通 EOA 可以在單筆交易中攜帶合約邏輯並執行。這種機制打破了傳統對賬戶行為的靜態假設，開發者不再能簡單地依賴賬戶地址的代碼狀態來判斷其行為模型，而需要重構對調用者身份與權限邊界的理解。

隨之而來的是安全分析範式的轉變。審計的重點不再侷限於“某地址是否有權限”，而是轉向“交易中攜帶的合約邏輯在當前上下文下能做什麼”。每一筆交易都可能承載一次獨立的行為定義，這賦予了賬戶更強的功能，也對安全審計提出了更高的要求。