FROST

假设一个协会由安娜、扬和伊娃管理积蓄。他们选择 2 人参与、共 3 人的规则：安娜与扬、安娜与伊娃，或扬与伊娃都可以批准付款。每人持有不同的秘密份额，即通过密码学构造的共同密钥材料的一部分。一份不够，但它们也不是同一个密码的三份副本。如果伊娃暂时无法参与，另外两人仍可协作。同一道门限也适用于攻击者：拿到足够多的份额，就同样能够签名。因此，分散保管只有在攻破一台设备或一个账户不会同时打开其余所有入口时，才有实际意义。 [1] [2]

安娜不应只因应用提示“等待签名”就确认操作。她需要知道收款人、金额、手续费，以及找零是否回到协会。每位签名者都需要可信的方式核对真实交易。Hash 是数据的简短密码学指纹，本身并不能向人解释数据的含义。FROST 让大家针对同一条消息协作，却不能判断发票是否真实，也无法判断某个人是否理解自己批准的具体内容。即使签名完成，也不代表付款已经在区块中得到确认。区块是写入 Bitcoin 网络共同历史的一组交易。RFC 9591 是信息性协议规范，并非对整个应用安全性的认证。 [1] [2]

Taproot 是 Bitcoin 的一项升级，允许通过相应密钥的签名，或通过满足预先设定的条件来花费资金。通过 Taproot 的密钥路径花费时，正确构造的门限签名可以看起来像普通的单密钥签名。观察者不能仅凭签名看出内部有多少份额或门限是多少。这有利于隐私和签名数据大小，但不意味着整笔交易或参与者之间的通信都是匿名的。Bitcoin 要求严格遵守 BIP 340；secp256k1 曲线提供了 Bitcoin 密钥计算的数学基础，但仅在这条曲线上使用通用 FROST 还不够。因此，Zcash Foundation (ZF) 单独提供面向 Taproot 的 frost-secp256k1-tr。还必须正确处理 Taproot 使用的密钥调整。同一种曲线名称并不能证明兼容，存在某个程序库也不代表所有钱包都支持。 [3] [4]

协会在签署任何内容之前，必须安全地产生份额。可信分发方可以先生成完整密钥，再将其拆分。但这里有一个敏感环节：分发方知道完整密钥，如果保留副本，就可能绕过原本设定的共同批准。另一种方式是 DKG，即分布式密钥生成，完整秘密密钥不必出现在任何一个参与者手中。这需要经过身份验证、受到保护的通信，以及正确执行协议。简单地用电子邮件发送几个文件并不够。RFC 9591 主要规定签名过程，不保证每个产品都实现 DKG。长期密钥份额也不同于针对某次具体付款产生的签名份额。 [1] [2]

签名本身分两轮进行，不包括之前的密钥生成。首先，每位入选参与者生成两个秘密的一次性值 nonce，并发送它们的公开承诺值；这些值以密码学方式将参与者与对应的 nonce 绑定。接着，他们收到共同消息和承诺列表，核对输入资料，再计算自己的签名份额。协调者负责合并。绑定因子使计算与具体消息、群组公钥及承诺值关联。采用 2 人参与、共 3 人的规则时，可以只选两人开始一次会话。但如果本次选中了三人，就必须全部提交贡献；不能简单地跳过中途不再回应的人。 [1] [3]

这里的 nonce 是只供一次签名尝试使用的秘密值，不是可以反复使用的密码。重复使用可能暴露秘密密钥材料。如果扬的电脑在发送签名份额后崩溃，恢复旧状态时不能把已经用过的 nonce 重新标为可用。付款没有完成，也不构成复用理由。安全实现需要可靠的随机性、相互隔离的并发尝试，以及对已消耗值的可靠停用。这也是不应自行拼凑零散脚本来实现 FROST 的原因。数学正确并不能弥补秘密数据管理的错误。 [1]

协调者负责组织消息，但仅凭这一角色无法代替协会签名；它需要选定份额持有者的贡献。不过，它可以扣留消息或中断会话，参与者提交无效结果也可能导致失败。检查可以发现无效的签名份额，但要把错误归到具体的人，必须可靠地确认消息来源。发现问题并不保证过程能够完成。重新尝试需要一组可用且获授权的参与者，以及新的 nonce。因此，协会还需要应对故障和分歧的方案，而不只是欢迎页面上的一个门限数字。 [1] [2]

如果伊娃丢失设备，“FROST”这个标签不会自动恢复资金。备份必须保留她的份额、标识符、必要的群组信息，以及将这些内容载入兼容软件的方法。它不一定就是普通的 Seed Phrase，也就是用单词表示的钱包备份。在其他人的帮助下恢复份额，以及更新份额，都是具体系统需要额外支持的流程。复制伊娃的份额仍然只是同一份额，不会增加一个独立的表决者。在保留同一群组密钥的情况下更新份额，也不能让此前被盗且数量足够的旧份额失效。因此，在投入真实积蓄前，试验应包括恢复、故障处理和准确的软件版本，而不只是完成一次签名。 [2] [3]