ビットコインレイヤー2ネットワークの聖杯：内省と契約
TechFlow厳選深潮セレクト
ビットコインレイヤー2ネットワークの聖杯：内省と契約
BTCエコシステムの人気契約操作コード提案：OP_CAT、CTV、APO、MATTを徹底解説
Web3業界の深掘り報道に専念し潮流を洞察執筆：Chakra Research
概要
イーサリアムなどのチューリング完全なブロックチェーンと比較して、ビットコインのスクリプトは非常に制限されており、基本的な操作しか行えず、乗算や除算さえサポートしていないとされている。さらに重要なのは、ブロックチェーン自体のデータがスクリプトからほとんど読み取れないため、柔軟性に欠け、プログラマビリティが低いことである。そのため長年にわたり、ビットコインのスクリプト（Script）に内省（Introspection）機能を持たせる方法が模索されてきた。
内省とは、ビットコインスクリプトがトランザクションデータを検査・制約できる能力を指す。これにより、スクリプトはトランザクションの詳細に基づいて資金の使用を制御し、より複雑な機能を実現できるようになる。現在のビットコインオペコード（Opcode）の多くは、ユーザーが提供したデータをスタックにプッシュするか、既存のスタックデータを操作するという二つの機能に限定されている。一方、内省オペコードは、現在のトランザクションデータ（タイムスタンプ、金額、トランザクションIDなど）をスタックにプッシュでき、UTXOの支出方法をより細かく制御できる。
現在のビットコインスクリプトでは、内省をサポートする主なオペコードは3つしかない：CHECKLOCKTIMEVERIFY、CHECKSEQUENCEVERIFY、CHECKSIG。なお、CHECKSIGにはCHECKSIGVERIFY、CHECKSIGADD、CHECKMULTISIG、CHECKMULTISIGVERIFYといった派生形もある。
「カヴェナント（Covenant）」とは、トークンの移転方法に対する制限であり、ユーザーがUTXOの分配方法を指定できる仕組みである。多くのカヴェナントは内省オペコードによって実現されており、現在Bitcoin Optechでは内省はカヴェナントの項目として議論されている。
ビットコインには現在2つのカヴェナントがある：CSV（CheckSequenceVerify）とCLTV（CheckLockTimeVerify）。これらはいずれも時間ベースのカヴェナントであり、ライトニングネットワークなど多くのスケーリングソリューションの基盤となっている。このことからも、ビットコインのスケーリングは極めて内省とカヴェナントに依存していることがわかる。
どのようにしてトークンの移転に制限をかけるのか？暗号世界では最も一般的な方法はコミットメント（Commitment）であり、通常ハッシュ（Hash）によって実現される。そして移転条件を満たしていることを証明するために、署名メカニズムによる検証が必要となる。そのため、カヴェナントには多くのハッシュおよび署名に関する調整が含まれている。
以下では、広く議論されているカヴェナントオペコードの提案について説明する。
CTV (CheckTemplateVerify) BIP-119
CTV（CheckTemplateVerify）は、BIP-119に含まれる、コミュニティで活発に議論されているビットコインアップグレードである。CTVは出力スクリプトが、その資金を使う際のトランザクションテンプレートを指定できるようにするもので、nVersion、nLockTime、scriptSig hash、input count、sequences hash、output count、outputs hash、input index などのフィールドを含む。これらのテンプレート制限はハッシュコミットメントによって実現され、将来の支出時にスクリプトが支出トランザクションの指定フィールドのハッシュ値と入力スクリプト内のハッシュ値が一致するかをチェックする。つまり、このテンプレートによって当該UTXOの将来の支出トランザクションの時間、方法、金額などが実質的に制限されることになる。
注目すべき点は、入力TXIDがハッシュコミットメントから除外されていることだ。これは必須の措置であり、LegacyまたはSegwitトランザクションにおいて、デフォルトのSIGHASH_ALL署名タイプでは、TXIDの生成にscriptPubKeyの値が依存するため、TXIDを含めるとハッシュコミットメントに循環が生じ、構築が不可能になってしまう。
CTVは新しいオペコードを通じて直接トランザクションの特定情報を取得しハッシュ化し、スタック上のコミットメントと比較することで内省を実現する。この方式はオンチェーンスペースの消費が少ないが、柔軟性にはやや欠ける。
ライトニングネットワークなどのビットコインレイヤー2ソリューションの基盤はプリサインされたトランザクションにある。プリサインとは、事前にトランザクションを生成・署名しておくが、一定の条件が満たされるまでネットワークにブロードキャストしないことを意味する。本質的に、CTVはより厳格なプリサイン機能を実現しており、そのコミットメントを直接チェーン上に公開し、あらかじめ定めたテンプレートに従ったトランザクションのみを許可する。
CTVは当初、ビットコインの混雑緩和（コンゲスチョンコントロール）のために提案された。ビットコインネットワークが混雑している場合、CTVを用いれば複数の将来のトランザクションを単一トランザクションでコミットでき、混雑時に多数のトランザクションをブロードキャストする必要がなくなる。ブロックの混雑が解消された後で、実際のトランザクションを完了すればよい。コンゲスチョンコントロールは、取引所の銀行runs（ジャッジリー）が発生した際に大きな助けとなる可能性がある。また、テンプレートは保険庫（Vault）の実装にも利用でき、ハッカー攻撃への防御にもなる。資金の行先が確定しているため、CTVスクリプトを使用するUTXOをハッカーが自分のアドレスに送金することはできない。
CTVはレイヤー2ネットワークに大きな改善をもたらすことができる。例えば、ライトニングネットワークにおけるTimeout Treesやチャネルファクトリーの実装では、CTVにより単一UTXOからCTVツリーを展開し、複数のステートチャネルを同時に開くことができる。オンチェーンでは1件のトランザクションと1回の確認で済む。また、CTVはArkプロトコルのアトミック取引ATLCにも支援を提供する。
APO (SIGHASH_ANYPREVOUT) BIP-118
BIP-118はtapscript向けに新たな署名ハッシュフラグSIGHASH_ANYPREVOUTを提案したもので、より柔軟な支出ロジックの記述を可能にする。APOはCTVと多くの点で類似しており、scriptPubKeysとTXIDの間の循環問題に対処するために、入力に関連する情報を除外し、出力のみを署名対象とする。これにより、異なるUTXOに動的にバインド可能なトランザクションが可能になる。
論理的には、署名検証オペレーションOP_CHECKSIG（および同種のオペコード）には以下の3つの機能がある：
-
支出トランザクションの各部分を組み立てる
-
それらをハッシュ処理する
-
そのハッシュが指定された鍵で署名されているか検証する
ここで署名の対象となる内容は大きく調整可能であり、どのトランザクションフィールドを組み込んで署名するかはSIGHASHフラグによって決定される。BIP 342の署名オペコード定義によれば、SIGHASHフラグにはSIGHASH_ALL、SIGHASH_NONE、SIGHASH_SINGLE、SIGHASH_ANYONECANPAYなどがあり、SIGHASH_ANYONECANPAYは入力を制御するもので、残りはすべて出力を制御する。
SIGHASH_ALLはデフォルトのSIGHASHフラグであり、すべての出力を署名対象とする。SIGHASH_NONEは出力を署名しない。SIGHASH_SINGLEは指定された1つの出力のみを署名する。SIGHASH_ANYONECANPAYは前述3つのSIGHASHフラグと併用可能で、これが設定されていると、指定された入力のみを署名対象とし、そうでなければすべての入力を署名しなければならない。
明らかに、これらのSIGHASHフラグでは入力の影響を排除できない。SIGHASH_ANYONECANPAYであっても、少なくとも1つの入力をコミットしなければならない。
そこでBIP 118はSIGHASH_ANYPREVOUT（APO）を提案した。APO署名は、支出される入力UTXO（PREVOUTと呼ぶ）をコミットする必要がなく、出力のみを署名すればよく、ビットコインの制御に高い柔軟性をもたらす。事前にトランザクションを構築し、対応するワンタイム署名と公開鍵を作成することで、その公開鍵アドレスに送られた資産は、あらかじめ構築されたトランザクションでのみ支出可能となり、カヴェナントを実現できる。APOの柔軟性はトランザクション修正にも使える。手数料が低すぎてチェーン上で滞っているトランザクションがあれば、新たに署名を得ることなく、手数料を高くした別のトランザクションを作成できる。また、マルチシグウォレットにおいても、支出入力に依存しない署名が可能になるため、操作が簡素化される。
scriptPubKeysと入力TXIDの間の循環が解消されたことで、APOは証人（Witness）にアウトプットデータを追加することで内省を実現できる。ただし、これは追加の証人データスペースを消費する。
ライトニングネットワークや保険庫などのオフチェーンプロトコルにおいて、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つのスクリプトを含める必要がある。1つは予定された出金プロセスを促進するOP_VAULTスクリプト、もう1つは出金完了前のいつでもコインを復元できるOP_VAULT_RECOVERスクリプトである。
OP_VAULTは、中断可能な時間ロック付き出金をどう実現するのか？簡単に言えば、OP_VAULTオペコードは、使用されたOP_VAULTスクリプトを指定されたスクリプトに置き換えるという処理を行う。これはMASTの単一リーフノードの更新に相当し、他のリーフノードは変更されない。TLUVと設計は似ているが、OP_VAULTは内部鍵の更新をサポートしない点が異なる。
スクリプト更新プロセスにテンプレートを導入することで、支払い制限を実現できる。ここで、時間ロックパラメータはOP_VAULTが指定し、CTVオペコードによるテンプレートがそのスクリプトパスで支出される出力集合を制限する。
BIP-345は保険庫専用に生まれたものであり、OP_VAULTとOP_VAULT_RECOVERを活用することで、ユーザーは安全なホスティング方法を持つことができる。高度にセキュアな鍵（ペーパーウォレット、分散型マルチシグ）をリカバリパスとし、日常的な支払いには一定の支出遅延を設定できる。ユーザーの端末は保険庫の支出状況を継続的に監視し、不正な移転が発生した場合はリカバリーが可能になる。
BIP-345が保険庫を実現する過程では、特にリカバリトランザクションの手数料問題を考慮する必要がある。これに対する実行可能な解決策には、CPFP、一時アンカー、SIGHASH_GROUPといった新しい署名ハッシュフラグなどがある。
TLUV (TapleafUpdateVerify)
TLUVはTaprootを中心に構築されたスキームであり、共有UTXOの効率的な退出問題を解決することを目指している。その思想は、Taproot出力が使用されるとき、TLUVスクリプトが記述する更新手順に従い、Taprootアドレスの内部構造と暗号学的変換を利用して、内部鍵とMASTを部分的に更新することで、カヴェナント機能を実現することにある。
TLUVのアイデアは、新しいオペコードTAPLEAF_UPDATE_VERIFYを通じて、以下の1つ以上の操作を実行することで、現在の支出入力に基づく新しいTaprootアドレスを作成することである：
-
内部公開鍵を更新する
-
メルクライトパスを剪定する
-
現在実行中のリーフノードを削除する
-
メルクライトパスの末端に新しいリーフノードを追加する
具体的には、TLUVは以下の3つの入力を受け取る：
-
内部公開鍵の更新方法を指定するもの
-
メルクライトパスに新しいリーフノードを指定するもの
-
現在のリーフノードおよび／または何個のメルクライトリーフノードを削除するかを指定するもの
TLUVオペコードは更新後のscriptPubKeyを計算し、現在の入力に対応する出力がそのscriptPubKeyに支出されているかを検証する。
TLUVの着想背景はコインプール（CoinPool）である。現在でもプリサイン済みトランザクションを使って共同プールを構築できるが、無許可の退出を実現したい場合、指数関数的に増加する署名数を作成する必要がある。一方、TLUVを使えば、プリサインなしで無許可の退出が可能になる。たとえば、複数の仲間がTaprootを使って共有UTXOを構築し、資金を束ねたとする。彼らは内部でTaproot鍵を使って資金を移動したり、共同署名で外部への支払いを行ったりできる。個人はいつでもこの共有プールから退出でき、自分の支払いパスを削除する。他のメンバーは従来のパスで支払いを続けられる。また、個人の退出は他のメンバーの追加情報を漏らさない。非プール化された取引と比べ、この方法はより効率的でプライバシーが高い。
TLUVオペコードは元のMASTの更新を通じて部分的な支出制限を実現したが、出力金額の内省は実現していない。そのため、新たなオペコードIN_OUT_AMOUNTが必要となる。これはスタックに2つのデータをプッシュする：この入力のUTXO金額と対応する出力金額。TLUV使用者は数学演算子を使って、更新されたscriptPubKey内で資金が適切に保持されているか検証することになる。
出力金額の内省はさらなる複雑性を伴う。ビットコインの金額はサトシ単位で最大51ビット必要だが、スクリプトでは32ビットの数学演算しか許可されていないため、オペコードの動作を再定義してスクリプトの演算子をアップグレードするか、IN_OUT_AMOUNTの代わりにSIGHASH_GROUPを使用する必要がある。
TLUVは分散型レイヤー2の資金プールにソリューションを提供する可能性を秘めているが、Taproot公開鍵のtweakに関しては信頼性がまだ確認されていない。
MATT
MATT（Merkleize All The Things）は以下の3つの目標を達成しようとする：状態のMerkle化、スクリプトのMerkle化、実行のMerkle化。これらを通じて汎用スマートコントラクトを実現する。
状態のMerkle化：各リーフノードが状態のハッシュ値であるMerkle Trieを構築し、Merkle Rootが全コントラクトの状態を表す。
スクリプトのMerkle化：Tapscriptで構成されるMAST。各リーフノードは可能な状態遷移パスを表す。
実行のMerkle化：暗号コミットメントと詐欺チャレンジ機構を通じて実行をMerkle化する。任意の計算関数に対して、参加者がオフチェーンで計算しコミットメントを発表する（f(x)=y）。他参加者が計算結果が誤っていると判断（f(x)=z）すると、チャレンジを発動し、二分探索法で仲裁を行う。これはOptimistic Rollupの原理と同じである。
Merkle化実行 欺詐チャレンジ
MATTを実現するためには、ビットコインのプログラミングスクリプトに以下の機能が必要である：
-
出力が特定のスクリプト（およびその金額）を持つことを強制する
-
データを出力に付加する
-
現在の入力（または他の入力）のデータを読み取る
第2点は極めて重要である。動的なデータにより、支出者が提供する入力データから状態を計算でき、これにより状態機械のシミュレーションが可能になり、次の状態と付加データを決定できる。MATTはOP_CHECKCONTRACTVERIFY（OP_CCV）オペコードを提案することでこれを実現する。これは以前提案されたOP_CHECKOUTPUTCONTRACTVERIFYおよびOP_CHECKINPUTCONTRACTVERIFYを統合したもので、追加のflagsパラメータで操作対象を指定できる。
出力金額の制御：最も直接的な方法は直接的な内省だが、出力金額は64ビット数であり、64ビット演算が必要となる。これはビットコインスクリプトでは実装が非常に複雑である。CCVはOP_VAULTと同様、遅延チェック方式を採用する。同一出力にCCVを持つすべての入力の金額を合計し、その出力金額の下限とする。遅延とは、このチェックがトランザクション処理中に、入力スクリプト評価時ではなく行われることを意味する。
詐欺証明の汎用性を考えると、MATTカヴェナントのいくつかの変形はすべての種類のスマートコントラクトやレイヤー2構築を実現できるはずである。ただし、資本のロックやチャレンジ期間の遅延といった追加要件の正確な評価が必要である。どのアプリケーションが許容可能な取引かを評価するためのさらなる研究が必要である。例えば、暗号コミットメントと詐欺チャレンジ機構を用いてOP_ZK_VERIFY関数を模倣し、ビットコイン上での信頼不要なRollupを実現できる。
実際、すでに動きが始まっている。Johan Torås Halsethは、MATTのソフトフォーク提案にあるOP_CHECKCONTRACTVERIFYオペコードを用いてelftraceを実現し、RISC-Vコンパイル対応プログラムすべてをビットコインチェーン上で検証可能にした。これにより、コントラクトプロトコルの一当事者が契約に基づいて資金を受け取るプロセスを、ビットコインネイティブな検証で橋渡しすることが可能になった。
CSFS (OP_CHECKSIGFROMSTACK)
APOオペコードの紹介で既に触れたように、OP_CHECKSIG（および関連オペコード）はトランザクションの組み立て、ハッシュ処理、署名検証の3つの責任を負う。しかし、それが検証するメッセージは、そのオペコードを使用するトランザクションのシリアライズ結果に固定されており、他のメッセージを指定できない。簡単に言えば、OP_CHECKSIG（および関連オペコード）は、署名メカニズムを通じて、トランザクション入力としてのUTXOが署名保持者に支出を許可されているかを検証することで、ビットコインの安全性を守っている。
CSFSはその名の通り、スタック（Stack）から署名を検証する。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のような単一目的の内省オペコードは最小限のオーバーヘッドで動作するが、新しい特殊内省オペコードを追加するたびにコンセンサス変更が必要になる。
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上でDraft状態であり、番号は未定である。
OP_CAT
OP_CATは謎めいた色彩を持つオペコードであり、元々中本聡によってセキュリティ上の理由で廃止されたが、最近になって多くのビットコインコア開発者の議論を呼び、インターネット上でのMeme文化さえ引き起こした。最終的にOP_CATはBIP-347を承認され、多くの人々から「最近で最も通過の可能性が高いBIP提案」と呼ばれている。
実際、OP_CATの挙動は非常に単純で、スタック上の2つの要素を1つに連結するだけである。どのようにしてカヴェナント機能を実現するのか？
実は、2つの要素を連結する機能は、強力な暗号データ構造であるMerkle Trieに対応している。Merkle Trieの構築には連結とハッシュの2つの操作だけで十分であり、ハッシュ関数はビットコインスクリプトで利用可能である。したがって、OP_CATがあれば理論上、ビットコインスクリプト内でMerkle Proofの検証が可能になる。これはブロックチェーンで最も一般的な軽量検証方式である。
前述したように、CSFSはOP_CATの助けを借りて汎用カヴェナントスキームを実現できる。実際、CSFSなしでも、Schnorr署名の構造を利用すれば、OP_CAT自身でトランザクションの内省を実現できる。
Schnorr署名では、署名対象のメッセージは以下のフィールドで構成される：
これらのフィールドはトランザクションの主要要素を含んでおり、それをscriptPubKeyまたは証人に配置し、OP_CATとOP_SHA256を使ってSchnorr署名を構築し、OP_CHECKSIGで検証できる。検証が通れば、スタック上に検証済みのトランザクションデータが残り、トランザクションの内省が実現され、入力、出力、宛先アドレス、関与するビットコイン金額など各部分を抽出・「検査」できる。
具体的な暗号原理については、Andrew Poelstraが発表した「CAT and Schnorr Tricks」の記事を参照されたい。
まとめると、OP_CATの柔軟性により、ほぼすべてのカヴェナントオペコードを模倣でき、多くのカヴェナントオペコードがOP_CATの機能に依存しているため、その合併リストでの位置は顕著に前進している。理論的には、OP_CATと既存のビットコインオペコードだけでも、信頼最小化のBTC ZK Rollupを構築できる。Starknet、Chakra、および他のエコシステムパートナーがこの実現に向けて積極的に推進している。
結論
我々がビットコインの拡張とプログラマビリティ向上のためのさまざまな戦略を探求する中で、前進する道はネイティブな改良、オフチェーン計算、複雑なスクリプト機能の組み合わせにあることが明らかである。
柔軟な基礎層がなければ、より柔軟なレイヤー2を構築することはできない。
オフチェーン計算によるスケーリングは未来の方向性だが、ビットコインのプログラマビリティに突破がなければ、スケーリングをより良く支援し、真の世界通貨になることはできない。
しかし、ビットコインの計算とイーサリアムの計算には本質的な違いがある。ビットコインは「検証」を唯一の計算形式としてサポートしており、汎用計算はできない。一方、イーサリアムは本質的に計算指向であり、検証は計算の副産物である。この差異は一点で明確に現れる：イーサリアムは失敗した取引に対してもガス形式の手数料を請求するが、ビットコインは請求しない。
カヴェナントは、計算ではなく検証に基づくスマートコントラクトの形態を実現している。カヴェナントについて、少数の中本教条主義者を除けば、誰もがカヴェナントがビットコインの改善策であると考えているようだ。しかし、どの方式でカヴェナントを実現するかについては、コミュニティ内で常に議論が続いている。
APO、OP_VAULT、TLUVはより直接的なアプリケーション志向であり、それらを選べば特定用途をより安価かつ効率的に実現できる。ライトニングネットワーク愛好家はLN-Symmetryを実現できるAPOを好むだろう。保険庫を実現したいなら、OP_VAULTを使うのが最良である。CoinPoolを構築するなら、TLUVの方がプライバシーと効率に優れる。OP_CAT、TXHASHはより汎用的であり、セキュリティホールの可能性も小さく、他のオペコードとの組み合わせでより多くのユースケースを実現できる。もちろん、スクリプトの複雑性という代償を払うかもしれない。CTVとCSFSはブロックチェーン処理プロセスに変更を加えており、CTVは遅延出力を、CSFSは遅延署名を実現している。MATTはやや異色で、楽観的実行と詐欺証明の思想を用い、Merkle Trie構造で汎用スマートコントラクトを実現しているが、依然として内省機能をもたらす新規オペコードが必要である。
我々は、ソフトフォークを通じてビットコインにカヴェナントをもたらす可能性について、ビットコインコミュニティが激しく議論しているのを見てきた。Starknetは正式にビットコインエコシステムに参入すると発表し、OP_CATマージ後6ヶ月以内にビットコインネットワーク上での決済を実現する計画を立てている。Chakraはビットコインエコシステムの最新動向を継続的に注視し、OP_CATソフトフォークのマージを推進するとともに、内省とカヴェナントがもたらすプログラマビリティを活用して、より安全で効率的なビットコイン決済レイヤーを構築していく。
本稿のレビューと提案に感謝：Jeffrey、Ben、Mutourend、Lynndell
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
@ChakraChain
