Covenantsの詳細：ビットコインのプログラム可能性をどのように実現するか？

著者：Jeffrey HU、Harper LI、HashKey Capital

最近、ビットコインコミュニティでは、OPCATなどのオペコードの再活性化に関する議論が盛り上がっています。Taproot Wizardは、Quantum CatsのNFTを発表し、BIP-420の番号を取得したと主張することで、多くの人々の注目を集めています。支持者は、OPCATを有効にすることで「制限条項」（covenants）を実現し、ビットコインのスマートコントラクトやプログラマビリティを実現できると主張しています。

「制限条項」という言葉に気づき、少し検索すれば、これは別の大きなラビリンスであることがわかります。開発者たちは何年も議論しており、OPCATの他にもOPCTV、APO、OP_VAULTなど、制限条項を実現する技術があります。

では、ビットコインの「制限条項」とは一体何でしょうか？なぜこれほど多くの開発者が数年にわたって関心を持ち、議論を続けているのでしょうか？ビットコインのどのようなプログラマビリティを実現できるのでしょうか？その背後にある設計原理はどのようなものなのでしょうか？この記事では、概観的な紹介と議論を試みます。

制限条項とは何か

Covenants（制限条項）は、将来のビットコイン取引に条件を設定できるメカニズムです。

現在のビットコインスクリプトにも制限条件が含まれています。たとえば、支出時には合法的な署名を入力する必要があり、適切なスクリプトに送信する必要があります。しかし、ユーザーがロックを解除できれば、そのUTXOを任意の場所に花費することができます。

制限条項は、ロックの解除方法に制限を加えることにより、UTXOのその後の支出を制限するなど、より多くの制限を設けることができます。これは「専用資金」の効果を実現することになります。また、1つの取引における他の入力条件を送信することも可能です。

より厳密に言えば、現在のビットコインスクリプトにも一定の制限条項が存在します。たとえば、オペコードに基づくタイムロックは、取引のnLockまたはnSequenceフィールドを通じて、取引の支出前に時間制限を実現しますが、基本的には時間に関する制限に限られています。

では、開発者や研究者はなぜこれらの制限チェックを設計するのでしょうか？制限条項は単に制限するためのものではなく、取引実行のルールを設定するためのものです。これにより、ユーザーは事前に設定されたルールに従って取引を実行し、所定のビジネスプロセスを完了することができます。

したがって、直感に反して、これによりより多くのアプリケーションシナリオが解放されるのです。

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

ステーキングの罰則を確保する

制限条項の最も直感的な例は、Babylonにおけるビットコインステーキングプロセスのスラッシュ取引です。

Babylonのビットコインステーキングプロセスでは、ユーザーは自分のBTC資産をメインチェーン上の特別なスクリプトに送信します。支出条件には2つの種類があります：

• ハッピーエンディング：一定の時間が経過した後、ユーザーは自分の署名でロックを解除でき、アンステークのプロセスが完了します。
• バッドエンディング：ユーザーがBabylonが借りたセキュリティのPoSチェーン上で二重署名などの悪行を行った場合、EOTS（extractable one-time signatures、一度だけ抽出可能な署名）を通じてこの資産をロック解除し、ネットワーク内の実行役割によって一部の資産が燃焼アドレス（スラッシュ）に強制送信されます。

出典：Bitcoin Staking: Unlocking 21M Bitcoins to Secure the Proof-of-Stake Economy

ここでの「強制送信」に注意してください。これは、UTXOをロック解除できる場合でも、その資産を他の任意の場所に送信することはできず、燃やすしかないことを意味します。これにより、悪行を働いたユーザーが自分の既知の署名を使って資産を自分に戻すことができず、罰則から逃れることができないようにします。

この機能がOPCTVなどの制限条項が実現された場合、ステーキングスクリプトの「バッドエンディング」分岐にOPCTVなどのオペコードを追加して制限を実現できます。

OP_CTVが有効化される前に、Babylonは回避策を通じて、ユーザーと委員会が共同で実行する方法で制限条項の強制実行効果を模擬する必要があります。

混雑制御

一般的に、混雑とは、ビットコインネットワーク上で手数料率が非常に高く、取引プールに多くの取引が積み上がっている状態を指します。したがって、ユーザーが取引を迅速に確認したい場合、手数料を引き上げる必要があります。

この時、ユーザーが複数の受取人に複数の取引を送信する必要がある場合、手数料を引き上げざるを得ず、比較的高いコストを負担することになります。同時に、全体のネットワークの手数料率もさらに引き上げることになります。

制限条項があれば、1つの解決策は、送信者が一括送信取引に先にコミットすることです。このコミットにより、すべての受取人は最終的な取引が行われることを信じることができ、手数料率が低い時に具体的な取引を送信することができます。

