ビットコインの次の大きなアップグレード？OP_CATとOP_CTVの評価

著者：ゲイブ・パーカー（アナリスト、ギャラクシー） 翻訳：ゴールデンファイナンス xiaozou

概要

• ビットコインは、プロトコルのアップグレードに対して保守的なアプローチを取っており、コンセンサスの変更を比較的稀にしてきました。しかし、以前のSegWitとTaprootのアップグレードが示したように、開発者はまだビットコインのプログラミング言語とネットワークパラメータを最適化することを望んでいる。

• ビットコインのプログラミング言語であるBitcoin Scriptは、トランザクションがグローバルな状態を運ぶことを可能にせず、イントロスペクション機能を備えているため、表現力が制限されています。その表現力には限界があります。

• 現在、OP_CAT (BIP 347)とOP_CTV (BIP 119)という2つの主要な提案があります。これらの提案は、ビットコインのトランザクションのプログラム可能性を強化し、トランザクションの出力をより費用に依存するものにすることを目的としている。これらの提案は、ビットコインスクリプトの機能を大幅に強化し、柔軟性を高める可能性があります。

• OP_CATとOP_CTVの最も有望な応用シナリオには：ビットコインの第1層（L1）と第2層（L2）間のトラストレス・クロスチェーン・ブリッジの作成。高度なセルフホストボールトソリューションの改善とライトニングネットワークの改善。

• ソフトフォークアップグレードのガバナンスプロセスには、複数のビットコイン関係者が関わっていました。プロトコルの概念化と技術レビューの初期段階では、メディアの影響力とコア開発者が最も影響力を持ちました。

• ギャラクシー・リサーチは、ビットコインのコア開発者は2025年にOP_CATまたはOP_CTVのコンセンサスに達すると予測していますが、アクティベーションプロセスが複雑なため、実際の実装には1～2年かかる可能性があります。

1.はじめに

ビットコインのプロトコルに変更を加えるには、プロトコル開発者、フルノード、エンドユーザー、ビットコイン開発者を含むが、これらに限定されない複数の利害関係者間での議論と協力が必要になる。フルノード、エンドユーザー、マイナーを含むがこれらに限定されない。プロトコルのアップグレードを達成するためのコンセンサスプロセスは、複雑で論争的です。例えば、2015年から2017年にかけての「ブロックサイズ論争」は、ビットコインコミュニティを二分し、一方はブロックサイズの変更を望み、他方はそれに反対した。数年にわたる議論は、最終的にブロックチェーンの永久フォークと、ビットコインをフォークした新しい暗号通貨ビットコインキャッシュの誕生につながった。

プロトコルの変更でコンセンサスを得るのが難しいことから、ビットコインの大幅なアップグレードは比較的まれだ。ビットコインのプロトコル開発者は、論争の的になるようなアップグレードを拒否してきた長い歴史があり、より幅広いビットコインコミュニティに支持されるアップグレードを実装するには何年もかかる。これは、予測可能性、ネットワークの忠実性、および後方互換性を促進するために、ビットコインの開発に保守的なアプローチを取るという開発者のコミットメントを強調しています。

ビットコインにおけるコンセンサスの変更はまれであるにもかかわらず、ビットコインの開発者は、ビットコインのスクリプトとネットワークパラメーターを最適化することにオープンであることを示しています。ブロックサイズの議論から生まれたSegregated Witness（SegWit）のアップグレードは、実際にブロックサイズの上限を増やし、より多くのトランザクションをブロックに含めることを可能にした。SegWitはまた、測定単位をバイトから仮想バイトに変更することで、トランザクションデータのフォーマットを最適化した。この移行は、署名データをウィットネスフィールドに移動させることと合わせて、ビットコインブロックが最大4mウェイト単位の取引データ（約4MB）を含むことを可能にする。ビットコインの最後のソフトフォークは、2021年のTaprootアップグレードであり、Tapscriptと呼ばれるスクリプト言語の更新バージョンを導入した。この新バージョンのビットコインスクリプトには、複数の公開鍵と署名を1つの署名鍵に統合するキーアグリゲーションが改良された新しい署名方式（シュナー署名）が含まれている。シュナー署名のキーアグリゲーションは、ライトニングネットワーク（ビットコイン財団レイヤーの上に構築されたビットコイン最大のP2P決済レイヤー）上のトランザクションのプライバシーを向上させながら、複数の署名を必要とするトランザクションデータの量を削減する。.SegWitとTaprootの概要を簡単に説明すると、ビットコインの開発者はビットコインに対するコンセンサスの変更を警戒しているが、これはビットコインの技術的特性が変わらないことを意味するものではない。

