05 · 钱包与账户：EOA / 合约钱包 / HD 钱包 / Nonce / Permit2 / EIP712 / AA（★★★★★）

很多人不会重视钱包这一层，但套利实战中钱包设计几乎决定了系统的安全性和可用性上限。 与 notes/06-账户模型.md 互补：那篇讲账户模型底层原理，本篇讲工程实践中"怎么用、怎么踩坑"。

0. 一句话本质

钱包不是"一个存钱的 App"，是"谁能对链上状态签发合法指令"的凭证系统。 EOA 靠一把私钥，合约钱包靠一段可编程逻辑，HD 钱包靠一棵可派生的密钥树， Nonce 保证指令不被重放，签名标准（Permit2/EIP712）让"授权"本身也能被签名而不必上链交易， Account Abstraction 则试图把"钱包"从"一把私钥"升级成"一个可编程账户"。

1. EOA：Externally Owned Account

  • 由一对公私钥控制，没有代码，主动发起交易的唯一账户类型（合约账户不能自己发起交易，只能被调用后在内部发起）。
  • 地址 = Keccak256(公钥) 后 20 字节（见 02-密码学基础.md §1）。
  • 套利工程视角：机器人的执行账户通常是 EOA（私钥直接由服务器持有，签名发交易）—— 这意味着私钥泄露 = 资金全部风险敞口，是安全设计的第一优先级（密钥管理见 §7）。

2. Contract Wallet（合约钱包）：多签与可编程权限

  • 本质是一个合约，账户逻辑（谁能操作、需要几人同意、能不能设定每日限额）完全可编程。
  • 多签（Multisig）（如 Gnosis Safe）：N 个签名者中 M 个同意才能执行交易， 常用于协议金库、DAO 资金、团队共管钱包——套利团队的"总资金池"通常放多签而非单一 EOA。
  • 风险与好处并存：合约钱包本身也是合约，可能有 bug（历史上 Parity 多签因初始化漏洞导致资金永久锁死）； 好处是可以做复杂权限（时间锁、白名单、限额）。

3. HD Wallet：为什么一句助记词能生成无数地址

  • Hierarchical Deterministic Wallet（分层确定性钱包，BIP32/BIP39/BIP44 标准）： 一个随机种子（助记词就是这个种子的可读编码）通过确定性算法派生出一整棵密钥树， 每个叶子节点是一对独立的公私钥。
  • 好处：备份一句助记词 = 备份无限个账户；不同链（以太坊/比特币/Solana）用不同的派生路径（如 m/44'/60'/0'/0/0）， 同一份助记词能派生出多链账户——这是为什么大多数钱包 App（MetaMask 等）只需要你备份一次助记词。
  • 套利工程实践：机器人集群通常用同一助记词派生多个执行账户（分散 nonce 竞争、隔离风险）， 但助记词本身仍是唯一根密钥，必须离线/加密保管。

4. Nonce：为什么重复交易会失败

  • 每个 EOA 有一个严格递增的计数器，每发一笔交易该值 +1；节点只接受"下一个预期 nonce"的交易。
  • 为什么重要：
    • 防重放攻击：同一笔已广播交易不能被重复执行两次。
    • 套利机器人常见故障点：并发发送多笔交易时 nonce 管理不当（比如两个进程用同一个 nonce）， 会导致其中一笔卡住/失败，必须有独立的 nonce 管理器（本地维护递增计数，或用 "nonce gap" 检测）。
    • Gas 涨价重发（replace-by-fee）也是通过"用相同 nonce、更高 gas price 重新发送"实现， 这是套利/MEV 场景里"加速交易上链"的标准手段。

5. Signature：为什么套利离不开签名

  • 见 02-密码学基础.md §3（ECDSA），这里聚焦"签名在套利场景的具体用法"：
    • 交易签名：每笔链上交易本身都需要私钥签名才能被节点接受。
    • 离线签名（不上链）：很多协议允许你用签名授权一个操作，而不需要自己先发一笔交易—— 这能省一次 gas、也能让第三方（如 Router 合约）代付 gas 执行，见下方 Permit/Permit2。

6. Permit / Permit2：把"授权"变成一次签名而不是一笔交易

  • 传统 ERC20 授权流程：先 approve（一笔交易，花 gas）→ 再调用目标合约的函数（第二笔交易）。
  • EIP-2612 Permit：让 ERC20 支持"用签名代替 approve 交易"——用户离线签一个消息， 目标合约调用 permit(owner, spender, value, deadline, v, r, s) 就能在同一笔交易里完成授权+使用， 省了一笔独立的 approve 交易。
  • Permit2（Uniswap 提出的通用授权层）：即使某个 ERC20 本身不支持 EIP-2612， 用户也只需一次性把额度授权给 Permit2 合约，之后所有对接 Permit2 的协议都能用签名（而非交易）来使用这份额度—— 本质是把"逐协议 approve"统一收敛成"一次性信任一个中间层"，大幅减少用户需要发起的授权交易数量。
  • 套利工程意义：机器人批量操作多个协议时，Permit2 能减少交易数（省 gas、省时间）， 但也意味着"信任 Permit2 合约本身的安全性"——这是引入新中间层必须权衡的风险。

