ビットコインのプログラム可能性：詳細な制限条項

最近、ビットコインコミュニティでは特定のオペコードの再有効化に関する議論が盛り上がり、制限条項とビットコインのプログラム可能性に対する関心が高まっています。この記事では、制限条項について概観的な紹介と議論を行います。

制限条項とは

制限条項は、将来のビットコイン取引に条件を設定できるメカニズムです。現在のビットコインスクリプトがどのようにアンロックするかを制限するのとは異なり、制限条項はUTXOのその後の使用をさらに制限し、「専用の資金」を実現します。

制限条項は単に制限のためのものではなく、取引実行のルールを設定しています。ユーザーはあらかじめ設定されたルールに従って取引を実行し、所定のビジネスプロセスを完了することができます。これにより、むしろさらに多くのアプリケーションシーンを解放することができます。

! 詳細な契約:ビットコインのプログラマビリティを実現する方法は?

アプリケーションシーン

ステーキングペナルティの確保

Bitcoinのステーキングにおいて、制限条項は悪事を働くユーザーに対する罰則取引が強制的に実行されることを保証するために使用され、ユーザーが罰を逃れるのを防ぎます。

混雑コントロール

ネットワークが混雑している時、制限条項により送信者はまず一つのバッチ送信の取引にコミットし、手数料率が下がった時に具体的な取引を送信することができ、コストを削減することができます。

###ボールト

制限条項は、アカウントがハッキングされても資金の使用を制限できる、より安全な保管庫アプリケーションを構築することができます。

さらに強力で柔軟な状態チャネル

制限条項は、EltooやArkなどの新しい状態チャネル設計を実現でき、ライトニングネットワークなどをより堅牢で柔軟にします。

! 詳細な契約:ビットコインのプログラマビリティを実現する方法は?

制限条項の技術概要

制限条項には多様な実装技術があり、タイプ、実装方法、再帰性などの観点から分類できます。主流の制限条項設計にはOP_CTV、APO、OP_VAULTなどがあります。

! 詳細な契約:ビットコインのプログラマビリティを実現する方法は?

制限条項の設計

制限条項の設計は、取引の"内省"、つまり取引自体の内容を確認する方法に主に焦点を当てています。主にオペコードベースと署名ベースの2つのアプローチがあります。

! 詳細な契約:ビットコインのプログラマビリティを実現する方法は?

APO ###

SIGHASH_ANYPREVOUT(APO)は、新しい署名方式で、取引の出力にのみ署名し、入力には署名しません。条件を満たすUTXOに事前署名された取引を柔軟に追加できます。

! 詳細な契約:ビットコインのプログラマビリティを実現する方法は?

OP_CTV

OP_CHECKTEMPLATEVERIFY(CTV)は、操作コードの改善により、ユーザーがビットコインの使用方法を制限できるようにします。これは、混雑制御や支出ツリーの構築などのシナリオに利用できます。

! 詳細な契約:ビットコインのプログラマビリティを実現する方法は?

OP_CAT

OP_CATはスタック内の2つの要素を連結でき、Merkleツリーの検証やSchnorr署名の強化など、さまざまな機能を柔軟に実現できます。

! 詳細な契約:ビットコインのプログラマビリティを実現する方法は?

まとめ

制限条項はビットコインスクリプトにおいて取引のさらなる支出を直接制限することができ、スマートコントラクトのような効果を実現します。このプログラム可能性はビットコイン上でよりネイティブに検証することができ、メインチェーンとチェーン外アプリケーションを改善し、新しいアプリケーションの方向性を開拓します。

しかし、制限条項は予期しない乱用や脆弱性を引き起こす可能性があるため、コミュニティはこれに対して慎重です。制限条項に関連するアップグレードは合意ルールのソフトフォークを含み、完了するまでに長い時間がかかる可能性があります。

! 詳細な契約:ビットコインのプログラマビリティを実現する方法は?