SegWitとTaprootの後、ビットコインの開発者は現在、トランザクションにスマートコントラクトロジックを追加するために、ビットコインのトランザクションプログラマビリティを向上させる方法を模索している。ビットコインのスマートコントラクトでは、支出条件（Unspent Transaction Outputs (UTXOs)が将来どのように支出されるかを制限し制御する能力であり、「コベナンツ」（「制限条項」または「コベナンツ」）として知られるより複雑で厳しい支出制約が使用される。「コベナンツ」）と呼ばれる、より複雑で厳しい支出制約がある。本稿ではまず、ビットコインのスクリプトとビットコインのUTXO会計モデルとの連携について検討する。続いて、保留中の2つのオペコード、OP_CTVとOP_CATを分析し、これらのオペコードがビットコインスクリプトを向上させ、効率的なトランザクションプログラマビリティを可能にする強力な機能を搭載する可能性を強調する。最後に、本稿はブリッジングやエスクローなどのビットコインのインフラに対するトランザクションプログラマビリティの重要性を強調し、OP_CTとOP_CTVのコンセンサスに達する可能性と、これらのオペコードを次のソフトフォークアップグレードに実装する道筋を展望する。

2.ビットコインスクリプトとUTXOモデル

ビットコインは、トランザクションを構造化するためにネイティブのスクリプト言語を使用しています。ビットコインスクリプト "と呼ばれます。スクリプトは、トランザクションの受信者が送信されたビットコインをどのように使うかを定義する一連の命令で構成され、「消費条件」とも呼ばれます。ビットコインスクリプトは、コマンド関数として実行される186のオペコードで構成されています。これらのオペコードは、ビットコインアセットがネットワーク上でどのように使用され、転送されるかの公式ルールを作成するために使用される。例えば、Pay-to-PubKey Hashトランザクションには4つのオペコードが含まれており、ビットコインがハッシュ化された公開鍵に使用され、使用者に関連付けられた正しい公開鍵と秘密鍵を使用してのみ使用できるビットコイントランザクションの支出条件を強制します。

ビットコインスクリプトは、入力と出力を使用するビットコインのUnspent Transaction Output（UTXOモデル）用に設計されています。各ビットコイン取引は少なくとも1つの入力と1つの出力で構成されますが、ほとんどの単純な取引は少なくとも1つの入力と2つの出力で構成されます（入力側のBTCの一部は取引の資金として使用され、一部は受信者に送信され、残りは出力側で送信者に返されます）。UTXOはまだ使用されていないビットコインの部分で、将来の取引で送信することができます。UTXOはトランザクションのインプットとして使用されると、もはやアウトプットではなくなります。従って、UTXOはユーザーがビットコインを使用する際に、常に作成と破棄が繰り返されます。

*アリスが自分のウォレットに1BTC相当のUTXOを持っていて、0.5BTCをボブに送った場合、アリスの入力は1BTCになります。差額の0.01 BTCは取引手数料に支払われるBTCを表す（この取引手数料はネットワークの混雑状況によって変動する）。* ステップ2で、アリスは0.5BTCと0.49BTCの2つの新しいUTXOを作成し、1つはアリスにお釣りを返し、もう1つは0.5BTCと0.49BTCの2つの新しいUTXOを作成する。ステップ3では、アリスは0.49 BTC相当の新しいUTXOを持つことになります。アリスがBobに0.5 BTCを支払う必要がある場合、アリスはステップ1で複数のUTXO、合計0.5 BTCを使うこともできることに注意してください。UTXOモデルはビットコインネットワークの重要な特徴であり、トランザクション処理と検証において重要な役割を果たしています。