以下の図のように、ブロックスペースの需要が非常に高い場合、取引が非常に高価になります。OP_CHECKTEMPLATEVERIFYを使用することで、大量の支払い処理業者は、すべての支払いを単一のO(1)トランザクションに集約して確認できます。その後、しばらくしてブロックスペースの需要が減少したときに、支払いをそのUTXOから拡張できます。

出典： https://utxos.org/uses/scaling/

このシナリオは、OP_CTVという制限条項が提案した典型的なアプリケーションケースです。他にも多くのアプリケーションケースがhttps://utxos.org/uses/から見つけることができ、混雑制御の他に、ソフトフォークベット、分散型オプション、ドライブチェーン、バッチチャネル、非対話型チャネル、信頼のない調整不要のマイニングプール、ボールト、より安全なハッシュ時間制約契約（HTLCS）制限などが列挙されています。

ボールト

ボールト（vault）は、ビットコインアプリケーションの中で広く議論されているアプリケーションシナリオの一つであり、特に制限条項の分野において重要です。日常の操作では、資金の保管と使用のニーズの間でバランスを取る必要があるため、人々は資金の安全を保証し、アカウントがハッキングされた場合（秘密鍵が漏洩した場合）でも資金の使用を制限できるボールトアプリケーションを望んでいます。

制限条項を実現する技術に基づいて、ボールト型のアプリケーションは比較的容易に構築できます。

OP_VAULTの設計案を例に取ると、ボールト内の資金を花費する際には、まず取引をブロックチェーンに送信する必要があります。この取引は、ボールトを花費する意図を示す「トリガー」であり、条件を設定します：

• すべてが正常であれば、2回目の取引は最終的な引き出し取引です。Nブロック待機した後、資金を任意の場所にさらに花費できます。
• もしこの取引が盗まれた（または「レンチ攻撃」によって脅迫された）場合、Nブロックの引き出し取引が送信される前に、すぐに別の安全なアドレス（ユーザーのより安全な保管）に送信できます。

OP_VAULTのプロセス、出典：BIP-345

制限条項がない場合でも、ボールトアプリケーションを構築することは可能です。実行可能な方法は、秘密鍵を使って後の支出の署名を準備し、その秘密鍵を破棄することです。しかし、制限は依然として多く、たとえば、その秘密鍵がすでに破棄されていることを確認する必要があります（ゼロ知識証明のトラストセットアッププロセスに似ています）、金額と手数料を事前に確定する必要があるため（事前署名が必要）、柔軟性が欠けるなどの問題があります。

OP_VAULTと事前署名式のボールトプロセスの比較、出典：BIP-345

より堅牢で柔軟なステートチャネル

一般的に、ライトニングネットワークを含むステートチャネルは、メインチェーンとほぼ同等のセキュリティを持つと考えられています（ノードが最新の状態を観察でき、正常に最新の状態をブロックチェーンに公開できる場合）。しかし、制限条項が導入されることで、いくつかの新しいステートチャネルの設計アイデアがライトニングネットワークの上により堅牢または柔軟に実現できるようになります。これには、Eltoo、Arkなどが含まれます。

Eltoo（LN-Symmetryとも呼ばれる）は、その中でも典型的な例の一つです。この技術は「L2」の音を取って、ライトニングネットワークに対して、後のチャネル状態が以前の状態を置き換えることを許可する実行層を提案します。これにより、罰則メカニズムを必要とせず、対戦相手の悪行を防ぐために複数の以前の状態を保存する必要がなくなります。この効果を実現するために、EltooはSIGHASH_NOINPUTの署名方式、すなわちAPO（BIP-118）を提案しました。

Arkは、ライトニングネットワークの入出力流動性やチャネル管理の難易度を低下させることを目的としています。これは、複数のユーザーが一定期間、サービスプロバイダーを取引相手として受け入れ、オフチェーンで仮想UTXO（vUTXO）の取引を行いながら、オンチェーンで1つのUTXOを共有することでコストを削減するjoinpool形式のプロトコルです。ボールトと同様に、Arkも現在のビットコインネットワーク上で実現可能ですが、制限条項が導入されることで、Arkは取引テンプレートに基づいて必要な相互作用の量を減らし、より信頼のない一方的な退出を実現できます。

制限条項技術の概観

上記のアプリケーションから見ると、制限条項は特定の技術というよりも効果のように見え、多くの実現方法があります。分類すると、以下のようになります：

• タイプ：汎用型、専用型
• 実現方法：オペコードベース、署名ベース
• 再帰：再帰、非再帰

