コヴェナントの探求：ビットコインにネイティブ・プログラマビリティをもたらす方法

By Jeffrey HU & Harper LI, HashKey Capital

最近、ビットコインコミュニティでは、OP_ATのようなオペコードの再有効化に関する議論が活発になっています。

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

「制限的誓約（restrictive covenants）」という用語に気づいて少し検索してみると、これも大きなウサギの穴であることがわかります。OP_CATに加えて、OP_CTV、APO、OP_VAULT、および制限条項を実装するための他のテクニックがあります。

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

「制限」とは何か？制限」とは

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

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

制限とは、UTXOのロックを解除する方法に対する制限ですが、例えば、UTXOが使われた後、そのUTXOにいくら使うことができるかを制限する、つまり「イーマーキング」効果のようなものを実現する、あるいは、UTXOが使われた後、そのUTXOにいくら使うことができるかを制限する、あるいは、1つのトランザクションに対して、他にどのような入力を送ることができるかを制限する。トランザクションに投入される条件など。最終的には、制限をビットコインのスクリプトに直接実装して、トランザクションのさらなる支出を制限することで、スマートコントラクトの効果に似たトランザクションルールを実現することができます。

より厳密に言えば、現在のビットコインスクリプトには、トランザクションのnLockまたはnSequenceフィールドをイントロスペクトすることで実装され、トランザクションが費やされるまでの時間を制限するopcodeベースの時間ロックなどの制限もあるが、時間的な制約に大きく制限されている。

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

そのため、むしろ直感に反して、これはより多くのアプリケーションシナリオをアンロックします。

誓約書の適用シナリオ

杭打ちの罰則を確実にする！

制限条項の最も直感的な例の1つは、ビットコインのステーキングプロセスにおけるバビロンのスラッシュ取引です。align: left;">ハッピーエンド：一定の時間が経過すると、ユーザーは自分の署名でロックを解除できる、つまり、ステーキング解除のプロセスが完了する

バッドエンド：ビットコインのステーキングプロセスの中で、最も直感的な例として、バビロンのスラッシュ取引がある。エンディング：ユーザーがバビロンによってセキュリティをリースされているPoSチェーン上で二重署名している場合、資産のその部分はEOTS（抽出可能な1回限りの署名）を介してロックを解除することができ、資産の一部は、ネットワーク内の実行ロールによって強制的にバーニングアドレス（スラッシュ）に送信することができます。焼却アドレス（スラッシュ）に送られる

(Source: Bitcoin Staking: Unlocking 21M Bitcoins to Secure the Proof-of-Stake Economy)

「Bitcoin Staking: Unlocking 21M Bitcoins to Secure the Proof-of-Stake Economy」。ここでの「強制送信」に注目してください。つまり、この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 ブロック待った後、資金はさらにどこでも使うことができる

盗まれた（あるいは「スパナ攻撃」の間に強要された）のがこの取引であることが判明した場合、N ブロックの引き出し取引が送信される前に、別の安全なアドレスにすぐに送信することができる（ユーザーにとってより安全な保管）

（OP_VAULTのプロセス、ソースはこちら。: BIP-345)

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

(OP_VAULT)vs. 署名前の保管庫プロセス、出典：BIP-345）

More Robust and Flexible State Channels

一般的に、次のように主張することができます。ライトニング・ネットワークを含むステート・チャネルは、メインチェーンとほぼ同等のセキュリティを持っています（ノードが最新の状態を観察していることが保証され、最新の状態を適切にチェーンにポストできるという意味で）。しかし、制約を考慮すれば、ライトニング ネットワークよりも堅牢で柔軟な新しいステート チャネル設計のアイデアもあります。よりよく知られているものには、Eltoo、Arkなどがあります。

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

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

コベナンツ技術の概要

上記のアプリケーションからわかるように、コベナンツ制限は技術というより効果です。それを実行するための技術的な方法はたくさんあります。

種類：一般的な、特殊な

実装

ImplementationsOpcode-based, Signature-based

Recursive:Recursive, Non-recursive

