ビットコインのレイヤー2ネットワークの重要性：内省と制約

チューリング完全なブロックチェーン、例えばイーサリアムと比べると、ビットコインのスクリプト言語は大幅に制限されており、基本的な操作しかできません。さらに、乗算や除算の機能も欠いています。特に、ブロックチェーン自体のデータはスクリプトからほとんどアクセスできず、柔軟性とプログラマビリティに重大な制約をもたらしています。そのため、ビットコインスクリプトに内省を可能にする方法が長らく求められてきました。

内省とは、ビットコインスクリプトがトランザクションデータを検査し、制約を加える能力を指します。これにより、スクリプトは特定のトランザクション詳細に基づいて資金の使用を制御し、より複雑な機能を実現できます。現在のビットコインのオペコードのほとんどは、ユーザーが提供したデータをスタックにプッシュするか、既にスタックにあるデータを操作します。しかし、内省オペコードは現在のトランザクションデータ（例えばタイムスタンプ、金額、トランザクションIDなど）をスタックにプッシュし、UTXOの支出をより詳細に制御することが可能です。

現在、ビットコインスクリプトで内省をサポートする主要なオペコードは3つだけです：

• CHECKLOCKTIMEVERIFY
• CHECKSEQUENCEVERIFY
• CHECKSIG

CHECKSIGにはいくつかのバリアントがあり、CHECKSIGVERIFY、CHECKSIGADD、CHECKMULTISIG、およびCHECKMULTISIGVERIFYが含まれます。

制約（コベナント即ち契約）とは、トークンの移転方法に制限を加えるものです。ユーザーは制約を通じてUTXOの分配方法を指定でき、その多くは内省オペコードを使用して実装されています。現在、ビットコインオプテックは内省を制約エントリに分類しています。

ビットコインには現在、2つの制約が存在します：CSV（CheckSequenceVerify）とCLTV（CheckLockTimeVerify）です。どちらも時間ベースの制約であり、ライトニングネットワークなど多くのスケーリングソリューションの基盤を形成しています。これは、ビットコインのスケーリングソリューションが内省と制約に大きく依存していることを示しています。

ビットコインの技術的進化とそのスケーリングソリューションに関心を持つ皆様にとって、これらの内省と制約の役割は極めて重要です。最新の動向を追い続け、暗号通貨の未来を見据えた知識を深めることが求められます。ビットコインの内省と制約（契約）に関するさらなる情報をお見逃しなく。

トークン移転に条件を追加する方法

暗号通貨の世界では、最も一般的な方法はコミットメントを通じて行われ、多くの場合、ハッシュを使用して実装されます。移転条件が満たされていることを証明するために、署名メカニズムが検証に使用されます。したがって、制約にはハッシュと署名の数多くの調整が関与します。

以下は、広く議論されている制約オペコードの提案です：

CTV (CheckTemplateVerify) BIP-119

BIP-119に含まれるCTV (CheckTemplateVerify)は、非常に議論されているビットコインのアップグレードです。CTVは、出力スクリプトに対して、nVersion、nLockTime、scriptSigハッシュ、入力数、シーケンスハッシュ、出力数、出力ハッシュ、入力インデックスなどのフィールドを含む取引テンプレートを指定することを可能にします。これらのテンプレート制限はハッシュコミットメントを通じて実装され、将来の取引スクリプトは、指定されたフィールドのハッシュ値が入力スクリプト内のハッシュ値と一致するかどうかを確認します。これらのテンプレートは、将来のUTXO取引の時間、方法、金額を基本的に定義します。

暗号通貨における最新の動向や技術的進展に注目し続け、暗号通貨の未来を見据えた知識を深めることが求められます。ビットコインの制約に関するさらなる情報をお見逃しなく。

特に、入力TXIDはハッシュコミットメントから除外されています。この除外は、レガシーやSegwit取引のいずれの場合でも、TXIDがデフォルトのSIGHASH_ALL署名タイプを使用する際にscriptPubKeyの値に依存するため必要です。TXIDを含めると循環依存が発生し、ハッシュコミットメントの構築が不可能になります。

