概要

イーサリアムなどのチューリング完全なブロックチェーンと比較して、ビットコインのスクリプトは非常に制約があり、基本的な操作しか行えず、乗算や除算のサポートも欠落しています。さらに重要なことは、ブロックチェーンのデータ自体がスクリプトにほぼアクセスできないため、柔軟性やプログラム性において大きな制約が生じています。そのため、ビットコインのスクリプトに対して自己検査を可能にするための長期的な取り組みが行われています。

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

現時点では、ビットコインスクリプトのサポートされている内部調査を行うための主要なオペコードは、checklocktimeverify、checksequenceverify、およびchecksigsとその変種であるchecksigverify、checksigadd、checkmultisig、checkmultisigverifyのみです。

契約とは、単純に言えば、コインの送金方法に制限を設け、ユーザーがutxoの配布方法を指定できるようにすることを指します。多くの契約は内省オペコードを介して実装され、内省に関する議論は現在、契約のトピックに分類されています。Bitcoinオプテック.

ビットコインには現在、csv（CheckSequenceVerify）とcltv（CheckLockTimeVerify）の2つの契約があります。これは、ビットコインのスケーリングソリューションの多くにとって基盤となる時間ベースの契約であり、ライトニングネットワークなどの多くのスケーリングソリューションに重要です。これは、ビットコインのスケーリングソリューションが内省と契約に重点を置いていることを示しています。

コインの送金に条件を追加するにはどうすればよいですか?クリプトスフィアでは、最も一般的な方法はコミットメントによるもので、多くの場合、ハッシュを介して実装されます。転送要件が満たされていることを証明するには、検証のための署名メカニズムも必要です。したがって、ハッシュと署名に対する多くの調整がコベナンツ内に存在します。

以下では、広く議論されている契約のオペコード提案について説明します。

ctv (checktemplateverify) bip-119

ctv (チェックテンプレート検証)は、bip-119に含まれるビットコインのアップグレード提案であり、コミュニティの注目を集めています。ctvは、トランザクションの資金を使用するためのテンプレートを出力スクリプトで指定できるようにします。テンプレートには、nversion、nlocktime、scriptsigハッシュ、入力カウント、シーケンスハッシュ、出力カウント、出力ハッシュ、入力インデックスなどのフィールドが含まれます。これらのテンプレート制約は、ハッシュのコミットメントを介して実装され、資金が使用されると、スクリプトは入力スクリプト内の指定されたフィールドのハッシュ値が支払いトランザクションのハッシュ値と一致するかどうかをチェックします。これにより、そのUTXOの将来のトランザクションの時間、方法、金額が制約されます。

特に、入力のtxidはこのハッシュから除外されます。この除外は必要です。なぜなら、レガシーおよびSegWitトランザクションの両方で、デフォルトのsighash_all署名タイプを使用する場合、txidはscriptpubkey内の値に依存するためです。txidを含めると、ハッシュのコミットメントに循環依存関係が生じ、構築が不可能になります。

ctvは、ハッシュ化するために指定されたトランザクション情報を直接取得し、スタック上のコミットメントと比較することによって内省を実装します。この内省の方法はチェーンスペースへの負荷が少ないですが、柔軟性には欠けています。

ビットコインのレイヤー2ソリューションであるライトニングネットワークの基盤は、事前に署名されたトランザクションです。事前署名は通常、条件が満たされるまでトランザクションを生成および署名するが、ブロードキャストは行わないことを指します。基本的に、CTVはより厳格な形式の事前署名を実装し、事前署名のコミットメントをチェーン上に投稿し、事前定義されたテンプレートに制限されます。

ctvは、ビットコインの混雑緩和を目的として最初に提案されたもので、混雑制御とも呼ばれます。高い混雑時には、ctvは1つのトランザクション内で複数の将来のトランザクションを確定することができ、ピーク時に複数のトランザクションをブロードキャストする必要がなく、実際のトランザクションは混雑が緩和された後に完了します。これは、取引所の銀行ランに特に役立ちます。さらに、テンプレートはハッキング攻撃から保護するための金庫の実装にも使用できます。資金の方向が事前に決定されているため、ハッカーはctvスクリプトを使用してutxoを自分のアドレスに送信することはできません。

