Covenants：ビットコインのプログラマビリティ

2024.05.20

共有先

TechFlow厳選深潮セレクト

Covenants：ビットコインのプログラマビリティ

ビットコインの「制限条項」とは一体何なのか？

2024.05.20 - 03:58:55

比特币

Web3業界の深掘り報道に専念し潮流を洞察

ビットコインの「制限条項」とは一体何なのか？

著者：HashKey Capital インベストメントリサーチ責任者 Jeffrey HU、HashKey Capital インベストメントマネージャー Harper LI

最近、ビットコインコミュニティではOP_CATなどのオペコードを再び有効化するという議論が巻き起こっている。Taproot WizardはQuantum CatsのNFTを発行し、BIP-420番号を取得したと宣言するなどして、多くの注目を集めた。支持者らは、OP_CATを有効化することで「制限条項」（covenants）を実現でき、ビットコイン上でスマートコントラクトやプログラマブル性を可能にすると主張している。

「制限条項」という言葉に気づき、少し調べてみれば、そこにはさらに大きな謎のウサギ穴があることに気付くだろう。開発者たちは長年にわたり、OP_CAT以外にもOP_CTV、APO、OP_VAULTなど、制限条項を実現するさまざまな技術について議論してきた。

それでは、「制限条項」とはいったい何か？なぜこれほど多くの開発者が長年にわたって注目し、議論を続けているのか？ビットコインのどのようなプログラマブル性を実現できるのか？背後の設計原理はどのようなものか？本稿ではこれらについて概観的な紹介と考察を行う。

「制限条項」とは何か

Covenants（カベンアンツ）は中国語で「限制条款」と訳され、「制限条項」または「契約」とも呼ばれる。これは将来のビットコイン取引に対して条件を設定できる仕組みである。

現在のビットコインスクリプトも、署名の正当性の検証やスクリプトの一致といった制限条件を含んでいる。しかし、ユーザーがロックを解除さえすれば、そのUTXOを任意の場所に送金できる。

一方で「制限条項」とは、このロックの解除条件に加えて、UTXOのその後の使用方法にさらなる制限を設けること、つまり「専款専用」のような効果を実現すること、あるいは取引に含まれる他の入力条件などを制限することを意味する。

より正確に言えば、現在のビットコインスクリプトにも一定程度の制限条項機能はある。例えば時間ロックはnLocktimeやnSequenceフィールドを内省することで、取引の支出時期に制限をかけることができるが、基本的には時間に関する制限に限られている。

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

直感に反するかもしれないが、こうした制限によってむしろ新たな応用シナリオが開かれるのである。

応用シナリオ

ステーキングにおけるペナルティの保証

制限条項のもっとも直感的な例は、BabylonがBitcoinステーキングプロセスで用いるslash取引である。

BabylonのBitcoinステーキングでは、ユーザーが自分のBTC資産をメインチェーン上の特定のスクリプトに送金する。支出条件は以下の2つに分けられる：

ハッピーエンド：一定期間後に、ユーザー自身の署名でロックを解除でき、unstakeが完了する
バッドエンド：ユーザーがBabylonがセキュリティを貸し出すPoSチェーン上で二重署名などの悪意ある行動をした場合、EOTS（extractable one-time signatures、抽出可能なワンタイム署名）によって資産のロックを解除し、ネットワーク上の実行者が一部の資産を強制的にバーンアドレスに送信（slash）する

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

ここで「強制送信」という点に注意が必要だ。つまり、UTXOのロックは解除できても、その資産は任意の場所に送ることができず、バーンされるしかない。これにより、悪意のあるユーザーが既知の署名を使って先回りして資産を自分に戻すことでペナルティを回避できないようにする。

この機能は、OP_CTVなどの制限条項が実装されれば、ステーキングスクリプトの「バッドエンド」ブランチにOP_CTVなどのオペコードを追加することで実現できる。

しかしOP_CTVが有効化される前は、Babylonは代替手段として、ユーザーと委員会が共同で執行する方法によって、制限条項の強制的効果を模倣している。

輻輳制御（コンゲスチョンコントロール）

一般的に、輻輳とはビットコインネットワークの手数料レートが高く、トランザクションプールに多数の取引が溜まり、迅速な確認を望むユーザーが手数料を引き上げざるを得ない状態を指す。

このとき、あるユーザーが複数の受取人に複数の取引を送らなければならない場合、高コストを負担せざるを得ず、結果としてネットワーク全体の手数料レートをさらに押し上げることになる。