CTVは新しいオペコードを通じて指定された取引情報を直接取得し、それをハッシュしてスタック上のコミットメントと比較することで内省を実現します。この方法はオンチェーンスペースを節約しますが、柔軟性には欠けます。

ライトニングネットワークのようなセカンドレイヤーソリューションの基盤は、事前に署名された取引です。事前署名とは、通常、取引を事前に生成し署名することを意味しますが、特定の条件が満たされるまでそれを放送しません。基本的に、CTVはより厳格な事前署名機能を実装し、事前に署名されたコミットメントを直接オンチェーンに公開し、予め定義されたテンプレートに従った取引のみを許可します。

CTVはビットコインの混雑を緩和するために初めて提案され、混雑制御とも呼ばれます。混雑が激しい時期に、CTVは単一の取引を通じて複数の将来の取引をコミットし、混雑時に複数の取引を放送する必要を回避し、混雑が緩和した後に実際の取引を完了させることができます。これにより、取引所の混雑時に大いに役立ちます。さらに、テンプレートは、ハッカー攻撃を防ぐために、資金の送金先を事前に決定するボールトの実装にも使用できます。これにより、CTVスクリプトを使用してUTXOをハッカーのアドレスに送信することが不可能になります。

CTVはセカンドレイヤーネットワークを大幅に改善できます。例えば、ライトニングネットワークでは、CTVを使用してタイムアウトツリーやチャネルファクトリーを実装することで、単一のUTXOがCTVツリーに拡張され、オンチェーンの取引と確認を一回だけで複数のステートチャネルを開くことができます。さらに、CTVはArkプロトコルにおけるアトミック取引（ATLC）もサポートします。

CTVはビットコインのネットワーク効率を向上させ、混雑を緩和するための強力なツールです。その技術的進化と可能性に注目し、暗号通貨の未来を見据えた知識を深めることが求められます。CTVに関するさらなる情報をお見逃しなく。

APO（SIGHASH_ANYPREVOUT）BIP-118

BIP-118は、より柔軟な支出ロジックを記述するために、タップスクリプト用の新しい署名ハッシュフラグであるSIGHASH_ANYPREVOUTを提案しています。APOとCTVは多くの点で類似しています。scriptPubKeyとTXIDの間の循環依存性に対処するために、APOの解決策は関連する入力情報を除外し、出力のみを署名することで、取引が動的に異なるUTXOに結びつくことを可能にします。

論理的には、検証操作であるOP_CHECKSIG（およびその関連オペコード）には3つの機能があります：

1. 支出取引の各部分を組み立てる。
2. これらの部分をハッシュ化する。
3. ハッシュが指定されたキーで署名されているかどうかを確認する。

署名の具体的な内容は大幅に調整可能であり、どの取引フィールドが署名されるかはSIGHASHフラグによって決まります。BIP 342の署名オペコードの定義によると、SIGHASHフラグにはSIGHASH_ALL、SIGHASH_NONE、SIGHASH_SINGLE、およびSIGHASH_ANYONECANPAYなどが含まれます。SIGHASH_ANYONECANPAYは入力を制御し、他のフラグは出力を制御します。

SIGHASH_ALLはデフォルトのSIGHASHフラグであり、すべての出力に署名します。SIGHASH_NONEは出力に署名せず、SIGHASH_SINGLEは指定された出力のみに署名します。SIGHASH_ANYONECANPAYは他の3つのフラグと組み合わせて設定でき、設定されると指定された入力のみに署名します。設定されない場合、すべての入力に署名する必要があります。

これらのSIGHASHフラグのいずれも、入力の影響を完全に排除することはできません。SIGHASH_ANYONECANPAYですら、1つの入力に対するコミットメントを必要とします。