CTV は、レイヤ 2 ネットワークを大幅に強化できます。たとえば、ライトニングネットワークでは、CTVは、単一のUTXOをCTVツリーに拡張し、1つのトランザクションと1つの確認で複数のステートチャネルを開くことで、タイムアウトツリーとチャネルファクトリの作成を可能にします。さらに、CTVはATLCを通じてARKプロトコルでのアトミック取引もサポートしています。

apo（sighash_anyprevout）bip-118

bip-118は、tapscriptのための新しい署名ハッシュフラグであり、sighash_anyprevoutとして知られるより柔軟な支出ロジックを容易にすることを目的としています。apoとctvは多くの類似点を共有しています。スクリプトパブリックキーと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が設定されている場合、指定された入力のみが署名されます。それ以外の場合、すべての入力が署名される必要があります。

明らかに、これらのSighashフラグは、1つの入力にコミットすることを必要とするSighash_anyonecanpayを含め、入力の影響を完全に除去しない。

したがって、BIP 118はsighash_anyprevoutを提案しています。APO署名は、使用済みの入力UTXO(PrevOutと呼ばれる)にコミットする必要はなく、出力に署名するだけでよいため、ビットコイン管理の柔軟性が高まります。トランザクションを事前に構築し、対応する 1 回限りの署名と公開鍵を作成することで、その公開鍵アドレスに送信された資産は、事前に構築されたトランザクションを通じて使用し、コベナンツを実装する必要があります。APOの柔軟性は、トランザクションの修復にも使用できます。手数料が低いためにトランザクションがチェーン上でスタックしている場合、別のトランザクションを簡単に作成して、新しい署名を必要とせずに手数料を増やすことができます。さらに、マルチシグニチャーウォレットの場合、使用済みのインプットに依存しないことで、操作がより便利になります。

スクリプトパブリックキーと入力トランザクションIDの間のサイクルを排除するため、APOはウィットネスに出力データを追加することで内観を行うことができますが、これには追加のウィットネススペースの消費が依然として必要です。

オフチェーンプロトコル、例えばライトニングネットワークやボールトに対して、APOは中間状態を保存する必要性を大幅に削減し、ストレージ要件と複雑さを大幅に減らします。APOの最も直接的なユースケースはeltooであり、チャネルファクトリーを簡素化し、軽量かつ安価なウォッチタワーを構築し、誤った状態を残すことなく単独の出口を可能にし、ライトニングネットワークのパフォーマンスを多方面で向上させます。APOはまた、CTV機能をシミュレートするために使用することもできますが、個人が署名と事前署名済みトランザクションを保存する必要があり、CTVよりもコストがかかり効率が低下します。

apoの主な批判は、既存のバージョンと後方互換性を持たせるだけでは実装できない新しいキーバージョンの必要性にあります。さらに、新しい署名ハッシュタイプは、二重支払いの潜在的なリスクをもたらす可能性があります。apoは、広範なコミュニティの議論の結果、セキュリティ上の懸念を軽減するために、元の署名メカニズムに定期的な署名を追加し、bip-118コードを取得しました。

op_vault bip-345

bip-345では、op_vaultとop_vault_recoverの2つの新しいオペコードの追加が提案されており、これらはctvと組み合わせることで、特定のコインの支出に遅延を強制するための特殊な契約を実装します。この遅延中に、以前に行われたトランザクションは回復パスを介して「元に戻す」ことができます。

ユーザーは、少なくとも2つのスクリプトを含む必要がある専用のタップルートアドレスを作成することで、バルトを作成できます。1つは、予想される引き出しプロセスを容易にするためのop_vaultオペコードを持ち、もう1つは、引き出しの完了前にいつでもコインを回収できるようにするop_vault_recoverオペコードを持ちます。

