从资金安全到合规监管：稳定币系统的 MPC 门限签名钱包架构选型与安全边界实战

作者：kent 日期：2026 年 8 月
分类：密码学工程 / 区块链架构 / 密钥管理

0. 写在前面的话

在规划一套全新的稳定币发行与金库管理系统时，我们面临着资金安全（防单点故障与内鬼）与合规风控（黑名单实时拦截、大额多重审批）的双重约束。在对智能合约多签与 MPC 门限签名进行深度对比后，我们决定将 MPC 门限签名（Threshold Signature Scheme, TSS） 作为高频运营金库与基础设施的底层密钥管理方案。

关于 GG18、CGGMP24、DKLS23、诚实多数与不诚实多数等密码学原理，本文不再逐一展开，而是重点聚焦稳定币系统在架构选型、拓扑设计、安全陷阱以及链上治理中的实际落地思考与权衡。

1. 为什么选择 MPC？（与智能合约多签的博弈与混合架构）

在确定技术路线时，团队内部曾对“智能合约多签（如 Gnosis Safe）”与“MPC 门限签名”的适用边界展开过深入讨论。

绝对地宣称“MPC 优于合约多签”在工程上是不客观的。两者在体系结构上各有优劣：

1.1 EIP-712 与 EVM 兼容性真相

很多文章宣称“Safe 无法签 EIP-712”，这是不准确的。Safe 官方原生支持 EIP-712、ERC-1271 以及链下收集 Owner 签名。 真正的工程痛点在于调用方的兼容性：

• 智能合约账户（CA）没有原生私钥，必须依赖外部协议与交易所主动适配 ERC-1271。而部分既有协议、无托管合约及机构接口仍仅支持 EOA 原生签名。
• MPC 在链下生成原生的 $(r, s)$ 签名，应用层在链下完成 Low-S 规范化（$s \le q/2$）。需要注意的是：如果将高 $s$ 转换为 $q-s$，必须同步翻转 recovery ID / yParity ($v’ = v \oplus 1$)，并在广播前于本地执行 ecrecover 恢复公钥核对签名地址，防止 $s$ 和 $v$ 独立拼装导致恢复出错误地址。

1.2 架构选择：MPC + 链上 Safe 的混合治理体系

基于上述对比，稳定币系统最佳的落地架构不是“用 MPC 完全取代合约多签”，而是分层混合架构：

• 高频运营划转 & 跨链原生兼容 $\rightarrow$ 使用 MPC 门限签名。
• 低频高风险治理（Mint/Burn 角色控制、合约升级、紧急 Pause） $\rightarrow$ 使用 Gnosis Safe 链上多签 + Timelock（时间锁）。

2. 稳定币系统的节点拓扑与策略控制面设计

在稳定币的资金划转中，常见的 2-of-3 拓扑需要特别注意密码学门限与业务审批门限的解耦。

2.1 明确三大门限与控制面安全边界

在标准的 2-of-3 EOA 门限中，任意两个节点组合（A+B、A+C、B+C）在密码学上均可合法签名。纯密码学门限无法强制“合规节点 B 必须参与”，因为 A 和 C 理论上可以在密码学上绕过 B。

因此，我们必须明确划分：

1. 密码学签名门限：底层 $2$-of-$3$ 计算逻辑。
2. 合规策略控制面（Policy Engine）：独立于密码学计算层之外。节点 B 嵌入合规规则引擎，日常运营流程固定要求业务节点 A 与合规节点 B 协同。若合规检查失败，节点 B 直接拒签（在 AML 风险响应中采用 Fail-closed 阻断策略）。
3. 灾备破玻璃（Break-glass）流程：节点 C 作为冷灾备节点，决不能在自动化流程中随意联机。一旦启用 A+C 组合，必须触发链上/链下 Timelock、多重人工独立审批与全路径审计。

关键安全边界：对普通 2-of-3 EOA 门限签名而言，Timelock、人工审批和策略引擎属于控制面约束，不能阻止已经控制 A+C 私钥分片的攻击者离线签名。如果业务要求合规节点 B 在密码学上绝对不可绕过，需要采用更强的结构（如 $3$-of-$3$、分层授权或链上多签治理控制），而不能仅依赖流程制度。

               +-----------------------------------+
               |     节点 A：业务/出纳节点 (Operations)   |
               |  - 自动化交易触发                |
               |  - 独立解析 Payload 并自行计算 Hash |
               |  - 持有私钥分片 x1                    |
               +-----------------+-----------------+
                                 |
                                 | (日常固定 A+B 签名)
                                 v