もし制限条項があれば、送信者はまず一括送金取引へのコミットメントを行える。このコミットメントにより、すべての受取人は最終的な取引が行われることを信じることができ、手数料レートが低いタイミングで具体的な取引を送信すればよい。

下図のように、ブロックスペースの需要が高いときは取引コストが非常に高くなる。OP_CHECKTEMPLATEVERIFYを利用すれば、大規模支払い処理業者はすべての支払いを単一のO(1)トランザクションに集約して確認できる。その後、ブロックスペースの需要が低下した時点で、そのUTXOから支払いを展開できる。

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

このシナリオは、制限条項であるOP_CTVが提案された際の典型的な応用例である。他にも 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などが紹介されている。

金庫（Vault）

金庫（vault）はビットコインアプリケーションにおいて広く議論されている応用分野であり、特に制限条項の領域では重要視されている。日常的な運用では資金の安全保管と利用ニーズの両立が不可欠であり、そのため「金庫」のようなアプリケーションが求められる。これは資金を安全に守り、仮にアカウントがハッキングされて秘密鍵が漏洩しても、資金の使用を制限できる。

制限条項技術を活用すれば、金庫型アプリケーションは比較的容易に構築できる。

OP_VAULTの設計案を例に挙げると、金庫内の資金を使用する際には、まず1回の取引をオンチェーンに送信する必要がある。この取引は資金使用の意図（「trigger」）を示し、以下の条件を設定する：

正常であれば、次の取引が最終的な出金取引となり、N個のブロック待機後に資金を任意の場所に送金できる
もし取引が盗まれた（あるいは「モンキレンチ攻撃」による強要状態にある）ことが判明した場合、Nブロックの出金取引が送信される前に、別の安全なアドレス（より安全な保管先）に即座に送金できる

OP_VAULTのフロー出典：BIP-345

なお、制限条項がない環境でも金庫アプリケーションは構築可能であり、一案として、事前に使用時の署名を準備しておき、その秘密鍵を破棄する方法がある。ただし制限も多く、秘密鍵が確実に破棄されたことを保証する必要がある（ゼロ知識証明のtrusted setupに似る）、金額と手数料が事前に決定される（事前署名のため）ため柔軟性に欠ける、などの課題がある。

OP_VAULTと事前署名式金庫のフロー比較出典：BIP-345

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

一般的に、ライトニングネットワークを含むステートチャネルは、ノードが最新状態を監視し、適切に最新状態をオンチェーンに公開できる限り、メインチェーンと同等の安全性を持つと考えられている。しかし、制限条項が導入されれば、ライトニングネットワークを超えるより堅牢で柔軟な新しいステートチャネル設計が可能になる。代表的なものにEltoo、Arkなどがある。

Eltoo（別名LN-Symmetry）はその典型例である。この技術は「L2」の語呂を取り、ライトニングネットワーク向けの実行レイヤーを提案しており、後続のチャネル状態が以前の状態を上書きできるようになり、ペナルティメカニズムが不要となる。これにより、相手の悪意を防ぐために複数の過去の状態を保存し続ける必要もなくなる。この効果を実現するために、EltooはSIGHASH_NOINPUTという署名方式（APO/BIP-118）を提案している。

一方、Arkはライトニングネットワークの流入流動性やチャネル管理の難しさを軽減することを目指している。これはjoinpool形式のプロトコルであり、複数のユーザーが一定期間、サービスプロバイダーを取引相手として受け入れ、チェーン外で仮想UTXO（vUTXO）の取引を行うが、オンチェーンでは一つのUTXOを共有することでコストを削減する。金庫と同様に、Arkも現行のビットコインネットワーク上で実現可能だが、制限条項を導入することで、取引テンプレートを活用して必要なインタラクション量を削減し、より非信頼的な片方向退出を実現できる。

制限条項技術の概要

上記の応用例からわかるように、制限条項は特定の技術というよりもむしろ一種の効果であり、それを実現する技術は複数存在する。分類すると以下のようなカテゴリがある：

タイプ：汎用型 vs 専用型
実装方法：オペコードベース vs 署名ベース
再帰性：再帰的 vs 非再帰的

ここで「再帰的」とは、ある制限条項の実装が次の出力だけでなく、さらにその次の出力にも制限をかけられることを意味し、制限が1回の取引を超えて、より深い取引レベルにまで及ぶことを可能にする。

主要な制限条項設計案には以下のようなものがある：

*再帰性：OP_CATと組み合わせた場合

制限条項の設計