op_vaultは、割り込み可能なタイムロック付き引き出しをどのように実装していますか？ op_vaultは、使用済みのop_vaultスクリプトを指定されたスクリプトで置き換えることにより、マストの単一のリーフを更新し、残りのタップルートリーフノードを変更せずにこれを実現しています。この設計はtluvに似ていますが、op_vaultは内部キーの更新をサポートしていません。

スクリプトの更新プロセス中にテンプレートを導入することで、支払いを制限することができます。タイムロックパラメータはop_vaultで指定され、ctvオペコードのテンプレートは、このスクリプトパスを通じて支払われることができる出力のセットを制限します。

bip-345は、紙ウォレットや分散マルチシグなどの非常に安全な鍵を回復経路として使用し、定期的な支払いに一定の遅延を設定することで、ユーザーに安全な保管方法を提供するためにop_vaultとop_vault_recoverを活用しています。ユーザーのデバイスは常に保管庫からの支出を監視し、予期しない転送が発生した場合、ユーザーは回復を開始することができます。

vault via bip-345の実装には、特に回復トランザクションに対するコストの問題を考慮する必要があります。可能な解決策には、CPFP（Child Pays for Parent）、一時的なアンカー、および新しいSighash_Group署名ハッシュフラグが含まれます。

tluv (tapleafupdateverify)

TLUVスキームはTaprootを中心に構築されており、共有UTXOからの脱出の問題に効率的に対処することを目的としています。指針となる原則は、 Taprootアウトプットが使われると、 TLUVスクリプトで記述されているように、 暗号化変換とTaprootアドレスの内部構造を通じて、 内部キーとマスト(TapScript Trie)を部分的に更新できることです。これにより、誓約機能の実装が可能になります。

tluvスキームのコンセプトは、新しいtaprootアドレスを作成することで、現在の支出入力に基づくものであり、新しいopcode、tapleaf_update_verifyを導入することによって達成できます。これは、以下のいずれかのアクションを実行することによって実現できます:

1. 内部公開鍵を更新する
2. マークルパスをトリムする
3. 現在実行されているスクリプトを削除します
4. マークルパスの最後に新しいステップを追加します

具体的には、tluvは3つの入力を受け入れます:

1. 内部公開鍵を更新する方法を指定するものの一つ。
2. Merkleパスの新しいステップを指定するもの。
3. 現在のスクリプトを削除するかどうか、およびメルクルパスのトリムするステップ数を指定するもの

tluvオペコードは、更新されたScriptPubKeyを計算し、現在の入力に対応する出力がこのScriptPubKeyに支払われていることを検証します。

tluvはcoinpoolの概念に触発されています。現在は予め署名されたトランザクションのみを使用して共同プールを作成できますが、許可されていない出口を実現するには指数関数的に増加する数の署名を作成する必要があります。しかし、tluvでは予め署名することなく許可されていない出口を可能にします。例えば、パートナーのグループはタップルートを使って共有UTXOを構築し、資金をプールすることができます。タップルートキーを使って内部で資金を移動したり、共同で署名して外部の支払いを開始したりすることができます。個々の参加者はいつでも共有資金プールから退出し、自分の支払い経路を削除することができますが、他の人々は元の経路を通じて支払いを完了することができ、個々の退出は他の参加者に関する追加の情報を公開しません。このモードは非プールトランザクションと比較して効率的でプライベートです。

tluvオペコードは、元のtaprootトライを更新することで部分的な支出制限を実現しますが、出力金額の内省は実装されていません。したがって、新しいオペコードであるin_out_amountが必要です。このオペコードは、スタックに2つのアイテムをプッシュします：この入力のUTXOの金額と対応する出力の金額、その後、tluvを使用している人々は、資金が適切に更新されたスクリプト公開鍵に保持されていることを数学演算子を使用して検証することを期待されています。

