ハッシュキー・キャピタル：ビットコイン「コベナンツ」のプログラム可能性

投稿者：HashKey Capital 投資調査部長 Jeffrey HU、HashKey Capital投資マネージャー Harper LI

最近、ビットコインコミュニティでは、OP_CATなどのオペコードの再有効化に関する議論が相次いでいます。 Taproot Wizardはまた、NFT for Quantum Catsのスルーを開始しました、また、Taproot WizardはQuantum CatsのNFTを立ち上げ、BIP-420番号を取得したなどと主張し、注目を集めている。支持者は、OP_CATがビットコインの「コベナンツ」、スマートコントラクト、またはプログラマビリティを可能にすると主張している。

「コベナンツ」という言葉に気づいて少し検索してみれば、これも大きなウサギの穴であることがわかるだろう。OP_CATに加えて、OP_CTV、APO、OP_VAULT、および制限条項を実装するための他のテクニックがあります。

では、ビットコインの「制限条項」とは一体何なのでしょうか？なぜ長年にわたって、開発者からこれほど注目され、議論されてきたのでしょうか？ビットコインのどのようなプログラマビリティを実現できるのか？その背景にある設計原理とは？この記事では、その概要と考察を試みます。

「コベナンツ」とは

「契約」と訳されることもあるコベナンツは、将来のビットコイン取引に条件を設定できる仕組みです。

現在のビットコインのスクリプトにも、支出時に正規の署名を入力する、適合したスクリプトで送信する、などの制限が含まれている。しかし、ユーザーがロックを解除することさえできれば、UTXOを好きな場所で使うことができる。

一方、制限には、UTXOのロックを解除する方法に関するこの制限を超えて、UTXOが使われた後にいくら使えるかを制限する、すなわち「earmarked」効果のようなものを達成するため、あるいは取引に投入できる他のインプットなど、さらなる制限が含まれます

制限には、UTXOを使う方法に関する制限も含まれます。

より厳密には、現在のビットコインスクリプトには、オペコードベースの時間ロックなどの制限があり、トランザクションのnLockまたはnSequenceフィールドをイントロスペクトすることで、トランザクションが消費できるまでの時間を制限しているが、大部分は時間に制限されている。

では、なぜ開発者や研究者はこのような制限チェックを設計するのでしょうか？なぜなら、制限は単に制限のための制限ではなく、トランザクションが実行される際のルールを設定するものだからです。こうすることで、ユーザーは事前に定義されたルールに従ってのみトランザクションを実行することができ、意図したビジネスプロセスを完成させることができるのです。

そのため、これがより多くのアプリケーションシナリオを解き放つ可能性があることは、より直感に反することです。

Application scenarios

Ensuring penalties for Staking

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

バビロンのビットコイン・ステーキング・プロセスでは、ユーザーはメイン・チェーン上のBTC資産を、2つの消費条件を持つ特別なスクリプトに送信します:

• ハッピーエンド：一定時間後、ユーザーは自分の署名でロックを解除できる、つまりアンステークプロセスを完了する

• 悪い結末：もしユーザーが、セキュリティのためにバビロンがリースしているPoSチェーンに二重署名している場合、資産のこの部分は、EOTS（抽出可能な1回限りの署名）を通じてロックを解除することができ、資産の一部は、実行ロールによって強制的にネットワークに送信することができます。実行ロールによって資産の一部を強制的に燃焼アドレス（スラッシュ）

ソース:Bitcoin Staking: Unlocking 21 M Bitcoins to Secure the Proof-of-Stake Economy

ここでの「強制送信」に注目してください。これは、UTXOのロックが解除できたとしても、資産を焼却以外の場所に送ることができないことを意味します。これは、たとえUTXOのロックが解除できたとしても、アセットを焼却以外の場所に送ることができないことを意味します。これにより、悪意のあるユーザーが、自分自身の既知のシグネチャを使用して、アセットを自分自身に転送して逃げることができないことを保証します。

この機能は、OP_CTVのような制限で実装されている場合、OP_CTVのようなオペコードをステーキングスクリプトの「バッドエンディング」ブランチに追加することで実装できます。

OP_CTVが有効になる前に、Babylonは、ユーザー＋委員会が協力することで、制限を強制する効果をシミュレートする回避策を必要としていました。

混雑制御

一般的に言えば、混雑とは、ビットコインネットワークの手数料率が高く、プールでパッケージされるのを待っている取引がたくさんある場合です。処理手数料を上げる必要がある。

この時点で、ユーザーが複数の受取人に複数のトランザクションを送信しなければならない場合、手数料を引き上げ、より高いコストを負担しなければならない。これはまた、ネットワーク全体の手数料率を押し上げる。