+--------------------------------+--------------------------------+
|     节点 B：合规/风控节点 (Compliance & Risk Engine)              |
|  - 实时 KYC/AML 黑名单拦截 (Fail-closed)                         |
|  - 大额触发人工二重审批 / 规则引擎                                |
|  - 独立解析 Payload 并自行计算 Hash                             |
|  - 持有私钥分片 x2                                              |
+--------------------------------+--------------------------------+
                                 |
                                 | (仅在 A 或 B 故障时触发破玻璃流程)
                                 v
               +-----------------+-------------------+
               |  节点 C：灾备/冷保管节点 (Cold Recovery)    |
               |  - 独立审批 + Timelock + 审计留痕            |
               |  - 持有私钥分片 x3 (HSM/TEE 保护)           |
               +-------------------------------------+

2.2 交易 Payload 解构与防盲签机制

签名节点在参与 MPC 计算前，绝对禁止直接接收外部传入的 Raw Hash 进行盲签（因为 Hash 本身不可反向解析）。 节点 A 与节点 B 必须独立解析原始交易 Payload，自行计算待签 Hash，并强制校验与绑定 Chain ID、Nonce、Target Contract、Function Selector、Amount 以及 EIP-712 Domain，校验无误后方可参与计算。

3. 密码学协议与开源库选型（辨析理论与落地方案）

3.1 协议派系与敌手模型

在协议选型中，我们重点评估了 CGGMP24、DKLS23 与 KU23。对于稳定币金库场景，必须坚守“不诚实多数（Dishonest Majority）”安全模型（如 CGGMP24 或 DKLS23），确保即使个别节点作弊，也不会泄露诚实节点的秘密分片。

3.2 严谨界定 2-of-3 门限失陷与 Key Refresh 的作用

关于密钥刷新（Key Refresh / Resharing），必须纠正一个常见的误区：

• Key Refresh 的真实作用：防范渐进式/移动攻击（Mobile Adversary）。如果攻击者在 Epoch 1 仅窃取了分片 $x_1$，在攻击者尚未能攻破第 2 个节点前，诚实节点触发 Key Refresh 生成新分片 $(x_1’, x_2’, x_3’)$，使得旧分片 $x_1$ 彻底失效。
• 门限失陷后的应急处置：在 $2$-of-$3$ 系统中，如果攻击者在同一时期获取了 A 和 B 两个有效分片，说明签名门限已经失陷。攻击者已经拥有合法签名或确定主私钥的能力。此时保持原公钥不变的 Key Refresh 绝对无法撤销攻击者的控制权！
• 紧急响应 SOP：一旦发生门限失陷（2 个分片泄露），唯一有效的处置是：立即触发链上紧急暂停（Pause）或多签限制 $\rightarrow$ 将资产与合约管理员角色紧急迁移至全新的公钥（新钱包） $\rightarrow$ 废除旧公钥，而不是尝试同公钥刷新。

3.3 开源实现初筛与协议能力对比

在进行开源库选型时，必须将“论文协议的能力”与“具体开源库的实现状态”严格剥离。

开源实现初筛与对比分析：

架构师选型要求：不能简单认为“引入库就自动获得了 CGGMP24 论文的所有功能”。若选择 LFDT，必须明确当前实现不支持同公钥 Refresh 的局限，一旦发生单分片泄露疑云应直接迁移新公钥；若生产环境必须原生支持同公钥 Refresh，应评估 Taurus CMP（补充审计）或 Silence Labs DKLS23 等完备实现。

3.4 预签名材料的分布式锁与防重用

对于支持预签名（Presign）的协议（CGGMP24 / DKLS23）：

• 秘密 nonce $k$ 碎片绝对禁止复用（一旦复用，主私钥数秒内可被推导破解）。
• 工程上必须加严苛的分布式事务锁。一旦签名会话发生网络超时或断连，该份预签名必须直接作废销毁，决不允许回收重试。

3.5 侧信道防护与物理隔离边界

针对非常数时间大整数运算的时序泄露风险：

