#baby $BABY ビットコインには組み込みのスラッシング（削減・罰則）ロジックがないのに、ビットコイン上でバリデータをどのようにスラッシュするのですか？
これ、実際に理解するのに思った以上に時間がかかりました。というのも、答えはスマートコントラクトではなく、コードではなく数学で巧妙にやりくりする署名方式だからです。
@BabylonLabs_io では、ビットコインのネイティブなシュノー（Schnorr）署名に基づく「抽出可能ワンタイム署名（Extractable One-Time Signature: EOTS）」を使います。核となるトリックはこうです。最終性プロバイダ（finality provider）は、投票する各ブロック高（height）ごとに固有の鍵ペアを生成します。彼らがその高さに対して署名するのが常に1ブロックだけである限り、署名は完全に安全で、何も漏れません。しかし同じ高さで矛盾する2つのブロックに署名すると、数学が破綻します。その高さごとの鍵を2通りのメッセージに使い回すと、ノンス（nonce）が再利用されることによるシュノー署名の仕組みのために、プライベート鍵が直接露出してしまうのです。
最終性ラウンド自体は、ブロックを実際に確定（finalize）するには、ステークされたBTCの総重量の3分の2超からの署名が必要です。したがって、安全性違反が起きるには、定義上、ステークの3分の1超が二重署名している必要があります。これが、「完全にスラッシュ可能（fully slashable）」という保証が、政策（ポリシー）の約束ではなく、数学的に強制される理由です。鍵が漏れた時点で、バビロンだけでなく、ただのバリデータでもなく、誰でもスラッシング取引を構築してブロードキャストできます。その段階では委員会の投票も不要で、異議申し立てのプロセスもなく、ただ露出した数学があるだけです。
まだはっきりした答えを見たことがない点：各ブロック高のために鍵生成を行うことは、複数のBSNを同時に運用する最終性プロバイダにとって意味のある運用上のオーバーヘッドになりますか？また、そのオーバーヘッド自体が、悪意ではなく過負荷の状況でプロバイダが誤ってランダムネスを再利用してしまう、といった攻撃面（攻撃可能性）になり得ますか？
EOTSのセキュリティは純粋に数学的な保証なのか、それとも最終性プロバイダが堅牢な鍵管理インフラを持っていることに、静かに依存しているのでしょうか？
$BABY