帳戶抽象化（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 透過此交易授權需要執行的合約代碼，其交易結構如下：
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]]
其中，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 可以在單筆交易中攜帶合約邏輯並執行。這種機制打破了傳統對帳戶行為的靜態假設，開發者不再能簡單地依賴帳戶位址的程式碼狀態來判斷其行為模型，而需要重構對呼叫者身分與權限邊界的理解。
隨之而來的是安全分析範式的轉變。審計的重點不再局限於“某個地址是否有權限”，而是轉向“交易中攜帶的合約邏輯在當前上下文下能做什麼”。每一筆交易都可能承載一次獨立的行為定義，這賦予了帳戶更強的功能，也對安全審計提出了更高的要求。