• 节点 A、B、C 绝不能部署在同一个云厂商的同一 VPC 内，实现物理与控制面隔离，降低共同基础设施失陷风险；
• 在敏感计算节点外层包裹 SGX / AWS Nitro Enclaves（TEE 可信执行环境） 或硬件安全模块（HSM），降低宿主机运维人员与恶意软件获取分片的风险；
• 清晰防线边界：跨云与 TEE 无法阻止拥有合法权限的参与方主动共谋，且 TEE 自身也有侧信道与远程证明链风险。时序攻击应作为系统接受的残余风险加以记录。

4. 最终架构蓝图与选型对照 CheckList

综合安全、性能、合规与落地难度，我们敲定了稳定币系统 MPC 钱包的技术蓝图：

               [ 链上治理层: Gnosis Safe 多签 + Timelock ]
               (负责: Mint/Burn 角色、合约升级、紧急 Pause)
                                  |
                                  v
               [ 业务划转层: 稳定币 Mint/Burn/Treasury 引擎 ]
                                  |
               v (发送原始交易 Payload，拒绝盲签 Raw Hash)
  +-------------------------------+-------------------+
  |          内部安全 API 网关 / 规则引擎总线           |
  +-------------------------------+-------------------+
                                  |
                +-----------------+-----------------+
                |                                   |
                v                                   v
  +---------------------------+       +---------------------------+
  |        MPC 节点 A         |       |        MPC 节点 B         |
  | (业务出纳 / 跨云部署)      |       |  (合规风控 / Fail-closed) |
  | - Rust/Go (CGGMP24/CMP)   |       |  - 链下实时 AML           |
  | - 部署于 TEE (Nitro/SGX)  |       |  - 交易 Payload 独立解析  |
  +---------------------------+       +---------------------------+
                |                                   |
                +-----------------+-----------------+
                                  | (日常 2-of-3 预签名 / 在线交互)
                                  v
   [ 链下 Low-S 规范化与 yParity 翻转拼装 (r, s, v) + 本地 ecrecover 核对 ]
                                  |
                                  v
             [ 广播至 Ethereum / Arbitrum / Base 节点 ]

架构选型对照 CheckList：

1. 架构模式：采用 MPC（高频划转） + Safe/Timelock（链上治理） 混合架构。
2. 协议与安全模型：坚守支持 CGGMP24 / DKLS23 的 2-of-3 不诚实多数模型。
3. 实现与 CVE 审查：严格区分论文能力与具体开源库实现；若使用 LFDT 需使用 cggmp24 >= 0.7.0-alpha.2 或更新的已修复版本，若需同公钥 Refresh 需评估 Taurus CMP 或 Silence Labs DKLS23 等完备实现。
4. 控制面与防盲签：节点独立解析交易 Payload 并自行计算 Hash（校验 ChainID/Nonce/Amount/EIP-712 Domain）；合规节点 B 嵌入 Fail-closed 阻断逻辑；明确控制面逻辑防绕过边界。
5. 预签名熔断：实现预签名分布式锁与状态熔断机制，“单次使用、异常即销毁”。
6. 侧信道与物理隔离：节点跨云部署并包裹 TEE (SGX/Nitro Enclaves)，降低共同基础设施失陷与宿主机侧信道风险。
7. 应急 SOP：建立单分片泄露的 Key Refresh 轮换机制；建立门限失陷（2 分片泄露）时的链上暂停 + 紧急资产与角色迁移至全新公钥的 Break-glass 流程。

5. 结语

在区块链安全领域，没有绝对的“银弹”。

MPC 门限签名技术将传统集中式的私钥风险分散到了网络拓扑与密码学协议中，为稳定币等金融级应用提供了高频划转与合规风控的新解法。但它绝非取代一切链上治理的替代品。

我们必须保持理性：区分密码学门限与业务控制面，区分论文证明与开源库现状。将 MPC 的高效与链上 Safe 的透明治理有机结合，才是金融级 Web3 基础设施落地的真正路径。

6. 参考资料

1. Safe EIP-712 and ERC-1271 Signature Support
2. LFDT Lockness cggmp21 Repository
3. GitHub Security Advisory: CVE-2025-66017（GHSA-8frv-q972-9rq5）
4. Taurus multi-party-sig Repository
5. Silence Laboratories dkls23 Repository & Audit Info
6. CGGMP21 Paper: UC Non-Interactive, Proactive, Threshold ECDSA
7. DKLS23 Paper: Threshold ECDSA in Three Rounds
8. NIST Multi-Party Threshold Cryptography Project