OP_CHECKSIGADD

このオペコードは3つのスタック項目、署名、累計カウント、公開鍵を取得し、カウントをそのまま、または1増やして押し戻します。BIP-342はこのオペコードに186を割り当て、同時にOP_CHECKMULTISIGを無効化したため、Taprootスクリプトのマルチシグはすべてこの方式で書かれます。実用的な利点は、しきい値ポリシーが20個の鍵で頭打ちにならなくなったことです。

仕組み

tapscriptのしきい値は、署名検査の連鎖と、その間で受け渡される集計、そして最後の比較からなります。

書き下すと、3つのうち2つの署名を必要とする形は次のようになります。1つ目の公開鍵を積み、OP_CHECKSIG、2つ目を積み、OP_CHECKSIGADD、3つ目を積み、OP_CHECKSIGADD、2を積み、OP_NUMEQUALとします。実行は左から右へ進みます。OP_CHECKSIGは1または0をスタックに残し、各OP_CHECKSIGADDは公開鍵を1つ取り出し、その累計を取り出し、この鍵に対して提示された署名を取り出し、署名が検証できた場合は1を加えた累計を押し戻します。最後の比較が、十分な数の署名が検証できたかを決めます。

参加しない署名者は、署名の代わりに空のバイト列を渡します。オペコードはそれを認識し、その枠を未署名として扱い、集計をそのまま返します。これにかかるのはウィットネス内の1バイトだけです。仕組みはこれだけであり、元の実装にあったオフバイワンの不具合のためにOP_CHECKMULTISIGが要求していたダミーのスタック要素も不要になります。

1つの鍵を1つの署名と照合することから、2つの帰結が生じます。検証はバッチ化できるようになります。ノードは候補の鍵を順に試す代わりに、ブロック内のすべてのSchnorr署名を1つの集約的な検証にまとめることができ、これがTaprootの検証高速化の大きな部分を占めます。また、鍵の数は、検証する署名1つにつき50のweight unitを消費するtapscriptの検証予算によって制限され、オペコードに書き込まれた固定の上限によっては制限されません。

使われる場面

OP_CHECKSIGADDは、複数の署名者を必要とするあらゆるTaprootスクリプトに現れます。ウォレットソフトウェアでは、これは通常、生のスクリプトではなくディスクリプターを意味します。

Bitcoin Coreはこれをtr()ディスクリプター内のmulti_aおよびsortedmulti_aフラグメントとして公開しているため、3鍵のクオラムはtr(internalkey,multi_a(2,KEY1,KEY2,KEY3))と書けばよく、オペコードの連鎖はソフトウェアが生成します。Miniscriptも同様に扱い、Taprootポリシーに対応したハードウェア機器は、事前に構成を知る必要なくこれらのスクリプトに署名します。

この設計はクオラムの形の作り方も変えます。3つの鍵すべてを1つのリーフに持たせる代わりに、taptreeは3つの別々の2鍵リーフを持てます。考えられる組ごとに1つであり、使用時には実際に署名した組だけが公開されます。これはスクリプトのリーフの点では余分にかかりますが、ウィットネス内の公開鍵を1つ節約し、使用のたびに鍵の全集合を公開するよりも実質的なプライバシー改善になります。

OP_CHECKSIGADD vs OP_CHECKMULTISIG

OP_CHECKSIGADDとOP_CHECKMULTISIGはどちらも鍵の集合に対して署名を数えますが、Taprootのリーフで機能するのは一方だけです。OP_CHECKMULTISIGはレガシーおよびSegWitバージョン0のスクリプトで引き続き完全に有効であるため、長年使われてきたbc1qのマルチシグは影響を受けず、移行も不要です。

tapscript内では、OP_CHECKMULTISIGとOP_CHECKMULTISIGVERIFYは完全に無効化されています。動作する場所以外に、3つの違いが重要です。旧オペコードはスクリプトあたりの公開鍵を20個に制限し、新オペコードにはそのような数がありません。旧オペコードはスタック上に余分なダミー項目を必要とし、BIP-147が後にこれを空にすることをコンセンサスルールとして強制しました。また、旧オペコードは、検証者が各署名がどの鍵に属するかを事前に知ることができないため、バッチ検証できません。