前述の説明から、現在のビットコインスクリプトはロックの解除条件にしか制限をかけておらず、UTXOがどのようにさらに使われるかについては制限していない。制限条項を実現するには、逆に考えてみるべきだ：なぜ現在のビットコインスクリプトでは制限条項が実現できないのか？

その主な理由は、現在のビットコインスクリプトが取引自体の内容を読み取れない、つまり取引の「内省」（introspection）ができないことにある。

もし取引の内省を実現できれば――取引のあらゆる内容（出力も含む）を検査できれば――制限条項も実現可能になる。

したがって、制限条項の設計思想は主に「いかにして内省を実現するか」に集中している。

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

最もシンプルなアイデアは、1つまたは複数のオペコード（1つのオペコード＋複数のパラメータ、または複数の機能を持つオペコード）を追加し、直接的に取引の内容を読み取るというものだ。これがオペコードベースのアプローチである。

もう一つのアプローチは、スクリプト内で直接取引の内容を読み取ったり検査したりせず、代わりに取引内容のハッシュを利用するというものだ。このハッシュに対してすでに署名がなされていれば、OP_CHECKSIGなどを改造してその署名を検証するだけで、間接的に取引の内省と制限条項を実現できる。これが署名ベースの設計であり、APOやOP_CSFSなどが含まれる。

APO

SIGHASH_ANYPREVOUT（APO）は、ビットコインの署名方式として提案されている。署名の最も単純な方法は、取引の入力と出力の両方にコミットすることだが、ビットコインにはより柔軟な方法、つまりSIGHASHがあり、取引の入力または出力の一部に選択的にコミットできる。

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

上図のように、ALLはすべてのデータに適用されるが、NONEはすべての入力にのみ適用され、出力には適用されない。SINGLEは同じ入力番号に対応する出力にのみ適用される。また、SIGHASHはANYONECANPAY修飾子と組み合わせることで、単一の入力にのみ適用できる。

一方、APOのSIGHASHは出力にのみ署名し、入力部分には署名しない。つまり、APO方式で署名された取引は、その後、条件を満たす任意のUTXOに追加して使用できる。

この柔軟性こそが、APOが制限条項を実現する理論的基盤である：

事前に1回または複数回の取引を作成できる
これらの取引情報をもとに、署名が1回だけ求まる公開鍵を構築できる
この公開鍵アドレスに送金された資産は、事前に作成された取引を通じてのみ使用可能となる

注目すべきは、この公開鍵に対応する秘密鍵が存在しないため、資産は事前に作成された取引でのみ使用できることを保証できる点である。したがって、事前に作成した取引で資産の行き先を規定することで、制限条項を実現できる。

イーサリアムのスマートコントラクトとの比較で理解を深めよう。スマートコントラクトでは、EOAの署名だけで自由に引き出すのではなく、一定の条件を満たした場合にのみ引き出せるようにする。まさにこれと同じ効果を、ビットコインは署名方式の改良によって実現できるのである。

ただし、このプロセスには循環依存という問題がある。事前に署名して取引を作成するには、入力の内容を知る必要があるためである。

APOおよびSIGHASH_NOINPUTがこの署名方式を実現する意義は、計算時に取引の全出力のみを知ればよいという点にある。

OP_CTV

OP_CHECKTEMPLATEVERIFY（CTV、BIP-119）は、Opcodeを改良するアプローチを採用している。これはコミットメントハッシュをパラメータとし、オペコードを実行するすべての取引が、そのコミットメントと一致する出力セットを含まなければならないとする。CTVにより、ビットコインユーザーは自らのビットコインの使い方を制限できるようになる。

この提案は当初、OP_CHECKOUTPUTSHASHVERIFY（COSHV）として発表され、輻輳制御取引の作成能力に重点を置いていたため、批判も「あまりに汎用性が低く、輻輳制御に特化しすぎている」という点に集中していた。

前述の輻輳制御の例では、送信者Aliceは10個の出力を生成し、そのハッシュをとり、得られたダイジェストを使ってCOSHVを含むtapleafスクリプトを作成する。また、参加者の公開鍵を用いてTaproot内部キーを形成し、Taprootスクリプトパスを明かさずに共同で支出できるようにする。

その後、Aliceは各受取人に10個の出力のコピーを渡し、彼らがそれぞれAliceのセットアップ取引を検証できるようにする。将来的にこの支払いを使いたいときは、誰でもコミットメントに合致する出力を含む取引を作成できる。