アウトプット金額の内省は、サトシ単位の金額は最大51ビットが必要ですが、スクリプトは32ビットの数学演算しか許可していないため、複雑さが増します。これには、スクリプト内のオペレータをアップグレードするためにオペコードの動作を再定義するか、sighash_groupを使用してin_out_amountを置き換える必要があります。

tluvは、分散型のレイヤー2の資金プールの解決策としての潜在能力を持っていますが、タップルートのトライを微調整する信頼性はまだ確認が必要です。

マット

matt（すべてのものをマークライズする）は、3つの目標を達成することを目指しています：ステートのマークライズ、スクリプトのマークライズ、実行のマークライズです。これにより、ユニバーサルスマートコントラクトが可能になります。

1. ステートのメルクル化: これはメルクルツリーを構築することを意味し、各葉ノードがステートのハッシュを表し、メルクルルートが契約の全体的なステートを具現化します。
2. スクリプトのマークル化：これは、タップスクリプトを使用してマストを形成することを指し、各葉ノードが可能な状態遷移パスを表す。
3. 実行のマークル化：実行は暗号的コミットメントおよび詐欺チャレンジメカニズムを介してマークル化されます。 任意の計算関数について、参加者はオフチェーンで計算し、その後コミットメントを公開できます、f(x)=y。 他の参加者が誤った結果、f(x)=zを見つけた場合、彼らはチャレンジを開始できます。 仲裁は、楽観的ロールアップの原理と同様に、バイナリサーチングを介して行われます。

実行のマーク化

実装マットには、ビットコインスクリプト言語には次の機能が必要です:

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

第2のポイントは重要です：動的データとは、支出者が提供する入力データによって状態が計算されることを意味します。これにより、次の状態と追加データを決定することができる、状態マシンのシミュレーションが可能になります。マットスキームは、以前に提案されたop_checkoutputcontractverifyおよびop_checkinputcontractverifyオペコードの統合であるop_checkcontractverify（op_ccv）オペコードを使用し、追加のフラグパラメータを使用して操作のターゲットを指定します。

出力金額の制御：最も直接的な方法は直接の内省です。ただし、出力金額は64ビットの数値であり、64ビットの算術演算が必要であり、ビットコインのスクリプティングにおいて複雑さを引き起こします。op_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（および関連する操作）は、署名の仕組みを介して、トランザクションの入力として支出されるUTXOが署名の保持者によって支出が許可されているかどうかを検証し、ビットコインのセキュリティを保護する役割を果たしています。

名前が示すように、csfsはスタックから署名を確認します。csfsオペコードは、スタックから署名、メッセージ、公開鍵の3つのパラメーターを受け取り、署名の有効性を確認します。これにより、人々はウィットネスを介してスタックに任意のメッセージを渡し、csfsを介して検証することができ、ビットコイン上でいくつかの革新が可能になります。

csfsの柔軟性により、支払い署名、認可委任、オラクル契約、二重支払い保護債などのメカニズムを実装することができます。そして、もっと重要なのは、トランザクションの内部観察です。トランザクション内の内容がop_checksigによって使用され、ウィットネスを介してスタックにプッシュされ、同じ公開鍵と署名をop_csfsとop_checksigの両方で検証し、両方の検証が成功した場合、op_csfsに渡された任意のメッセージ内容は、op_checksigで暗黙的に使用されるシリアライズされた支出トランザクション（およびその他のデータ）と同じです。その結果、スタック上に検証されたトランザクションデータを取得し、他のオペコードで支出トランザクションに制限を適用するために使用することができます。

csfsは、op_catと共に頻繁に現れます。なぜなら、op_catはトランザクションの異なるフィールドを接続してシリアル化を行うことができ、内省に必要なトランザクションフィールドをより正確に選択することができるからです。op_catがないと、スクリプトは個別にチェックできるデータからハッシュを再計算することができないため、本当にできることはハッシュが特定の値に対応しているかどうかを確認することです。つまり、コインは単一の特定のトランザクションを介してのみ使用することができます。

