MPC 钱包与密钥管理：门限签名、2-of-3 架构与攻击面分析

私钥一旦完整地存在于某一台设备的某一时刻，它就已经是一个单点故障：可能被窃取、被内部人员导出、被备份文件泄露，也可能因为设备损坏而永久丢失。MPC 钱包的思路是让私钥从生成到签名全程不以完整形态出现——每个参与方只持有一份分片，签名时通过多方计算协同产出一个合法的签名，而任何人都无法从自己的分片与交互记录中还原出私钥。

本文从门限签名原理讲到工程落地：TSS 的密钥生成与签名协议、2-of-3 架构的恢复路径、与多签钱包的取舍、分片托管与备份策略、性能与延迟、通信与重放攻击面，最后是合规与托管场景下的实践要点。

前置：多签与托管钱包的架构与治理实践，钱包与 dApp 的签名交互流程。

目录

• 1. MPC 钱包的定位与基础
• 2. 门限签名与 TSS 协议
• 3. 2-of-3 架构与恢复流程
• 4. 与多签和智能合约钱包的取舍
• 5. 密钥分片托管与备份
• 6. 签名流程与性能
• 7. 攻击面分析
• 8. 密钥刷新与主动安全
• 9. 合规与托管实践
• 10. 工程落地建议

1. MPC 钱包的定位与基础

1.1 与传统方案的分野

MPC 的核心卖点有三个：链上无足迹（对链而言就是一个普通 EOA 签名，兼容所有链与所有 dApp）、无单点私钥（任何一方都无法独立签名）、可编程策略（分片可托管在服务端、用户设备、恢复方）。

1.2 密码学基础

MPC 钱包依赖两类原语：

• 秘密分享（Secret Sharing）：Shamir 方案把秘密 s 拆成 n 份，任意 t 份可重构，少于 t 份得不到任何信息。经典方案是「先拆分再重构」，重构时私钥会短暂完整出现，因此不能直接用于签名。
• 门限签名（Threshold Signature）：密钥生成阶段就直接产出分片，签名阶段通过多方计算产出签名，私钥全程不重构。这才是 MPC 钱包的正确基础。

Shamir（不安全用法）：拆私钥 → 签名时重构 → 私钥短暂暴露在内存
TSS（安全用法）：    分布式生成 → 分布式签名 → 私钥从未存在

2. 门限签名与 TSS 协议

2.1 两类签名算法

EdDSA 与 Schnorr 的签名是「私钥与随机数的线性组合」，分片可以直接相加，实现简洁；ECDSA 需要计算 k^-1，无法直接线性组合，必须引入 Paillier 同态加密或不经意传输（OT）来安全计算逆元，这是 ECDSA 门限签名实现复杂、性能较低的根本原因。

2.2 密钥生成（DKG）

分布式密钥生成（DKG）让参与方在不暴露各自秘密的前提下共同产出一个公钥：

DKG 流程（t-of-n）：
1. 每个参与方 Pi 生成随机多项式 fi(x)，阶为 t-1
2. Pi 计算 fi(j) 并私密发送给 Pj（加密 + 认证）
3. 每个 Pj 收到的所有 fi(j) 求和，得到自己的分片 sj
4. 各方广播对 fi(0) 的承诺，验证分片一致性
5. 公钥 = 各方承诺之和，私钥 = 各 fi(0) 之和（从未被任何人知道）

关键安全点：分片必须经认证信道传输，且必须有对承诺的一致性校验（Feldman / Pedersen VSS），否则恶意参与方可以发送不一致的分片，导致后续签名永久失败（这是一种 DoS 攻击，称为「分片污染」）。

// 概念示意：分片求和（实际实现使用成熟库如 multi-party-ecdsa）
fn combine_share(shares: &[Scalar]) -> Scalar {
    shares.iter().fold(Scalar::zero(), |acc, s| acc + s)
}

2.3 签名协议

签名需要 t 方参与，通常分若干轮通信：

门限 ECDSA 签名（简化）：
Round 1: 各方生成随机数分片，计算并广播承诺
Round 2: 各方计算 k 的门限逆元（需 Paillier/OT），计算 r 与 s 分量并验证

轮次越多、通信量越大，延迟越高。生产系统通常把签名压缩到 2~3 轮，并把大数运算下沉到高性能库。