上記のUTXOの例は、完全にビットコインスクリプトを使用して構築されています。各UTXOには、UTXOが使用される一連の条件を含むロックスクリプトが含まれています。UTXOのロックスクリプトは、ユーザーが対応する公開鍵に関連付けられた正しい秘密鍵署名を提供することで、入力（使用されるUTXO）の所有権を証明したときにロックが解除されます。この情報は「スクリプト署名」と呼ばれ、入力に正しいスクリプト署名が含まれると、使用条件が満たされ、ビットコインを使用できるようになる。アリスとボブのUTXOの例に戻ると、ステップ1では、アリスはUTXOを使用するために入力で秘密鍵署名を提供する必要があり、次にボブは新しく受け取った0.5 BTCを使用する前に同じ情報を提供する必要があります。

ビットコインのスクリプト言語には、複数の署名を要求したり、特定のブロックの高さでビットコインのロックを解除したりするなど、より複雑な支出条件を含めることができます。しかし、ビットコインのスクリプトは普遍的ではなく、イーサのネイティブプログラミング言語であるSolidityの表現力に欠けている。その結果、ビットコインスクリプトを使用したブリッジングおよびホスティングソリューションのスマートコントラクトロジックのプログラミングは非常に困難です。

3.2025年時点でのビットコイン・スクリプティングの障害

ビットコイン・スクリプティングは、ユーザーへの有用性とダブルフラッシュ攻撃への耐性を証明しましたが、スクリプト言語にはダブルフラッシュ攻撃への耐性を欠いています。スクリプト言語には、表現力やグローバルな状態を保存する機能など、汎用的な機能が欠けています。ビットコインスクリプトが表現力に乏しいのは、スタックベースのプログラミング言語であるため、大きな数に対する乗算や算術演算を実行できないからだ。Bitcoin Scriptは32ビットサイズの値に対してのみ、自明でない（non-trivial）計算を行うことができる。その結果、Bitcoin Script は 32 ビットより大きいスタック要素を互いに分離します。この 32 ビットの制限により、暗号関数、乗算、除算を使用する計算量の多いコマンドが分離され、現在のオペコード セットよりも大きなスクリプト サイズが必要になります。複数のオペコードを使用して算術と乗算をシミュレートすることは可能ですが、これには多くのスタック要素が必要であり、Bitcoinスクリプトのスタックサイズは1,000要素に制限されています。その結果、トランザクション出力に現在の演算を超える複雑な費用条件を作成することは困難である。

ビットコインスクリプトの最大の限界は、この言語が支出者から提供された入力しか読み取れないため、取引データを読み書きして保存できないことだ。プログラミング言語がグローバルな状態を保存できない場合、スクリプトはアプリケーションやブリッジ上の口座残高を独自に検証できない。ビットコインのスクリプティングロジックはグローバルステートにアクセスすることができない。その結果、汎用的な機能を開発したり、L2ネットワークとビットコインのベースレイヤーとの間に信頼性のないブリッジを構築したりすることはほぼ不可能です。

ビットコインのスクリプトの制限を克服する取り組みは、2020年以来進行中です。長年にわたり、ビットコインのスクリプトの表現力を向上させる唯一の方法は、規約を可能にする新しいオペコードを実装するソフトフォークアップグレードを実行することであるというコンセンサスが開発者の間で得られているようです。ビットコインコミュニティの一部は、これらのアップグレードがビットコインネットワークにリスクをもたらすと考えていますが、コミュニティの別の一部は、ビットコインのユースケースを拡大するために、ビットコインにはより多くのプログラマビリティ機能が必要であると考えています。どのオペコードがビットコイン取引のプログラマビリティを向上させるのに最も適しているかについては、まだ実質的な進展は見られないが、現在、コベナンツの支持者は、OP_CTVとOP_CATがビットコイン取引のプログラマビリティを向上させるための主要なビットコイン改善提案（BIP）であることにほぼ同意している。私たちは、ビットコインにコベナンツを実装するための2つ以上のソリューションがあることを理解していますが、この記事では、OP_CTVとOP_CATという2つの最も顕著な提案のみを説明します。

4.BIP119（OP_CTV）

