Social Recovery Wallets（社交恢复钱包）

目录

1. 什么是社交恢复钱包
2. 三大核心组件
3. 与传统多签钱包的区别
4. Shamir 秘密共享——守护者如何保管密钥
5. 多方系统的安全优势
6. 推荐的钱包产品
7. 智能合约钱包的主要缺点
8. 总结对比
9. 实践项目：在 Sepolia 上部署一个简易社交恢复钱包

---

1. 什么是社交恢复钱包

社交恢复钱包（Social Recovery Wallet）是一种以智能合约为基础的高级加密资产存储方案，由以太坊创始人 Vitalik Buterin 等业界领袖强烈推荐。

它解决的核心痛点是：“私钥丢了怎么办？”

传统钱包（EOA）私钥一旦丢失，资产就永久消失，没有任何找回机制。而社交恢复钱包引入了”守护者”制度，允许你在丢失主密钥时，通过事先指定的守护者合作将账户控制权恢复到新密钥上。

---

2. 三大核心组件

组件一：单一签名密钥（Signing Key）

这是你日常使用的主密钥，用于授权每一笔转账或合约交互。在正常状态下，你只需这一把钥匙就能完成所有操作，体验与普通钱包完全一样。

组件二：守护者（Guardians）

守护者是你预先指定的受信任个人或实体，数量通常为 3 人或更多。

守护者可以是：

• 你信任的朋友或家人
• 另一台属于你自己的设备
• 硬件钱包
• 专业的托管机构

关键点：守护者在平时对你的账户没有任何权力，只有在恢复流程触发时才会参与。

组件三：多数合作恢复（Majority Recovery）

当主签名密钥丢失或被盗时，预先定义的守护者中的多数必须合作，才能将账户的签名密钥更换为新的密钥。

举例说明（3 个守护者，需 2 人同意）：

你的 3 位守护者：Alice、Bob、Carol

主密钥丢失后，恢复流程：
1. 你联系 Alice 和 Bob 发起恢复请求
2. Alice 和 Bob 各自确认同意
3. 智能合约验证 2/3 同意条件满足
4. 旧签名密钥被替换为你的新密钥
5. 账户恢复完成，资产安全

---

3. 与传统多签钱包的区别

这是最容易混淆的地方，核心区别在于日常使用体验。

对比维度	社交恢复钱包	传统多签钱包（如 Safe）
日常转账	只需 1 个签名，即时完成	每笔交易都需要多人签名
密钥恢复	守护者多数同意后可恢复	无专属恢复机制
使用场景	个人用户	团队/组织资金管理
操作便利性	高（日常单签）	低（每次都多签）
安全冗余	守护者提供恢复保障	多签本身就是安全机制

一句话总结： 社交恢复钱包平时用起来像普通钱包一样方便，只有在需要恢复时才依赖多人协作；而多签钱包每次操作都需要多人参与。

---

4. Shamir 秘密共享——守护者如何保管密钥

你可能会有一个疑问：“守护者持有我的密钥碎片，他们会不会偷走我的钱？”

这里就用到了一项密码学技术：Shamir 秘密共享（Shamir’s Secret Sharing）。

工作原理

主密钥不是完整地交给某一个守护者，而是被数学切割成多个”份额（Share）“，每位守护者只持有其中一片：

完整主密钥 K
   ↓ 数学分割（Shamir算法）
份额A → 发给 Alice（20个单词）
份额B → 发给 Bob（20个单词）
份额C → 发给 Carol（20个单词）

任意 2 份份额 → 可重构出完整密钥 K
任意 1 份份额 → 无法获得任何密钥信息

具体数值示例（2-of-3 方案）

假设主密钥数值为 1234（实际是256位大数，这里简化）：

• 设定阈值：需要 2 个份额才能恢复
• 算法生成：
  • 份额A = 5678（给 Alice）
  • 份额B = 9012（给 Bob）
  • 份额C = 3456（给 Carol）
• 任意两个份额通过多项式运算即可还原出 1234
• 单独持有任何一个份额，无法推算出原始密钥

恢复份额的实际形式

守护者收到的份额通常表现为一段20到33个英文单词的助记词序列，例如：

apple banana cherry dog elephant fox grape harvest...

这些单词本身对守护者毫无意义，也无法单独使用，只有达到阈值数量的份额合并后才能恢复密钥。

---

5. 多方系统的安全优势

优势一：多重防护层

敏感操作（如更换签名密钥）需要经过多个独立步骤和多人授权，攻击者无法仅凭控制单一密钥就完成攻击。

优势二：密钥妥协缓解

即使你的主签名密钥被黑客获取，黑客依然无法直接更换密钥（因为更换密钥需要守护者多数同意）。而你可以通过守护者发起紧急恢复，将密钥换掉，让黑客持有的旧密钥失效。

攻击场景对比：

普通 EOA 钱包：
黑客拿到私钥 → 立刻转走全部资产 → 无法阻止 ✗

社交恢复钱包：
黑客拿到主签名密钥 → 可以发起普通交易
但如果你发现异常 → 立刻联系守护者发起恢复 → 更换密钥 → 黑客旧密钥作废 ✓

---

6. 推荐的钱包产品

社交恢复钱包

• Argent：最知名的社交恢复钱包，支持移动端，内置守护者系统
• Safe（前身 Gnosis Safe）：既支持多签也支持社交恢复模块
• Trezor Model T：硬件钱包，支持 Shamir 备份

多签钱包

• Safe：行业标准多签方案，广泛用于 DAO 和团队资金管理

