---
title: "门限签名"
description: "门限签名让达到法定数量的参与者在私钥材料保持分散的情况下生成一个普通可验证签名。了解 M-of-N、DKG、签名、恢复与操作风险。"
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 门限签名

> 仅供教育参考，不构成投资或安全建议。只有协议、实现、参与者和恢复流程都得到独立保护时，门限设计才能降低特定的密钥风险。

<a id="answer"></a>

## 直接答案

门限签名方案允许 N 个参与者中至少 M 个协作，以一个公钥生成签名。少于 M 份有效份额既不应生成签名，也不应泄露签名密钥。在设计正确的协议中，日常签名不需要重构完整私钥。

验证者通常使用该签名类型的普通验证算法。它看到的可能是一个 ECDSA、EdDSA 或 Schnorr 签名，而不是链上签名者名单。这种互操作性很有用，但也意味着链上未必能看出门限、参与者或其控制是否真正独立。

门限签名是安全多方计算（MPC）的一种应用，两者并非同义词。MPC 钱包可以使用门限签名协议，而 MPC 也包含许多与签名无关的计算。同样，如果使用前必须重构秘密，把种子备份拆分开也不属于门限签名。

安全结论带有前提。它取决于具体协议、攻击者模型、经认证的通信、随机数、份额存储、参与者独立性、软件供应链、策略引擎和恢复设计。只有“M-of-N”不足以构成安全评估。

<a id="mechanism"></a>

## 运作机制

1. **选择方案与威胁模型。** 明确签名算法、M-of-N 门限、参与者身份、失陷假设、网络模型和所需安全性质。能抵御静态失陷的协议，未必能抵御随时间先后攻破不同参与者的攻击者。
2. **创建分布式密钥材料。** 可信经销方可以拆分秘密；也可以通过分布式密钥生成（DKG），由各方在不组合私钥的情况下共同建立份额和公钥。DKG 消除了经销方，却增加了交互轮次、证明、投诉处理和失败情形。
3. **授权一条确切消息。** 参与者必须分别把请求绑定到链、账户、金额、目的地址、费用、nonce 和策略上下文。密码学法定人数不能替代交易审查。
4. **运行签名协议。** 选定的法定参与者交换承诺、证明和签名份额。协议规定的 nonce 材料必须唯一且受保护；复用或偏差可能泄露密钥材料。有些方案需要预处理，而 FROST 规定的是两轮 Schnorr 门限协议。
5. **验证并维护。** 广播前，用群组公钥检查合成结果。随后应按需保留记录、监测故障、依照明确仪式刷新份额或轮换密钥，并测试恢复流程不会暗中降低门限。

| 设计 | 验证者看到什么 | 门限在哪里执行 | 主要审查边界 |
| --- | --- | --- | --- |
| 门限签名 | 一个签名和一个公钥 | 链下密码学协议 | 协议、客户端、份额、协调器、策略与恢复 |
| 链上多签 | 多次批准或合约状态 | 区块链或智能合约 | 合约、签名者集合、门限、模块与升级权力 |
| 拆分备份 | 重构后的普通密钥 | 恢复流程 | 份额保管、重构环境与恢复后处理 |

不同签名家族和安全模型使用不同的门限协议。线性结构让 Schnorr 类构造相对直接，但具体协议仍然关键。ECDSA 签名不具备相同的线性，因此门限 ECDSA 需要额外的多方技术。签名聚合、多签和门限签名的输出可能表面相似，其参与和安全主张却不同。

<a id="example"></a>

## 示例

设想一个 2-of-3 托管设计，份额分别由交易团队、独立风险团队和恢复服务商持有。普通提款由交易与风险团队处理。一个份额不可用时，其余任一获授权组合仍可保持可用性。

数字本身不能证明独立性。如果前 2 个份额运行在同一云账户、接受同一个身份令牌，或依赖一个已被攻破的服务作出策略决定，一次事件就可能控制法定人数。应根据威胁模型分离设备、管理员、凭证、网络、地域、供应商和批准证据。

部署前至少测试以下路径：