その中で、再帰とは、ある制限条項の実現が、次の出力を制限することによって次の出力を制限することができ、追加の制限が1つの取引を超えて、より高い取引深度に達することを意味します。

いくつかの主流の制限条項設計には以下が含まれます：

制限条項の設計

前述の説明からわかるように、現在のビットコインスクリプトは主にロック解除の条件を制限しており、UTXOがどのようにさらに花費されるかを制限していません。制限条項を実現するためには、逆に考える必要があります：なぜ現在のビットコインスクリプトは制限条項を実現できないのでしょうか？

その理由は、現在のビットコインスクリプトが取引自体の内容を読み取ることができない、すなわち取引の「内省」（introspection）ができないからです。

もし取引の内省を実現できれば、取引の任意の内容（出力を含む）をチェックできるようになり、制限条項を実現できるのです。

したがって、制限条項の設計思考も主に内省を実現する方法に焦点を当てています。

オペコードベース vs 署名ベース

最も単純で直接的な考え方は、1つまたは複数のオペコード（すなわち1つのオペコード+複数のパラメータ、または複数の異なる機能のオペコード）を追加して、取引の内容を直接読み取ることです。これがオペコードベースのアプローチです。

もう一つのアプローチは、スクリプト内で取引自体の内容を直接読み取ってチェックするのではなく、取引内容のハッシュを利用することです。もしこのハッシュがすでに署名されている場合、スクリプト内でOPCHECKSIGなどを改造してこの署名をチェックすることで、間接的に取引の内省と制限条項を実現できます。このアプローチは署名ベースの設計方式に該当します。主にAPOやOPCSFSなどが含まれます。

APO

SIGHASH_ANYPREVOUT（APO）は、提案中のビットコイン署名方式の一つです。署名の最も単純な方法は、取引の入力と出力の両方を約束することですが、ビットコインにはより柔軟な方法、すなわちSIGHASHがあり、取引内の入力または出力のいずれかを選択的に約束することができます。

現在のSIGHASHおよびその組み合わせによる取引入力出力の署名範囲（出典『Mastering Bitcoin, 2nd』）

上の図に示すように、すべてのデータに適用されるALLの他に、NONEの署名方式はすべての入力にのみ適用され、出力には適用されません。SINGLEはこの基礎の上に、同じ入力番号の出力にのみ適用されます。さらに、SIGHASHは組み合わせることができ、ANYONECANPAY修飾子を追加すると、1つの入力にのみ適用されます。

APOのSIGHASHは、出力にのみ署名し、入力部分には署名しません。これは、APO方式で署名された取引が、その後条件を満たす任意のUTXOに追加できることを意味します。

この柔軟性がAPOによる制限条項実現の理論的基盤です：

• 1つまたは複数の取引を事前に作成できます。
• これらの取引の情報を使用して、署名を1つだけ求めることができる公開鍵を構築します。
• こうすることで、その公開鍵アドレスに送信された資産は、事前に作成された取引を通じてのみ花費できるようになります。

注目すべきは、この公開鍵には対応する秘密鍵がないため、これらの資産は事前に作成された取引を通じてのみ花費できることが保証される点です。これにより、事前に作成された取引の中で資産の行き先を指定することで、制限条項を実現できます。

このプロセスを理解するために、イーサリアムのスマートコントラクトと比較することができます。スマートコントラクトを通じて、特定の条件を満たさない限り、契約アドレスから資金を引き出すことができないことを実現できます。これはEOA署名に頼るのではなく、ビットコインが署名メカニズムの改善を通じてこの効果を実現できることを意味します。

しかし、上記のプロセスには計算時に循環依存の問題があります。なぜなら、入力の内容を知る必要があるため、事前に署名して取引を作成する必要があるからです。

APOおよびSIGHASH_NOINPUTは、この署名方式の意義が、計算時に取引のすべての出力を知る（指定する）だけで済むようにすることにあります。

OP_CTV

OP_CHECKTEMPLATEVERIFY（CTV）、すなわちBIP-119は、オペコードの改善方式を採用しています。これは、コミットメントハッシュをパラメータとして受け取り、オペコードを実行する取引がそのコミットメントに一致する出力のセットを含むことを要求します。CTVを通じて、ビットコインユーザーはビットコインの使用方法を制限できるようになります。

この提案は、最初はOP_CHECKOUTPUTSHASHVERIFY（COSHV）という名前で発表され、初期には混雑制御取引の作成能力に重点が置かれていたため、この提案に対する批判も、あまり一般的ではなく、混雑制御のユースケースに特化しすぎているというものでした。