3. 2-of-3 架构与恢复流程

3.1 分片分布

2-of-3 是消费级与机构级 MPC 钱包最常见的配置，三份分片分别放在：

日常签名用 A + B，用户设备丢失时用 B + C 恢复（或重建新分片），服务方宕机时用 A + C。

3.2 恢复流程

恢复不是「重构私钥」，而是用两份分片重新执行一次 DKG，生成一套全新的分片与公钥映射（保持同一公钥）：

设备丢失恢复流程：
1. 用户通过身份验证（邮箱 + 生物特征 / 证件）
2. 服务方与恢复方各出分片，执行主动刷新协议
3. 产出新分片集合（公钥不变，链上地址不变），旧分片全部作废
4. 记录恢复事件并通知用户

关键性质是公钥不变：用户不需要迁移资产、不需要更新合约授权。这也是 MPC 相对多签的最大便利之处。

3.3 恢复环节的信任

恢复流程的安全性取决于身份验证的强度：如果恢复仅依赖邮箱验证码，攻击者攻破邮箱即可接管钱包。机构级方案通常要求：

• 多重身份验证（设备指纹 + 生物特征 + 人工审核）。
• 恢复延迟（如 48 小时冷静期），期间可通过原设备取消。
• 恢复通知多渠道触达（邮件、短信、App 推送）。

4. 与多签和智能合约钱包的取舍

4.1 对比矩阵

4.2 选型要点

• 需要兼容非 EVM 链（Solana、Bitcoin）：只能选 MPC。
• 需要链上透明的治理与审计：多签合约更合适。
• 需要社交恢复、代付 gas、批量执行：ERC-4337 智能合约钱包。
• 对 gas 极度敏感的高频交易：MPC 优势明显。

实务中常出现混合架构：用 MPC 管理「热钱包」，用多签管理「冷金库」，两者通过策略引擎联动。

// 混合架构中的链上限额检查（多签金库侧）
contract VaultGuard {
    mapping(address => uint256) public dailyLimit;
    mapping(address => uint256) public spentToday;

    function checkAndRecord(address token, uint256 amount) external {
        require(spentToday[token] + amount <= dailyLimit[token], "DAILY_LIMIT");
        spentToday[token] += amount;
    }
}

5. 密钥分片托管与备份

5.1 托管位置的组合

5.2 备份策略

• 分片加密后备份：备份的是分片而非私钥，单份泄露不构成威胁，但仍应加密（防止分片+侧信道组合攻击）。
• 异地多副本：同一分片在至少两个地理区域备份，防止区域性灾难。
• 备份介质隔离：冷分片备份不应与热分片放在同一信任域。
• 定期演练恢复：备份的价值只有在恢复演练通过后才被证实。

备份检查清单：
□ 每个分片至少 2 份异地副本
□ 备份加密密钥与分片分开保管
□ 恢复演练每季度至少一次
□ 人员离职后分片访问权限即时回收

6. 签名流程与性能

6.1 延迟构成

总延迟 = 网络往返 + 密码学计算 + 策略校验 + 链上广播
典型量级（2-of-3，跨地域）：
网络往返      20 ~ 200 ms
ECDSA 门限签名 30 ~ 300 ms（依赖 Paillier 实现）
策略校验      1 ~ 20 ms
链上广播      视链而定

与本地私钥签名（微秒级）相比，MPC 的延迟高出一到两个数量级。对交易机器人、高频 DEX 套利这类场景，MPC 可能不适用；对资产托管、机构结算，几百毫秒完全可以接受。

6.2 性能优化手段

预计算是效果最显著的手段：把与消息无关的计算（如 Paillier 密钥、随机数承诺）提前离线完成，签名时只需少量在线交互。

6.3 并发与队列

服务端需处理多个并发签名请求，必须注意：

• 每个签名会话使用独立的随机数与会话 ID，绝不复用。
• 同一分片的并发访问需串行化，避免状态竞争。
• 会话超时后必须显式清理中间状态。

7. 攻击面分析

7.1 通信层

7.2 协议层

• 随机数复用：ECDSA 中若两次签名使用相同的 k，私钥可被直接解出（这是最致命的实现错误）。必须使用密码学安全的随机源，并在协议层校验 k 的新鲜性。
• 签名轮次重放：攻击者重放之前的签名轮次，可能诱导生成对旧消息的签名。
• 恶意参与方偏离协议：需要可识别中止（identifiable abort），能定位到具体是哪一方作恶。