APOは、ビットコイン取引の柔軟性と効率を向上させるための強力なツールであり、その技術的進化と将来の可能性に注目することが重要です。SIGHASH_ANYPREVOUTに関するさらなる情報をお見逃しなく。

したがって、BIP 118はSIGHASH_ANYPREVOUTを導入します。APO署名は消費された入力UTXO（PREVOUTと呼ばれる）にコミットする必要がなく、出力のみを署名するため、ビットコインの制御においてより高い柔軟性を提供します。取引を事前に構築し、対応する使い捨て署名と公開鍵を作成することで、その公開鍵アドレスに送られた資産は事前に構築された取引を通じてのみ消費され、制約を実現します。

APOの柔軟性は、取引の修復にも利用できます。取引が低い手数料のためにオンチェーンで詰まった場合、新しい署名を必要とせずに手数料を増やすための別の取引を簡単に作成できます。さらに、マルチシグウォレットの場合、消費された入力に依存しない署名は操作を簡素化します。

scriptPubKeyと入力TXIDの間の循環依存性を排除することで、APOは証人に出力データを追加することで内省を実現できますが、これには追加の証人データスペースが必要です。

ライトニングネットワークやボールトのようなオフチェーンプロトコルにおいて、APOは中間状態の保存の必要性を減らし、ストレージ要件と複雑さを大幅に低減します。APOの最も直接的な使用例はEltooであり、チャネルファクトリーの簡素化、軽量で安価なウォッチタワーの構築、誤った状態を残さずに一方的な退出を可能にし、ライトニングネットワークのパフォーマンスを向上させます。APOはCTVの機能をシミュレートできますが、署名と事前署名取引の個人保管が必要であり、CTVよりもコストが高く効率が低いです。

APOの主な批判は、新しい鍵バージョンが必要であり、既存のシステムと互換性がないことです。さらに、新しい署名ハッシュタイプは二重支出のリスクをもたらす可能性があります。広範なコミュニティの議論の後、APOは元の署名に加えて通常の署名を必要とし、セキュリティの懸念を軽減し、BIP-118の番号を獲得しました。

APOに関するさらなる情報とその影響について、暗号通貨の未来を見据えた最新の知識を提供し続けます。ビットコインの進化とその技術的な展開に注目してください。

OP_VAULT BIP-345

BIP-345は、新しいオペコードであるOP_VAULTとOP_VAULT_RECOVERを提案しており、CTVと連携して専用の制約を実装し、指定されたトークンの支出に対して遅延期間を設け、その期間中に「リカバリーパス」を通じて支出を取り消すことができるようにします。

ユーザーは特定のTaprootアドレスを設定し、MASTに少なくとも2つのスクリプトを含めることでボールトを作成できます。一つは予想される引き出しプロセスを容易にするためのOP_VAULTスクリプト、もう一つは引き出し完了前にコインの回収を確保するためのOP_VAULT_RECOVERスクリプトです。

OP_VAULTはどのようにして中断可能なタイムロック付きの引き出しを実現するのか？

簡単に言えば、OP_VAULTオペコードは消費されたOP_VAULTスクリプトを指定されたスクリプトに置き換え、MASTの単一リーフノードを更新し、他の部分は変更せずに保持します。これはTLUVに似ていますが、内部キーの更新をサポートしません。

スクリプトの更新時にテンプレートを導入することで、支払いの影響を制限できます。タイムロックパラメータはOP_VAULTによって指定され、CTVオペコードによって導入されたテンプレートは、そのスクリプトパスを通じて支出される出力のセットを制限します。

BIP-345はボールト向けに設計されており、ユーザーが高度に安全なリカバリーパス（ペーパーウォレット、分散型マルチシグネチャ）を持ちながら、日常的な支払いのために支出遅延を設定できるようにします。ユーザーのデバイスはボールトの支出を継続的に監視し、不正な送金が発生した場合には回収を可能にします。

