ビットコインのレイヤー2ネットワークの聖杯：内観と誓約

Photo of cd cdLast Updated: 7月 13, 2024
1 minute read

イーサリアムのようなチューリング完全なブロックチェーンと比べると、ビットコインのスクリプト言語はかなり制限されており、基本的な操作しかできず、掛け算や割り算の関数さえ欠けていると考えられている。さらに重要なことに、ブロックチェーン自身のデータはスクリプトにほとんどアクセスできないため、柔軟性とプログラマビリティに大きな制限がある。そのため、ビットコインスクリプトのイントロスペクションを可能にする方法が長い間模索されてきた。

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

現在、Bitcoinスクリプトには、イントロスペクションをサポートする3つの主要なオペコードしかない：CHECKLOCKTIMEVERIFY、CHECKSEQUENCEVERIFY、CHECKSIG です。CHECKSIGには、CHECKSIGVERIFY、CHECKSIGADD、CHECKMULTISIG、CHECKMULTISIGVERIFYなど、いくつかのバリエーションがあります。

規約はトークンの譲渡方法に関する制限である。ユーザーはコベナンツを通じてUTXOがどのように分配されるかを指定することができ、その多くはイントロスペクションオプコードを使用して実装されている。現在、Bitcoin Optechはイントロスペクションをコベナントエントリーに分類している。

ビットコインには現在2つの特約がある：CSV (CheckSequenceVerify)とCLTV (CheckLockTimeVerify)であり、どちらも時間ベースのコベナンツであり、ライトニングネットワークのような多くのスケーリングソリューションの基盤を形成している。このことは、ビットコインのスケーリング・ソリューションがイントロスペクションと誓約に大きく依存していることを示している。

トークン譲渡に条件を追加する方法

暗号の世界では、最も一般的な方法はコミットメントによるもので、多くの場合ハッシュを使って実装されている。譲渡条件が満たされていることを証明するため、検証には署名メカニズムが使われる。そのため、誓約にはハッシュと署名の調整が数多く含まれる。

以下は、広く議論されているコヴェナント・オペコードの提案である：

CTV（チェックテンプレートベリファイ） BIP-119

BIP-119 に含まれるCTV（CheckTemplateVerify）は、大いに議論されているビットコインのアップグレードである。CTVは、出力スクリプトがnVersion、nLockTime、scriptSigハッシュ、入力カウント、シーケンスハッシュ、出力カウント、出力ハッシュ、入力インデックスなどのフィールドを含む支出トランザクションのテンプレートを指定することを可能にします。これらのテンプレート制限は、ハッシュコミットメントを通じて実装され、今後の支出スクリプトは、支出トランザクション内の指定されたフィールドのハッシュ値が入力スクリプト内のものと一致するかどうかをチェックする。これらのテンプレートは基本的に、将来のUTXOトランザクションの時間、方法、 金額を定義する。

注目すべきは、入力TXIDがハッシュコミットメントから除外されていることである。レガシー・トランザクションでもSegwitトランザクションでも、デフォルトのSIGHASH_ALL署名タイプを使用する場合、TXIDはscriptPubKey値に依存するため、この除外が必要です。TXIDを含めると、循環的な依存関係が生じ、ハッシュコミットメントを構築できなくなります。

CTVは、新しいオペコードを通じて指定されたトランザクション情報を直接取得し、それをハッシュ化し、スタック上のコミットメントと比較することでイントロスペクションを実現する。この方法はオンチェーンでの空間消費は少ないが、柔軟性に欠ける。

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

CTVは当初、ビットコインの輻輳を緩和するために提案されたもので、輻輳制御とも呼ばれる。輻輳が高い期間中、CTVは単一のトランザクションを通じて将来の複数のトランザクションをコミットすることができ、輻輳中に複数のトランザクションをブロードキャストする必要性を回避し、輻輳が緩和された後に実際のトランザクションを完了する。これは交換実行時に大きく役立つ可能性がある。さらに、テンプレートを使って金庫を実装することができ、資金の行き先があらかじめ決められているため、ハッカーによる攻撃を防ぐことができ、ハッカーがCTVスクリプトを使ってUTXOをアドレスに送ることが不可能になる。

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

