账户抽象（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通过此交易授权需要执行的合约代码，其交易结构如下：
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字段修改为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)"（检查地址代码长度）来防止合约账户参与某些操作，例如空投、抢购等：
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可以在单笔交易中携带合约逻辑并执行。这种机制打破了传统对账户行为的静态假设，开发者不再能简单地依赖账户地址的代码状态来判断其行为模型，而需要重构对调用者身份与权限边界的理解。
随之而来的是安全分析范式的转变。审计的重点不再局限于“某地址是否有权限”，而是转向“交易中携带的合约逻辑在当前上下文下能做什么”。每一笔交易都可能承载一次独立的行为定义，这赋予了账户更强的功能，也对安全审计提出了更高的要求。
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