制限がある場合の1つの解決策は、まず送信者が一括送信される1つのトランザクションにコミットすることです。このコミットメントにより、最終的なトランザクションは通過し、特定のトランザクションを送信する前に手数料率が低くなるまで待つことができると、すべての受信者を納得させることができます。

以下に示すように、ブロックスペースの需要が高い場合、トランザクションを行うには非常にコストがかかります。OP_CHECKTEMPLATEVERIFYを使用することで、大量の支払いを行うプロセッサーは、すべての支払いをO(1)の単一トランザクションに集約して確認することができる。その後、ブロックスペースの必要性が減少する一定期間後に、支払いをそのUTXOから拡張することができます。

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

このシナリオは、このOP_CTV但し書きが提示する典型的なユースケースの1つです。上記の輻輳制御に加えて、このページにはソフトフォークベット、分散型オプション、ドライブチェーン、バッチチャネル、非対話型チャネル、トラストレスコーディネーション-フリーの輻輳制御が掲載されています。チャンネル、トラストレスコーディネーションフリーマイニングプール、保管庫、より安全なハッシュドタイムロックコントラクト（HTLCS）制限、などが挙げられています。

保管庫

保管庫は、特に制限の分野において、ビットコインのより広く議論されているアプリケーションシナリオの1つです。日々の運用では、資金を安全に保管する必要性と資金を使用する必要性のバランスを取ることが避けられないため、保管庫アプリケーションのクラスが望まれています：資金を安全に保管し、アカウントがハッキング（秘密鍵の漏洩）された場合でもその使用を制限することができるアプリケーションです。

保管庫クラスのアプリケーションは、制限条項を実装する技術に基づいて、比較的簡単に構築できます。

OP_VAULTの設計を例にとると、保管庫で資金を使うには、まずトランザクションをチェーン上に送信する必要がある。このトランザクションは、金庫を使用する意図、すなわち「トリガー」を示し、その中に条件が設定されています。何も問題がなければ、2番目のトランザクションが最終的な引き出しとなります。Nブロック待った後、資金はさらにどこでも使うことができます

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

制限条項のないデータ保管庫アプリケーションを構築することが可能であることに留意すべきである。しかし、秘密鍵が破棄されたことを確認する必要がある（ゼロ知識証明における信頼されたセットアッププロセスに似ている）、（事前署名のため）事前に金額や手数料を決定する柔軟性に欠ける、などの制限がまだある。

.

OP_VAULTと署名済み保管庫プロセスの比較、出典：BIP-345 

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

一般的に、ライトニング・ネットワークを含むステート・チャネルは、メインチェーンとほぼ同レベルのセキュリティ（ノードが最新の状態を観察し、最新の状態を適切にチェーンに投稿できることを保証するという点）を持っていると仮定できます。ただし、新しいステート・チャネルの設計アイデアの中には、ライトニング・ネットワークの上でより堅牢で柔軟なものになるものもある。よりよく知られているものには、EltooやArkなどがあります。

Eltoo（LN-Symmetryとしても知られる）はその代表例です。L2」という言葉をもじったこの技術的ソリューションは、ライトニング・ネットワークのエンフォースメント・レイヤーを提案するもので、ペナルティ・メカニズムを必要とすることなく、後の任意のチャネル状態が前の状態に取って代わることを可能にし、その結果、ライトニング・ネットワーク・ノードが敵対者の悪行を防ぐために前の状態を複数保存する必要性も回避します。上記の効果を得るために、EltooはSIGHASH_NOINPUTシグネチャ、APO（BIP-118）を提案している。

一方、Arkは、ライトニングネットワークにおけるインバウンドモビリティとチャネル管理の難しさを軽減することを目的としている。これはジョインプール形式のプロトコルであり、複数のユーザーがサービスプロバイダを一定期間カウンターパーティとして受け入れ、オフチェーンでは仮想UTXO（vUTXO）を取引しますが、オンチェーンでは単一のUTXOを共有してコストを削減します。Vaultingと同様に、Arkは現在のビットコインネットワークに実装することができます。しかし、制限を導入することで、Arkはトランザクションテンプレートに基づいて必要な相互作用の量を減らすことができ、より非信頼的な一方的な出口を可能にします。

制限技術の概要

上記のアプリケーションからわかるように、制限は技術というよりも効果であり、そのため、それを実装する方法はたくさんあります。p style="text-align: left;">実装: オプコードベース、署名ベース

