Bitcoinの「契約条件」は、将来のBitcoin取引に条件を設定するメカニズムです。この記事では、制限条項の基本的な概念、適用シナリオ、および技術実装方法が概説され、それらの背後にある設計原則についても議論されています。OP_CAT、OP_CTV、APOなどの技術提案が紹介され、それらがBitcoinのプログラム可能性とスマートコントラクト機能をどのように向上させるかについても触れられています。同時に、この記事では、Bitcoinネットワークでの制限条項の適用（過負荷制御、ボルト、ステータスチャンネルなど）や、制限条項の実装と潜在的なコミュニティの論争に関する設計アイデアにも触れています。

共同執筆ジェフリー・フー and Harper Li

最近、BitcoinコミュニティでOP_CATなどのオペコードを再度有効にすることに関する議論が盛んになっています。また、Quantum CatsのNFTを立ち上げ、BIP-420を割り当てたと主張して注目を集めています。支持者は、OP_CATを有効にすることで「契約」を実現し、その結果、Bitcoinでスマートコントラクトやプログラム可能性をもたらすと主張しています。

もし「契約」という言葉に気づいたら、少し調べてみると、これも別の大きな問題があることがわかります。開発者たちは、OP_CTV、APO、OP_VAULT、OP_CATなどの契約を実装するテクノロジーについて数年間話してきました。

より正確には、現在のBitcoinスクリプトには、取引のnLockまたはnSequenceフィールドを内部調査して取引が支出されるまでの時間を制限するオペコードベースのタイムロックなど、いくつかの種類の契約条件がありますが、それらは依然として時間制限に制限されています。

ビットコインの「契約」は具体的には何ですか？なぜそれが開発者から長年注目と議論を集めているのですか？ビットコインのプログラム可能性は何が実現できますか？それにはどのような設計原則がありますか？この記事では、概要と議論を提供しようとしています。

「契約条件」とは何ですか？

Covenantは、将来のBitcoin取引に条件を設定できるメカニズムです。

実際、現在のBitcoinスクリプトには制約が含まれており、正当な署名を入力する必要がある、支出時には適合スクリプトを送信する必要があるなどの制約があります。ユーザーがそれをロック解除できる限り、そのUTXOをどこでも使用できます。

その契約は、この制限の上に追加の制限を設け、支出後にUTXOの支出を制限するなど、取引に入力されたその他の入力条件などを制限することで、その効果を達成することを目指しています。

なぜ開発者や研究者がこれらの制限チェックを設計するのでしょうか？それは、契約条件が無意味な制限だけでなく、取引実行のルールを設定することが目的だからです。このように、ユーザーは事前に設定されたルールに従って取引を実行するだけで、意図したビジネスプロセスを完了できます。

したがって、これはかえってより多くのアプリケーションシナリオをもたらします。

アプリケーションシナリオ

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

ビットコインのステーキングプロセスでのバビロンのスラッシュトランザクションは、契約の最も直感的な例の1つです。

バビロンのBitcoinステーキングプロセスには、ユーザーがBTCをメインチェーン上の特別なスクリプトに送信し、2つの支出条件がある。

• ハッピーエンド：一定の時間が経過すると、ユーザーは自分自身の署名でアンロックでき、これはアンステーキングプロセスが完了したことを意味します。
• 悪い結末：ユーザーがPoSチェーンで二重支払い攻撃を受けた場合、ユーザーはEOTS（取り出し可能なワンタイム署名）を使用して自分自身の署名で資産をアンロックすることができ、ネットワーク内の実行アクターによって一部の資産が焼却アドレス（スラッシュ）に送信されることが強制される可能性があります。

ソース：ビットコインステーキング：プルーフオブステーク経済を確保するための2100万ビットコインのロック解除

「強制」という言葉に注意してください。これは、UTXOをロック解除できたとしても、資産を他の場所に送信することはできず、燃やすだけです。これにより、悪意のあるユーザーが自分自身に資産を自分自身の既知の署名で送り返すことができないようになります。

この機能は、OP_CTVなどの契約を実装した後、ステーキングスクリプトの「不良エンディング」にオペコードを追加することで実装できます。

OP_CTVが有効になる前に、バビロンは、ユーザーと委員会が協力して契約を強制する効果を模倣するための回避策が必要となります。

輻輳制御/スケーリング

一般的に、混雑とは、ビットコインで手数料が高く、トランザクションプールに蓄積された比較的多数のトランザクションがパックされるのを待っている状態です。したがって、ユーザーが迅速にトランザクションを確認したい場合は、手数料を引き上げる必要があります。

