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]
第1ラウンドで参加者は二つの秘密 nonce を生成し、その公開コミットメントを共有します。第2ラウンドではメッセージ、参加者一覧、自分のコミットメントを確認して署名シェアを計算します。調整役がシェアを集約します。結合係数は 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 signature, MuSig2, Multisig, Taproot, Shamir Secret Sharing.