摘要

  • RFC 9591 规定两轮 FROST：达到门限的参与者各自产生份额，协调者将其聚合为只含 R 与 z 的 Schnorr 签名，并用同一个群组公钥验证。
  • 最终签名没有携带参与者名单、个人份额、协调者选择或业务审批。归因要靠认证通道、两轮转录、成员版本和本地政策决定共同完成。

验证式只回答了一个问题

设想一个五人控制组采用三人门限。最后的签名通过了验证，说明消息、签名和群组公钥满足 Schnorr 关系。它没有说明本轮是第一、第三、第五名成员，还是另一组合法的三人；更没有说明这三人是在批准付款、发布软件，还是被要求对一个看不懂的摘要提供计算。

FROST 的价值就在这里：外部系统不必理解多方过程，也能像验证单一签名者那样验证结果。RFC 9591 的若干密码套件可产生兼容 Ed25519 或 Ed448 的签名。分散持有的秘密，对外仍表现为一个紧凑、熟悉的签名对象。

这种兼容性同时制造了一条证据边界。群组公钥下的有效签名是强密码事实；“这些具名负责人批准了该行为”是身份、权限和业务事实。前者不会自动包含后者。

本轮参与者由协议外部决定

FROST 预先存在一个最大成员集合、最低门限、不同的非零标识符、秘密份额和对应的公开验证份额。在有协调者的模式中，协调者决定本轮参加者，转发两轮输入，聚合份额并发布签名。RFC 明确写明：协调者和签名者集合由协议外部选择。

系统也可以不设单一协调者，让所有成员互相广播承诺和份额。这样消除了一个固定角色，却没有消除选择权：应用仍要确定谁是合格成员、门限是多少、这次请求什么消息、什么条件允许结果离开系统。

数学标识符不是员工身份，也不是董事职权或授权委托书。人员离职、角色调整、代理期限到期时，标识符本身不会变化。可审计系统必须把份额标识符绑定到经过认证的主体、成员册版本、生效时段、公开份额和撤销记录。

第一轮产生只能使用一次的状态

每个入选参与者先生成两枚秘密 nonce，再公开相应承诺。第二轮中，协调者发送待签消息和完整、有序的承诺列表。群组公钥、消息、整份列表和个人标识符共同产生绑定因子，参与者再用秘密份额与一次性 nonce 计算自己的签名份额。

这里的“一次性”不是建议。RFC 要求 nonce 不得用于第二次 sign，并在签名完成后删除。重复使用可能让其他参与者恢复完整秘密份额。灾备系统如果回滚到旧 nonce 池，可能恢复了可用性，却破坏了密钥安全。

参与者集合连续性也不是附带信息。RFC 9591 提到一种能把标量乘法从线性降为常数的优化，但不推荐使用，因为它失去“第一轮开始者与第二轮产出者为同一集合”的保证。性能提升改变了审计能够主张的内容，因此不能只作为基准测试决策。

聚合完成时，名单已经不在输出里

协调者把份额相加，得到 (R, z)。规范的最终编码没有门限值、参与者标识、个人承诺、份额或本地审批结果。若组织没有在发布前保存会话转录，之后不能从签名字节重新恢复这些事实。

聚合之前，协调者可以根据个人公开份额、个人承诺、完整列表、消息与群组公钥逐份验证。聚合失败时，这一检查可以定位提交了错误份额的参与者。不过定位还依赖认证通道；否则系统只知道某个标识符的数学关系错误，不知道网络消息究竟来自谁。

拒绝参与又是另一种事实。FROST 不会替应用识别沉默成员。应用可以记录请求已送达、截止时间已过、没有有效回复，却不能据此直接断言恶意、失职或被攻陷。对异常成员采取何种措施也明确不在 RFC 范围内。

正确份额不等于业务同意

RFC 建议应用验证输入，避免成员沦为任意消息的签名预言机。数字货币场景可能要求检查交易格式与相关方意图；门限 TLS 签名者可能要求看到原始握手消息，而不是盲信别人送来的 transcript hash。

这说明验证必须分层。解析成功不等于内容获准；内容获准不等于审批者仍有角色；个人份额正确不等于下游执行的对象与他看到的对象相同。若界面展示、规范化消息、被签字节和最终动作之间没有指纹关联，签名验证无法弥补语义断裂。

完整收据至少要连接：成员资格与门限、本轮选择、认证身份、第一轮承诺、准确消息、本地政策结论、第二轮份额、聚合验证、结果发布和下游动作。任何一环都不能借用相邻一环的权威。

可识别中止不是健壮性承诺

错误份额可以触发可识别中止，但一个成员发送畸形数据或干脆不参加，仍可阻止本轮产生有效签名。RFC 9591 明确说 FROST 不提供健壮性；ROAST 是另一个用于增强异步健壮性的封装协议。二者不能在宣传材料中合并成一个保证。

FROST 也不是后量子方案。它依赖离散对数困难性。RFC 9591 是 IRTF Informational 文件，代表 CFRG 共识，不是 IETF 标准或部署命令。测试向量通过、库声称支持和生产控制完成是三种不同记录。

按照卢恒的运行代码优先原则，真实结论来自实际执行的检查：具体实现和套件、异常输入拒绝、nonce 防回滚、成员变更、认证通道、完整会话与下游动作。按照现实层与符号层的区分，“签名有效”是可执行密码事实；“委员会授权”则需要独立的委托和责任链。

来源