This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
ビットコイン制限条項：BTCの新しい世代のプログラム可能性を開放する
ビットコイン制限条項:プログラム可能性の新しい方向性
ビットコインコミュニティは最近、OP_CATなどのオペコードの再有効化について活発な議論を展開しています。Taproot Wizardは、Quantum Cats NFTのリリースやBIP-420番号の取得を主張することで、大量の注目を集めました。支持者は、OP_CATの有効化により「制限条項」を実現できるとし、ビットコインにスマートコントラクトとプログラム可能性をもたらすと述べています。
"制限条項"(covenants)この概念は開発者たちの間で何年にもわたって議論を引き起こしてきました。OP_CATの他にも、OP_CTV、APO、OP_VAULTなど、制限条項を実現するためのさまざまな技術的提案があります。では、ビットコインの"制限条項"とは何でしょうか？なぜこれほど広範で持続的な関心を引き起こすのでしょうか？それはビットコインにどのようなプログラム可能性をもたらすのでしょうか？その背後にある設計原理は何でしょうか？この記事では、これらの問題について概観的に紹介し、議論します。
! 詳細な契約:ビットコインのプログラマビリティを実現する方法は?
"制限条項"とは何ですか
"制限条項"(契約)は、将来のビットコイン取引に条件を設定できるメカニズムです。現在のビットコインスクリプトには、有効な署名の入力や要件を満たすスクリプトの提供など、いくつかの制限条件が含まれています。しかし、ユーザーがロックを解除できれば、UTXOを任意の場所で消費することができます。
そして、制限条項はこの基盤の上にさらに多くの制限を追加しました。たとえば、UTXOのその後の支出先を制限し、"専用用途"の効果を実現することや、取引の他の入力の条件を制限することなどです。
より正確に言えば、現在のビットコインスクリプトも一定の制限条項機能を備えており、例えばオペコードに基づくタイムロックがあります。取引のnLockまたはnSequenceフィールドをチェックすることによって、取引の支出前の時間制限を実現できます。しかし、現在は主に時間に関する制限に限られています。
開発者がこれらの制限チェックを設計した目的は、単に制限するためだけではなく、取引実行のルールを設定するためです。ユーザーはあらかじめ設定されたルールに従って取引を実行することしかできず、それによって予定されたビジネスプロセスを完了します。
したがって、制限条項は直感に反してより多くのアプリケーションシーンを解放することができます。
! 詳細な契約:ビットコインのプログラマビリティを実現する方法は?
アプリケーションシーン
ステーキングペナルティの確保
制限条項の直感的な例は、Babylonにおけるビットコインのステーキングにおけるスラッシュ取引です。
Babylonのビットコインステーキングプロセスは、ユーザーがBTC資産をメインチェーン上の特別なスクリプトに送信することであり、支出条件は2つ含まれています:
正常終了: 一定の時間が経過した後、ユーザーは自分の署名を使用してロックを解除し、unstakeプロセスを完了します。
罰金終了: ユーザーがBabylonのレンタルセキュリティのPoSチェーン上で二重署名などの悪行を行った場合、EOTS(を通じて一回限りの署名)を使用して資産を解除できます。ネットワーク内の実行役割が一部の資産を強制的に焼却アドレス(slash)に送信します。
ここでの「強制送信」とは、UTXOを解放できる場合でも、その資産を他の場所に自由に送信できず、焼却されるしかないことを意味します。これにより、不正なユーザーが既知の署名を使って資産を自分に戻すことができず、罰を逃れることができないようにします。
OP_CTVなどの制限条項が実装された後、ステーキングスクリプトの「ペナルティ終了」ブランチに関連する操作コードを追加して制限を実現できます。
そして、OP_CTVが有効になる前に、Babylonはユーザーと委員会が共同で実行する回避策を通じて制限条項の強制執行効果をシミュレートする必要があります。
! 詳細な契約:ビットコインのプログラマビリティを実現する方法は?
混雑抑制
ネットワークが混雑していると、トランザクションプールに大量の未処理トランザクションが蓄積され、ユーザーは迅速な確認を得るために手数料を引き上げる必要があります。ユーザーが複数の受取人に対して複数のトランザクションを送信しなければならない場合、より高いコストを負担せざるを得ず、同時にネットワーク全体の手数料率をさらに押し上げることになります。
制限条項がある場合、送信者は最初にバッチ送信取引を約束することができます。この約束により、すべての受信者は最終的に取引が実行されると信じることができ、手数料率が低下するのを待って具体的な取引を送信できます。
ブロックスペースの需要が非常に高いとき、取引は高価になります。OP_CHECKTEMPLATEVERIFYを使用することで、大規模な支払い処理業者は、すべての支払いを単一のO(1)トランザクションに集約して確認することができます。その後、ブロックスペースの需要が減少すると、そのUTXOから支払いを展開することができます。
これはOP_CTVという制限条項が提案する典型的な適用例の一つです。
! 詳細な契約:ビットコインのプログラマビリティを実現する方法は?
###ボールト
保管庫(vault)はビットコインアプリケーションで広く議論されているシナリオであり、特に制限条項の分野で重要です。日常の操作では、資金の保管と使用のニーズのバランスを取る必要があり、人々は資金の安全を保証し、アカウントがハッキングされた(場合でも私鍵の漏洩)があっても資金の使用を制限できるような保管金庫アプリケーションを望んでいます。
制限条項技術に基づいて、比較的容易に保管庫型アプリケーションを構築できます。
OP_VAULTプランの例として: 保管庫資金を使う際には、まず取引を1件オンチェーンで送信して意図("trigger")を示し、条件を設定する必要があります:
通常の場合: 2回目の取引は最終的な出金取引です。N個のブロックを待った後、資金を任意のアドレスにさらに使用できます。
異常な状況: 盗まれた取引(または脅迫)が発見された場合、N個のブロックの出金取引送信前に、資金をより安全なアドレスに即座に送信できます。
注意が必要です。制限条項がなくても、保管庫アプリを構築することはできます。一つの方法は、将来の支出のためにサインを準備するために秘密鍵を用意し、その後秘密鍵を破棄することです。しかし、この方法にはまだ限界があります。秘密鍵が破棄されたことを確認する必要があり、金額や手数料を事前に確定する必要があるなど、柔軟性に欠けます。
! 詳細な契約:ビットコインのプログラマビリティを実現する方法は?
より強靭で柔軟な状態チャネル
ステートチャンネル(は、ライトニングネットワーク)を含み、ノードが最新の状態を観測でき、正常に最新の状態をオンチェーンに公開できる場合、メインチェーンとほぼ同じ安全性を持つと見なされます。制限条項があることで、いくつかの新しいステートチャンネル設計は、ライトニングネットワークの基盤の上でより堅牢または柔軟になることができます。比較的有名なものには、EltooやArkなどがあります。
Eltoo(はLN-Symmetry)とも呼ばれ、典型的な例です。これは、フラッシュネットワークに実行層を提供し、どの後の通路状態が以前の状態を置き換えることを可能にし、罰則メカニズムなしで、したがってフラッシュネットワークノードが敵による悪行を防ぐために複数の以前の状態を保存する必要を回避できます。EltooはSIGHASH_NOINPUT署名方式、すなわちAPO(BIP-118)を提案して、この効果を実現します。
Arkは、ライトニングネットワークの入出流動性やチャネル管理の難易度を低下させることを目的としています。これは、複数のユーザーが一定期間内にサービスプロバイダーを取引相手として受け入れるjoinpool形式のプロトコルで、チェーン外で仮想UTXO(vUTXO)取引を行いますが、コストを削減するためにチェーン上で1つのUTXOを共有します。保管庫に似て、Arkは現在のビットコインネットワーク上でも実現可能ですが、制限条項を導入することで、Arkは取引テンプレートに基づいて必要な相互作用の量を減少させ、より信頼を必要としない片側の退出を実現します。
! 詳細な契約:ビットコインのプログラマビリティを実現する方法は?
制限条項の技術概要
上記のアプリケーションからわかるように、制限条項は特定の技術というよりも一種の効果のようであり、さまざまな実現方法があります。以下のいくつかの次元から分類できます:
その中で、再帰とは、制限条項の実現が次の出力を制限することによって次の出力を制限できることを指し、複数の取引にわたる制限を実現します。
主流の制限条項の設計には次のものが含まれます:
! 詳細な契約:ビットコインのプログラマビリティを実現する方法は?
制限条項の設計
現在のビットコインスクリプトは主にロック解除条件を制限しており、UTXOがどのようにさらに使用されるかは制限していません。制限条項を実現するためには、なぜ現在のスクリプトがこの機能を実現できないのかを再考する必要があります。
主要な理由は、現在のビットコインスクリプトが取引自体の内容、すなわち取引の"内省"(introspection)を読み取ることができないことです。
もし取引の内省——取引の任意の内容(を確認することができれば、出力)を含めて、制限条項を実現できる。
したがって、制限条項の設計は主に内省をどのように実現するかに関するものです。
! 詳細な契約:ビットコインのプログラマビリティを実現する方法は?
オペコードベース vs シグネチャベース
最も直接的な考え方は、1つまたは複数の操作コード(を追加することです。1つの操作コード+複数のパラメーター、または複数の異なる機能の操作コード)で、直接取引内容を読み取ることです。これが操作コードに基づく考え方です。
別のアプローチは、スクリプト内で取引の内容を直接読み取って確認するのではなく、取引内容のハッシュを利用することです——このハッシュが署名されている場合、スクリプト内でOP_CHECKSIGなどを改造することで、この署名を確認でき、取引の内省や制限条項を間接的に実現できます。これは署名に基づく設計方式で、主にAPOやOP_CSFSなどを含みます。
! 詳細な契約:ビットコインのプログラマビリティを実現する方法は?
APO ###
SIGHASH_ANYPREVOUT(APO)は提案されているビットコインの署名方式です。署名の最も簡単な方法は、取引の入力と出力の両方を約束することですが、ビットコインにはより柔軟な方法、つまりSIGHASHがあり、取引の中の入力または出力に対して選択的に約束することができます。
APOのSIGHASHは出力の署名のみを行い、入力部分の署名は行いません。これは、APO方式で署名された取引が、その後条件を満たす任意のUTXOに追加できることを意味します。
この柔軟性が、APO による制限条項の実装の理論的根拠です。
注目すべきは、この公開鍵に対応する秘密鍵がないため、これらの資産はあらかじめ作成された取引を通じてのみ使用できることです。私たちはあらかじめ作成されたこれらの取引の中で資産の行き先を指定することができ、制限条項を実現することができます。
私たちは、イーサリアムのスマートコントラクトを比較することで理解できます: スマートコントラクトを介して実現できるのは、特定の条件を満たさない限り、コントラクトアドレスからの引き出しができないということです。単にEOA署名によって自由に支出できるわけではありません。この点から見ると、ビットコインは署名メカニズムの改善によってこの効果を実現できます。
しかし、上記のプロセスの問題は、計算時に循環依存性が存在することです。なぜなら、取引を事前に署名して作成するために入力内容を知る必要があるからです。
APOおよびSIGHASH_NOINPUTがこの署名方式を実現する意義は、この循環依存の問題を解決できることであり、計算する際には(が指定する)取引の全ての出力だけを知っていれば十分である。
! 詳細な契約:ビットコインのプログラマビリティを実現する方法は?
OP_CTV
OP_CHECKTEMPLATEVERIFY(CTV)、すなわちBIP-119は、改良されたオペコードを採用しています。