その場合、ユーザーが複数のアドレスに複数の取引を送る必要がある場合、手数料を引き上げて高コストを負担しなければならなくなります。それに伴い、全ネットワークの取引手数料がさらに上昇することになります。

契約があれば、解決策があります: 複数の出力を持つ単一のコミットされたトランザクション。このコミットメントにより、すべての受取人が最終トランザクションが行われることを納得し、特定のトランザクションを送信する前にみんなが手数料が低いまで待つことができます。

以下のように、ブロックスペースの需要が高いと、取引手数料が非常に高額になります。 OP_CHECKTEMPLATEVERIFYを使用することで、高い取引量の支払処理業者は、すべての支払いを1つのO（1）トランザクションにまとめて確認できます。その後、時間が経過すると、ブロックスペースの需要が低下すると、支払いをそのUTXOから拡張することができます

ソース：https://utxos.org/uses/scaling/

このシナリオは、このOP_CTV制限によって提示されたより典型的なユースケースの1つです。他にも多くのユースケースが で見つかることがあります。https://utxos.org/uses.上記の過負荷制御に加えて、ページにはSoft Fork Bets、Decentralized options、Drivechains、Batch Channels、Non-Interactive Channels、Trustless Coordination-Free Mining Pools、Vaults、Safer Hashed Time Locked Contracts（HTLCS） Limitsなどがリストされています。

ボールト

Vaultsは、特に契約の領域内で、ビットコインアプリケーションのより広く議論されているユースケースの1つです。日々の運用は、資金を安全に保ちつつ使用する必要とのバランスを取ることを避けることはできませんので、資金を安全に保つことができるだけでなく、口座がハッキングされた場合（たとえば、秘密鍵が侵害された場合）に資金の使用を制限することができるようなVaultがあれば良いでしょう。

制限条項を実装するために使用される技術に基づいて、この種の保管ボールトは比較的簡単に構築することができます。

OP_VAULTのデザインスキームを例に取ると、ボールト内の資金を支出する際に、まずチェーンにトランザクションを送信する必要があります。このトランザクションは、ボールトを支出する意図を示し、それが「トリガー」となり、その中に条件が設定されます:

• すべてがうまくいけば、2回目の取引は最終的に資金を引き出すことになります。Nブロックを待った後、資金はさらにどこでも使えるようになります。
• もし取引が盗まれた場合（または「トリガーアタック」で強制された場合）、資産は即座に別の安全なアドレスに送信される可能性があります（ユーザーにとってより安全です）、Nブロック後に出金取引が送信されます。

OP_VAULTのプロセス、ソース：BIP-345

なお、契約なしで金庫を構築することも可能です。その方法の1つは、後で支出するための署名を準備するために秘密鍵を使用し、その後この秘密鍵を破壊することです。ただし、秘密鍵が破壊されたことを確認する必要があるなど、さらに制限があります（ゼロ知識証明の信頼セットアッププロセスに類似）。また、事前に金額と手数料を決定する柔軟性がないことも制限の1つです（事前署名のため）。

事前計算された保管庫とOP_VAULT，ソース：BIP-345

より堅牢で柔軟な状態チャネル

一般的に、ライトニングネットワークを含むステートチャネルは、（ノードが最新の状態を観察でき、最新の状態を適切にチェーンに投稿できるという点で）メインチェーンとほぼ同じセキュリティを持つと仮定できる。ただし、コヴェナントにより、いくつかの新しいステートチャネルデザインをライトニングネットワークの上でより堅牢かつ柔軟に構築できるようになった。よく知られているものには、Eltoo、Arkなどがある。

Eltoo（LN-Symmetryとも呼ばれる）は典型的な例です。“L2”の頭字語を取り、この技術はペナルティ機構なしに以前の状態を置き換えることができるようにするライトニングネットワークの実行レイヤーを提案しており、これによりライトニングネットワークのノードが悪意のある行為を防ぐために複数の以前の状態を保存する必要がなくなります。上記の効果を達成するために、EltooはSIGHASH_NOINPUT署名、APO（BIP-118）を提案しています。

Arkは、ライトニングネットワークのインバウンド流動性とチャネル管理の難しさを軽減することを目的としています。これはjoinpoolの形式のプロトコルであり、複数のユーザーが一定期間、サービスプロバイダーをカウンターパーティとして受け入れ、オフチェーンで仮想UTXO（vUTXO）を取引しますが、コストを削減するためにチェーン上でUTXOを共有します。Vaultsと同様に、Arkは現在のBitcoinネットワーク上で実装することができます。ただし、契約書の導入により、Arkはトランザクションテンプレートに基づいて必要な相互作用の量を削減し、より信頼性のある片側の脱退を可能にします。

