ERC-4337 安全：打包器、支付大师、签名

ERC-4337 将“账户安全”从单一的外部拥有账户 (EOA) 签名检查，根本性地转变为一个分布式系统，该系统包含智能账户代码、链上 EntryPoint 和链下基础设施。

虽然这带来了巨大的灵活性（自定义身份验证、Gas 赞助、交易批处理），但也造成了一个碎片化的安全边界。一个表示“授权 X”的签名可以悄无声息地变成“授权在链 A 上为账户 B，在支付方策略 C 下的 X”。

严峻的现实是：账户抽象 (AA) 中最昂贵的 Bug 几乎从来都不是奇特的密码学问题。它们是无聊的、系统性的故障：

• 哈希或打包不匹配。
• 不完整的域隔离。
• 重放窗口。
• “策略签名”未能实际绑定到其授权的资产。

要保护 AA 实现，你必须将以下组件视为一个单一的安全边界。

• UserOperation：生活在专用内存池中的“伪交易”对象。
• Smart Account：实现 validateUserOp，验证授权，强制执行重放保护，并处理预付款。在不匹配时，必须返回“签名失败”代码而不回滚。
• EntryPoint：链上协调器。它运行验证、执行调用并处理存款/质押。
• Bundlers：链下中继器，通过 JSON RPC 接收 UserOperations，模拟/验证它们，并通过 handleOps 将它们提交到链上。
• Paymasters (可选)：在可编程条件下赞助 Gas 的智能合约。至关重要的是，即使 User Operation 稍后回滚，它们也会支付执行费用。
• Factories：处理账户部署数据。一个主要的攻击面，用于“拒绝钱包”的恶意攻击（例如，initCode 抢跑）。

威胁模型如何转变

在传统的 EOA 模型中，区块链强制执行有效性。在 ERC-4337 下，“有效性函数”是在验证期间执行的 EVM 代码，这极大地改变了威胁模型：

• 基础设施现在是一个安全边界：Paymasters 依赖于外部签名者。如果被攻破，它们就会成为中心化的策略瓶颈。
• 可用性 = 活度：如果 Bundlers 宕机，或者 Paymaster 的存款耗尽，你的“无 Gas 引导”就会中断。可用性是一种一级故障模式。
• 复杂的 Nonce 语义：ERC-4337 将 Nonce 视为一个 192 位密钥加上一个 64 位序列。不正确的使用会导致钱包卡死和重放 Bug。
• 多重签名表面：你现在有 validateUserOp 签名、Paymaster 授权签名，并且通常还有 ERC-1271 合约签名 (isValidSignature)。每个都是潜在的重放向量。

真实世界的故障模式和案例研究

签名验证和重放 Bug

• 哈希不匹配：在 2023 年初，Alchemy 指出了一些漏洞，其中基于 calldata 的“打包和哈希”快捷方式导致了哈希冲突。如果参与者为相同的操作计算出不同的哈希，签名就会绑定到错误的执行。
• ERC-1271 跨账户重放：如果同一个 EOA 控制多个智能账户，签名可能会在它们之间重放，除非应用程序的签名消息绑定了特定的合约地址和链 ID (EIP-712 包装)。
• Paymaster 重放：对 Paymasters 的多次审计发现，仅验证“发件人、收件人、和 Gas 参数”允许验证者签名在多个交易中重放。修复：将签名绑定到 userOpHash 加上一个 Nonce。

拒绝钱包和活度

• 初始化/部署恶意攻击：攻击者可以从 UserOp 中提取 initCode 并抢跑部署。原始的 UserOp 失败，迫使用户重新签名。
• 通过 postOp 回滚造成声誉损害：如果操作在模拟后失败，Bundlers 会严重惩罚 Paymasters。代币状态漂移（例如，在模拟和执行之间 allowances 发生变化）可能导致 postOp 回滚，从而导致 Bundlers 限制你的 Paymaster。

工程手册：组件指南

签名：禁止定制验证

将签名验证视为一个库决策，而不是应用层面的巧妙设计。

• 严格限制 validateUserOp：只有你选择的 EntryPoint 才能调用它。
• 没有自定义汇编哈希：严格按照规范要求计算 userOpHash。
• 禁止原始 ecrecover：使用经过广泛审查的库（如 OpenZeppelin 的 SignatureChecker）来防止签名可塑性。

Paymasters：严格的赞助控制

Paymaster 是一个带有严格欺诈引擎的链上信用卡。如果它失败，网络会惩罚你的可用性。

• 绑定到 userOpHash：除非正式证明安全，否则不要手动选择字段进行签名。
• 限制最大成本：始终验证 maxCost 假设并强制执行每用户预算。
• 限制 postOp 复杂性：设计代币流程，使得 postOp 传输回滚实际上不可能发生，或者导致严格受限、受监控的损失。

Bundlers：设计弹性

Bundlers 不能伪造操作，但它们可以审查、延迟或将你的 calldata 泄露给 MEV 管道。

• 实现故障转移：集成多个 Bundlers，并在 eth_sendUserOperation 错误激增时自动故障转移。
• 监控模拟失败：高模拟失败率通常表明签名逻辑损坏或 Paymaster 策略漂移。

测试和不变式清单

确保你的测试套件（例如 Foundry）明确涵盖这些场景：

• 跨链重放：在链 A 上签名的 UserOperation 在链 B 上失败。
• 跨 EntryPoint 重放：为 EntryPoint X 的签名在 EntryPoint Y 上失败。
• ERC-1271 隔离：用于智能账户 1 的 ERC-1271 签名在智能账户 2 上失败，即使它们由同一个 EOA 拥有。
• Paymaster 重放：在新的 UserOperation 中重新提交相同的 Paymaster 签名失败（强制 Nonce/有效期）。
• 防抢跑：直接的 Factory 部署调用回滚；只有 EntryPoint SenderCreator 路径成功。

带有风险控制映射的实用清单

下表有意侧重于生产中最可能首先出现故障的部分。

保护你的账户抽象基础设施

账户抽象引入了智能合约管理授权和风险方式的巨大转变。无论你是构建自定义 Paymaster、集成 Bundler 回退逻辑，还是为你的智能账户主网部署做准备，你都需要高保真度的安全情报。

• 原文链接： x.com/spearbit/status/20...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～