账户抽象钱包安全审计深度解析：EIP4337检查项全览

查找币:余老师 | 学术研究 | 2026-05-10 12:04 | 1 次浏览 | 0 条回复

查找币学术研究安全研究 Web3安全区块链安全

## 前言随着EIP4337标准的逐步落地，账户抽象（Account Abstraction, AA）钱包正成为Web3安全领域的热点。作为查找币安全团队的技术分享，本文旨在为审计人员提供一套基于EIP4337标准的账户抽象钱包安全审计检查项，并结合实际案例给出针对性的审计指南。我们假设读者已熟悉EIP4337和EIP7562标准的核心内容，因此不再赘述标准细节，而是聚焦于技术实现与安全风险。 ## EIP4337架构与交易执行流程 ### 架构概览 EIP4337的核心设计在于将用户操作（UserOperation）与以太坊原生交易解耦。用户通过EOA签署`UserOperation`数据，并将其提交至独立的Alt Mempool（替代内存池）。该内存池独立于以太坊主网内存池，专门汇总用户提交的UserOp。Bundler（打包者）从该内存池中提取UserOp，并在本地模拟执行，模拟失败的UserOp将被丢弃。最终，所有UserOp的执行由Bundler调用EntryPoint合约完成。 ### 交易执行流程 1. **用户签署**：EOA生成并签署`UserOperation`，包含调用目标、数据、签名等字段。 2. **提交至Alt Mempool**：用户通过RPC将UserOp发送至独立的Alt Mempool。 3. **Bundler提取与模拟**：Bundler从内存池提取UserOp，并在本地模拟执行以验证合法性。 4. **EntryPoint调用**：Bundler调用EntryPoint合约，EntryPoint经过验证后调用用户AA钱包。 5. **执行Calldata**：AA钱包执行用户指定的calldata，完成交易逻辑。 6. **费用支付**：用户向Bundler支付手续费，或指定Paymaster进行代付。审计人员需熟悉上述流程，特别是EntryPoint与AA钱包的交互细节，以识别潜在攻击面。 ## 安全审计检查项基于上述架构，查找币安全团队整理出以下核心检查项，建议审计人员在审计每个4337钱包时逐一验证： ### 1. 检查EVM兼容链兼容性 - **问题**：多数AA钱包部署在Ethereum主网，但主网上海升级后新增`PUSH0`字节码。Solidity 0.8.20及以上版本默认编译为上海升级后的字节码，可能导致在其他EVM兼容链（如Polygon、BSC）上部署失败。 - **审计建议**：检查合约编译的Solidity版本，确认是否包含`PUSH0`字节码。多链部署时，建议使用`<0.8.20`版本或指定`evm_version = "paris"`。 - **示例配置**： ```solidity solc = "0.8.19" evm_version = "paris" ``` ### 2. 检查接口实现与返回值是否符合EIP4337标准 - **钱包核心接口**：`validateUserOp`必须返回`validationData`，包含`authorizer`、`validUntil`和`validAfter`。 ```solidity function validateUserOp(PackedUserOperation calldata userOp, bytes32 userOpHash, uint256 missingAccountFunds) external returns (uint256 validationData); ``` - **Paymaster核心接口**：`validatePaymasterUserOp`返回`context`和`validationData`；`postOp`处理执行后逻辑。 ```solidity function validatePaymasterUserOp(PackedUserOperation calldata userOp, bytes32 userOpHash, uint256 maxCost) external returns (bytes memory context, uint256 validationData); function postOp(PostOpMode mode, bytes calldata context, uint256 actualGasCost, uint256 actualUserOpFeePerGas) external; ``` - **签名验证**：失败时`authorizer`返回`SIG_VALIDATION_FAILED`（`1`）；成功时返回`SIG_VALIDATION_SUCCESS`（`0`），而非`revert`。其他失败情况必须`revert`。 ### 3. 检查钱包调用者是否可信 - **风险**：钱包或Paymaster的`validateUserOp`、`executeUserOp`、`validatePaymasterUserOp`、`postOp`等函数应限制调用者，仅允许EntryPoint合约调用。若未限制，攻击者可伪造UserOp绕过验证。 - **审计建议**：使用`require(msg.sender == entryPoint)`或`onlyEntryPoint`修饰器。 ### 4. 检查`handleOps`与`innerHandleOp`的交互安全 - **问题**：在`innerHandleOp`执行失败时，`postOp`可能不被触发（即使指定了Paymaster）。攻击者可利用此漏洞，使`innerHandleOp`和`postOp`均失败，耗尽Paymaster资金。 - **审计建议**：Paymaster需设计容错机制，确保即使`postOp`未执行，也能正确处理费用。例如，在`validatePaymasterUserOp`中预扣费用，或使用时间锁延迟结算。 ### 5. 检查模块化钱包的实施安全 - **风险**：EIP4337钱包可能支持用户自定义模块（如社交恢复、合约升级、保险库）。若模块管理不当，攻击者可注入恶意模块。 - **审计建议**： - 确保“增加/移除/使用”模块的操作有权限控制（如多签或时间锁）。 - 使用`DELEGATECALL`执行模块时，检查钱包插槽存储的数据安全性，防止存储冲突或重入攻击。 - 对模块函数进行白名单限制，避免任意调用。 ### 6. 检查`UserOperation`的Gas限制 - **问题**：`UserOperation`中的`preVerificationGas`、`verificationGasLimit`、`callGasLimit`等参数可能被操纵，导致Gas耗尽或执行失败。 - **审计建议**：确保钱包在`validateUserOp`中验证Gas参数合理性，防止恶意用户设置过低Gas导致交易卡死。 ### 7. 检查签名验证逻辑 - **风险**：签名验证可能被绕过，如使用`ecrecover`时未检查`v`值范围，或支持多种签名方案（如ECDSA、BLS）时未正确区分。 - **审计建议**：使用标准化签名库（如OpenZeppelin的`ECDSA`），并验证签名参数（如`v` ∈ {27, 28}）。对多签名方案，需明确标识签名类型。 ### 8. 检查非重入与重放攻击 - **问题**：`UserOperation`的`nonce`机制可防止重放，但若`nonce`管理不当，攻击者可重复提交相同UserOp。 - **审计建议**：钱包应使用递增的`nonce`，或基于用户地址和时间戳生成唯一标识。`validateUserOp`中需检查`nonce`的合法性。 ### 9. 检查Paymaster的`postOp`执行逻辑 - **风险**：`postOp`可能被多次调用或跳过，导致费用计算错误。 - **审计建议**：`postOp`应使用状态变量记录执行状态，防止重入。同时，确保`postOp`的`mode`参数（如`opSucceeded`、`opReverted`）被正确处理。 ### 10. 检查`EntryPoint`的`deposit`与`withdraw`函数 - **问题**：用户或Paymaster通过`deposit`存入资金，Bundler通过`withdraw`提取费用。若权限控制不当，攻击者可盗取存款。 - **审计建议**：确保`withdraw`仅由Bundler调用，且金额受限于实际Gas消耗。使用`onlyEntryPoint`或`onlyBundler`修饰器。 ## 总结上述检查项基于EIP4337标准，覆盖了账户抽象钱包的核心安全维度。由于不同钱包实现差异较大，且EIP4337生态仍处于早期阶段，审计人员需结合实际代码进行深入分析。对于正在开发的项目，查找币安全团队建议开发者在设计阶段即考虑这些检查项，以降低后期修复成本。最后，本文旨在提供技术参考，具体审计需结合工具（如Slither、Mythril）和手动审查。 **本文由查找币安全团队整理发布**

账户抽象钱包安全审计深度解析：EIP4337检查项全览

查找币安全研究院

主题延伸阅读