そしてこれらのうち、再帰的：があります。制限が実装されており、また、次の出力を制限することで、1つのトランザクションを超えて、より高い深さのトランザクションに進むことができる追加を実装することが可能である。

主な制限の設計には以下のようなものがあります：

制限条項条項の設計

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

主な理由は、現在のビットコインスクリプトは取引自体の内容、つまり取引の「内観」を読むことができないからです。

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

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

Operand-based vs. signature-based

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

別の考え方としては、トランザクションの内容そのものをスクリプトで直接読み込んでチェックする代わりに、トランザクションの内容のハッシュを使うことができる。このハッシュがすでに署名されている場合、スクリプトに例えば OP_CHECKSIGなどを後付けするだけで、この署名のチェックを可能にし、間接的にトランザク ションのイントロスペクションと制限句を実装することができる。この考え方は、署名設計アプローチに基づいている。主なものはAPOとOP_CSFSである。

APO

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

現在のSIGHASHの範囲と、トランザクションの入力と出力に対する署名の組み合わせ（出典：「ビットコインを使いこなす、第2回」

上図のように、すべてのデータに適用されるALLを除き、NONEは出力ではなくすべての入力のみに適用されるように署名され、SINGLEは同じ入力シリアル番号を持つ出力のみに適用されるように署名される。SINGLEはこれに基づいており、同じ入力シリアル番号を持つ出力にのみ適用される。さらに、SIGHASHは、ANYONECANPAY修飾子を重ねて、単一の入力にのみ適用するように組み合わせることができます。

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

この柔軟性が、APOによる制限条項の実装の理論的根拠です：UTXOへのAPOの適用は問題ありません。制限条項の実装の理論的根拠：

1つまたは複数のトランザクションを事前に作成することができる

これらのトランザクションの情報は、1つの署名のみを導き出すことができる公開鍵を構築するために使用される

そのため、その公開鍵アドレスに送られたアセットは、事前に作成されたトランザクションを通じてのみ使用することができます

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

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

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

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

OP_CTV

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

当初はOP_CHECKOUTPUTSHASHVERIFY (COSHV)として導入され、輻輳制御トランザクションを作成する機能に初期の焦点が当てられていました。

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

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

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

（出典：https://bitcoinops.org/ja/newsletters/2019/05/29/#proposed-transaction-output-commitments)

APOのようなものです。同様に、アドレスは支出条件に基づいて構築することができ、「ロック」は他のキーの追加、タイムロック、コンポーザブル・ロジックなど、さまざまな方法で行うことができます。

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

CTVは、ハッシュトランザクションが、使用済みトランザクションが定義されたマッチングに一致するかどうかをチェックできること、つまりトランザクションデータを「ロック」を解除するキーとして使用できることを提案することで、これをベースにしている。

上記の10人のレシーバーの例を拡張することができる。レシーバーはさらに、署名されているがブロードキャストされていないtxとしてそのアドレスキーを次のバッチのレシーバーのアドレスに設定することができ、以下の図に示すようなツリー構造を形成する。

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

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

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

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

OP_CAT

OP_CAT も、冒頭で説明したように、現在非常に人気のあるアップグレード案で、スタックの2つの要素を連結する機能を実装しています。concatenanteです。シンプルに見えますが、OP_CATはスクリプトでできることに柔軟性があります。

この最も直接的な例はメルクルツリーの操作であり、これはまず2つの要素が連結され、次にハッシュ化されると解釈できます。現在、ビットコインスクリプトにはOP_SHA256のようなハッシュオプコードがあるため、OP_CATを使って2つの要素を連結することができれば、OP_CATを使って同じことを行うことが可能です。CATで2つの要素の連結を実現するには、スクリプトにメルクルツリーの検証機能を実装すればよく、ある程度、ライトクライアントを検証する機能がある。

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

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

OP_CAT自体は新しい機能ではありません。OP_CATはビットコインの初期のバージョンに存在していましたが、悪用の可能性があるため2010年に無効化されました。

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

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

結論

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

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

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