跳转到内容

门限签名

来自BitcoinWiki

门限签名允许达到规定数量的参与者利用同一签名密钥的份额,协作生成数字签名。在加密货币托管中,这种方式可以将签名权限分散到不同系统或组织。门限方案取决于具体的密码学协议和密钥管理设计;MPC wallet这一名称并不说明这些细节。[1]

门限与多重签名

在门限方案中,只要参与者的子集达到要求,就能签名。FROST 是两轮式 Schnorr 门限签名协议,其安全假设涉及密钥份额的生成方式和遭到攻破的参与者数量。RFC 9591是 Crypto Forum Research Group 的信息类出版物,并非 Internet Standards Track 规范。[1]

多方参与签名并不总是等同于门限签名。MuSig2由 BIP 327规定,将参与者的公钥聚合并生成兼容 BIP 340的 Schnorr 签名,但要求所有参与密钥聚合的签名者共同签名。这是 n-of-n 多重签名方案,而非 t-of-n 门限方案。[2]

安全假设与运行条件

分散密钥份额会改变信任模型,但并不免除对安全系统的需求。FROST 假设密钥份额得到安全生成和分发,并对攻击者能够攻破的参与者数量设有限制。其安全注意事项涉及 nonce 重用、侧信道和协议故障。签名可用性与防伪造能力是不同的属性。[1]

托管服务

截至2026年十月核查的 Google Cloud Multi-party Compute 文档描述了一种将门限签名与组织控制相结合的托管平台。文档将该服务标为 Preview,并介绍了 v1beta API。文档列出面向 Bitcoin 和 EVM 兼容应用的 secp256k1曲线 ECDSA;这不应被理解为支持所有区块链签名格式。[3]

密码学授权也不同于自动化交易策略检查。Google 的策略文档指出,足够数量的签名者可以授权一笔被自动化策略拒绝的交易。因此,必须结合该服务的签名者和治理模型来理解策略判定结果。[4]

参考资料

  1. ↑ 1.0 1.1 1.2 RFC 9591: The Flexible Round-Optimized Schnorr Threshold (FROST) Protocol, June 2024, introduction and security considerations.
  2. ↑ BIP 327: MuSig2 for BIP340-compatible Multi-Signatures, motivation and general signing flow, checked 29 October 2026.
  3. ↑ Google Cloud: Multi-party Compute overview, checked 29 October 2026.
  4. ↑ Google Cloud: Transaction policy evaluation, checked 29 October 2026.