账户抽象ERC-4337：让钱包体验像App一样简单

Day 24: 账户抽象 (Account Abstraction) - ERC-4337

Week 4 学习路径

Week 4: NFT与新范式
├── Day 22: ERC721/1155标准对比 ✅
├── Day 23: NFT市场机制(版税/稀有度) ✅
├── Day 24: 账户抽象(AA) ERC4337 ✅ ← 今天
├── Day 25: 社交恢复、Gas代付、批量交易
├── Day 26: The Graph Subgraph原理
├── Day 27: 集成Subgraph到项目
└── Day 28: Uniswap产品分析文章

核心概念

什么是账户抽象（Account Abstraction）？

一句话定义：让智能合约成为用户的主账户，实现可编程的交易验证和执行逻辑。

类比理解：传统钱包就像一把只认钥匙的锁——丢了钥匙（私钥）就完了。账户抽象就像智能门锁——可以用指纹、密码、人脸、甚至让朋友帮你开门，还能设置自动开门规则。

传统账户 vs 智能账户
═══════════════════════════════════════════════════════════

传统账户 (EOA - Externally Owned Account)
├── 由私钥控制
├── 只能用 ECDSA 签名验证
├── 必须用 ETH 支付 Gas
├── 丢失私钥 = 永久丢失资产
└── 每笔交易只能做一件事

智能账户 (Smart Contract Account)
├── 由合约代码控制
├── 可自定义验证逻辑（多签、生物识别、社交恢复）
├── 可用任意代币支付 Gas，或让别人代付
├── 可设置恢复机制
└── 可批量执行多个操作
═══════════════════════════════════════════════════════════

为什么账户抽象是 Web3 的关键？

知识点1: ERC-4337 架构

为什么是 ERC-4337？

以太坊之前有多个账户抽象提案（EIP-86、EIP-2938），但都需要修改协议层。ERC-4337 的突破在于：不需要改变以太坊底层，完全在应用层实现。

核心组件架构

ERC-4337 系统架构
═══════════════════════════════════════════════════════════

用户 (User)
    │
    │ 创建 UserOperation
    ▼
┌─────────────────┐
│  UserOperation  │ ← 伪交易对象，包含用户意图
│  (用户操作)     │
└────────┬────────┘
         │ 提交到 Alt Mempool
         ▼
┌─────────────────┐
│    Bundler      │ ← 收集、验证、打包 UserOps
│   (打包者)      │
└────────┬────────┘
         │ 发送交易到链上
         ▼
┌─────────────────┐
│   EntryPoint    │ ← 全局入口合约，处理所有 UserOps
│  (入口合约)     │
└────────┬────────┘
         │ 调用
         ▼
┌─────────────────┐     ┌─────────────────┐
│  Smart Account  │ ←── │    Paymaster    │ (可选)
│  (智能账户)     │     │   (付款者)      │ Gas 代付
└─────────────────┘     └─────────────────┘
═══════════════════════════════════════════════════════════

知识点2: UserOperation 详解

UserOperation 结构

UserOperation 是用户意图的载体，比传统交易包含更多信息：

struct UserOperation {
    address sender;           // 智能账户地址
    uint256 nonce;            // 防重放攻击
    bytes initCode;           // 首次使用时部署账户的代码
    bytes callData;           // 要执行的操作数据
    uint256 callGasLimit;     // 执行操作的 Gas 限制
    uint256 verificationGasLimit; // 验证签名的 Gas 限制
    uint256 preVerificationGas;   // 额外 Gas（打包等）
    uint256 maxFeePerGas;     // 最高 Gas 价格
    uint256 maxPriorityFeePerGas; // 最高小费
    bytes paymasterAndData;   // Paymaster 地址和数据（可选）
    bytes signature;          // 用户签名
}

UserOperation vs 传统交易

知识点3: Bundler（打包者）

Bundler 的职责

Bundler 工作流程
═══════════════════════════════════════════════════════════

1. 监听 Alt Mempool
   └── 收集用户提交的 UserOperations

2. 验证 & 模拟
   ├── 检查签名有效性
   ├── 检查账户余额/Paymaster
   ├── 模拟执行，确保不会失败
   └── 过滤无效操作

3. 打包 (Bundle)
   ├── 将多个 UserOps 打包成一笔交易
   └── 优化 Gas 效率

4. 提交到 EntryPoint
   └── 作为普通交易发送到链上

5. 收取报酬
   └── 从 UserOp 的 Gas 费用中获利
═══════════════════════════════════════════════════════════

Bundler 市场是去中心化的

主要 Bundler 服务商

知识点4: Paymaster（付款者）

Paymaster 能做什么？

Paymaster 是可选的智能合约，可以代替用户支付 Gas 费：

