MPC 钱包技术实现 ​

本文档详细介绍 MPC（多方计算）钱包的技术原理、产品功能和安全架构。本 MPC 方案基于 Lindell 17 论文，并扩展为 2-of-n 门限方案。

一、概述 ​

1.1 什么是 MPC 钱包？ ​

MPC（Multi-Party Computation）钱包将私钥拆分为多个"份额"（shares），分布在不同参与方之间。签名时各方协作完成计算，私钥本身从不完整出现。

1.2 为什么需要 MPC 钱包？ ​

• 消除第三方信任依赖
• 增强数据隐私
• 消除单点故障（SPOF）
• 减少冷存储依赖
• 提供接近 Web2 的用户体验

1.3 行业发展 ​

| Coinbase | 2023.03 | 自托管 | 个人及更多 | | Binance | 2023.11 | 自托管 | 个人 |

关键问题：MPC 不存在 BIP 级别的共识方案，业界基本都基于著名密码学论文私有实现，导致了 MPC 钱包孤岛化的问题。

二、产品功能 ​

2.1 功能总览 ​

graph LR
    A[创建] --> B[备份]
    B --> C[签名交易]
    C --> D[恢复]
    D --> E[逃逸]

    A -->|"服务端生成share1(TEE内)<br/>客户端生成share2,share3"| A
    B -->|"客户端加密share3<br/>备份到第三方"| B
    C -->|"share1+share2<br/>协作签名"| C
    D -->|"share3+share1<br/>重新计算新的3个share"| D
    E -->|"share1+share2<br/>计算出根私钥→EOA"| E

2.2 各功能说明 ​

三、技术原理 ​

3.1 Shamir 秘密分享（SSS） ​

核心原理 ​

一句话理解：两个点确定一条直线，三个点确定一条抛物线（拉格朗日插值法）。

构造 次多项式：

• 秘密（如私钥）编码为常数项 （即 ）
• 在曲线上取 个不同的点分配给 个参与者
• 任意 个点可通过拉格朗日插值恢复秘密
• 少于 个点无法获取任何关于秘密的信息

举例（银行卡密码） ​

假设银行卡密码是 ，构造 ：

1. 在直线上取两个点分别给两人
2. 需要时两人提供各自的点
3. 两点确定一条直线，算出 即密码

SSS 的缺点 ​

1. Dealer 作恶：分发错误的分片
2. Player 作恶：恢复阶段提供错误分片

→ 因此单纯 SSS 不够安全，需要 DKG 和 VSS 增强。

3.2 分布式密钥生成（DKG） ​

目标：不需要 Dealer（中心化分发者），每个参与方自己生成秘密并互相分享。

sequenceDiagram
    participant P1 as 参与方 P1
    participant P2 as 参与方 P2
    participant P3 as 参与方 P3

    Note over P1,P3: 每个参与方生成自己的随机多项式
    P1->>P1: 生成 f1(x) = a1·x + b1
    P2->>P2: 生成 f2(x) = a2·x + b2
    P3->>P3: 生成 f3(x) = a3·x + b3

    Note over P1,P3: 互相分发计算结果
    P2->>P1: 发送 f2(1)
    P3->>P1: 发送 f3(1)
    P1->>P2: 发送 f1(2)
    P3->>P2: 发送 f3(2)
    P1->>P3: 发送 f1(3)
    P2->>P3: 发送 f2(3)

    Note over P1,P3: 各自求和得到私钥份额
    P1->>P1: share1 = f1(1)+f2(1)+f3(1)
    P2->>P2: share2 = f1(2)+f2(2)+f3(2)
    P3->>P3: share3 = f1(3)+f2(3)+f3(3)

    Note over P1,P3: 任意2个share可恢复私钥 b1+b2+b3

关键特点：

• 完整私钥从未在任何单一实体中出现
• 实际使用中采用 VSS（可验证秘密分享） 代替 SSS，防止作弊
• 采用 Feldman's VSS 方案

3.3 从 2-2 到 2-n 的扩展 ​

创新点：基于拉格朗日插值权重，将 Lindell 17 的 2-2 方案扩展到 2-n。

群体私钥定义 ​

• Lindell 17 原始：
• 扩展：（便于扩展到多方）

权重计算 ​

假设多项式 ，群体私钥 = 1

三个点 、、，取任意两点计算权重：

• 验证： = 群体私钥 ✅

一句话总结：已知直线上两点，通过拉格朗日权重计算出两个值，其和等于 y 轴截距（群体私钥）。

3.4 阈值签名（与 ECDSA 对比） ​

Paillier 同态加密 ​

核心特性（加同态）：仅已知公钥和两个加密消息 和 ，不解密即可计算出 。

群体签名计算公式：

展开后：

P2 将部分计算结果用 Paillier 加密发给 P1，P1 利用同态性质完成最终计算。

sequenceDiagram
    participant P1 as 参与方 P1 (share1)
    participant P2 as 参与方 P2 (share2)

    Note over P1,P2: 签名准备
    P1->>P1: 生成 k1, 计算 R1=k1·G
    P2->>P2: 生成 k2, 计算 R2=k2·G
    P1->>P2: 发送 R1
    P2->>P1: 发送 R2

    Note over P1,P2: 计算群体 R
    P1->>P1: R = k1·R2 = k1·k2·G
    P2->>P2: R = k2·R1 = k1·k2·G

    Note over P1,P2: 同态加密协作签名
    P2->>P2: 用Paillier公钥加密部分计算
    P2->>P1: 发送加密结果
    P1->>P1: 利用同态性质完成签名计算
    P1->>P1: 得到最终签名 (r, s)

验签 ​

签名结果与 EOA 完全一致，因此验签无差别。

注意：MPC 签名中临时密钥 使用不确定性随机算法（而非 RFC6979），导致相同数据每次签名结果不同。这对某些 L2（如 dYdX）会有影响。

3.5 备份与恢复 ​

云恢复 ​

当用户设备的 share2 丢失，使用 share1 + share3 恢复：

通过拉格朗日插值计算缺失的 share2：

三个点的横坐标是 MPC 协议预定义的常量。

逃逸 ​

使用拉格朗日插值恢复完整私钥 ：

四、安全架构 ​

4.1 三层安全保障 ​

graph TB
    A[安全架构] --> B[鉴权层]
    A --> C[传输层]
    A --> D[计算层]

    B --> B1[用户中心 Token 鉴权]
    C --> C1[RSA 公钥加密 AES Key]
    C --> C2[AES 对称加密通信]
    D --> D1[AWS Nitro Enclaves TEE]
    D --> D2[AWS KMS 密钥管理]

4.2 Share1 鉴权 ​

所有与服务端的交互均携带鉴权 token，每次请求先过用户中心。

4.3 传输安全 ​

1. 端内存有 RSA 公钥，服务端存有对应 RSA 私钥
2. 端内生成随机 AES key，用 RSA 公钥加密后发送给服务端
3. 服务端解密后暂存 AES key
4. 后续通信均用此 AES key 对称加密

先非对称、再对称——兼顾安全性和性能。

4.4 计算安全：TEE ​

使用 AWS Nitro Enclaves 可信执行环境：

关键：share1 的加密和解密全程在 TEE 内完成，外部无法访问。

五、总结与展望 ​

技术总结 ​

当前问题 ​

• 用户量较少，接入新链开发成本高
• 部分用户质疑中心化服务安全性
• Web3 用户已接受助记词/私钥概念，MPC 对他们是"伪需求"
• 交互触发验证，影响体验

未来方向 ​

MPC 技术积累可复用于新场景，如（底层 MPC + 上层 AA 方案，用户无感创建钱包）。