---

7. 智能合约钱包的主要缺点

社交恢复钱包本质上是智能合约钱包，因此有以下固有限制：

缺点一：dApp 兼容性有限

部分 dApp 对智能合约钱包的支持不够完善，可能遇到无法连接或功能异常的情况。

缺点二：Gas 费用更高

每次交互都需要调用智能合约逻辑，比普通 EOA 转账消耗更多 Gas。

缺点三：跨链地址不一致（重要！）

这是最容易踩坑的地方：

EOA 钱包地址：
  以太坊主网：0xABCD...1234
  Polygon：   0xABCD...1234  ← 完全相同
  Arbitrum：  0xABCD...1234  ← 完全相同

智能合约钱包地址：
  以太坊主网：0xABCD...1234
  Polygon：   0x9999...FFFF  ← 不同！（需要单独部署）
  Arbitrum：  0x7777...EEEE  ← 不同！（需要单独部署）

这意味着你在每条链上都需要单独部署并管理自己的合约钱包，不能像 EOA 那样用同一个地址跨链接收资产。

---

8. 总结对比

钱包类型	日常便利性	密钥丢失风险	跨链一致性	Gas 费用	推荐人群
EOA（普通钱包）	高	极高（永久丢失）	一致	低	轻度用户
多签钱包	低（每次多签）	中	不一致	高	团队/组织
社交恢复钱包	高（日常单签）	低（可恢复）	不一致	较高	个人高价值资产

---

9. 实践项目：在 Sepolia 上部署一个简易社交恢复钱包

项目目标

实现一个具备核心功能的社交恢复钱包合约，支持：

• 单签名日常转账
• 守护者管理
• 2-of-3 多数投票恢复签名密钥

项目架构

SocialRecoveryWallet.sol
├── 状态变量
│   ├── address public owner（当前签名密钥/所有者）
│   ├── address[] public guardians（守护者列表）
│   ├── uint256 public threshold（恢复所需最少同意数，如 2）
│   └── mapping: guardian => bool（是否已投票支持恢复）
│   └── address public proposedNewOwner（待恢复的新所有者地址）
│   └── uint256 public recoveryVoteCount（当前投票数）
├── 日常功能
│   ├── execute()：owner 调用，发送 ETH 或调用合约
│   └── receive()：接收 ETH
└── 恢复功能
    ├── proposeRecovery(newOwner)：守护者提议新 owner
    ├── supportRecovery()：其他守护者投票支持
    └── executeRecovery()：投票达到 threshold 后执行，更换 owner

合约核心逻辑思路

步骤一：初始化

构造函数接收三个参数：

• _owner：初始签名密钥地址
• _guardians：守护者地址数组（至少3个）
• _threshold：恢复所需最小同意数（建议设为 guardians.length / 2 + 1）

步骤二：日常转账（execute）

只有 owner 可以调用，使用低级 call 发送 ETH 或触发其他合约函数：

function execute(address to, uint256 value, bytes calldata data)
    external
    onlyOwner
    returns (bytes memory)
{
    (bool success, bytes memory result) = to.call{value: value}(data);
    require(success, "执行失败");
    return result;
}

步骤三：发起恢复（proposeRecovery）

只有守护者可以调用，提议将 owner 替换为新地址。调用时重置所有投票状态，记录提议的新地址，并记录发起人的第一票：

function proposeRecovery(address newOwner) external onlyGuardian {
    // 重置上一次的恢复流程
    // 设置 proposedNewOwner = newOwner
    // 重置 recoveryVoteCount = 1
    // 标记发起者已投票
}

步骤四：支持恢复（supportRecovery）

其他守护者调用此函数表示同意。需要判断：

• 调用者是守护者
• 当前有进行中的恢复提议
• 调用者尚未投票（防止重复投票）

投票数加一后，如果达到 threshold，自动执行恢复（或由用户手动调用 executeRecovery）。

步骤五：执行恢复（executeRecovery）

验证投票数 >= threshold 后，将 owner 更新为 proposedNewOwner，并清空所有投票状态。

部署与测试流程

环境准备

1. 安装 Foundry（curl -L https://foundry.paradigm.xyz | bash）
2. 初始化项目：forge init social-recovery-wallet
3. 准备 4 个 Sepolia 测试地址：1个 owner + 3个 guardian

部署步骤

forge create SocialRecoveryWallet \
  --constructor-args <owner地址> "[<guardian1>,<guardian2>,<guardian3>]" 2 \
  --rpc-url https://rpc.sepolia.org \
  --private-key <你的私钥>

测试场景

1. 向合约地址转入少量 Sepolia ETH
2. 用 owner 私钥调用 execute 转出部分 ETH，验证日常功能正常
3. 用 guardian1 调用 proposeRecovery(新地址) 发起恢复
4. 用 guardian2 调用 supportRecovery() 支持（此时票数 = 2 = threshold）
5. 调用 executeRecovery()，检查 owner 是否已更新为新地址
6. 用旧 owner 尝试调用 execute，应该 revert（验证旧密钥已失效）
7. 用新 owner 调用 execute，应该成功

关键安全注意事项

• 防重入：execute 函数使用 Checks-Effects-Interactions 模式或 ReentrancyGuard
• 防重复投票：用 mapping 记录每个守护者是否已投票
• 恢复锁定期：生产环境应加入时间锁（如 48 小时冷却），防止守护者联合作恶
• 守护者数量：至少 3 人，threshold 不低于 guardians 数量的 2/3