OP_EQUAL

バイト0x87は、ビットコインが本当に必要とする唯一の比較を行います。すなわち、この2つのデータの塊は同一かという比較です。比較は数値ではなく生のバイトに対して行われるため、この言語には算術的な等価性のための別のオペコードが用意されています。3で始まるアドレスにこれまでに送ったすべての支払いは、この1つの命令でスクリプトを終えます。

仕組み

スタックから2つの項目が取り出され、1つが戻されます。一致すれば0x01という1バイト、一致しなければ空の項目です。ビットコインは空の項目を偽として扱うため、結果はそれに続くどの命令からでも検査できます。

バイト比較は見た目より厳格です。人が同じ数値と呼ぶ2つの値でも、バイト列としては異なることがあり、このオペコードはそれを不一致とみなします。これはこのオペコードの本来の役割、すなわちハッシュとプリイメージの比較において、どんな違いであれ不一致とすべき場面では正しい動作であり、算術結果の比較には代わりにOP_NUMEQUALが使われる理由でもあります。

興味深い性質は、このオペコードが行わないことです。結果に対して作用するのではなく、結果を残します。スクリプトは最上位に残った項目が真であるときにのみ成功して終わるため、このオペコードで終わるスクリプトは問いを投げかけ、その結果を答えとしてそのまま残します。Bitcoin Coreのcleanstackルールは、他に何も残ってはならないと付け加えており、スクリプトハッシュの使用ではこれが真の値ちょうど1つで、それ以上は何もないことを意味します。

この最後の点は見た目以上の意味を持ちます。pay-to-script-hashはハッシュ化されたスクリプトに関する一般的なルールではなく、23バイトの正確な1つのパターン、すなわちハッシュのオペコード、20バイトのプッシュ、そして最後にこのオペコード、に関するルールです。同じ論理を統合された検証形式で書くと、特別な扱いは適用されず、redeem scriptは取り出されることも実行されることもなく、出力はプリイメージを当てた者が誰でも使用できる通常のハッシュパズルのように振る舞います。

目にする場面

3で始まるアドレスのすべての未使用出力は、ブロックエクスプローラー上で同じ3つのトークンからなるアセンブリを示し、ここで終わります。取引所がこれまでに送ったすべてのラップされたSegWitの出金も同様です。

ハッシュロック契約にも現れます。ライトニングネットワークの支払いスクリプトは秘密の値をハッシュ化し、その結果を固定値と比較します。これにより、受取人が32バイトのプリイメージを明かした瞬間に、支払いが複数のホップを越えて決済されるのです。チェーン間のアトミックスワップも同じ形を使います。

OP_EQUAL vs OP_EQUALVERIFY

OP_EQUALVERIFYは、検査を組み込んだOP_EQUALです。バイト0x88は同じ比較を行い、答えが偽であれば直ちにスクリプトを中断し、成功したときにはスタックに何も残しません。どちらを選ぶかは、その後に何が続くかという問題です。比較がスクリプトの最終的な答えである場合は、pay-to-script-hashがそうであるように、単純な形式を使います。比較が複数の条件のうちの1つであり、実行を続けなければならない場合は、従来の単一鍵テンプレートが署名を検査する前に行うように、検証形式を使います。検証形式はまた、比較と別個の検証命令を書くより1バイト節約でき、スクリプトのすべてのバイトが重み4単位ずつでトランザクションの非ウィットネス部分に置かれていた頃には、はるかに大きな意味を持っていました。