BIP-345を使用してボールトを実装する際には、特に回収トランザクションに関する手数料の問題を考慮する必要があります。可能な解決策としては、CPFP（子が親のために支払う）、一時的なアンカー、新しい署名ハッシュフラグ（SIGHASH_GROUP）などがあります。

OP_VAULTとその関連機能についてさらに詳しい情報を提供し、暗号通貨の未来を見据えた最新の知識をお届けします。ビットコインの技術的進化に注目し、その可能性を共に探求しましょう。

TLUV（TapleafUpdateVerify）

TLUVスキームはTaprootを基盤としており、共有UTXOから効率的に退出する問題を解決することを目的としています。基本原則は、Taproot出力が消費されるとき、TLUVスクリプトで記述された更新手順に従ってTaprootアドレスの内部構造と暗号変換を使用して内部キーとMASTを部分的に更新することで、契約機能を実現することです。

TLUVスキームの考え方は、新しいオペコードTAPLEAF_UPDATE_VERIFYを通じて現在の支出入力に基づいて新しいTaprootアドレスを作成し、次のいずれかまたは複数の操作を実行できるようにすることです：

• 内部公開鍵の更新
• マークルパスのトリム
• 現在実行中のリーフノードの削除
• 新しいリーフノードをマークルパスの末尾に追加

具体的には、TLUVは以下の3つの入力を取ります：

1. 内部公開鍵の更新方法に関する仕様
2. マークルパス用の新しいリーフノード
3. 現在のリーフノードを削除するかどうか、および/または削除するマークルパスリーフノードの数に関する仕様

TLUVオペコードは更新されたscriptPubKeyを計算し、現在の入力に対応する出力がそのscriptPubKeyに消費されたかどうかを確認します。

TLUVのインスピレーションはコインプールから得ています。現在、共同プールは事前署名取引を使用して作成できますが、許可不要の退出を実現するには、指数関数的に増加する署名を作成する必要があります。TLUVは事前署名取引なしで許可不要の退出を可能にします。例えば、パートナーグループがTaprootを使用して共有UTXOを構築し、資金をプールします。彼らはTaprootキーを使用して内部で資金を移動したり、共同で署名して外部への支払いを行うことができます。個々のメンバーはいつでも共有プールから退出でき、その支払いパスを削除できますが、他のメンバーは追加の情報を公開することなく、元のパスを通じて支払いを完了し続けることができます。この方法は、非プール取引と比べてより効率的でプライバシー保護に優れています。

TLUVとその関連機能についてさらに詳しい情報を提供し、暗号通貨の未来を見据えた最新の知識をお届けします。ビットコインの技術的進化に注目し、その可能性を共に探求しましょう。

TLUV（TapleafUpdateVerify）オペコードは、元のMASTを更新することで部分的な支出制限を実現します。しかし、出力額の内省は実現しません。そのため、新しいオペコードであるIN_OUT_AMOUNTが必要となります。これは、スタックに2つのデータ、すなわちこの入力のUTXOの額と対応する出力額をプッシュします。TLUVを使用する人は、その後、数値演算子を用いて更新されたscriptPubKey内で資金が適切に保存されているかどうかを確認することが求められます。

出力額の内省はさらに複雑さを増します。というのも、ビットコインの額はサトシで表され、最大51ビットを必要としますが、スクリプトは32ビットの数値演算しか許可していません。これにより、オペコードの動作を再定義するか、IN_OUT_AMOUNTを置き換えるためにSIGHASH_GROUPを使用することで、スクリプト内の演算子をアップグレードする必要があります。

TLUVは分散型のレイヤー2コインプールに対するソリューションを提供することが期待されていますが、Taproot公開鍵の調整に関する信頼性についてはさらに確認が必要です。

TLUVおよび関連する新機能についての詳細な情報を提供し、ビットコインの未来を見据えた最新の知識をお届けします。暗号通貨の技術的進化とその可能性に注目し続けてください。

MATT

MATT（Merkleize All The Things）は、以下の3つの目標を達成することを目指しています：状態のMerkle化、スクリプトのMerkle化、実行のMerkle化です。これにより、一般的なスマートコントラクトが実現されます。