契約の概要

上記の応用から明らかなように、契約はある特定の技術よりも効果のようなものであり、そのため実装方法はさまざまです。次のように分類することができます:

• タイプ：一般的、制限的
• 実装：オペコードベース、署名ベース
• 再帰：再帰的、非再帰的

ここで再帰的とは、契約の実装によって次の取引の出力を制限することもできるということを意味します。つまり、取引チェーン内の各取引は前の取引によって制限されます。

人気のある契約デザインには、次のようなものがあります:

契約のデザイン

前回の紹介からわかるように、現在のBitcoinスクリプトは主にアンロックの条件を制限しており、UTXOのさらなる支出方法を制限していません。契約を実装するには、逆の視点で考える必要があります。なぜ現在のBitcoinスクリプトで契約を実装できないのでしょうか？

現在のビットコインスクリプトはトランザクションそのものを読むことができないため、トランザクションの内観ができないというのが主な理由です。

もし内省を実装できれば、トランザクション内の何でも（出力を含む）を検査できるようになり、契約を実装できるかもしれません。

したがって、契約の設計は、内省を実装する方法にも中心を置いています。

Opcodeベース対署名ベース

最も単純で原始的なアイデアは、1つまたは複数のオペコード（1つのオペコード+複数のパラメータ、または異なる機能を持つ複数のオペコード）を追加し、トランザクションの内容を直接読み取ることです。これは、オペコードベースのアイデアとしても知られています。

別の考え方は、スクリプト内で直接トランザクションの内容を読み取り、確認する代わりに、トランザクション内容のハッシュを使用することができるというものです。つまり、このハッシュが署名されている場合、スクリプト内のOP_CHECKSIGのようなオペコードを変換してこの署名を確認することで、トランザクションの内部検査と契約を間接的に実装することができます。この考え方は、署名デザインアプローチに基づいています。主にAPOとOP_CSFSを含みます。

APO

SIGHASH_ANYPREVOUT（APO）は署名ハッシュの提案です。署名の最も簡単な方法は、トランザクションの入力と出力の両方にコミットすることですが、ビットコインがトランザクションの入力または出力のどちらかに選択的にコミットするための柔軟な方法があります。これがSIGHASHとして知られています。

トランザクションの入力と出力のためのSIGHASHおよびその組み合わせの現在の範囲（出典：Mastering Bitcoin、2nd）

上記のように、ALLに加えて、すべてのデータに適用されるALLに加えて、ALLがすべての入力にのみ適用されるように署名されているNONEがあり、そしてSINGLEは、同じ入力インデックス番号を持つ出力にのみ適用することでこれを構築しています。さらに、SIGHASHは、ANYONECANPAY修飾子を重ねて組み合わせることで、1つの入力にのみ適用されるようにできます。

APOのSIGHASHは、一方で、出力のみに署名し、入力には署名しません。これは、APOで署名されたトランザクションは、条件を満たす任意のUTXOに後で添付することができることを意味します。

この柔軟性は、APOの契約の実施の背後にある理論です：

• 1つ以上の取引を事前に作成することができます
• これらの取引からの情報は、支出署名のみが派生/確認される公開鍵を構築するために使用されます
• この公開キーアドレスに送信された資産は事前に作成された取引を通じてのみ使用できるようになります。

この公開鍵に対応する秘密鍵がないため、これらの資産は事前に作成された取引を介してのみ使用できることに注意する価値があります。その後、これらの事前に作成された取引で資産がどこに行くかを指定することで、契約を実装できます。

これは、イーサリアムのスマートコントラクトと比較してさらに理解することができます: スマートコントラクトで達成できることは、特定の条件が満たされた場合にのみ契約アドレスからお金を引き出すことができ、EOA署名で任意に費やすことはできないということです。この観点から見ると、ビットコインは署名メカニズムの改善を通じてこの効果を達成することができます。

ただし、上記のプロセスには問題がある。dev@lists.linuxfoundation.org/msg08075.html">計算上の循環依存があります。前もって署名してトランザクションを作成するために入力を知る必要があります。

この署名方法のAPOとSIGHASH_NOINPUTの実装の重要性は、計算時にトランザクションの完全な出力を知る必要があるという点で、この循環依存の問題を解決していることにあります。

OP_CTV