ビットコイン改善案119（BIP119）は、CHECK-としても知られています。TEMPLATE-VERIFY (CTV) は、ビットコイン・コアの開発者ジェレミー・ルービンによる2020年1月の提案です。この提案は新しいオペコード、OP_CTVを導入し、ビットコイントランザクションの出力に一般的な支出条件、または誓約を強制します。CHECK_TEMPLATE_VERIFY」のテンプレート部分は、ビットコインのスクリプトを記述する際に従わなければならないトランザクション形式を指す。 CHECK-TEMPLATE-VERIFYは、トランザクションの出力に対するロックスクリプトが、ロックスクリプトに格納された支出条件にコミットすることを可能にする新機能である。をハッシュとしてコミットできるようにする新機能である。したがって、トランザクションの出力は、コミットされたハッシュに詳細な条件が満たされた場合にのみアンロックできる。OP_CTVの利点は、トランザクションの送信者が受信者に支出条件を課すことができることであり、これは送信者の支出条件しか構築できない現在のビットコインスクリプトのルールから大きく変わった点である。

コベナンツ契約には主に2つのタイプがあります。一般的なコベナンツは複製することができ、複数のUTXOに適用することができます。コベナンツはUTXOが使用された後も有効期限が切れることはありません。一方、事前計算されたコベナンツは複製することができるが、使用できる回数は限られており、事前に定義された回数に限られる。事前に計算された契約のロジックは、送信者が事前に指定する必要があり、支出の条件を無期限に複製することができないという点で、一般的な契約とは異なります。再帰的契約としても知られる一般的な契約は、UTXOの代替可能性にリスクをもたらす可能性がある。これが、BIP119の提唱者が通常、事前計算された契約を使用するOP_CTVユースケースのみに焦点を当て、BIP119が一般的な契約をサポートしない理由である。例えば、一般契約が有効化された場合、カストディアンやビットコイン取引所は恒久的な支出条件で引き出しを処理することができるかもしれず、それらのビットコインは政府または他の当局によって精査される可能性から決して解放されないかもしれません。

5.BIP119を使用したコベナンツの展開

保管庫のシナリオを例にとると、OP_CTVの機能について、以下のように実装できます。契約:

アリスは今後10年間で、1BTC相当のUTXOのうち0.8BTCをボブとチャーリー（それぞれ0.4BTC）に使いたい。にも送りたい。

ステップ1: アリスはBobとCharlieに1BTC分のUTXOを使い、ロックスクリプトにBobとCharlieが525kブロック後、つまり約10年後にBTCを使えることを詳細に記述します。アリスはまた、自分のUTXOを525kブロック後、つまり～10年後にロックするために、～0.2BTCの変化出力が彼女が所有する保管庫アドレスに送られることを詳細に説明する指示も含んでいます。

ステップ2: BobとCharlieは、525kブロック後に0.4 BTCと評価されたそれぞれのUTXOを使います。Aliceによってセットアップされたロックスクリプトは、コミットされたハッシュと現在のブロックの高さを照合し、条件が満たされた場合、Bobは

ステップ2でBobとCharlieがUTXOを使った後、「ロックダウンスクリプト」とも呼ばれるビットコインスクリプトの一部が、消費条件の達成をチェックします。BobとCharlieがUTXOを使った後、「ロックスクリプト」とも呼ばれるビットコインスクリプトの一部が、BTCを放出する前に、すべての条件が満たされていることを確認するために、支出の条件の履行をチェックします。この動作はしばしば、正しいスクリプト署名で出力されたビットコインの「ロック解除」と呼ばれます。条件が満たされていない場合、ロックスクリプトはBTC送金を開始しません。

ステップ3: チャーリーとボブがロックスクリプトで約束されたハッシュを満たした後、お釣りとしてアリスに返されたUTXO（～0.2 BTC）が、指定された保管庫スクリプト公開鍵を持つアドレスへの入力として使用されます。保管庫スクリプト公開鍵には、Aliceが525kブロック後に保管庫のロックを解除して、~0.2BTC相当のUTXOを使うことを可能にするハッシュが含まれています。保管庫スキームを使用する利点は、誰かが彼女の秘密鍵を盗み、525kブロックの時間ロックの前にUTXOのロックを解除しようとした場合に備えて、Aliceがハッシュに秘密の回復アドレスなどの詳細なセキュリティ対策を追加できることです