このプロセス全体を通じて、Aliceがセットアップ取引を作成・送信する際、メールやクラウドドライブなどの既存の非同期通信手段で10個の出力コピーを送信できる。つまり、受取人はオンラインである必要もなければ、相互にやり取りする必要もない。

出典：

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

APOと同様に、支出条件に基づいてアドレスを構築でき、「錠」をさまざまな方法で作成できる。他の鍵や時間ロック、組み合わせ可能なロジックなどを追加できる。

出典：

https://twitter.com/OwenKemeys/status/1741575353716326835

CTVは、ハッシュ化された支出取引が定義されたものと一致するかどうかを検査できることを提案しており、取引データ自体を「鍵」としてロックを開ける。

上記の10人の受取人の例をさらに拡張すると、受取人はさらにそのアドレス鍵を、署名済みだが未ブロードキャストのtxとして次の一連の受取人アドレスに送信でき、これを繰り返すことで下図のような木構造が形成される。Aliceはオンチェーン上で1つのUTXOのブロックスペースしか使わず、複数ユーザーの口座残高変更を含む構造を構築できる。

出典：

https://twitter.com/OwenKemeys/status/1741575353716326835

もし、この木構造の末端の一つがライトニングチャネルやコールドストレージ、他の支払い経路だった場合はどうか？こうした場合、単一の多次元支出木は、多次元多层次の支出木へと拡張され、サポートできるシナリオはさらに豊かで柔軟になる。

出典：

https://twitter.com/OwenKemeys/status/1744181234417140076

CTVは2019年にCOSHVから名称変更され、2020年にBIP-119番号が割り当てられ、CTVコントラクトをサポートするプログラミング言語Sapioが登場。2022～2023年にはコミュニティ内で多くの議論、更新、アクティベーション方式の論争があり、現在も注目度の高いソフトフォークアップグレード提案の一つである。

OP_CAT

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

最も直接的な例はMerkleツリー関連の操作である。Merkleツリーは2つの要素を連結してハッシュする操作と理解できる。現在のビットコインスクリプトにはOP_SHA256などのハッシュオペコードがあるため、OP_CATで2要素の連結が可能になれば、スクリプト内でMerkleツリーの検証機能を実現でき、軽量クライアントによる検証能力を一定程度備えることになる。

もう一つの基礎的な実現例はSchnorr署名の強化である：スクリプトの支出署名条件を、ユーザーの公開鍵と公開nonceの連結に設定できる。その後、署名者が別の取引で資金を他の場所に送ろうとした場合、同じnonceを使用せざるを得ず、その結果秘密鍵が漏洩してしまう。つまり、OP_CATによりnonceに対するコミットメントを実現し、事前に署名された取引の有効性を確保できる。

OP_CATの他の応用例としては、Bistream、ツリーシグネチャ、耐量子Lamport署名、金庫などがある。

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

しかし、現在OP_CATを再び有効化しても以前のようなスタック爆発は起きないのか？現在のOP_CAT提案はtapscript内でのみ有効化されるため、tapscriptでは各スタック要素が520バイト以内に制限されており、以前のようなスタック爆発問題は発生しない。また、中本聪がOP_CATを直接無効化したのは厳しすぎたのではないかと考える開発者もいる。ただし、OP_CATの柔軟性ゆえに、現在予見できない脆弱性を引き起こす可能性があるシーンも確かに存在する。

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

結び

「自律が自由をもたらす」。上記の紹介からわかるように、制限条項はビットコインスクリプト内で取引のさらなる支出を制限できるため、スマートコントラクトに類似した取引ルールを実現できる。BitVMなどのオンチェーン外方式と比べ、このプログラミング方式はビットコイン上でよりネイティブに検証でき、メインチェーン上のアプリ（輻輳制御）、オンチェーン外アプリ（ステートチャネル）、その他新たな応用分野（ステーキングペナルティなど）の改善にも寄与する。

制限条項の実現技術がさらに基礎的なアップグレードと組み合わされれば、プログラマブル性の可能性はさらに広がる。例えば、最近レビュー中の64ビット演算子の提案は、OP_TLUVや他の制限条項と組み合わせることで、取引出力のサトシ数量に基づいたプログラミングが可能になる。

しかし、制限条項は計画外の乱用や脆弱性を引き起こす可能性もあるため、コミュニティは慎重な姿勢を取っている。また、制限条項のアップグレードはコンセンサスルールのソフトフォークを伴う。タップルートのアップグレード時の状況を踏まえると、制限条項関連のアップグレードも時間がかかるだろう。