7. EIP712：让离线签名"人类可读、不可被跨场景重放"

  • 问题：任意字符串都能被 ecrecover 验证签名，但用户在钱包里签一段没有结构的字节， 既看不懂签的是什么，也可能被诱导签一个"看起来是给 A 用，实际能在 B 场景重放"的消息。
  • EIP712 定义了一套"结构化数据签名"标准：签名消息带有类型化字段（如 {owner, spender, value, nonce, deadline}） 和一个"域分隔符"（domain separator，包含合约地址、chainId、协议名称版本）， 钱包 App 能显示"你正在签什么"，且同一份签名不能在不同合约/不同链上被重放。
  • Permit、大多数链下订单簿（如 0x Protocol、Seaport）、跨链消息授权都建立在 EIP712 之上。

8. Account Abstraction（ERC-4337）：未来趋势

  • 问题：EOA 的账户逻辑是硬编码在协议层的（只能用 ECDSA 签名、gas 必须用 ETH 支付、 没有原生的多签/限额/社交恢复能力）。
  • ERC-4337 在不修改以太坊协议本身的前提下，通过一套"UserOperation + Bundler + EntryPoint"体系， 让账户逻辑完全可编程：可以用任意签名方案（如生物识别、多签、Passkey）、 可以让第三方代付 gas（Paymaster）、可以批量执行多个操作（batching）。
  • 套利工程意义：AA 账户能实现"策略合约本身既是账户又是执行者"，减少 EOA 私钥暴露面， 还能通过 Paymaster 用稳定币付 gas，简化多链资金管理——是当前钱包架构演进的主要方向。

9. 前置名词小词典

  • 助记词（Mnemonic / Seed Phrase）：BIP39 标准编码的随机种子，人类可记录的形式。
  • 派生路径（Derivation Path）：HD 钱包中定位某个具体密钥在树中位置的路径字符串。
  • 域分隔符（Domain Separator）：EIP712 中用于区分"这份签名是给哪个合约/哪条链用的"的哈希值。
  • Bundler：ERC-4337 中负责收集 UserOperation、打包提交上链的角色，类似"账户抽象层的 mempool 参与者"。
  • Paymaster：ERC-4337 中代替用户支付 gas 的合约，可实现"用稳定币付 gas"等体验。

10. 常见误区

  • ❌ "钱包地址泄露就等于私钥泄露" → 地址是公开信息，泄露地址无风险；私钥/助记词才是唯一敏感信息。
  • ❌ "Permit2 授权无限额度很安全，因为随时能撤销" → 无限额度授权给中间层，若中间层本身出漏洞， 风险敞口是全部余额，"能撤销"不等于"零风险窗口"。
  • ❌ "多签钱包比 EOA 绝对安全" → 多签把风险从"私钥泄露"转移到"合约逻辑漏洞 + 签名者串通"，是不同维度的风险，不是消除风险。
  • ❌ "AA 账户就是多签钱包的另一个名字" → AA 的核心是账户逻辑可编程，多签只是其中一种可能实现， AA 还包括代付 gas、批量操作、自定义签名方案等更广泛的能力。

11. 与套利实践的对应 / 自检问题

对应：06-Token标准.md（Permit/Permit2 是 ERC20 生态的一部分）、 11-量化套利系统.md（"自动执行"模块必须处理 nonce 管理与密钥安全）、 12-系统架构设计.md（"Wallet Center"是系统架构里独立的一块）。

自检：

  1. 你的机器人同时对 3 条链发交易，nonce 管理如果出错会导致什么后果？
  2. Permit2 相比传统 approve 流程，省掉了哪一步？代价是新增了什么信任假设？
  3. EIP712 的"域分隔符"具体防止了什么类型的攻击？
  4. 为什么说 ERC-4337 不需要修改以太坊协议本身就能实现账户抽象？

── Q&A / 更正记录区（按日期追加）──

原始讨论记录见 Q&A/（按日期归档，保留完整来回过程）；本节是同步后的结论摘要， 只增不删——若后续发现本篇正文表述不准确，按更正记录追加在此，不删改正文， 保留"原来写的是什么 → 后来发现哪里不准 → 更正为什么"的轨迹。规范见 Q&A/README.md。

  • (2026-07-26 建立。暂无 Q&A——后续围绕本篇的提问/质疑/更正在此累积。)