誓約がない場合、先の例では、アリスはボブとチャーリーに使うBTCに将来の支出条件を強制するために、事前署名トランザクションを作成する必要がある。事前署名トランザクションは、送信者の秘密鍵によって事前に署名された単一または複数のトランザクションであるが、確認と実行のために実際にネットワークにブロードキャストされることはない。署名済みトランザクションは、チェーン上で実行されるまで複数のトランザクションのデータを保存しておく必要があるため、スケーラブルではない。さらに、事前署名付きトランザクションでは、資金を使用する際にすべての署名当事者間で双方向性が必要となる。しかし、OP_CTVを通じてコミットされたハッシュを使用してコベナンツを実装することで、ユーザーは署名前のトランザクションのデータを保存する必要性が軽減され、トランザクションに関連するすべての当事者間の対話性に依存することができます。

大まかに言えば、この機能は、洗練された、高度に安全で弾力性のあるホスティングとセキュリティ設計の範囲を作成するために使用することができ、セルフホストまたはホストされたセットアップを改善したり、革新的な新しい定足数またはビジネスアカウントのセットアップを作成したり、より高い透明性と信頼性を備えたより自律的な実行シナリオを作成したりするのに役立ちます。

6.BIP347（OP_CAT）

BIP347は、イーサン・ハイルマン（Ethan Heilman）とアーミン・サブーリ（Armin Sabouri）によって開発されたもう1つのビットコイン改善案です。Armin Sabouriが2023年10月に書いたもので、ビットコイン取引の出力に事前に計算された支出条件も可能にする。この提案は、ビットコインのスクリプト言語にOP_CATオペコードを追加することを提案しており、ビットコインの開発者がスタック内の2つのデータポイントを「結合」し、それらの値をスタックの最上位に配置することを可能にする機能である。簡単な背景を見てみよう。"連結 "とは、2つ以上のコードの文字列を、より大きなバイト列またはデータに結合するプロセスである。ビットコインスクリプトはスタックベースのプログラミング言語で、各コード文字列を順次計算します。5行のコードのスタックの場合、ビットコインスクリプトは1行目を最初に計算し、5行目を最後に計算します。残念ながら、ビットコインのスクリプト言語には、開発者がスタック全体で複数のコード文字列を結合できるオペコードが含まれていない。現在、ビットコインのスクリプトには算術と乗算の機能がないため、ビットコインのスクリプトを圧縮する機能が阻害され、1つのスタック内での大きなスクリプト（32ビット以上）と小さなスクリプト（32ビット未満）の相互作用が制限されている。スクリプトを「連結」して圧縮し、大きなスクリプトが小さなスクリプトと通信できるようにする機能がなければ、トランザクション出力に関する複雑な費用条件は実現不可能です。

重要なことに、スタックの最上部にあるビットコインスクリプトの接続要素は、算術と乗算の機能をエミュレートできるため、エラーが発生しやすい長くてデータ量の多いスクリプトを書く必要なく、複雑なスクリプトを作成できます。さらに、OP_CATの接続性により、開発者は、2021年11月に有効化されたTaprootアップグレードの一環として、新しいトランザクションタイプを可能にするために使用されるネイティブスクリプト言語であるTapscriptで、Merkleツリーやその他のハッシュデータ構造を使用して経費条件を生成することができます。

注目すべきは、サトシ・ナカモトがOP_CATや、ビットコインのスクリプトがスクリプト内で複雑な数学演算を直接実行できるようにする他のオペコードを無効にしたことです。サトシ・ナカモト自身がOP_CATを削除したのは、ビットコインのスクリプトが2,000バイトに制限されていた当時、OP_DUPとの組み合わせでデータ量の多いスクリプトを構築できたからだ。このサイズのスクリプトは、ビットコインノードの計算リソースに負担をかけ、過負荷をかける可能性があった。しかし、Taprootのアップグレードにより、2021年にTaprootスクリプトのサイズ制限（520バイト）が導入されたため、OP_CATがノードオペレータに過度の計算オーバーヘッドをもたらすことはなくなりました。

7.BIP347（OP_CAT）による誓約の展開