上記の混雑制御ユースケースにおいて、送信者のアリスは10個の出力を作成し、これら10個の出力をハッシュ化し、生成された要約を使用してCOSHVを含むタップリーフスクリプトを作成できます。アリスはまた、参加者の公開鍵を使用して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を次の受取人アドレスに送信するように設定できます。これを繰り返すことで、以下の図のような木構造を形成できます。アリスは、1つのUTXOのブロックスペースを使用して、複数のユーザーのアカウント残高の変更を構築できます。

出典： https://twitter.com/OwenKemeys/status/1741575353716326835

もしその葉の1つがライトニングチャネル、コールドストレージ、または他の支払い経路であればどうでしょうか？この場合、この木は単次元の多層支出木から多次元の多層支出木に拡張され、サポートできるシナリオはさらに豊かで柔軟になります。

出典： https://twitter.com/OwenKemeys/status/1744181234417140076

CTVは提案以来、2019年にCOSHVから改名され、2020年にBIP-119に割り当てられ、CTV契約をサポートするプログラミング言語Sapioが登場しました。2022年、2023年にはコミュニティで多くの議論や更新が行われ、その活性化プランについての議論もあり、現在もコミュニティで多く議論されているソフトフォークアップグレード提案の一つです。

OP_CAT

OPCATは、冒頭で紹介したように、現在非常に注目されているアップグレード提案であり、スタック内の2つの要素を連結（concatenate）する機能を実現します。見た目はシンプルですが、OPCATはスクリプト内で多くの機能を柔軟に実現できます。

最も直接的な例は、マークルツリーに関連する操作です。マークルツリーは、2つの要素をまず連結し、その後ハッシュ化するものと理解できます。現在のビットコインスクリプトにはOPSHA256などのハッシュオペコードがあるため、OPCATを使用して2つの要素を連結できれば、スクリプト内でマークルツリーの検証機能を実現でき、ある程度軽量クライアント検証の能力を持つことになります。

さらに、実現の基盤にはSchnorr署名の強化も含まれています。スクリプトの支出署名条件をユーザーの公開鍵と公開nonceの連結として設定できます。その後、署名者がこの資金を他の場所に花費するために別の取引を署名しようとすると、同じnonceを使用する必要があり、秘密鍵が漏洩することになります。つまり、OP_CATを通じてnonceのコミットメントを実現し、署名された取引の有効性を確保します。

OP_CATの他のアプリケーションシナリオには、Bistream、ツリー署名、量子耐性のLamport署名、ボールトなどがあります。

OPCAT自体は新しい機能ではなく、ビットコインの初期バージョンに存在していましたが、攻撃に利用される可能性があるため、2010年から無効化されました。たとえば、OPDUPとOP_CATを繰り返し使用することで、フルノードがこのようなスクリプトを処理する際にスタックが爆発することが容易に起こります。このデモを参照。

しかし、現在OPCATを再有効化しても、前述のスタック爆発の問題は発生しないのでしょうか？現在のOPCAT提案は、tapscript内での有効化のみを含んでおり、tapscriptは各スタック要素が520バイトを超えないことを制限しているため、以前のスタック爆発の問題は発生しません。また、一部の開発者は、中本聡がOPCATを直接無効化したのは過度に厳しい可能性があると考えています。しかし、OPCATの柔軟性により、現在ではいくつかの脆弱性を引き起こす可能性のあるアプリケーションシナリオを完全に排除することは難しいかもしれません。

したがって、アプリケーションシナリオと潜在的なリスクを総合的に考慮すると、OP_CATは最近多くの注目を集めており、PRレビューも行われており、現在最もホットなアップグレード提案の一つとなっています。

結論

「自律は自由をもたらす」。上記の説明からわかるように、制限条項はビットコインスクリプト内で取引のさらなる花費を制限することを直接実現し、スマートコントラクトのような取引ルールを実現します。BitVMなどのオフチェーン方式と比較して、このプログラミング方式はビットコイン上でよりネイティブに検証でき、メインチェーン上のアプリケーション（混雑制御）、オフチェーンアプリケーション（ステートチャネル）、および他の新しいアプリケーション方向（ステーキング罰則など）を改善することができます。

制限条項の実現技術がさらにいくつかの基盤のアップグレードと組み合わされれば、プログラマビリティの潜在能力がさらに解放されるでしょう。たとえば、最近のレビューでの64ビット演算子の提案は、提案されたOP_TLUVや他の制限条項と組み合わせることができ、取引出力のサトシの数に基づいてプログラミングを行うことができます。

しかし、制限条項は計画外の悪用や脆弱性を引き起こす可能性もあるため、コミュニティはこれに対して慎重です。また、制限条項のアップグレードは、コンセンサスルールのソフトフォークアップグレードを伴う必要があります。タップルートアップグレード時の状況を考慮すると、制限条項に関連するアップグレードも時間を要する可能性があります。