- 每个获授权的 2 方组合都能为预期消息签名；
- 1 方不能签名、重构密钥或替换参与者；
- 重复、乱序、中止和延迟的会话不会复用 nonce 材料；
- 被攻破的协调器不能修改消息或隐瞒参与者故障；
- 备份恢复、份额刷新、参与者替换和完整密钥轮换都保持文档规定的授权策略。

记录每次仪式生成的公钥和软件版本。恢复后的份额即使在密码学上可用，如果绕过当前批准策略，也不算成功恢复。

<a id="risks"></a>

## 风险

- **相关性失陷：** 名义上分离的份额依赖同一管理员、云、依赖项、签名镜像或策略服务。
- **恶意或失陷的法定人数：** 一旦 M 个获授权参与者批准恶意消息，结果仍是有效签名。
- **Nonce 与随机数故障：** 复用、偏差、泄露、回滚或不安全的预处理可能暴露份额或实际私钥。
- **协议与实现不匹配：** 针对某一协议、群组、失陷模型或会话假设的证明，不会自动覆盖另一实现。
- **协调器与网络滥用：** 协调器即使不能单独签名，也可能审查、提供矛盾信息、收集元数据、重放会话或选择性中止。
- **可用性故障：** 在线、兼容且通过策略批准的参与者少于 M 时无法签名；低于盗窃门限也可能造成拒绝服务。
- **不安全的刷新或恢复：** 陈旧备份、参与者替换或紧急重构可能降低门限、复活已撤销份额或暴露完整密钥。
- **不可见的治理：** 链上可能只显示一个普通签名，但密钥轮换、允许名单、软件更新或恢复管理员仍是强大的控制点。
- **错误等同：** BLS 聚合、N-of-N 多签、拆分种子和 M-of-N 门限签名不能仅因都组合了多方贡献就视为可互换。

<a id="misconceptions"></a>

## 常见误区

- **“私钥从未存在。”** 日常操作中可能从不组合私钥，但设置、导入、备份、迁移或紧急恢复可能改变这一结论。应询问每个生命周期阶段发生过什么。
- **“2-of-3 消除了所有单点故障。”** 它只消除由真正独立份额和服务代表的故障；共用基础设施或策略可以重新引入单点。
- **“链上一个签名证明只有一个人批准。”** 输出通常不会披露参与方数量，也不会说明哪项链下策略授权了他们。
- **“门限签名能阻止恶意交易。”** 它执行的是密码学法定人数，不是正确判断。合谋或受骗的法定人数仍可授权盗窃。
- **“任何 MPC 或门限库都适用于任何链。”** 签名格式、曲线、哈希规则、密钥派生、交易编码、协议假设和验证器支持都必须匹配。

<a id="related"></a>

## 相关主题

- [MPC 钱包](/zh-cn/crypto/mpc-wallet/)
- [多签钱包](/zh-cn/crypto/multisig-wallet/)
- [私钥管理](/zh-cn/crypto/private-key-management/)
- [BLS 签名](/zh-cn/crypto/bls-signature/)
- [Nonce](/zh-cn/crypto/nonce-crypto/)

<a id="sources"></a>

## 来源

- [NIST First Call for Multi-Party Threshold Schemes](https://csrc.nist.gov/pubs/ir/8214/c/final) - NIST（查阅日期：2026-08-21）
- [Threshold Schemes for Cryptographic Primitives](https://doi.org/10.6028/NIST.IR.8214) - NIST（查阅日期：2026-08-21）
- [RFC 9591: The FROST Protocol](https://www.rfc-editor.org/rfc/rfc9591.html) - IETF（查阅日期：2026-08-21）
- [Digital Signature Standard (DSS)](https://doi.org/10.6028/NIST.FIPS.186-5) - NIST（查阅日期：2026-08-21）
- [Fast Multiparty Threshold ECDSA with Fast Trustless Setup](https://doi.org/10.1145/3243734.3243859) - ACM（查阅日期：2026-08-21）

Source: https://wiki.fcontext.com/zh-cn/crypto/threshold-signature/index.mdx