状態のMerkle化: 各リーフノードが状態のハッシュであるMerkleトライを構築し、Merkleルートが全体のコントラクト状態を表します。

スクリプトのMerkle化: 各リーフノードが可能な状態遷移パスであるTapscriptで構成されたMASTを作成します。

実行のMerkle化: 暗号コミットメントと不正チャレンジメカニズムを通じて実現されます。任意の計算関数に対して、参加者はオフチェーンで計算を行い、コミットメントf(x)=yを公開します。他の参加者が結果f(x)=zを見つけた場合、これにチャレンジでき、バイナリサーチを通じて仲裁が行われます。これは、Optimistic Rollupの原則に似ています。

MATTを達成するためには、ビットコインプログラミングスクリプトに以下の機能が必要です：

1. 特定のスクリプトを出力に強制する（およびその金額）
2. データを出力に添付する
3. 現在の入力（または他の入力）からデータを読み取る

2つ目のポイントは重要です。動的データは、支出者が提供する入力データを通じて状態計算を可能にし、状態機械をシミュレートし、次の状態と添付データを決定するためです。MATTは、以前提案されたOP_CHECKOUTPUTCONTRACTVERIFYおよびOP_CHECKINPUTCONTRACTVERIFYオペコードを組み合わせ、操作の対象を指定するための追加のフラグパラメータを持つOP_CHECKCONTRACTVERIFY（OP_CCV）オペコードを提案します。

出力額の制御: 最も直接的な方法は直接内省です。しかし、出力額は64ビットの数値であり、64ビットの操作を必要とするため、ビットコインスクリプトの実装には複雑さが加わります。CCVは、OP_VAULTに似た遅延チェックを採用し、すべての入力の入力額を合計し、CCVをその出力額の下限として同じ出力に割り当てます。このチェックは、入力スクリプトの評価中ではなく、取引プロセスに遅延されます。

不正証明の一般性を考えると、MATTコントラクトのいくつかのバリアントは、すべての種類のスマートコントラクトまたはレイヤー2構築を実現するべきですが、追加要件（資本のロックインやチャレンジ期間の遅延など）の正確な評価が必要です。例えば、暗号コミットメントと不正チャレンジメカニズムを使用してOP_ZK_VERIFY機能をシミュレートし、ビットコイン上で信頼のないRollupsを実現することが可能です。

実際には、すでに進行中のことがあります。Johan Torås Halsethは、MATTソフトフォーク提案のOP_CHECKCONTRACTVERIFYオペコードを使用してelftraceを実装し、RISC-Vコンパイルをサポートするすべてのプログラムをビットコインチェーン上で検証できるようにしました。これにより、契約プロトコルのためのネイティブなビットコイン検証ブリッジが可能になります。

CSFS（OP_CHECKSIGFROMSTACK）

APOオペコードの導入から、OP_CHECKSIG（および関連操作）がトランザクションの組み立て、ハッシュ化、および署名検証を担当していることがわかります。しかし、検証されるメッセージはこのオペコードを使用してトランザクションのシリアライゼーションから派生したものであり、他のメッセージを指定することはできません。簡単に言うと、OP_CHECKSIG（および関連操作）は、UTXOがトランザクション入力として署名保有者によって消費することが認可されていることを検証し、ビットコインのセキュリティを保護する役割を果たします。

CSFSはその名の通り、スタックからの署名をチェックします。CSFSオペコードはスタックから3つのパラメータ、すなわち署名、メッセージ、および公開鍵を取り、署名の有効性を検証します。これにより、任意のメッセージを証人データを通じてスタックに渡し、CSFSで検証することが可能となり、ビットコインにおけるいくつかの革新を実現します。