また、とりわけ再帰性とは、次のトランザクションの出力を次のトランザクションの出力に制限することで、次のトランザクションの出力も制限する制限の実装があり、追加される制限が単一のトランザクションを超えて、より高い深さのトランザクションにまで及ぶことが実現できることを意味します。

主流の制限条項の設計には、次のようなものがあります：

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

Design of Restriction Clauses

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

主な理由は、現在のビットコインスクリプトはトランザクション自体、つまりトランザクションの「イントロスペクション」を読むことができないからです。

トランザクションのイントロスペクションを実装できれば、トランザクション内のあらゆるもの（出力を含む）を調べることができ、制限条項が実装されるでしょう。

そのため、制限条項の設計思考も、どのようにイントロスペクションを実装するかを中心に展開されます。

オペランドベースとシグネチャベースの比較

最も単純で粗雑なアイデアは、トランザクションを直接読み取るために、1つ以上のオペコード（すなわち、1つのオペコード＋複数のパラメータ、または異なる機能を持つ複数のオペコード）を追加することです。これもオペコードの考えに基づいている。これもまた、オペコードに基づいた考え方である。

別の考え方としては、トランザクションの内容そのものをスクリプトで直接読み取ってチェックする代わりに、トランザクションの内容のハッシュを使用することができます。この署名のチェックを可能にするために、トランザクションのイントロスペ クションと制限条項を間接的に実装することができる。この考え方は、シグネチャ設計アプローチに基づいている。主なものはAPOとOP_CSFSである。

APO

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

SIGHASHとそのポートフォリオによるトランザクションの入力と出力に対する現在の署名の範囲（出典「Mastering Bitcoin, 2 nd"

上図のように、すべてのデータに適用されるALLに加えて、NONEの署名はすべての入力にのみ適用され、出力には適用されない。さらに、SIGHASHは、ANYONECANPAY修飾子を重ね合わせて、単一の入力にのみ適用することができます。

一方、APOのSIGHASHは、入力ではなく出力にのみ署名します。つまり、APOで署名されたトランザクションは、条件を満たすどのUTXOにも添付することができます。

この柔軟性が、APOによる制限条項の実施の理論的根拠です。paddingleft-2">

この公開鍵には秘密鍵の対応するものがないため、注目に値します。は、これらの資産が事前に作成されたトランザクションを通じてのみ使用できることを保証できる。そして、これらの事前に作成されたトランザクションの中で、資産の行き先を指定することで、制限条項を実装することができる。

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

しかし、上記のプロセスの問題点は、事前に署名してトランザクションを作成するために入力を知る必要があるため、計算に循環依存性があることです。

APOとSIGHASH_NOINPUT のこの署名の実装の意義は、計算時に（指定された）トランザクションの完全な出力を知るだけでよいので、循環依存の問題を解決できることです。

OP_CTV

OP_CHECKTEMPLATEVERIFY (CTV)、またはBIP-119は、Opcodeに改良されたアプローチを取ります。これはコミットメントハッシュを引数として取り、オペコードを実行するすべてのトランザクションがそのコミットメントに一致する一連の出力を含むことを要求します。CTVによって、ビットコインユーザーはビットコインの使用方法を制限できるようになります。

当初はOP_CHECKOUTPUTSHVERIFY（COSHV）として導入され、輻輳制御トランザクションを作成する機能に初期の焦点が当てられていましたが、この提案に対する批判は、それが十分に汎用的ではなく、輻輳制御ユースケースに特化しすぎているという事実にも集中しています。

前述の輻輳制御のユースケースでは、送信者であるAliceは10個の出力を作成し、その10個の出力をハッシュ化し、その結果のダイジェストを使ってCOSHVを含むタップリーフスクリプトを作成することができる。Aliceはまた、参加者の公開鍵を使用してTaproot内部鍵を形成し、Taprootスクリプトへのパスを明かすことなく支出を共同作業できるようにすることができる。

それからアリスは、各受取人がアリスのセットアップトランザクションを検証できるように、10個の出力すべてのコピーを各受取人に渡す。後で支払いを使いたいとき、彼らの誰もが約束された出力でトランザクションを作成することができます。

アリスがセットアップトランザクションを作成し送信する間、アリスは電子メールやクラウドドライブなどの既存の非同期通信手段を通じて、10個のアウトプットのコピーを送信することができる。これは、受信者がオンラインである必要も、お互いにやりとりする必要もないことを意味します。

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

APOと同様に、アドレスは支出条件に基づいて構築することができ、「ロック」はさまざまな方法で作成することができます。

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

CTVはこれをベースにしている。CTVは、ハッシュ消費されたトランザクションが定義されたものと一致するかどうかをチェックする機能、すなわちトランザクションデータを「ロック」を解除するためのキーとして使用する機能を提案することによって、これを構築する。