OP_CHECKTEMPLATEVERIFY（CTV）、またはBIP-119は、Opcodeの改善を使用しています。コミットメントハッシュを引数として取り、オペコードを実行するトランザクションがそのコミットメントに一致する一連の出力を含む必要があります。CTVでは、BitcoinユーザーがBitcoinの使用方法を制限することができます。

元々はOP_CHECKOUTPUTSHASHVERIFY（COSHV）として導入され、初期の焦点は過負荷制御トランザクションの作成能力に置かれていましたが、提案への批判は、それが一般的でないことや過負荷制御のユースケースに特化しすぎていることにも集中しています。

上記の輻輳制御ユースケースでは、送信者であるアリスは、10個の出力を作成し、それら10個の出力をハッシュし、その結果のダイジェストを使用して、COSHVを含むtapleafスクリプトを作成し、参加者の公開鍵を使用して、Taproot内部キーを形成することができます。これにより、Taprootスクリプトのパスを公開せずにお金を支出するために協力できます。

その後、アリスはそれぞれの受取人にすべての10の出力のコピーを渡して、それぞれがアリスの設定トランザクションを検証できるようにします。後で支払いを行いたいときには、彼らのどなたでもコミットされた出力を持つトランザクションを作成することができます。

プロセス全体を通じて、アリスが設定トランザクションを作成し送信する際、アリスはこれらの出力の10コピーを既存の非同期通信手段（電子メールやクラウドドライブなど）を介して送信できます。これにより、受信者はオンラインである必要がなく、互いにやり取りする必要もありません。

ソース: https://bitcoinops.org/en/newsletters/2019/05/29/#proposed-transaction-output-commitments

APOと同様に、支出条件に基づいてアドレスを構築することができ、追加のキー、相対的または固定のタイムロック、およびそれらを組み合わせるための他のロジックを含むさまざまな方法で「ロック」を行うことができます。

ソース：https://twitter.com/OwenKemeys/status/1741575353716326835

これに基づいて、CTVは、ハッシュ後の支出取引が定義されたものと一致するかどうかを確認することを提案しており、これは取引データが「ロック」を解除するためのキーとして使用されることを意味します。

上記の10人の受信者の例を拡張することができます。ここで、受信者はさらに彼のアドレスキーを署名されたがブロードキャストされていないTXにし、次の受信者に送信することができます。そして、以下の図に示すように、ツリー構造を形成します。アリスは、ブロックスペースのUTXO 1つだけを使用して、チェーン上の複数のユーザーの口座残高の変更を構築できます。

ソース：https://twitter.com/OwenKemeys/status/1741575353716326835

そして、1枚の葉がライトニングチャネル、または冷蔵庫、または他の支払い経路だったらどうでしょうか？その場合、木は単一次元のマルチレイヤー支払いツリーから多次元のマルチレイヤー支払いツリーに拡張され、サポートされるシナリオはより豊かで柔軟になります。

ソース: https://twitter.com/OwenKemeys/status/1744181234417140076

提案されて以来、CTVは2019年にCOSHVから名前が変更され、2020年にBIP-119が割り当てられ、CTVをサポートする契約を作成するために使用されるプログラミング言語であるSapioの出現、そして2022年および2023年のアクティベーションオプションに関するコミュニティの多くの議論、更新、および論争を受け、今でもコミュニティで最も議論されているソフトフォークアップグレード提案の1つです。

OP_CAT

OP_CATは、オープニング段落で説明されているように、現在注目を集めているアップグレード提案であり、スタックから2つの要素または2つのデータセットを連結する機能を実装します。簡単に見えますが、OP_CATは非常に柔軟であり、さまざまな方法でスクリプトに実装できます。

最も直接的な例は、Merkle Treeの動作であり、これは2つの要素が連結されてからハッシュ化されると解釈できます。現在、BitcoinスクリプトにはOP_SHA256やその他のハッシュオペコードが存在しているため、OP_CATを使用して2つの要素を連結することができれば、スクリプトでMerkle Tree検証機能を実装できます。これにより、ある程度の軽量クライアント検証の機能も提供されます。

実装の別の基盤は、Schnorr署名の強化です：スクリプトの支出署名条件を、ユーザーの公開鍵と公開ノンスの連結に設定できます。その後、署名者が資金を別の場所に使うために別のトランザクションに署名したい場合、同じノンスを使用する必要があります。これにより、プライベートキーが漏洩する可能性があります。つまり、OP_CATはノンスへのコミットメントを達成し、署名されたトランザクションの有効性を確保します。

