撰文：Beosin
賬戶抽象（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 引入了一種新的交易類型 0x04（SetCode），它允許 EOA 通過此交易授權需要執行的合約代碼，其交易結構如下：
其中 authorization_list 包含了多個授權列表，也可包含非交易發起者的授權行爲，內部結構是：
其中，chain_id 表示用戶授權生效的鏈，要求其值必須等於執行鏈的鏈 ID 或爲 0。當 chain_id 爲 0 時，表示授權對所有支持 EIP-7702 的 EVM 鏈生效，但前提是其他參數（如 nonce）需匹配。address 則表示用戶授權的目標合約地址。
授權完成後，系統會將授權用戶的 code 字段修改爲 0xef0100 || address，其中 address 即爲授權的合約地址。如果想要取消授權，只需發起一筆 SetCode 交易將 address 設置爲 0 地址。
2. EIP7702 的優勢
(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、ERC1155 等代幣合約在向合約地址轉賬時，會調用標準回調接口（如 onERC721Received、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)」（檢查地址代碼長度）來防止合約賬戶參與某些操作，例如空投、搶購等：
在 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 可以在單筆交易中攜帶合約邏輯並執行。這種機制打破了傳統對賬戶行爲的靜態假設，開發者不再能簡單地依賴賬戶地址的代碼狀態來判斷其行爲模型，而需要重構對調用者身份與權限邊界的理解。隨之而來的是安全分析範式的轉變。審計的重點不再侷限於 「某地址是否有權限」，而是轉向 「交易中攜帶的合約邏輯在當前上下文下能做什麼」。每一筆交易都可能承載一次獨立的行爲定義，這賦予了賬戶更強的功能，也對安全審計提出了更高的要求。