csfsはcltv、csv、ctv、apoなどのオペコードを実装でき、これにより多目的な内省オペコードとなります。そのため、Bitcoin Layer2のスケーラビリティソリューションにも役立ちます。欠点は、csfsを使用した内省のために署名済みトランザクションの完全なコピーをスタックに追加する必要があり、これによりトランザクションのサイズが大幅に増加する可能性があります。これに対して、cltvやcsvのような単一目的の内省オペコードは最小限のオーバーヘッドしかなく、新しい特殊な内省オペコードを追加するたびにコンセンサスの変更が必要となります。

txhash (op_txhash)

op_txhashは、オペレーターが特定のフィールドのハッシュを選択してスタックにプッシュできるようにする直感的に有効なオペコードです。具体的には、op_txhashはスタックからtxhashフラグをポップし、そのフラグに基づいて（タグ付きで）txhashを計算し、その結果のハッシュをスタックに再度プッシュします。

txhashとctvの類似点により、コミュニティ内でこれら2つに関する議論がかなり発生しています。

txhashは、トランザクション手数料に関連する多くの問題に対処するために、支出トランザクションの一部を明示的に指定することができるより高度なトランザクションテンプレートを提供する、ctvの普遍的なアップグレードと考えることができます。他の契約オペコードとは異なり、txhashは証人に必要なデータのコピーを必要とせず、さらにストレージ要件を削減します。また、ctvとは異なり、txhashはnop互換性がなく、tapscriptでのみ実装することができます。txhashとcsfsの組み合わせは、ctvとapoの代替として機能することができます。

契約を構築する観点からは、txhashは「加算型契約」の作成により適しており、トランザクションデータのすべての部分をスタックにプッシュし、それらをハッシュして得られるハッシュが固定値と一致することを検証します。一方、ctvは「減算型契約」の作成により適しており、保持したいトランザクションデータのすべての部分をスタックにプッシュします。そして、固定された中間状態からローリングsha256 opcodeを使用してハッシュが開始され、トランザクションハッシュデータのプレフィックスをコミットする中間状態が生成されます。自由な部分はこの中間状態にハッシュされます。

txhash仕様で定義されたtxfieldselectorフィールドは、op_txなどの他のオペコードに展開されることが期待されています。

txhashに関連するBIPは現在GitHubでドラフト状態であり、番号が割り当てられていません。

op_cat

op_catは、もともと中本哲史によってセキュリティ上の懸念から放棄された謎に包まれたオペコードですが、最近ではコアビットコイン開発者の間で激しい議論を引き起こし、インターネット上でミーム文化さえも生み出しています。最終的に、op_catはBIP-347で承認され、最近では最も通過の可能性の高いBIP提案と呼ばれています。

実際、op_catの振る舞いは非常に単純であり、スタックから2つの要素を連結します。それが契約機能を有効にする方法は何ですか？

実際に、2つの要素を連結する能力は、強力な暗号化データ構造であるMerkle Trieに対応しています。Merkle Trieを構築するには、連結とハッシュ演算のみが必要であり、ハッシュ関数はBitcoinスクリプトで利用可能です。したがって、OP_CATを使用することで、理論的にBitcoinスクリプト内でMerkle証明を検証することができます。これは、ブロックチェーン技術における最も一般的な軽量検証方法の1つです。

前述のように、csfsはop_catの助けを借りて、普遍的な契約スキームを実装することができます。実際、csfsがなければ、schnorr署名の構造を活用して、op_cat自体がトランザクションの内部調査を実現することができます。

Schnorr署名では、署名する必要があるメッセージは次のフィールドで構成されています:

これらのフィールドには、トランザクションの主要な要素が含まれています。これらをスクリプトパブキーまたはウィットネスに配置し、op_catとop_sha256を組み合わせてシュナール署名を構築し、op_checksigを使用して検証することで、トランザクションの内部を調査することができます。検証が成功すると、スタックには検証済みのトランザクションデータが保持され、トランザクションの入力、出力、対象アドレス、または関連するビットコインの金額など、さまざまな部分を抽出して「確認」することができます。