CSFSの柔軟性により、支払い署名、権限委譲、オラクル契約、ダブルスペンド防止ボンドなどの様々なメカニズムを実装することができ、さらに重要なのはトランザクションの内省を可能にすることです。CSFSを使用したトランザクション内省の原理は非常にシンプルです。OP_CHECKSIGで使用されるトランザクション内容が証人を通じてスタックにプッシュされ、同じ公開鍵と署名を使用してCSFSとOP_CHECKSIGの両方で検証が行われ、両方が通過した場合、CSFSに渡される任意のメッセージの内容が、OP_CHECKSIGによって暗黙的に使用されるシリアル化された支出トランザクション（およびその他のデータ）と同じであることになります。これにより、スタック上で検証されたトランザクションデータを取得し、他のオペコードで支出トランザクションに制約を適用することができます。

CSFSは、OP_CATと一緒に使用されることがよくあります。OP_CATはトランザクションの異なるフィールドを連結してシリアル化を完了し、トランザクションフィールドをより正確に選択して内省を行うことができるからです。OP_CATがなければ、スクリプトは個別にチェック可能なデータからハッシュを再計算することができないため、ハッシュが特定の値と一致するかどうかしかチェックできず、コインは単一の特定のトランザクションを通じてのみ消費されることになります。

CSFSはCLTV、CSV、CTV、APOのようなオペコードを実現することができ、一般的な内省オペコードであるため、ビットコインのレイヤー2スケーリングソリューションにも寄与します。その欠点は、署名されたトランザクションの完全なコピーをスタックに追加する必要があり、CSFSを内省に使用したいトランザクションのサイズを大幅に増加させる可能性があることです。これに対して、CLTVやCSVのような単一目的の内省オペコードは最小限のオーバーヘッドしかありませんが、新しい特別な内省オペコードを追加するには合意変更が必要です。

CSFSとその関連機能についての詳細な情報を提供し、ビットコインの未来を見据えた最新の知識をお届けします。暗号通貨の技術的進化に引き続きご注目ください。

TXHASH（OP_TXHASH）

OP_TXHASHは非常にシンプルな内省オペコードであり、オペレーターがフィールドのハッシュを選択し、それをスタックにプッシュすることを可能にします。具体的には、OP_TXHASHはスタックからtxhashフラグをポップし、そのフラグに基づいて（フラグ付きの）txhashを計算し、結果のハッシュをスタックにプッシュします。

TXHASHとCTVの類似性から、コミュニティ内で両者についての広範な議論が行われてきました。

TXHASHはCTVの一般的なアップグレードと見なすことができ、より高度なトランザクションテンプレートを提供し、ユーザーが支出トランザクションの部分を指定できるようにすることで、トランザクション手数料に関連する多くの問題を解決します。他の契約オペコードとは異なり、TXHASHは証人に必要なデータのコピーを提供する必要がないため、ストレージニーズをさらに削減します。CTVとは異なり、TXHASHはNOP互換ではなく、tapscriptでのみ実装できます。TXHASHとCSFSの組み合わせは、CTVおよびAPOの代替と見なすことができます。

契約の構築に関しては、TXHASHは、固定したいトランザクションデータのすべての部分をスタックにプッシュし、それらを一緒にハッシュ化して結果が固定値と一致するかどうかを確認することで「加算契約」を達成しやすくします。CTVは、自由にしておきたいトランザクションデータのすべての部分をスタックにプッシュし、固定された中間状態から開始するローリングOP_SHA256を使用することで「減算契約」を達成しやすくします。その中間状態はトランザクションハッシュデータプレフィックスをコミットします。自由な部分はその中間状態にハッシュされます。

TXHASH仕様で定義されたTxFieldSelectorフィールドは、OP_TXなどの他のオペコードに拡張されることが期待されています。

TXHASHに関連するBIPは現在Githubでドラフトステータスにあり、まだ番号が割り当てられていません。

TXHASHおよび関連機能についての詳細な情報を提供し、ビットコインの未来を見据えた最新の知識をお届けします。暗号通貨の技術的進化に引き続きご注目ください。

OP_CAT

