FROST 全称为 Flexible Round-Optimized Schnorr Threshold。这是一种门限签名协议：足够多的参与者使用共同公钥签名，而不必在签名过程中把完整私钥重建到同一处。
在 2-of-3 方案中，两份可用且获授权的份额就足够，一份则无法生成签名。攻击者取得两份也能达到门限。长期密钥份额并不是某条消息的部分签名；签名仍须经过共同协议并使用新鲜的一次性数值。 [RFC 9591 — FROST]
可信分发者可以创建秘密并分配份额，因此知道完整密钥，必须安全处理它。DKG 支持不依赖这一单独分发者的共同生成，但需要自身的通信和验证。RFC 9591 主要规定签名；其中的分发者附录，并不代表每个部署都会自动使用 DKG。 [RFC 9591 — FROST] [ZF FROST Book — key generation and recovery]
第一轮，参与者生成两个秘密 nonce，并分享它们的公开承诺。第二轮，参与者核验消息、参与者列表及自己的承诺，再计算签名份额。协调者把份额聚合。绑定因子将 nonce 与特定消息及承诺集合关联；这里的两轮不包含之前的密钥生成。 [RFC 9591 — FROST] [ZF frost-secp256k1-tr — Taproot implementation]
重复使用 nonce 可能泄露秘密密钥材料。使用后必须安全停用秘密 nonce，即使该次尝试中止也一样；恢复旧备份不能使它们重新可用。随机性、并发会话和持久化消耗记录都是安全的一部分，而不仅仅是加速优化。 [RFC 9591 — FROST]
协调者收集承诺与签名份额；没有足够密钥份额，就无权独自签名。但它可以扣留消息或导致中止。检查错误份额可能识别其来源，却不能保证会话完成。经过身份认证的传输和足够多可用参与者仍不可少。 [RFC 9591 — FROST]
用于 Bitcoin 时，结果必须符合 BIP 340 的准确编码、哈希及规则，以及必要的 Taproot 密钥调整。仅在通用 FROST 套件中选用 secp256k1 并不够。ZF 为 Taproot 单独提供 frost-secp256k1-tr；应核验具体套件及其测试。链上的单个签名本身不会暴露内部门限。 [ZF frost-secp256k1-tr — Taproot implementation] [BIP 340 — Schnorr Signatures for secp256k1]
份额需要正确的标识符、群组公开资料和兼容软件。借助其他人恢复丢失份额，或刷新份额，都是部署必须实际支持的额外协议。复制同一份额不会增加独立参与者。备份方案既须保留门限要求，也须阻止已消耗 nonce 再次出现。 [ZF FROST Book — key generation and recovery] [ZF frost-secp256k1-tr — Taproot implementation]
每名签名者都应核验收款方、金额、手续费及批准规则，而不是盲目签署协调者给出的哈希。FROST 解决共同签名，不保证业务意图正确。使用前应确认实现版本、恢复流程及故障行为；一份信息性 RFC 并不是对整个钱包的认证。 [RFC 9591 — FROST]
要获得更完整的理解，请将本词条与以下词条结合阅读： Schnorr签名, MuSig2, Multisig, Taproot, Shamir Secret Sharing.