MetaMask 架构分析
1. Google 登录 + 无种子短语的钱包架构
MetaMask 提供了「Seedless Onboarding」（无种子注册）模式——用户通过 Google 登录 + 密码即可创建钱包，无需手动保管助记词（SRP）。
关键事实：SRP（种子短语）仍然存在，只是由系统自动生成并加密备份到 MetaMask 服务器，用户不可见。
1.1 核心组件
组件 (@metamask/*) |
职责 |
|---|---|
seedless-onboarding-controller |
编排整个 seedless 流程：认证 → 密钥派生 → 备份 → 恢复 |
social-controllers |
处理 Google/Apple OAuth 社交登录 |
passkey-controller |
WebAuthn 通行密钥，用于设备级安全认证 |
authenticated-user-storage |
存储用户数据到 MetaMask 服务器 (非 E2EE，但内容加密) |
profile-sync-controller |
跨设备同步加密数据，客户端加密后上传 |
delegation-controller |
EIP-712 签名委托记录管理 |
1.2 整体架构
图 1
1.3 创建钱包流程
图 2
1.4 多设备恢复（电脑 → 手机）
图 3
1.5 其他设备修改密码后的同步
图 4
2. 安全模型
2.1 密钥层次
用户密码 + TOPRF 分布式节点
│
▼
encKey (AES-256-GCM 加密密钥)
│
├──▶ 加密 SRP → 上传 MetaMask 服务器 (密文)
│
└──▶ 加密本地 Vault (密文)
2.2 各方的能力边界
| 参与方 | 能做什么 | 不能做什么 |
|---|---|---|
| MetaMask 服务器 | 存储加密 SRP blob（密文），OAuth 身份验证 | 解密 SRP（没有用户密码，且 TOPRF 密钥分散在阈值节点） |
| TOPRF 阈值节点 | 参与密钥派生计算（OPRF 协议） | 单节点无法还原密钥（需要阈值数量的节点协作） |
| 提供 OAuth idToken 验证用户身份 | 与密钥完全无关 | |
| 用户 | 持有密码 + Google 账号，两个因子缺一不可 | 也是唯一能解密 SRP 的人 |
2.3 安全依赖
| 因素 | 作用 |
|---|---|
| Google 账号 (OAuth) | 认证层——确认"你是谁"，获取访问加密 blob 的权限 |
| 用户密码 | 加密层——派生密钥材料，没有它无法解密 SRP |
| TOPRF 阈值 (MPC) | 分布式密钥派生，降低单点风险 |
3. 与传统注册模式对比
| 传统模式（助记词） | Seedless 模式（Google + 密码） | |
|---|---|---|
| SRP 是否存在 | 是，用户手动记录保管 | 是，系统自动生成，用户无感知 |
| SRP 存储位置 | 仅本地 Vault（加密） | 本地 Vault（加密） + 服务器备份（加密） |
| 跨设备同步 | 手动输入助记词导入 | Google 登录 → 自动解密恢复 |
| 丢失风险 | 丢助记词 = 丢资产 | 丢 Google 号 或 丢密码 = 丢资产 |
| 服务器可见内容 | 无 | 加密后的密文 blob（不可读） |
| 服务器安全性 | 不依赖 | 依赖 MetaMask 服务器可用性，但不依赖其保密性 |
4. 关键源码
| 组件 | 路径 |
|---|---|
| SeedlessOnboardingController | @metamask/seedless-onboarding-controller/src/SeedlessOnboardingController.ts |
| TOPRF 安全备份 | @metamask/toprf-secure-backup |
| Authenticated User Storage | @metamask/authenticated-user-storage |
| Profile Sync Controller | @metamask/profile-sync-controller |
| Social Controllers | @metamask/social-controllers |
| Passkey Controller | @metamask/passkey-controller |
| 仓库 | MetaMask/core |