// 反例：危险的随机数生成（绝不可用于生产）
// let k = Scalar::from(12345u64);   // 固定 k → 私钥可被直接恢复

// 正例：使用 CSPRNG 并由协议校验
let k = Scalar::random(&mut OsRng);

7.3 实现层

• 侧信道：大数运算的时间与功耗特征可能泄露分片信息，需常量时间实现。
• 内存残留：分片使用后应立即清零（zeroize），避免被内存转储获取。
• 依赖库漏洞：门限签名库历史上出现过多次实现缺陷，需持续跟踪安全公告，调试日志中绝不可打印分片或中间密钥材料。

7.4 风险清单

8. 密钥刷新与主动安全

8.1 主动刷新（Proactive Refresh）

刷新协议在不改变公钥的前提下重新生成所有分片：攻击者即使拿到了 t-1 份旧分片，刷新后也全部失效。

刷新流程：
1. 各方生成一个「零分享」多项式（各阶系数之和为 0）
2. 各方互相发送零分享的子分片，并加到自己的分片上
3. 分片全部更新，公钥与地址保持不变

零分享的关键性质是「各方分片之和不变」，因此公钥不变。这让定期刷新成为对抗长期潜伏攻击的有效手段。

8.2 刷新触发条件

• 定期刷新：如每季度一次，限制长期潜伏攻击者的时间窗。
• 事件驱动刷新：设备更换、人员变动、安全事件后立即刷新。
• 合规要求：部分托管规范要求密钥材料定期轮换。

8.3 与密钥轮换的区别

9. 合规与托管实践

9.1 合规关注点

9.2 治理策略引擎

机构级 MPC 钱包通常把「谁能签、签什么、签多少」做成链下策略引擎，在签名前强制校验：

策略示例：
- 单笔转账 ≤ 10 ETH 需 2-of-3；> 10 ETH 需 3-of-3 或人工审批
- 白名单地址可直接放行，非白名单需双人复核
- 每日累计转出上限，超过需走治理流程
- 异常时间（非工作时间）交易自动升级审批层级

策略引擎是 MPC 钱包的「大脑」，其自身的安全等级必须与分片托管同等对待。

9.3 托管服务选型

评估托管方案时应确认：

• 分片是否跨独立信任域（服务方 + 用户 + 第三方）。
• 是否支持主动刷新与可识别中止。
• 恢复流程的身份验证强度与冷静期。
• 是否提供可验证的审计日志与独立第三方审计报告。
• 退出机制：用户能否在不依赖服务方的情况下恢复资产。

10. 工程落地建议

10.1 实施路线

1. 明确威胁模型：先回答「防谁」——外部攻击者、内部人员还是服务方作恶。
2. 选择曲线与算法：EVM 生态选 secp256k1 门限 ECDSA，Solana 生态选 ed25519。
3. 确定分片分布：至少三个独立信任域，避免同一云厂商托管全部热分片。
4. 设计策略引擎：把业务规则前置到签名之前，而非事后审计。
5. 建立刷新与恢复演练：把刷新纳入常规运维，恢复演练按季度执行。
6. 接入监控：签名失败率、延迟分布、异常策略命中、分片访问日志。

10.2 常见误区

• 把 MPC 当成万能药：若三份分片都在同一台服务器上，MPC 毫无意义。
• 忽略恢复流程：绝大多数 MPC 事故出在恢复环节而非签名环节。
• 忽视随机数质量：固定或低熵的 k 会让门限签名彻底失效。
• 不做主动刷新：长期不刷新让「潜伏式」攻击者的时间窗无限大。
• 把策略引擎做成单点：策略引擎被攻破等于所有分片失守。

10.3 速查表与一句话记忆

一句话记忆：MPC 的价值是消除单点私钥，代价是把风险转移到协议实现、通信安全与恢复流程上，而事故往往出在后两者。

延伸阅读

• 多签与托管钱包的治理架构与运维实践
• 钱包签名交互与 dApp 集成流程
• ERC-4337 账户抽象与社交恢复模块
• 去中心化身份与密钥绑定关系
• 密钥管理与合约安全的整体风险视角
• Web3 区块链专题 — 区块链 Web3 专题