2021年のTaprootのアップグレードでは、以下のようになります。Schnorr署名は公開鍵と秘密鍵の集約をサポートし、複数の当事者が単一の署名でトランザクションに共同署名できるようにします。Schnorr署名は公開鍵と秘密鍵の集約をサポートしており、複数の当事者が1つの署名で取引に共同署名することができます。Schnorr署名に含まれる検証オペコードをOP_CATと組み合わせることで、取引ハッシュを生成する非再帰型契約が作成されます。OP_CATを使用することで、ユーザーはスクリプトのロックを解除するための要件として、送信先アドレスや送信金額などトランザクションの特定の部分を制約することができ、トランザクションハッシュがロック解除のキーとして機能する。

保管庫のシナリオを例として、OP_CAT機能によってコベナンツがどのように実現されるかを以下に概説します。この例の技術的な詳細は、この記事の範囲を超えています。

アリスは100ブロック後にUTXOのロックを解除する保管庫を作りたいと考えています。アリスはUTXOをボールトのアドレスに使い、ボールトアンロックスクリプトの消費条件の詳細(ブロックの高さなど)をウィットネスフィールドに入力します。

*ステップ2：アリスのトランザクション中、OP_CATは証人フィールドのVaultロック解除コマンドを連結し、それらを2回ハッシュしてsighash/txhashを取得します。style="text-align: "left;">*ステップ3: 100ブロック確認後、Aliceは保管庫UTXOの支出トランザクションをブロードキャストすることで、彼の保管庫ビットコインの支出プロセスを開始します。Aliceが全ての支出条件を満たしたことを確認するために、AliceのウォレットはバックグラウンドでCheckSigオペコードを実行します。CheckSig関数はセットアップトランザクションのコンポーネントを再構築し、現在のトランザクションの公開鍵署名を検証して、すべての保管庫の支出条件が満たされていることを確認します。

*ステップ4: Aliceのトランザクションの公開鍵がCheckSigによって検証された後（これは証人フィールドに保存された支出条件を再構築する）、Aliceは自由にUTXOを使うことができる。style="text-align: "left;">上記の例は、OP_CAT単独ではトランザクションに支出条件を強制できないこと、むしろOP_CATをビットコインスクリプトの他のオペコードと組み合わせることで、誓約を有効にするためのスクリプティングを簡素化できることを示しています。

OP_CATをCheckSigと組み合わせて使用してコベナンツを作成することはできますが、OP_CATを単独で追加しても、ビットコインスクリプトにSolidityのような機能をもたらすことはできません。この制限は、OP_CTVのみを追加する場合にも適用される。OP_CATを使用しても、ビットコイントランザクションは最小限のイントロスペクトしかできない。つまり、トランザクションは以前のトランザクションの要素や状態に完全にアクセスできない。OP_CATはTaproot出力のリーフノードを修正したり、使用されている内部鍵を検証したりすることはできない。Taprootリーフノードは、Taproot出力に提出される個々の消費条件またはスクリプトである。各リーフノードは、ビットコインを使用する可能性のある1つの方法を表しています。Bitcoin Taproot トランザクションの内部キーは、最も効率的な支出パスに使用されるプライマリ公開キーです。内部キーを使用してUTXOを使用する場合、スクリプトやMerkleパスを明らかにすることなく、チェーン上の署名を提供するだけです。

これらの制限は、OP_TWEAK_VERIFYやOP_INTERNALKEYなどの他のオペコード案で対処できることに注意することが重要です。全体として、OP_CATは、トランザクション出力に複雑な費用条件を生成するための主要なビルディングブロックと考えることができますが、CheckSigを含む他のビルディングブロックは、ビットコイントランザクションにおけるプログラマビリティの開発を進めるために重要です。strong>

