バッチ検証

検証者はu個の署名をまとめ、最初以外のすべてにランダムなスカラーで重みを付け、u回ではなく1つの方程式でまとめて処理します。BIP-340はまさにそのために作られ、署名を64バイトに固定しましたが、標準化されたECDSAは追加のウィットネスデータを加えない限りまとめて検証することはできません。バッチ処理は各検証者の選択であるため、ノードが履歴を検証する速さが変わるだけで、あなたのコインには何の影響もありません。

仕組み

バッチ検証はBIP-340でBatchVerifyとして規定されており、u個の32バイトの公開鍵、u個のメッセージ、u個の64バイトの署名を受け取り、それらすべてに対して1回で答えを返します。

まず重みです。検証者は、曲線の位数をnとして1からn-1の範囲のu-1個の整数を、バッチ内のすべての入力（鍵、メッセージ、署名のいずれも）のハッシュをシードとする生成器から決定的に生成します。BIP-340はSHA256を安全なシードハッシュと呼び、ChaCha20をそれを256ビットの整数に展開する安全な方法と呼び、範囲外になったものは飛ばします。

次にバッチは1つの検査に集約されます。s値の重み付き和に生成点を掛けたものが、R点と、各署名のチャレンジにその署名自身の公開鍵を掛けたもののそれぞれに同じ重みを適用したものの和と等しくなければなりません。それらのu個の別々の検査は1つの比較になり、BIP-340はこれに大きな高速化をもたらすとしています。

その節約には署名ごとのコストが伴います。BatchVerifyは各r値を曲線上に戻しますが、単一の検証ではそれは行いません。VerifyはsとチャレンジからRを再計算し、そのx座標がrと等しいことだけを確認します。

保証は意図的に非対称です。バッチ内のすべての署名が有効であれば、BatchVerifyは常に成功します。1つでも無効であれば、成功する確率は無視できる程度にとどまります。ただし、問題のある署名を特定することはできないため、どの署名が壊れたかを知る必要がある検証者は、それらを1つずつ検査します。

どこで見られるか

バッチ検証は完全にネットワークの検証者側に存在するため、ウォレットの画面や手数料の見積もりに現れることはありません。

効果を発揮するのは、何年分ものTaprootの支払いを一度に処理するノードであり、支払いを送るウォレットではありません。BIP-340はどこでもバッチ処理を義務付けておらず、単一署名の検証が定義であり、バッチは検証者が選べるものです。このBIPはバイトレベルで規定されたアルゴリズムを要求しており、それはDER解析がBIP-66まで欠いていた厳密性であり、ある検証者には有効で別の検証者には無効な署名を誰も作れないようにするためです。検証者は自らのバッチを選ぶため、両者を食い違わせようとする攻撃者に対しても、バッチ検証と単一検証が無視できる確率でしか異ならないようにしているのは、このバイトレベルの厳密性です。

バッチ処理はまた、単独では恣意的に見えるBIP-340内の選択も説明します。署名はより短い形式を取ることもでき、そこでは128ビットのセキュリティ目標に16バイトのハッシュで足りますが、このBIPはそれを退けました。互いに信頼しない署名者が協力する場合、短いハッシュは脆く、バッチ処理に対応するのはRを含む長い形式だからです。公開鍵はビットコインで通常の33バイトの圧縮エンコードではなく32バイトであり、これはコンパクトさのために選ばれ、省かれるy座標は曖昧なままにせず偶数側に固定されています。効率的な検証とバッチ処理の両方が、それを曖昧でなくする必要があるからです。

ECDSAにはそのどれも当てはまりません。BIP-340はこれを署名方式を変える理由の1つとして挙げています。標準化された形式は、追加のウィットネスデータを加えない限り、個別に検証するよりバッチで効率的に検証することはできないからです。

バッチ検証vs MuSig2

バッチ検証とMuSig2はどちらも多数の署名を安くしますが、ブロードキャストされる内容を変えるのはMuSig2だけです。

MuSig2は取引がネットワークに届く前に複数の署名者を1つの鍵と1つの通常の64バイトの署名に集約するため、その節約はプライバシーとブロックスペースにあり、n-of-nです。すべての署名者が参加しなければなりません。バッチ検証は各署名をそのままの位置に残し、検証者が行う計算を並べ替えるだけであり、誰の協力も必要とせず、誰も気づくことすらありません。ノードは、無関係な取引において、何年も離れて見知らぬ人が作った署名をまとめてバッチ処理できます。