OP_CATは、サトシ・ナカモトによってセキュリティの懸念から廃止された、やや謎めいたオペコードです。しかし、最近になってビットコインのコア開発者の間で広範な議論を巻き起こし、オンラインコミュニティではミームにさえなっています。最終的に、OP_CATはBIP-347として承認され、近いうちに最も通過する可能性の高いBIP提案として多くの人々に注目されています。

実際、OP_CATの動作は非常にシンプルです。それはスタック上の2つの要素を1つに連結するだけです。しかし、これがどのように契約機能を実現するのでしょうか？

2つの要素を連結する機能は、Merkle Trieと呼ばれる強力な暗号データ構造に対応します。Merkle Trieの構築には連結とハッシュ化の操作だけが必要で、これらはビットコインスクリプトで利用可能です。したがって、OP_CATを使用すれば、理論的にはビットコインスクリプトでMerkle証明を検証することができ、これはブロックチェーンにおける最も一般的な軽量検証方法です。

前述のように、CSFSはOP_CATを使用して一般的な契約スキームを実現することができます。実際、CSFSがなくても、Schnorr署名の構造により、OP_CAT自体がトランザクション内省を実現できます。

Schnorr署名では、署名されるメッセージは以下のフィールドで構成されます：

• バージョン
• ロックタイム
• 入力数
• 出力数
• 入力のリスト（各入力には前のトランザクションハッシュ、インデックス、スクリプトの長さ、スクリプト、シーケンスが含まれます）
• 出力のリスト（各出力には値、スクリプトの長さ、スクリプトが含まれます）

これらのフィールドはトランザクションの主要な要素を含んでいます。これらをscriptPubKeyまたは証人に配置し、OP_CATおよびOP_SHA256を使用してSchnorr署名を構築し、OP_CHECKSIGで検証することができます。検証が通過すれば、スタックには検証されたトランザクションデータが残り、トランザクション内省が可能になります。これにより、入力、出力、送金先アドレス、または関連するビットコインの金額など、トランザクションのさまざまな部分を抽出して「検査」することができます。

詳細な暗号理論については、アンドリュー・ポエルストラの「CAT and Schnorr Tricks」の記事を参照してください。

まとめると、OP_CATの柔軟性は、ほぼすべての契約オペコードを模倣することができ、多くの契約オペコードがその機能に依存しています。これにより、OP_CATはマージリストでの地位を大幅に向上させます。理論的には、OP_CATと既存のビットコインオペコードだけで、信頼最小化されたBTC ZK Rollupを構築することができます。Starknet、Chakra、およびその他のエコシステムパートナーがこれを実現するために積極的に取り組んでいます。

OP_CATおよびその関連機能についての詳細な情報を提供し、ビットコインの未来を見据えた最新の知識をお届けします。暗号通貨の技術的進化に引き続きご注目ください。

結論

ビットコインの拡張とそのプログラマビリティの向上を目指す様々な戦略を探る中で、ネイティブな改良、オフチェーン計算、複雑なスクリプト機能の組み合わせが前進の鍵であることが明らかになってきました。

柔軟なベースレイヤーがなければ、より柔軟なセカンドレイヤーを構築することは不可能です。

オフチェーン計算のスケーラビリティが将来の方向性である一方で、ビットコインのプログラマビリティは突破口を見つけ、スケーリングをより良くサポートし、真の世界通貨となる必要があります。

しかし、ビットコインの計算は根本的にイーサリアムの計算とは異なります。ビットコインは計算の一形態として「検証」をサポートするのみであり、一方、イーサリアムは根本的に計算を行い、検証はその副産物です。この違いは、イーサリアムが失敗したトランザクションに対してガス料金を請求するのに対し、ビットコインはそうしないことにも表れています。

契約は計算ではなく検証に基づくスマートコントラクトの一形態を実現します。契約に関しては、厳格なサトシ原理主義者を除けば、多くの人々がビットコインの改善に契約が良い選択肢であると考えています。しかし、コミュニティはどのスキームを使って契約を実装するかについて絶えず議論しています。