Starkware（Ether上のStarknet zk-rollupのクリエーター）は、OP_CATがどのようにトラストレス・ビットコイン・ブリッジングのためのSTARK検証機とMerkle検証機の作成をサポートするかを強調したレポートを発表しました。信頼性のないブリッジングは、Merkleツリーに記録されたトランザクションの連鎖を通じてブリッジの状態を維持する再帰的コントラクトシステムによって構築される。OP_CAT契約は、各新規の入出金トランザクションが、現在のブリッジ状態を反映する有効な状態遷移を含むことを要求する。ユーザーは、効率的な検証のために複数のトランザクションをバッチに集約するメルクル ツリーを使用する専用の入出金特約を通じてブリッジとやり取りする。この Merkle ツリーのルートは、その後メインのブリッジ契約にマージされ、各入金・出金を検証・処理する。引き出しの際、契約は引き出しアドレスがリーフ・トランザクションで入力された最初のアドレスと一致することを確認することで所有権を検証する。この設計では、ビットコインスクリプトの効率的な状態更新のためにMerkle証明を利用し、OP_CATによって作成されたオンチェーンコントラクトのロジックによってのみブリッジングの状態とルールが強制されるトラストレスシステムを構築している。OP_CATの機能により、ハッシュデータを連結することでSTARK検証器をビットコインスクリプトに組み込むことができるため、UTXOでロックされたスクリプトは、エンドシステムの状態遷移のzk-proof（ゼロ知識証明）を検証することができます。

タプロット・ウィザード・チームは、OP_CATとBitVMを組み合わせた新しいトラストレス・ブリッジング・フレームワークを革新しました。 BitVMは、任意の計算をビットコイン上で分割して実行できるようにすることで、チューリング完全な表現力を可能にします。BitVMは、Bitcoinスクリプトを利用した任意の計算と、Bitcoin上の複数のトランザクションに計算を分割するランタイムを組み合わせる。OP_CATは「スタック上のCAT」と呼ばれる技術によってビットコインのロックとロック解除を行うことができる。OP_CATは "CAT on the stack "と呼ばれる技術によって、以前のトランザクションのデータを運ぶことができる。この技術では、スタック上のハッシュ・データを連結して、OP_CATが検証できるメルクル・ツリーのルートを構築する。その結果、CatVMブリッジは、引き出し成功後にメルクルのルートが引き継がれることを保証するために、以前のトランザクション、入金、引き出しからのトランザクション固有のデータが次のトランザクションに含まれなければならないことを保証します。CAT on the stackトリックはまた、ユーザーが引き出した後、残りのブリッジされたビットコインを適格なユーザーが引き出すことができることを保証します。

(2)高度なVaultエスクロー

ビットコインVaultは新しいエスクローソリューションで、秘密鍵が漏洩した場合にユーザーがビットコインを引き出すことができるよう、リカバリーパスなどのセキュリティ機能を備えています。BIP 345は、正式にはOP_VAULTとして知られており、OP_CTVを利用してビットコインエスクローのセキュリティパラメータを強化する、保留中のビットコイン強化案です。OP_CATはまた、事前署名されたトランザクションを必要とせずにビットコイン保管庫の支出条件を作成するために使用できることに注意することが重要である。OP_VAULT は、OP_CTV に依存して、預託者が複数の取引に事前に署名することなく、保管庫のビットコインの支出条件を作成します。特約により、保管庫には時間遅延を設けることができます。この時間遅延は、誰かが元の時間ロックの前に保管庫のビットコインを使用しようとしたときにトリガーされます。

(3)非均等化契約

非均等化契約は、ビットコインのネットワークに導入されました。ネットワークに導入された非同期契約は、署名者が二重に使用すると署名キーが漏れるビットコインのトランザクション出力です。実際には、ユーザーは没収可能なマージンとしてネイティブビットコインをロックする。このマージンにより、ユーザーはベースレイヤー上で 0 確認トランザクションを実行することができ、後にブロック内で採掘される。0 確認トランザクションは、ビットコインのコンセンサスルールによって検証され、保護された瞬時のビットコイン取引である。0確定のトランザクションは、ビットコインのコンセンサスルールによって検証され、保護された瞬時のビットコイン取引である。0確定のトランザクションの送信者が、トランザクションがマイニングされる前にインプットを消費した場合、取引相手は危殆化した署名キーからビットコインのマージンを没収される可能性がある。

(4)ライトニングネットワークの改善

OP_CATはチャネルファクトリを有効にすることができます。OP_CATはチャンネルファクトリーを有効にすることができます。例えば、アリスが2つのライトニングチャンネル（1つはボブと、もう1つはチャーリーと）を作成したい場合、アリスはボブとチャーリーの両方とチャンネルオープン取引（2つの取引）をブロードキャストします。チャネルオープン取引では、両者がビットコインを2/2のマルチ署名アドレスに入金する必要がある。チャネルファクトリーにより、BobとCharlieは新たなチャネルオープン取引をブロードキャストすることなく、互いに別のチャネルをオープンすることができる。このように、最初のチャネル開設取引の参加者全員が、お互いに別のチャネルを開設することができます。

