---
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-tw/crypto/mpc-wallet/)
- [多簽錢包](/zh-tw/crypto/multisig-wallet/)
- [私鑰管理](/zh-tw/crypto/private-key-management/)
- [BLS 簽章](/zh-tw/crypto/bls-signature/)
- [Nonce](/zh-tw/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-tw/crypto/threshold-signature/index.mdx