原著者: HashKey Capital 投資リサーチ責任者 Jeffrey HU、HashKey Capital 投資マネージャー Harper LI
最近、ビットコイン コミュニティで OP_CAT などのオペコードの再有効化に関する議論が盛り上がっています。 Taproot Wizard はまた、Quantum Cats NFT を起動し、BIP-420 番号を取得したと主張することで多くの人々の注目を集めました。支持者は、OP_CATを有効にすると、ビットコインの「コベナント」、スマートコントラクト、またはプログラム可能性が有効になると主張しています。
「制限」という言葉に気づいて少し検索してみると、これがまた大きなウサギの穴であることがわかります。開発者は、OP_CAT に加えて、OP_CTV、APO、OP_VAULT、および制限条項を実装するその他の技術について長年議論してきました。
では、ビットコインの「制限」とは一体何なのでしょうか？なぜ数年間、これほど多くの開発者の注目と議論を集めてきたのでしょうか?ビットコインではどのようなプログラマビリティを実現できるのでしょうか?その背後にある設計原理は何ですか?この記事では、概要の紹介と考察を提供します。
「制限」とは何ですか
コベナントは中国語で「制限」と訳され、「契約」と訳されることもあり、将来のビットコイン取引の条件を設定できるメカニズムです。
現在のビットコインスクリプトには、法的署名の入力や支出時に一致するスクリプトの送信などの制限条件も含まれています。ただし、ユーザーがロックを解除できる限り、好きな場所で UTXO を使用できます。
制限条項は、UTXO 後の支出を制限するなど、この制限を解除する方法に基づいてさらに制限を加えることで、「専用資金」やトランザクション待機で送信されるその他の入力条件と同様の効果を実現します。
より厳密に言えば、現在のビットコインスクリプトにも一定の制限があります。たとえば、オペレーションコードに基づく時間ロックは、トランザクションの nLock または nSequence フィールドをイントロスペクトすることでトランザクションが消費されるまでの時間制限を実現します。時間の制約に限定されます。
では、開発者や研究者はなぜこのような制限チェックを設計するのでしょうか?制限条項は、制限のための制限であるだけでなく、トランザクション実行のルールも設定するためです。このように、ユーザーは、あらかじめ設定されたルールに従ってトランザクションを実行するだけで、所定のビジネス プロセスを完了できます。
したがって、直感に反しますが、これにより、より多くのアプリケーション シナリオが可能になります。
アプリケーションシナリオ
ステーキングペナルティを確保する
制限条項の最も直感的な例の 1 つは、ビットコインのステーキング プロセスにおけるバビロンのスラッシュ トランザクションです。
Babylon のビットコインステーキングプロセスでは、ユーザーがメインチェーン上の特別なスクリプトに BTC 資産を送信します。支出条件には次の 2 種類があります。
ハッピーエンド: 一定の時間が経過すると、ユーザーは自分の署名でロックを解除でき、アンステークプロセスが完了します。
バッドエンド: ユーザーが Babylon によってリースされている特定の PoS チェーンで二重署名などの悪行を行った場合、EOTS (抽出可能なワンタイム署名、ワンタイム抽出可能な署名) を通じて、資産のこの部分のロックが解除される可能性があります。ネットワーク内の実行アクターは、アセットの一部を書き込みアドレス (スラッシュ) に強制的に送信します。
出典: ビットコインステーキング: プルーフオブステークエコノミーを確保するために 2,100 万ビットコインのロックを解除
ここでの「強制送信」に注意してください。これは、この UTXO のロックを解除できたとしても、アセットを任意に他の場所に送信することはできず、書き込みのみが可能であることを意味します。これにより、悪意のあるユーザーが処罰を逃れるために既知の署名を使用して資産を自分に転送することができなくなります。
OP_CTV などの制限が実装された後にこの関数が実装される場合、OP_CTV などのオペコードをステーキング スクリプトの「バッド エンディング」ブランチに追加して、制限を実装できます。
OP_CTV がアクティブ化される前に、Babylon はユーザーと委員会が共同で実装する柔軟な方法を使用して、制限条項を強制する効果をシミュレートする必要があります。
輻輳制御
一般的に、混雑とは、ビットコインネットワーク上の取引手数料が非常に高く、パッケージ化を待っているトランザクションがより多くトランザクションプールに蓄積されている場合を指します。そのため、ユーザーが取引を迅速に確認したい場合は、取引手数料を増やす必要があります。
このとき、利用者が複数の取引を複数の受取人に送金しなければならない場合には、手数料が増加し、比較的高額な費用を負担することになる。同時に、ネットワーク全体の処理速度もさらに向上します。
制限がある場合の解決策の 1 つは、送信者がバッチ送信トランザクションにコミットすることです。この約束により、すべての受信者は最終トランザクションが実行されると信じ込むことができ、処理率が低くなるまで特定のトランザクションを送信する前に待つことができます。
以下のグラフに示すように、ブロック領域の需要が高い場合、トランザクションの実行に非常にコストがかかります。 OP_CHECKTEMPLATEVERIFY を使用すると、大口決済処理業者は確認のためにすべての支払いを単一の O(1) トランザクションに集約できます。その後、時間の経過とともにブロック領域の需要が減少すると、支払いをその UTXO からスケールアウトできます。 
出典: https://utxos.org/uses/scaling/
このシナリオは、OP_CTV 制限条項によって提案される典型的なアプリケーション ケースです。上記の輻輳制御に加えて、このページには、ソフト フォーク ベット、分散型オプション、ドライブチェーン、バッチ チャネル、非インタラクティブ チャネル、トラストレス コーディネーション フリー マイニングがリストされています。プール、ボールト、より安全なハッシュ タイム ロック コントラクト (HTLCS) の制限など。
保管庫
Vault は、ビットコイン アプリケーション、特に制限条項の分野で広く議論されているアプリケーション シナリオです。日々の業務では必然的に資金の保管と資金の使用ニーズのバランスが必要となるため、人々は資金の安全性を確保し、たとえアカウントがハッキングされた場合でも資金のセキュリティを制限できる一種の保管庫アプリケーションを望んでいます（秘密キーは資金の使途が流出。
Vault クラスのアプリケーションは、制限を実装する手法に基づいて比較的簡単に構築できます。
OP_VAULT の設計を例に挙げます。ボールト内の資金を使用する場合、最初にトランザクションをチェーンに送信する必要があります。このトランザクションは、ボールトを使用する意図、つまり「トリガー」を示し、その中に条件を設定します。
すべて問題がなければ、2 番目のトランザクションで最後の出金が行われます。 N ブロック待った後、資金はどこでもさらに使用できます
このトランザクションが盗まれた（または「レンチ攻撃」中に強制された）ことが判明した場合は、N ブロックの出金トランザクションが送信される前に、トランザクションを別の安全なアドレス（ユーザーにとってより安全なストレージ）に即座に送信できます。
OP_VAULT のプロセス、ソース: BIP-345
ボールト アプリケーションは制限なく構築することもできることに注意してください。実現可能な方法は、秘密キーを使用して将来の支出に備えて署名を準備し、その後秘密キーを破棄することです。ただし、秘密鍵が確実に破棄されていることを確認する必要がある（ゼロ知識証明における信頼できるセットアップ プロセスと同様）、金額と手数料が事前に決定されている（秘密鍵が破棄される必要があるため）など、依然として多くの制限があります。事前署名）、柔軟性に欠けています。
OP_VAULT と署名済みボールト プロセスの比較、出典: BIP-345
より堅牢で柔軟な状態チャネル
ライトニングネットワークを含むステートチャネルは、一般にメインチェーンとほぼ同等のセキュリティを持っていると考えられます（ただし、ノードが最新のステータスを監視でき、通常は最新のステータスをチェーンに公開できる場合）。ただし、制限が設けられている場合、一部の新しいステート チャネル設計アイデアは、ライトニング ネットワーク上でより堅牢または柔軟になる可能性があります。より有名なものには、Eltoo、Ark などが含まれます。
Eltoo (LN-Symmetry としても知られる) は、より典型的な例の 1 つです。この技術ソリューションは「L2」と同義であり、ペナルティ メカニズムを必要とせずに後続のチャネル状態を前の状態に置き換えることを可能にする Lightning ネットワークの実行層を提案します。したがって、Lightning と同様に保存する必要性も回避できます。ネットワークノード。対戦相手の悪事を防ぐための複数の以前の状態。上記の効果を達成するために、Eltoo は SIGHASH_NOINPUT 署名方法、すなわち APO (BIP-118) を提案しました。
Ark は、ライトニング ネットワークのインバウンド流動性とチャネル管理の困難を軽減することを目的としています。これは、ジョインプール形式のプロトコルであり、複数のユーザーが一定期間内にサービス プロバイダーをカウンターパーティとして受け入れ、チェーンの外部で仮想 UTXO (vUTXO) トランザクションを実行できますが、コストを削減するためにチェーン上で UTXO を共有します。ボールトと同様に、Ark は現在のビットコイン ネットワークにも実装できますが、制限を導入した後、Ark はトランザクション テンプレートに基づいて必要な対話の量を削減し、よりトラストレスな一方的な終了を実現できます。
制限の技術的概要
上記のアプリケーションからわかるように、制限条項は特定のテクノロジーというよりは効果に近いため、制限条項を実装するには多くの技術的な方法があります。分類されている場合、これには次のものが含まれる可能性があります。
タイプ：一般型、特殊型
実装方法：オペコードベース、シグネチャベース
再帰: 再帰的、非再帰的
このうち、再帰とは、いくつかの制限句の実装を指します。追加された制限は 1 つのトランザクションを超え、より高いトランザクションの深さに達する可能性があります。
一般的な制限条項の設計には次のようなものがあります。 
* 再帰: OP_CAT と組み合わせた場合
制限の設計
前の紹介からわかるように、現在のビットコイン スクリプトは主にロック解除の条件を制限しており、UTXO のさらなる使用方法は制限していません。制限を実装するには、逆に考える必要があります。なぜ現在のビットコイン スクリプトでは制限を実装できないのでしょうか?
主な理由は、現在のビットコイン スクリプトがトランザクション自体の内容、つまりトランザクションの「イントロスペクション」を読み取ることができないことです。
トランザクションの内容 (出力を含む) を検査するトランザクション イントロスペクションを実装できれば、制約を実装できます。
したがって、制限条項の設計上の考え方は、主に内省をどのように実現するかに焦点を当てています。
オペコードベースとシグネチャベース
最も単純かつ大雑把なアイデアは、トランザクションの内容を直接読み取るために 1 つ以上のオペコード (つまり、1 つのオペコード + 複数のパラメーター、または異なる関数を持つ複数のオペコード) を追加することです。これはオペレーションコードに基づいた考え方です。
もう 1 つのアイデアは、スクリプト内でトランザクション自体の内容を直接読み取って確認することはできませんが、トランザクション内容のハッシュを使用できるということです。ハッシュが署名されている場合は、OP_CHECKSIG After などのスクリプト内で変更するだけです。この署名をチェックすることで、トランザクションのイントロスペクションと制限を間接的に実装できます。このアイデアはシグネチャーデザインに基づいています。主にAPOやOP_CSFSなどが含まれます。
アポ
SIGHASH_ANYPREVOUT (APO) は、ビットコインの署名方法として提案されています。署名する最も簡単な方法は、トランザクションの入力と出力の両方にコミットすることですが、ビットコインには、トランザクションの入力または出力を選択的にコミットする、より柔軟な方法、つまり SIGHASH もあります。
SIGHASH の現在の署名範囲とトランザクションの入力と出力のその組み合わせ (出典: 「Mastering Bitcoin, 2 nd」)
上の図に示すように、すべてのデータに適用される ALL に加えて、NONE 署名メソッドはすべての入力にのみ適用され、出力には使用されません。SINGLE はこれに基づいており、同じ入力シーケンス番号を持つ出力にのみ適用されます。さらに、ANYONECANPAY モディファイアを重ねた後、SIGHASH を組み合わせることもできます。これは 1 つの入力にのみ適用されます。
APO の SIGHASH は出力のみに署名し、入力部分には署名しません。これは、APO で署名されたトランザクションを、後で条件を満たす任意の UTXO にアタッチできることも意味します。
この柔軟性は、APO が制限条項を実装するための理論的基盤です。
1 つ以上のトランザクションを事前に作成できます
これらのトランザクションの情報を使用して、署名のみを取得できる公開鍵が構築されます。
このようにして、その公開鍵アドレスに送信された資産は、事前に作成されたトランザクションを通じてのみ使用できます。
この公開キーには対応する秘密キーがないため、これらの資産は事前に作成されたトランザクションを通じてのみ使用できることが保証されることに注意してください。次に、これらの事前作成されたトランザクションで資産の宛先を規定して、制限条件を実装できます。
イーサリアムのスマート コントラクトを比較すると、さらに理解できます。スマート コントラクトを通じて達成できることは、EOA 署名で任意にお金を使うのではなく、特定の条件を通過した場合にのみコントラクト アドレスからお金を引き出すことができるということです。この観点から見ると、ビットコインは署名メカニズムの改善を通じてこの効果を達成できます。
しかし、上記のプロセスの問題は、トランザクションを事前に署名して作成するために入力を認識する必要があるため、計算に循環依存関係が存在することです。
この署名メソッドを実装する APO と SIGHASH_NOINPUT の重要性は、計算時に、トランザクションのすべての出力を知る (指定する) だけで済むことです。
OP_CTV
OP_CHECKTEMPLATEVERIFY (CTV)、BIP-119 では、オペコードを改善する方法が採用されています。これはコミットメント ハッシュをパラメータとして受け取り、オペコードを実行するトランザクションにはそのコミットメントに一致する一連の出力が含まれている必要があります。 CTV を通じて、ビットコイン ユーザーはビットコインの使用方法を制限できるようになります。
この提案はもともと OP_CHECKOUTPUTSHASHVERIFY (COSHV) という名前で発表され、初期には輻輳制御トランザクションを作成する機能に焦点を当てていたため、この提案に対する批判は、このスキームが十分に一般的ではなく、輻輳制御のユースケースに特化しすぎていることにも焦点を当てていました。
前述の輻輳制御の使用例では、送信者のアリスは 10 個の出力を作成してハッシュし、結果のダイジェストを使用して COSHV を含むタップリーフ スクリプトを作成できます。また、Alice は参加者の公開鍵を使用して Taproot 内部鍵を形成することもでき、Taproot スクリプト パスを明らかにすることなく参加者が協力して支出を行うことができます。
次に、アリスは各受信者に 10 個の出力すべてのコピーを渡し、各受信者がアリスのセットアップ トランザクションを検証できるようにします。後で支払いを使いたいときは、どちらかが約束された出力を含むトランザクションを作成できます。
プロセス全体を通じて、Alice がセットアップ トランザクションを作成して送信すると、Alice は電子メールやクラウド ドライブなどの既存の非同期通信方法を介して出力の 10 個のコピーを送信できます。これは、受信者がオンラインである必要も、受信者同士がやり取りする必要もないことを意味します。
出典: https://bitcoinops.org/en/newsletters/2019/05/29/#proused-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 に割り当てられ、22 年と 23 年に CTV 契約のサポートを作成するためのプログラミング言語 Sapio として登場しました。そのアクティベーション計画に関する議論は、コミュニティ内で最もよく議論されているソフト フォーク アップグレード提案の 1 つです。
OP_CAT
冒頭で紹介したように、OP_CATも現在注目を集めているアップグレード案であり、スタック内の2つの要素を連結（concatenante）する機能を実装しています。単純そうに見えますが、OP_CAT は非常に柔軟で、スクリプトに多くの関数を実装できます。
最も直接的な例は、マークル ツリーに関連する操作です。マークル ツリーは、2 つの要素が最初に結合され、次にハッシュされるものとして理解できます。現在、ビットコインスクリプトには OP_SHA 256 などのハッシュオペレーションコードがあるため、OP_CAT を使用して 2 つの要素を結合できれば、マークルツリーの検証機能をスクリプトに実装でき、特定のクライアントに対する軽い検証も行うことができます。程度。
追加の実装基盤には、Schnorr 署名の機能強化も含まれています。スクリプトの署名条件をユーザーの公開キーと公開 nonce の結合に設定すると、署名者が別のトランザクションに署名したい場合、資金が別の場所に使用されます。同じ nonce を使用して秘密鍵を漏洩させます。つまり、ノンスへのコミットメントは OP_CAT を通じて実現され、それによって署名されたトランザクションの正当性が保証されます。
OP_CAT のその他のアプリケーション シナリオには、バイストリーム、ツリー署名、耐量子ランポート署名、ボールトなどが含まれます。
OP_CAT 自体は新しい機能ではありませんが、ビットコインの初期のバージョンには存在していましたが、攻撃に悪用される可能性があるため 2010 年に無効になりました。たとえば、OP_DUP と OP_CAT を再利用すると、そのようなスクリプトを処理するときに完全なノードでスタックが爆発する可能性があります。このデモを参照してください。
しかし、ここで OP_CAT を再度有効にすると、上記のスタック爆発の問題は発生しなくなりますか?現在の OP_CAT 提案では、tapscript での有効化のみが必要であり、tapscript では各スタック要素が 520 バイト以下に制限されているため、以前のスタック爆発の問題は発生しません。サトシ・ナカモトによるOP_CATの直接禁止は厳しすぎるのではないかと考える開発者もいます。ただし、OP_CAT の柔軟性により、脆弱性を引き起こす可能性のある一部のアプリケーション シナリオは現時点では解決できません。
したがって、アプリケーションのシナリオと潜在的なリスクを考慮して、OP_CAT は最近大きな注目を集めており、現在最も人気のあるアップグレード提案の 1 つです。
結論
「自己規律は自由をもたらします。」 上記の紹介からわかるように、制限条項をビットコイン スクリプトに直接実装して、さらなるトランザクション支出を制限することで、スマート コントラクト効果と同様のトランザクション ルールを実現できます。 BitVM などのオフチェーン手法と比較して、このプログラミング手法はビットコイン上でよりネイティブに検証でき、メイン チェーン上のアプリケーション (輻輳制御)、オフチェーン アプリケーション (ステータス チャネル)、およびその他の新しいアプリケーションの方向性も改善できます (ステーキングペナルティなど）。
制限条項の実装テクノロジーを基盤となるアップグレードと組み合わせることができれば、プログラマビリティの可能性がさらに解き放たれます。たとえば、最近検討されている 64 ビット オペレーターの提案は、提案されている OP_TLUV や、トランザクションによって出力される SATOSHI の数に基づいてプログラムできるその他の制限とさらに組み合わせることができます。
ただし、制限的な条件は予期せぬ悪用や抜け穴につながる可能性があるため、コミュニティもこれについてはより慎重になっています。さらに、制限条項のアップグレードには、コンセンサス ルールのソフト フォーク アップグレードも必要です。タップルート アップグレード中の状況を考慮すると、制限に関連するアップグレードも完了までに時間がかかる可能性があります。
この記事に対するレビューと提案をしてくれた Ajian、Fisher、Ben に感謝します。
参考文献
https://utxos.org/
規約に関連するリソースのコレクション:
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-final2 8.pdf
https://maltemoeser.de/paper/covenants.pdf
https://bitcoinops.org/en/topics/op_cat/
OP_CAT:
https://github.com/bitcoin-inquisition/binana/blob/master/2024/BIN-2024-0001.md
CAT と Schnorr のトリック: https://medium.com/blockstream/cat-and-schnorr-tricks-i-faf1b59bd298