アポ(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つの入力にコミットする必要がある。

そのため、BIP 118はSIGHASH_ANYPREVOUTを導入した。APO署名は、使用済みの入力UTXO（PREVOUTと呼ばれる）にコミットする必要はなく、出力にのみ署名することで、ビットコイン制御に高い柔軟性を提供する。トランザクションを事前に構築し、対応する1回限りの署名と公開鍵を作成することで、その公開鍵アドレスに送信されたアセットは事前に構築されたトランザクションを通じて使用されなければならず、規約が達成される。

APOの柔軟性は取引の修復にも利用できる。手数料が低いために取引がチェーン上で立ち往生した場合、新たな署名を必要とせずに、手数料を増やすために別の取引を簡単に作成することができる。さらに、マルチシグネチャーのウォレットでは、使用済みの入力に依存しない署名により、運用がよりシンプルになる。

scriptPubKeyと入力TXIDの間の循環的な依存関係を排除することで、APOはウィットネスに出力データを追加することでイントロスペクションを実現できるが、これにはまだ追加のウィットネスデータ領域が必要である。

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

APOの主な批判は、新しい鍵のバージョンが必要で、既存のシステムと互換性がないことだ。さらに、新しい署名のハッシュ・タイプは、潜在的な二重支出リスクをもたらすかもしれない。コミュニティでの広範な議論の結果、APOはオリジナルの署名に加えて通常の署名を要求するようになり、セキュリティ上の懸念が緩和され、BIP-118番号を獲得した。

op_vault bip-345

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

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

OP_VAULTはどのようにして割り込み可能なタイムロック引き出しを実現しているのか？

簡単に言うと、OP_VAULTオプコードは、使用済みのOP_VAULTスクリプトを指定の スクリプトに置き換え、MASTの1つのリーフノードを更新し、残りは変更しない。これはTLUVに似ているが、内部キーの更新をサポートしていない。

スクリプトの更新中にテンプレートを導入すると、支払効果を制限することができる。時間ロックパラメータはOP_VAULTによって指定され、CTVオペコードによってもたらされるテンプレートは、そのスクリプトパスを通して費やされる出力のセットを制限する。

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

BIP-345でデータ保管庫を実装するには、特にリカバリ・トランザクションの手数料問題を考慮する必要がある。考えられる解決策としては、CPFP (Child Pays for Parent)、一時アンカー、SIGHASH_GROUP のような新しい署名ハッシュフラグなどがある。

TLUV (TapleafUpdateVerify)

TLUVスキームはTaprootを中心に構築され、共有UTXOからの効率的な終了の問題を解決することを目的としている。指針となる原則は、Taproot出力が使用されたときに、Taprootアドレスの内部構造と暗号変換を使用して、TLUVスクリプトによって記述された更新手順に従って内部鍵とMASTを部分的に更新し、それによって契約機能を実現することである。

TLUVスキームのアイデアは、新しいオペコードTAPLEAF_UPDATE_VERIFYを通じて、現在の支出入力に基づいて新しいタプロットアドレスを作成することである：

  • 内部公開鍵の更新
  • メルクルパスをトリミングする
  • 現在実行中のリーフノードを削除する
  • メルクルパスの末尾に新しいリーフノードを追加する。

具体的には、TLUVは3つの入力を受け取る：

  1. 内部公開鍵の更新方法に関する仕様書
  2. メルクルパスの新しいリーフノード
  3. 現在のリーフノードを削除するかどうか、および／または、いくつのMerkleパスのリーフノードを削除するかの指定。

TLUV opcodeは、更新されたscriptPubKeyを計算し、現在の入力に対応する 出力がそのscriptPubKeyに費やされているかどうかを検証する。

TLUVの着想はコインプールにある。今日、共同プールは事前署名トランザクションを使用して作成することができるが、パーミッションレス・エグジットを実現したい場合、指数関数的に増加する署名を作成する必要がある。TLUVは事前署名トランザクションなしでパーミッションレス・エグジットを可能にする。例えば、パートナーのグループがTaprootを使って共有UTXOを構築し、資金をプールするとする。彼らはTaprootキーを使用して内部的に資金を移動したり、共同で署名して外部への支払いを行うことができます。個人はいつでも共有プールから抜けることができ、支払い経路を削除することができる一方、他のメンバーは残りのメンバーに関する追加情報を公開することなく、元の経路で支払いを完了し続けることができる。この方法は、プールされていないトランザクションと比較して、より効率的でプライベートです。

TLUVオペコードは、元のMASTを更新することにより、部分的な支出制限を実現する。しかし、これは出力量のイントロスペクションを実現しない。従って、新しいオペコード IN_OUT_AMOUNT が必要である。このオペコードは、スタック上に2つのデータをプッシュする：この入力のUTXOの金額と対応する出力金額である。TLUVを使用する人は、次に数学演算子を使用して、更新されたscriptPubKeyに資金が適切に保存されているかどうかを検証することが期待される。

ビットコインの金額はサトシで表され、最大51ビットを必要とするが、スクリプトでは32ビットの数学演算しかできないため、出力金額のイントロスペクションには別の複雑さが加わる。このため、オペコードの動作を再定義するか、IN_OUT_AMOUNTの代わりにSIGHASH_GROUPを使用して、スクリプト内の演算子をアップグレードする必要があります。

TLUVは非中央集権的なレイヤー2コインプールのソリューションを提供すると期待されているが、Taprootの公開鍵を調整する点での信頼性についてはさらなる確認が必要だ。

MATT

MATT（Merkleize All The Things）は、3つの目標を達成することを目指している：Merkleizingステート、Merkleizingスクリプト、Merkleizing実行である。

  • メルクル化状態: Merkle Trieを構築する。各リーフノードは状態のハッシュであり、Merkle Rootは契約状態全体を表す。
  • メルクル化スクリプト: タプスクリプトで構成されるMASTで、各リーフノードは状態遷移の可能性のあるパスである。
  • メルクル化の実行: 暗号化されたコミットメントと不正チャレンジメカニズムによって実現される。任意の計算関数について、参加者はオフチェーンで計算し、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関数をシミュレートするために暗号コミットメントと不正チャレンジメカニズムを使用することで、Bitcoin上でトラストレスなロールアップを実現する。

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

csfs (op_checksigfromstack)

APOオペコードの紹介から、OP_CHECKSIG（および関連するオペレーション）がトランザク ションのアセンブル、ハッシュ化、署名検証を担当することがわかっている。しかし、OP_CHECKSIG が検証するメッセージは、このオペコードを使用したトランザクショ ン直列化から派生したものであり、他のメッセージを指定することはできない。簡単に言えば、OP_CHECKSIG（および関連する操作）は、トランザクション入力としての UTXO が署名保持者によって使用されることを許可されていることを検証する役割を果たし、その結果ビットコインのセキュリティを保護する。

CSFSはその名の通り、スタックから署名をチェックする。CSFSオペコードはスタックから署名、メッセージ、公開鍵の3つのパラメータを受け取り、署名の有効性を検証する。つまり、どのようなメッセージでも証人データを介してスタックに渡され、CSFSによって検証される可能性があり、ビットコインのいくつかの革新を可能にする。

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

OP_CATはトランザクションの異なるフィールドを連結してシリアライズを完了することができるため、CSFSは OP_CATとともに出現することが多く、イントロスペクションのためにトランザクションフィールドをより正確に選択することができる。OP_CATがないと、スクリプトは個別にチェック可能なデータからハッシュを再計算できないため、ハッシュが特定の値と一致するかどうかしかチェックできない。

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

txhash (op_txhash)

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

TXHASHとCTVは類似しているため、この2つについてはコミュニティで広範な議論がなされてきた。

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

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

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

TXHASHに関連するBIPは、現在Githubのドラフト状態であり、まだ番号が割り当てられていない。

OP_CAT

OP_CATは、セキュリティ上の懸念からサトシ・ナカモトによって非推奨とされた、少々謎めいたオペコードである。しかし、最近になってビットコインのコア開発者の間で広範な議論が巻き起こり、オンラインコミュニティではミームにまでなっている。最終的にOP_CATはBIP-347として承認され、多くの人が近い将来可決される可能性が最も高いBIP提案と呼んでいる。

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

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

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

シュナー署名では、署名されるメッセージは以下のフィールドで構成される：

  • バージョン
  • ロックタイム
  • 入力数
  • 出力カウント
  • 入力のリスト（それぞれ前のトランザクションのハッシュ、インデックス、スクリプトの長さ、スクリプト、シーケンスを含む）
  • 出力のリスト（それぞれ値、スクリプトの長さ、スクリプトを含む）

これらのフィールドには、トランザクションの主要な要素が含まれる。これらを scriptPubKey または witness に配置し、OP_CAT と OP_SHA256 を使用することで、シュナー署名を構築し、OP_CHECKSIG で検証することができる。検証に合格すると、スタックは検証済みのトランザクションデータを保持し、トランザク ションのイントロスペクションを可能にする。これにより、トランザクションの入力、出力、宛先アドレス、関係するビットコイン金額など、トランザク ションの様々な部分を抽出して「検査」することができる。

より詳細な暗号原理については、Andrew Poelstraの記事 “CAT and Schnorr Tricks “を参照のこと。

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

結論

ビットコインを拡大し、そのプログラマビリティを強化するための様々な戦略を模索する中で、進むべき道には、ネイティブな改良、オフチェーンでの計算、複雑なスクリプト機能の組み合わせが必要であることが明らかになった。

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

オフチェーンでの計算スケーラビリティは未来のものだが、ビットコインのプログラマビリティは、スケーリングをよりよくサポートし、真の世界通貨となるために突破しなければならない。

しかし、ビットコインの計算はイーサリアムの計算とは根本的に異なる。ビットコインは計算の一形態として「検証」のみをサポートしているのに対し、イーサリアムは基本的に計算であり、検証は副産物である。この違いは、イーサリアムが取引に失敗した場合にガス料金を請求するのに対し、ビットコインは請求しないことからも明らかだ。

コントラクトは、計算ではなく検証に基づくスマートコントラクトの一形態を実現する。コントラクトについては、一部の厳格なサトシ原理主義者を除けば、ほとんどの人がコントラクトはビットコインを改善するための良い選択だと考えている。しかし、コミュニティでは、コントラクトを実装するためにどの方式を使うべきかが常に議論されている。

APO、OP_VAULT、TLUVは直接的なアプリケーションに傾いている。これらを選択することで、特定のアプリケーションをより安価かつ効率的に実装することができる。ライトニング・ネットワークの愛好者は、LN対称性を実現するAPOを好む。保管庫を作成したい場合はOP_VAULTを使用するのが最善であり、コインプールを構築する場合はTLUVの方がよりプライベートで効率的である。OP_CATとTXHASHはより一般的で、セキュリティの脆弱性が少なく、他のオペコードとの組み合わせによってより多くのユースケースを実現することができます。CTVとCSFSはブロックチェーン処理のアプローチを調整した：CTVは遅延出力を実装し、CSFSは遅延署名を実装している。MATTは比較的ユニークで、楽観的実行と不正証明を使っており、一般的なスマート・コントラクトを実現するためにMerkle Trie構造に依存している。

ビットコインコミュニティはすでにソフトフォークによるコントラクト導入の可能性について激しく議論していることがわかる。Starknetはビットコインエコシステムへの参入を正式に発表し、OP_CATのマージから6カ月以内にビットコインネットワーク上で決済を実装する予定です。Chakraは今後もビットコインエコシステムの最新動向を監視し、OP_CATソフトフォークマージを推進し、イントロスペクションやコントラクトがもたらすプログラマビリティを利用して、より安全で効率的なビットコイン決済レイヤーを構築していきます。

Photo of cd cdLast Updated: 7月 13, 2024
1 minute read