特定の暗号原理については、アンドリュー・ポエルストラの「Cat and Schnorr Tricks」という記事を参照することができます。

要約すると、op_catの汎用性により、ほとんど任意の契約のopcodeをエミュレートすることができます。多くの契約のopcodeは、op_catの機能に依存しており、その位置を著しく向上させています。理論的には、op_catと既存のBitcoinのopcodeのみに依存して、信頼度の高いBTCのZKロールアップを構築できることを期待しています。StarkNet、Chakra、他のエコシステムパートナーは、これを実現するために積極的に取り組んでいます。

結論

ビットコインのスケーリングとプログラムの多様な戦略を探索するにつれて、ネイティブの改良、オフチェーンの計算、洗練されたスクリプト機能の組み合わせが前進するための明確な道筋となることが明らかになります。

柔軟な基盤層がなければ、より柔軟な第2層を構築することは不可能です。

オフチェーン計算スケーリングは将来の方向性ですが、ビットコインのプログラム可能性はこのスケーラビリティをよりよくサポートし、真のグローバル通貨になるために突破する必要があります。

ただし、ビットコイン上の計算の性質は、イーサリアム上の計算とは根本的に異なります。ビットコインは「検証」の形式の計算のみをサポートし、一般的な計算を実行することはできません。一方、イーサリアムは本質的に計算可能であり、検証は計算の副産物です。この違いは、1つのポイントから明らかです：イーサリアムは、実行に失敗したトランザクションにガス料金を請求しますが、ビットコインはそうしません。

契約は計算ではなく検証に基づくスマートコントラクトの一形態を表しています。数少ないサトシ原理主義を除いて、誰もが契約をビットコインを改善する良い選択肢と考えているようです。しかし、コミュニティは依然として、契約を実装するためにどのアプローチを使用すべきかについて激しく議論を続けています。

APO、op_vault、およびTLUVは直接アプリケーションに傾いており、それらを選択することで、より安価で効率的な方法で特定のアプリケーションを実現できます。ライトニングネットワークの愛好家は、LN対称性を実現するためにAPOを好みます。Vaultの実装を検討している人は、op_vaultが最適です。コインプールを構築するために、TLUVはより多くのプライバシーと効率を提供します。op_cat と txhash はより用途が広く、セキュリティの脆弱性が発生する可能性が低く、他のオペコードと組み合わせることで、より多くのユースケースを実装できますが、スクリプトの複雑さが軽減される可能性があります。CTVとCSFSはブロックチェーン処理を調整し、CTVは遅延出力を実装し、CSFは遅延署名を実装しました。Mattは、楽観的な実行と不正防止の戦略で際立っており、Merkle Trieの構造を利用してユニバーサルスマートコントラクトを実装していますが、それでも内省的な機能のために新しいオペコードが必要です。

ビットコインコミュニティは、ソフトフォークによる契約の取得可能性について積極的に議論していることがわかります。スタークネットは、Op_Catの統合後6ヶ月以内にビットコインネットワークでの決済実装を計画し、公式にビットコインエコシステムへの参入を発表しました。チャクラはビットコインエコシステムの最新動向を引き続き監視し、Op_Catソフトフォークの統合を推進し、契約によってもたらされるプログラム性を活用して、より安全で効率的なビットコイン決済層を構築していく予定です。

免責事項：

1. この記事は[から転載されましたミラー].すべての著作権は元の著者に帰属します。[チャクラ]. if there are objections to this reprint, please contact the ゲートラーンチームがすぐに対応します。
2. 免責事項：本記事に表明された見解や意見は、著者個人のものであり、投資アドバイスを意味するものではありません。
3. 他の言語への記事の翻訳はGate.ioの学習チームによって行われます。特に言及されていない限り、翻訳された記事のコピー、配布、または盗作は禁止されています。