Paymaster 的三种模式
═══════════════════════════════════════════════════════════

1. 完全赞助 (Sponsorship)
   ├── DApp 为用户支付所有 Gas
   ├── 用户 0 费用交互
   └── 适合：新用户获客、促销活动

2. ERC-20 支付 (Token Paymaster)
   ├── 用户用 USDC/USDT 等支付 Gas
   ├── Paymaster 收取代币，用 ETH 付 Gas
   └── 适合：不想持有 ETH 的用户

3. 条件赞助 (Conditional)
   ├── 满足条件才赞助（如持有 NFT）
   ├── 每日限额、白名单等
   └── 适合：会员体系、防滥用
═══════════════════════════════════════════════════════════

Paymaster 工作流程

// Paymaster 核心接口
interface IPaymaster {
    // 验证是否愿意为此 UserOp 付款
    function validatePaymasterUserOp(
        UserOperation calldata userOp,
        bytes32 userOpHash,
        uint256 maxCost
    ) external returns (bytes memory context, uint256 validationData);

    // 操作执行后的回调（如收取用户的 ERC-20）
    function postOp(
        PostOpMode mode,
        bytes calldata context,
        uint256 actualGasCost
    ) external;
}

Paymaster 安全机制

知识点5: 智能账户实现

主流智能钱包对比

Safe 钱包架构

Safe 多签钱包结构
═══════════════════════════════════════════════════════════

Safe Proxy (用户的钱包地址)
    │
    ├── Owner 1 (你的手机)
    ├── Owner 2 (你的硬件钱包)
    ├── Owner 3 (你的朋友/家人)
    │
    └── 执行策略: 3 个 Owner 中需要 2 个签名

功能模块（可插拔）:
├── 社交恢复模块
├── 每日限额模块
├── 白名单模块
└── 自动化模块
═══════════════════════════════════════════════════════════

Argent 的 Guardian 系统

Argent 社交恢复
═══════════════════════════════════════════════════════════

你的 Argent 钱包
    │
    ├── Guardian 1: 朋友 A 的钱包
    ├── Guardian 2: 朋友 B 的钱包
    ├── Guardian 3: Argent 官方（可选）
    │
    └── 恢复策略: 多数 Guardian 同意即可恢复

场景: 手机丢失
1. 在新手机安装 Argent
2. 发起恢复请求
3. Guardian 们确认是你本人
4. 等待安全期（如48小时）
5. 成功恢复钱包访问权
═══════════════════════════════════════════════════════════

对比分析: EOA vs Smart Account

链上实操记录

操作1: 体验 Safe 钱包

步骤:

1. 访问 app.safe.global

2. 连接你的 MetaMask（作为 Owner 之一）

3. 点击 "Create new Safe"

4. 选择网络（推荐 Polygon 或 Arbitrum，Gas 低）

5. 添加 Owner 地址（可以添加你的多个地址）

6. 设置签名阈值（如 2/3）

7. 支付部署 Gas，创建 Safe

观察:

• Safe 地址是一个合约地址（不是 0x 开头的普通地址格式不同）
• 可以看到多签流程：发起交易 → 收集签名 → 执行
• 模块系统：可以添加各种功能模块

操作2: 体验 Argent 钱包（移动端）

步骤:

1. 下载 Argent 应用（iOS/Android）

2. 创建新钱包（无需助记词！）

3. 添加 Guardian（可以先跳过）

4. 体验发送交易的流程

观察:

• 注册流程像普通 App，无需备份助记词
• 交易确认使用生物识别（指纹/面容）
• 内置 DeFi 功能（Swap、Staking）

操作3: 使用 Stackup 或 Pimlico 测试 AA

步骤:

1. 访问 stackup.sh 或 pimlico.io

2. 查看文档，了解如何发送 UserOperation

3. 使用测试网体验 Gas 代付功能

观察:

• UserOperation 比普通交易包含更多字段
• Paymaster 可以让你不花 ETH 就完成交易
• 批量操作可以节省 Gas 和时间

今日思考

问题1: 为什么 AA 还没有大规模普及？

我的理解：

1. 生态兼容性：很多 DApp 仍假设用户是 EOA，需要适配

2. 部署成本：首次使用需要部署合约，有额外成本

3. 用户习惯：MetaMask 已成为主流，迁移成本高

4. 开发者认知：很多开发者还不熟悉 AA

5. 但趋势已定，Coinbase、OKX 等都在推智能钱包

问题2: Paymaster 会不会被滥用？

我的理解：

有可能，但有防护机制：

• 质押机制：Paymaster 需质押 ETH，作恶会被罚没
• 限额控制：可设置每用户/每日限额
• 条件验证：可要求用户持有特定 NFT 或代币
• 经济模型：最终还是有人付费，只是转移了支付方