上記の10人の受信者の例を拡張することができ、その受信者はさらに次の受信者のアドレスのバッチに、署名されているがブロードキャストされていないtxとして自分のアドレスキーを設定することができ、以下の図に示すようなツリー構造を形成する。アリスは、複数のユーザーを巻き込んだアカウント残高の変更を構築するために、チェーン上のブロックスペースの1ユートだけを使います。

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

また、葉の1つがライトニング・チャンネルであったり、コールドストレージであったり、その他の支払い経路であったりしたらどうだろう？そうすれば、ツリーは1次元の多層経費ツリーから多次元の多層経費ツリーへと拡大し、サポートできるシナリオはより豊かで柔軟なものになるでしょう。

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

CCTVは、その提案以来、2019年にCOSHVから名称変更を受け、2020年にBIP-119 を割り当てられ、CTVをサポートする契約を作成するために使用されるプログラミング言語であるSapioとして登場し、22、 23でそれのための多くのコミュニティ議論、更新、および活性化オプションを受けています。Sapioは、22年と23年にコミュニティで多くの議論、更新、そしてその有効化方式についての議論を受けており、今でもコミュニティでより議論されているソフトフォークアップグレード案の1つです。

OP_CAT

OP_CAT も、冒頭で説明したように、現在多くの注目を集めているアップグレード提案で、スタックの2つの要素を連結する機能（「concatenante」）を実装しています。concatenante) を実装している。シンプルに見えますが、OP_CATは非常に柔軟で、スクリプトで実装することができます。

この最も直接的な例は、2つの要素が連結された後にハッシュ化されると解釈できる、メルクルツリーの操作です。現在、ビットコインのスクリプトには、ハッシュを表すOP_SHA 256などのオペコードがあるので、OP_CATを使ってこれを実装できれば現在のビットコインスクリプトにはハッシュにOP_SHA 256などのオペコードがあるので、OP_CATを使って2つの要素をスプライスすることができれば、メルクルツリーの検証機能をスクリプトに実装することができ、ある程度ライトクライアントの検証機能を持つことができます。

もう1つの実装基盤には、シュナー署名の拡張があります。スクリプトのspend署名条件を、ユーザーの公開鍵と公開nonceの連結に設定できます。署名者が別のトランザクションに署名して別の場所で資金を使いたければ、同じnonceを使用しなければならず、秘密鍵の漏洩につながる。つまりOP_CATは、署名されたトランザクションの有効性を保証するために、nonceのコミットメントを可能にする。

OP_CATの他のシナリオには、Bistream、ツリー署名、量子に強いLamport署名、保管庫などがあります。

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

しかし、OP_CATを今再び有効にしても、前述のスタック爆発の問題は起こらないのでしょうか？現在のOP_CATの提案は、スタック要素あたり520バイト以下に制限されているtapscriptで有効にするだけなので、以前のようなスタック爆発の問題は発生しません。また、サトシ・ナカモトがOP_CATを完全に無効にするのは厳しすぎるのではないかと考える開発者もいる。しかし、OP_CATの柔軟性により、脆弱性につながるようなアプリケーション・シナリオが現時点では排除できないことも事実でしょう。

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

結論

「自己規制は自由をもたらす」のであり、上記の紹介からわかるように、制限条項はビットコインのスクリプトに直接実装して、スマートコントラクトと同様の効果を達成するために、トランザクションのさらなる支出を修飾することができます。取引ルール。このプログラミングアプローチは、BitVMのようなオフチェーンアプローチよりもビットコイン上でネイティブに検証することができ、メインチェーン上のアプリケーション（輻輳制御）、オフチェーンアプリケーション（ステートチャネリング）、その他のアプリケーションの新しい方向性（ステーキングペナルティなど）を改善することもできます。

制約の実装技術は、いくつかの基本的なアップグレードと組み合わせれば、プログラマビリティの可能性をさらに引き出すことができます。たとえば、レビュー中の64ビット演算子に関する最近の提案は、提案されたOP_TLUVや、トランザクションによって出力されたサトシの数に基づいてプログラム可能な他の制約とさらに組み合わせることができます。

しかし、制限条項は意図しない悪用や脆弱性につながる可能性もあるため、コミュニティは警戒しています。さらに、制限条項のエスカレーションは、コンセンサスルールのソフトフォークアップグレードを伴う必要がある。タップルートのアップグレードを取り巻く状況を考えると、制限に関連するアップグレードも完了までに時間がかかるかもしれません。

レビューと提案をしてくれたJian氏、Fisher氏、Ben氏に感謝する！

参考文献
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-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