FROST は、しきい値型の Schnorr 署名、つまり複数の人が共同で電子署名を作るためのプロトコルです。しきい値とは、共通の秘密鍵の異なるシェアを持つ人のうち、少なくとも決められた人数が協力しなければ署名できないという条件です。秘密鍵は署名を作るために必要な数値で、ここでは署名の際、完全な鍵の代わりに各人のシェアを使います。結果は一つのグループ公開鍵で検証できます。公開鍵は共有してもよく、それだけでは署名を作れません。名称は Flexible Round-Optimized Schnorr Threshold の略で、ウォレットや新しい種類のビットコインではありません。
アンナ、ヤン、エヴァがある団体の積立金を管理しているとします。選ぶのは 2 of 3 というルールです。アンナとヤン、アンナとエヴァ、またはヤンとエヴァが支払いを承認できます。それぞれが持つのは異なる秘密のシェア、つまり共通の鍵材料を暗号学的に分散した一部分です。一つでは足りませんが、同じパスワードのコピーが三つあるわけでもありません。エヴァが参加できなくても、残る二人は協力できます。同じ境界は攻撃者にも当てはまります。十分な数のシェアを入手すれば、攻撃者も署名できます。したがって分散が役立つのは、一台の端末や一つのアカウントの侵害が、ほかのすべてへのアクセスにつながらない場合です。 [1] [2]
アンナは、アプリに「署名待ち」と表示されたという理由だけで承認すべきではありません。送金先、金額、手数料を把握し、お釣りがあれば団体に戻ることも確認する必要があります。各署名者には、実際の取引を信頼できる方法で確認する手段が必要です。Hash はデータの短い暗号学的な指紋ですが、それだけでは人に内容を説明できません。FROST は同じメッセージへの協力を可能にするだけで、請求書が本物か、本人が承認内容を理解したかまでは判断しません。署名が完成しても、支払いがブロックで承認されたことにはなりません。ブロックは、Bitcoin ネットワークの共通の履歴に記録される取引のまとまりです。RFC 9591 は情報提供を目的としたプロトコル仕様であり、アプリ全体の安全性を認証するものではありません。 [1] [2]
Taproot は Bitcoin の改良で、対応する鍵の署名を使うか、あらかじめ定めた条件を満たすことで資金を使用できる仕組みです。適切に構成されたしきい値署名は、Taproot のキーパスで支出する際、単一の鍵による通常の署名のように見せられます。署名だけから内部のシェア数やしきい値は分かりません。これはプライバシーや署名データの大きさに利点がありますが、取引全体や参加者同士の通信が匿名になるわけではありません。Bitcoin では BIP 340 の厳密な規則が必要で、鍵の計算の数学的な土台となる secp256k1 曲線上で、一般的な FROST を使うだけでは不十分です。そのため Zcash Foundation (ZF) は Taproot 用の frost-secp256k1-tr を別に提供しています。Taproot が使う鍵の調整も正しく処理しなければなりません。曲線名が同じでも互換性の証明にはならず、ライブラリがあることと、すべてのウォレットが対応することも別です。 [3] [4]
団体は何かを署名する前に、シェアを安全に作らなければなりません。信頼する配布者が完全な鍵を生成し、それを分割する方法があります。ただし、その時点では配布者が鍵全体を知っています。コピーを残せば、予定していた共同承認を迂回できてしまいます。もう一つの方法が DKG、分散鍵生成です。完全な秘密鍵を一人の参加者のもとに出現させずに生成できますが、認証された保護通信と、プロトコルの正しい実行が必要です。ファイルをいくつかメールで送るだけでは足りません。RFC 9591 は署名を中心に規定しており、あらゆる製品の DKG 対応を約束するものではありません。また、長期的な鍵のシェアと、特定の支払いに対する署名シェアは別物です。 [1] [2]
署名そのものは二つのラウンドで行い、それ以前の鍵生成は含みません。まず選ばれた各参加者が、nonce という秘密の使い捨て値を二つ作り、その公開コミットメントを送ります。これは参加者をそれらの nonce に暗号学的に結び付ける値です。次に共通メッセージとコミットメント一覧を受け取り、資料を確認して自分の署名シェアを計算します。コーディネーターがそれらを結合します。結合係数によって、計算は特定のメッセージ、グループ公開鍵、コミットメントに結び付きます。2 of 3 なら二人を選んでセッションを始められます。ただし三人全員を選んだセッションでは全員の寄与が必要で、途中で応答しなくなった人を単に省くことはできません。 [1] [3]
ここでの nonce は一回の署名試行のための秘密値であり、何度も使えるパスワードではありません。再利用すると秘密の鍵材料が漏れるおそれがあります。ヤンのコンピューターが署名シェア送信後に停止した場合、古い状態から復元しても、使用済みの nonce を未使用として扱ってはいけません。支払いが完了しなかった場合も再利用は認められません。安全な実装には、適切な乱数、並行する試行の分離、消費済みの値を確実に使用不能にする処理が必要です。これは、寄せ集めのスクリプトで FROST を自作すべきでない理由の一つです。数学が正しくても、秘密データの扱いを誤れば守れません。 [1]
コーディネーターはメッセージを取りまとめますが、その役割だけで団体の代わりに署名することはできません。選ばれたシェア保有者の寄与が必要です。一方で、通信を止めたりセッションを中断させたりすることはできます。参加者の無効な寄与でも失敗は起こります。検証で無効な署名シェアを検出できても、誰に原因があるか特定するにはメッセージの出所を確実に把握する必要があります。問題の発見は完了の保証ではありません。再試行には、参加可能な正規のグループと新しい nonce が必要です。団体には、最初の画面にあるしきい値の数字だけでなく、障害や意見の不一致への対応策も必要です。 [1] [2]
エヴァが端末を失っても、FROST という名前だけでは資金は復旧しません。バックアップには本人のシェア、識別子、必要なグループ情報、そして互換ソフトウェアで読み込む手段が必要です。一般的な Seed Phrase、つまり単語によるウォレットのバックアップと、自動的に同じものになるわけではありません。他の参加者の助けによるシェア復旧やシェアの更新は、個々のシステムが対応すべき追加の手順です。エヴァのシェアをコピーしても同じシェアのままで、独立した一票は増えません。同じグループ鍵を維持した更新でも、以前に盗まれた十分な数のシェアは無力化できません。実際の積立金を使う前の試験には、一度の署名成功だけでなく、復旧、障害対応、正確なソフトウェアのバージョン確認も含める必要があります。 [2] [3]
理解を深めるには、この項目とあわせて次もお読みください Schnorr Signature, MuSig2, Multisig, Taproot, Shamir Secret Sharing, Bitcoin.