问题3: AA 对产品设计有什么影响？

我的理解：

作为 PM，AA 带来的机会：

• 降低门槛：用户无需理解私钥、Gas，像 App 一样注册
• 免 Gas 促销：新用户前 N 笔交易免费
• 批量操作：一键完成多步骤流程（如 Swap + Stake）
• 安全特性：交易限额、白名单，适合企业/机构
• 订阅模式：定时自动执行的交易

学习资源

视频教程

文档阅读

工具网站

延伸阅读

面试题准备

Q1: 账户抽象(AA)对用户体验有什么影响？

30秒版本:

AA 让钱包体验从"管理私钥"变成"使用 App"。用户可以用邮箱/手机注册、用 USDC 付 Gas 或免 Gas、丢失设备后社交恢复、一次签名完成多步操作。这大幅降低了 Web3 的使用门槛，是大规模采用的关键。

2分钟版本:

• 背景: 当前 Web3 最大障碍是私钥管理和 Gas 费理解
• AA 带来的改变:

1. 注册体验: 无需备份助记词，像 App 一样注册

2. Gas 支付: 可用稳定币支付，或由 DApp 赞助

3. 安全性: 社交恢复、多签、交易限额

4. 操作效率: 批量交易，一次签名完成多步骤

5. 签名方式: 支持 Passkey（指纹/面容）

• 实际案例: Coinbase Smart Wallet、Reddit Vault
• 我的观点: AA 是 Web3 大规模采用的必经之路，预计未来2-3年会成为主流

可能追问:

• ERC-4337 为什么不需要修改协议？→ 通过 EntryPoint 合约和 Alt Mempool 在应用层实现
• Paymaster 如何盈利？→ 通过代币兑换差价、品牌合作、或作为获客成本

Q2: ERC-4337 的核心组件有哪些？各自作用是什么？

30秒版本:

四个核心组件：1) UserOperation - 用户意图的载体；2) Bundler - 收集打包 UserOps 并提交上链；3) EntryPoint - 全局入口合约，处理所有 UserOps；4) Paymaster - 可选，代替用户支付 Gas。

2分钟版本:

1. UserOperation（用户操作）

• 类似交易但更丰富的数据结构
• 包含 sender、callData、签名、Paymaster 信息等
• 支持批量操作和自定义验证逻辑

2. Bundler（打包者）

• 监听 Alt Mempool 收集 UserOps
• 验证和模拟，过滤无效操作
• 打包多个 UserOps 成一笔交易
• 去中心化市场，任何人可运行

3. EntryPoint（入口合约）

• 全局单例合约，所有 UserOps 的入口
• 验证签名、执行操作、处理 Gas 结算
• 确保整个流程的安全性

4. Paymaster（付款者）

• 可选组件，实现灵活的 Gas 支付
• 三种模式：完全赞助、ERC-20 支付、条件赞助
• 需质押 ETH 作为安全保证

Q3: 如果你是钱包产品的 PM，会如何设计 AA 钱包的新用户引导？

30秒版本:

三步走：1) 0 摩擦注册 - 邮箱/手机号即可，首次交易时再部署合约；2) 新手保护 - 默认开启交易限额和安全延迟；3) 渐进式教育 - 先用起来，再逐步引导设置 Guardian 和高级功能。

2分钟版本:

1. 注册流程

• 支持邮箱/手机号/社交登录
• 使用 Passkey 作为默认签名方式
• 合约部署延迟到首次交易（降低成本）
• 前5笔交易 Gas 赞助

2. 安全设置（渐进式）

• Day 1: 基础使用，后台默认设置
• Day 7: 提示添加第一个 Guardian
• Day 30: 引导设置交易限额
• 高价值操作时强制要求升级安全等级

3. 教育内容

• 情境化教学：在用户第一次 Swap 时解释滑点
• 避免术语：用"备份联系人"代替"Guardian"
• 可视化进度：安全等级进度条

4. 差异化功能

• 新用户：简化界面，隐藏高级功能
• 进阶用户：开放多签、自动化等
• 企业用户：审批流程、权限管理

代码实践

今日无代码改动

Day 24 主要是理解 AA 概念和体验智能钱包。后续可考虑：

• 集成 AA SDK（如 ZeroDev）到 momoweb3
• 添加 Smart Wallet 连接支持
• 实现 Gas 赞助功能

明日预告

Day 25: 社交恢复、Gas代付、批量交易

• 学习内容: AA 的实际应用场景深入
• 链上操作: 使用 Pimlico/Stackup 测试 Gas 代付
• 产出要求: AA 用例清单
• 关键概念: 如何设计安全又好用的恢复机制