OP_CTVは、1つのUTXOが複数のユーザーを表す共有UTXOを作成することができます。CTVを使用した共有UTXOは、複数のユーザーが1つのオンチェーン取引で複数のライトニングチャンネルを開くことを可能にします。通常、各ライトニングチャンネルには1つのオンチェーン取引が必要です。そのため、多くのユーザーがライトニングチャンネルを開設すると、保留中のトランザクションでメモリプールがいっぱいになり、トランザクション手数料が増加する可能性があります。これは現在のところ問題ではありませんが、数百万人のアクティブユーザーを惹きつけるライトニングネットワークをサポートするためには、チャネル開設の規模を拡大する必要があります。

9.OP_CTおよびOP_CTVに関連するリスク

すべてのビットコインのソフトフォークには、新しいオペコードのバグや予期しない使用例などの技術的リスクが含まれています。ユースケース。前者はまれだが、後者は碑文の作成で露呈する。SegWitとTaprootのアップグレードにより、ユーザーは画像やテキストデータを文字列データとしてウィットネスフィールドに入力できるようになった。デジタルアートや可換トークンの作成は、SegWitやTaprootの有効化の焦点ではありませんでしたが、数年後、賢い開発者がこれらのアップグレードを他の目的に使用する方法を発見しました。このような新しい使用例に対するコミュニティの驚きは、新しいソフトフォークをサポートすることをためらわせるかもしれないからです。

ビットコインのアップグレード能力に関する弱気なセンチメントにもかかわらず、OP_CATとOP_CTVは重点的にテストされ、研究されてきました。コベナンツに対する当初の批判は、政府が一連の承認されたアドレスにのみビットコインの使用を許可する支出条件をアプリケーションに強制する可能性があるというものだった。支出条件の条件は資金を所有するユーザーによって決定されるため、この批判は無効である。ユーザーは将来の支出を特定のアドレスに制限するトランザクションを作成できるが、このような制限は第三者によって外部から強制されることはなく、ロックインされた資金が使用された後も永続させることはできない。その結果、政府は自己ホスト型の保管庫アプリやブリッジによって資金がどのように使われるかを強制することはできない。カストディアンやビットコイン取引所は、ユーザーが資金をどのように使うかを制限することはできますが、OP_CTVが許可していない一般的な特約を強制する能力がなければ、引き出した資金に恒久的な支出条件を追加することはできません。

全体として、OP_CATとOP_CTVはシンプルなオペコードであり、それぞれがうまく機能を実行します。OP_CATはスタックの最上位で2つの要素を接続し、OP_CTVはロックスクリプトで支出条件をハッシュできます。OP_CATはスタックの最上位にある2つの要素を接続し、OP_CTVはロックスクリプトの消費条件をハッシュ化することができます。これらのオペコードのいくつかの使用例（例えば、信頼できないブリッジの開発）は、ブリッジがバグやハッキングの影響を非常に受けやすいため、まださらなる研究と実世界でのテストが必要です。

10.次のソフトフォークアップグレードのための規約展開パス

将来のプロトコルのアップグレードに関するビットコインの利害関係者のコンセンサスを決定することは、複雑なプロセスであり、そのライフサイクルを通じて進化します。ビットコインのアップグレードの歴史に関するBCAPの報告書には、これらのステークホルダーの役割が以下のように詳細に記載されています。style="text-align: left;">*Economic Nodes: 取引所、カストディアン、マーチャント、決済プロバイダー

*Investors: MegaWhale、MicroStrategy, ETFプロバイダー, Galaxy

*Media Redditors: CoinDesk, Bitcoin Magazine, X Celebrities, Podcasts

*Media Redditors: CoinDesk, Bitcoin Magazine, X Celebrities, Podcasts

*Miners: Bitmain、MicroBT、Riot、Marathon、大規模なプライベートマイナー

*Protocol Developers: Bitcoin Core Developers