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 可以在单笔交易中携带合约逻辑并执行。这种机制打破了传统对账户行为的静态假设，开发者不再能简单地依赖账户地址的代码状态来判断其行为模型，而需要重构对调用者身份与权限边界的理解。

随之而来的是安全分析范式的转变。审计的重点不再局限于“某地址是否有权限”，而是转向“交易中携带的合约逻辑在当前上下文下能做什么”。每一笔交易都可能承载一次独立的行为定义，这赋予了账户更强的功能，也对安全审计提出了更高的要求。