OP_CATの他の用途には、ビットストリーム,木の署名, 量子耐性のあるLamport署名, ボールト、およびその他。

OP_CAT自体は新機能ではありませんが、Bitcoinの初期バージョンに存在していました無効2010年、攻撃者によって悪用される可能性があるために登場しました。たとえば、OP_DUPやOP_CATの繰り返し使用は、そのようなスクリプトを処理する際にフルノードスタックが簡単に爆発する可能性があります。デモ.

しかし、現在、OP_CATが再度有効になった場合、前述のスタック爆発問題は発生しないのではないでしょうか？現在のOP_CAT提案は、スタック要素あたりのバイト数が520バイトの制限があるtapscriptでのみ有効にするというものであり、これにより以前のスタック爆発問題は発生しません。OP_CATを完全に無効にすることで、一部の開発者は、Satoshi Nakamotoが厳しすぎるかもしれないと考えています。しかし、OP_CATの柔軟性により、脆弱性につながる可能性のあるいくつかのアプリケーションシナリオが存在する可能性があるかもしれません。

したがって、アプリケーションシナリオと潜在的なリスクを組み合わせると、OP_CATは最近多くの関心を集めており、またPR レビューそして現在、最もホットなアップグレード提案の1つです。

結論

上記の紹介からもわかるように、「自己規制は自由をもたらす」ということが、契約はビットコインスクリプトに直接実装され、取引にさらなる支出を認めるための条件を満たすことができるため、スマートコントラクトの効果に類似した取引ルールが可能になります。このプログラミングアプローチは、オフチェーンのアプローチ（BitVMなど）よりもビットコインでよりネイティブに検証でき、メインチェーン（過負荷制御）、オフチェーンアプリケーション（ステートチャネル）、および他の新しいアプリケーション方向（ステーキングスラッシングなど）におけるアプリケーションの改善も可能です。

契約の実装技術は、他のいくつかのアップグレードと組み合わせると、プログラム可能性の潜在能力をさらに引き出すことができます。たとえば、最近の64ビット算術に関する提案

in the レビュー提案されたとさらに組み合わせることができますOP_TLUVまたは、取引によって出力されたサトシの数に基づいてプログラムされた他の契約

ただし、契約は予期せぬ濫用や脆弱性につながることもあるため、コミュニティはこれについても慎重です。また、契約のアップグレードはコンセンサスルールのソフトフォークアップグレードを必要とするでしょう。Taprootアップグレードに関連する状況を考えると、契約に関連するアップグレードも時間がかかる可能性が高いです。

特別なお礼

Thanks Ajian, フィッシャー and ベンレビューと提案のために！

参照

• https://utxos.org/
• https://bitcoincovenants.com/
• 契約に関連するリソースのコレクション: https://gist.github.com/RobinLinus/c96fb7c81430ec6dc92f048687bd3068
• https://anyprevout.xyz/
• BIP 345：OP_VAULT提案：https://www.btcstudy.org/2023/04/13/bitcoin-improvement-proposals-345-op-vault-commit-0b0674c546/
• https://fc17.ifca.ai/bitcoin/papers/bitcoin17-final28.pdf
• https://maltemoeser.de/paper/covenants.pdf
• https://bitcoinops.org/en/topics/op_cat/
• OP_CAT: https://github.com/ビットコイン-審問/ビナナ/blob/master/2024/BIN-2024-0001.md
• CATとSchnorr Tricks: https://medium.com/blockstream/cat-and-schnorr-tricks-i-faf1b59bd298

免責事項: この資料は一般情報のみを目的としており、投資勧誘または投資の提案と解釈すべきではありません。また、HashKey Capitalはこの情報の利用や依存に関連していかなる責任も負わないものとします。

最新のHashKey Capitalニュースをお知らせします -

ウェブサイト — https://hashkey.capital/

Twitter — https://twitter.com/HashKey_Capital

LinkedIn — https://www.linkedin.com/company/hashkeycapital/

ステートメント:

1. この記事は[から転載されました中], 著作権は元の著者に属します [ジェフリーフーおよびHarper Li], if you have any objections to the reprint, please contact the Gate Learnチーム、および関連手順に従ってチームができるだけ早く対応します。

2. 免責事項：この記事で表現されている見解や意見は、著者個人の見解を表すものであり、投資アドバイスを構成するものではありません。

3. その他の言語版はGate Learnチームによって翻訳され、記事には言及されていませんGate, 翻訳された記事は無断転載、配布、または盗用してはいけません。