APO、OP_VAULT、およびTLUVは直接的なアプリケーションに傾倒しています。それらを選択することで、特定のアプリケーションをより安価かつ効率的に実装できます。ライトニングネットワークの支持者はAPOを好みます。なぜなら、APOはLN-シンメトリーを実現するからです。ボールトを作成したい場合は、OP_VAULTを使用するのが最善です。コインプールを構築するには、TLUVがよりプライベートで効率的です。OP_CATとTXHASHはより一般的であり、セキュリティ上の脆弱性が少なく、他のオペコードとの組み合わせにより多くのユースケースを実現できますが、スクリプトの複雑さが増す可能性があります。CTVとCSFSはブロックチェーンの処理方法を調整しました。CTVは遅延出力を実装し、CSFSは遅延署名を実装します。MATTは比較的ユニークで、楽観的な実行と不正証明を使用し、Merkle Trie構造に依存して一般的なスマートコントラクトを実現しますが、内省機能を提供するために新しいオペコードが依然として必要です。

ビットコインコミュニティはすでにソフトフォークを通じて契約を導入する可能性について熱心に議論しています。Starknetはビットコインエコシステムへの参入を公式に発表し、OP_CATの統合から6か月以内にビットコインネットワーク上での決済を実装する予定です。Chakraはビットコインエコシステムの最新動向を引き続き監視し、OP_CATソフトフォークの統合を推進し、内省と契約がもたらすプログラマビリティを活用して、より安全で効率的なビットコインの決済レイヤーを構築していきます。

内省（Introspection）

内省は、ビットコインスクリプト内でトランザクションデータを検査し、その内容に基づいて動作を制御する技術です。ビットコインのスクリプト言語は通常、トランザクションの入力や出力を直接参照することができませんが、内省オペコードを用いることでこれが可能になります。内省により、トランザクションの特定のフィールド（例えば、タイムスタンプやトランザクションIDなど）をスタックにプッシュし、それを基に条件を検証できます。

例

• **CHECKLOCKTIMEVERIFY（CLTV）やCHECKSEQUENCEVERIFY（CSV）**は、特定の条件（時間やシーケンス）を満たすまでトランザクションの実行を遅延させる内省オペコードの一例です。
• **OP_CHECKSIGFROMSTACK（CSFS）**は、スタックから取り出したメッセージに対する署名を検証することで、任意のデータをチェックする内省オペコードです。

制約（Covenants）

制約（契約）は、トークンの移転に特定の制約や条件を設定するスクリプトのことです。コベナントを使うことで、ユーザーはUTXO（未使用トランザクション出力）の分配方法や使用条件を詳細に規定することができます。これにより、資金の不正使用を防止し、特定の用途に資金を確実に使用することができます。

例

• OP_VAULTは、資金の引き出しに一定の遅延を設け、その期間中に資金を回収できるようにする契約オペコードです。
• **CHECKTEMPLATEVERIFY（CTV）**は、特定のテンプレートに従ってトランザクションを作成することを強制するオペコードで、トランザクションの出力を予め定義された形式に制限します。

内省と制約の組み合わせ

内省と契約を組み合わせることで、ビットコインの取引はより柔軟かつ安全になります。内省オペコードを使用してトランザクションデータを検査し、そのデータに基づいて契約条件を評価・実行することが可能になります。

これにより、以下のような高度な機能が実現できます：

• 高度な資産管理: 資金の使用条件を詳細に設定し、特定の目的に対してのみ使用できるようにする。
• セキュリティの強化: 不正なトランザクションを防止するための条件付き承認プロセスの導入。
• スケーリングソリューション: ライトニングネットワークや他のレイヤー2ソリューションにおける効率的な資金管理と取引の実行。

ビットコインの進化とその未来に注目し、最新の知識を提供してまいります。暗号通貨の技術的進展に引き続きご期待ください。