フラクタル・ビットコインOP_CAT：制限条項の技術的詳細

著者：gangzhu 来る：X, @bangzhu_x

制限条項案としてのOP_CATを理解する

OP最近347のBIP番号を得た制限条項提案としてのOP_CAT。まず、「制限条項（covenant）」とは何かを理解しよう。

 1. まず、現在存在するビットコインスクリプトの基本的な制限を理解することから始めましょう。表面的には、ビットコインは基本的なスマートコントラクト（資金のロックとロック解除のルールを定義するコード）の作成を可能にしている。しかし、そのプログラミング言語であるビットコインスクリプトは非常に限られており、トランザクションが資金を移動させるときにのみ登場する。

2.現在のビットコインでは、コインの移動経路を事前に設定する、というより指定する方法はありません。また、ロックする際に、金額を引き出す速度を制限することもできません（PSBT（Pending Signed Bitcoin Transactions）に基づく非従来型のワークフローを使用しない限り、これは以下のいずれによってもうまく処理されません）。取引手数料も、もう使わないと決めたときにブロードキャストを確実に削除してブロックすることもできません）。この単純さは、ビットコインのセキュリティモデルの中心ではあるが、それでもスクリプトのようなスクリプト言語が（基本的な）スマートコントラクトをサポートする能力には大きな制限がある。線形実行モデル。

リニア実行モード

1.ビットコインスクリプトの制限の1つは、その動作モードにあります：オペコードは順次実行され、ループはありません。

このP2PKHトランザクションを例にとると、スクリプトは、公開鍵のコピー、公開鍵のアドレスへのハッシュ、ハッシュがロックスクリプトと一致するかどうかの検証、そして最後にその公開鍵に対するトランザクション署名のチェックというように、直線的に実行されていることがわかります。ループがないことは、スクリプトがチューリング完全ではなく、終了が保証されていることを意味し、ノードのダウンやネットワーク全体の大幅な速度低下を引き起こす可能性のある操作の無限ループを防止する。この設計上の選択により、リソースの消費を静的に制限できる一方で、スクリプトが複雑なワークフローを管理する能力は制限される。

2.基本的な算術演算ができないこと Bitcoin Scriptは100未満の重要なオペコードしか持っておらず、スタック上のオブジェクトを乗算、除算、結合できません。OP_CATに関心のある多くのユーザーはご存知かもしれないが、サトシ・ナカモトは2010年にOP_OR、OP_MUL（乗算）、OP_DIV（除算）、OP_CAT（文字列連結）など、ビットコインのいくつかのオペコードを無効にした。これらの無効化されたオペコードは、元の実装に悪用される可能性のある脆弱性があり、ネットワークのセキュリティを犠牲にする可能性があったため、削除された。しかし、これらのオペコードがないため、スクリプトは基本的な数学演算を実行することが難しくなります。

3.取引データが見えない浅はかな言い方をすれば、ビットコインのスマートコントラクトはブロックチェーン上で情報が公開されているため、取引金額やデータの他の部分を見ることができると思い込んでいる人が大多数だと思います。しかしその逆で、ビットコインのコントラクトは取引データに基づいて消費条件を設定できない。なぜなら、ビットコインスクリプトの取引データを理解する能力は非常に限られているからだ。もしスクリプトが取引データの詳細を内省する能力を持っていれば、特定の支出条件を強制したり、段階的に実行されるトランザクションを作成したり、より高度な安全管理機能（例えば "安全管理契約（vault）").

4.では、私たちはどうするつもりなのでしょうか。Simplicity言語など、ビットコインスクリプトのより前衛的な実験は、スタックフォーム制約に代わるものを提供することに取り組んでいます。一方、OP_MULTISHA256、OP_LESS、OP_LE32TOLE64のようなオペコードは、ビットコインの演算機能をアップグレードすることを目指しています。OP_CTVやOP_CATのような内省的なオペコードに対処するための提案は、「制約」に分類されます。では、「スマートコントラクト」と「制約条項」の違いは何でしょうか？

5.スマートコントラクト vs. 制限条項スマートコントラクトは、仲介者を介さずに送金する自己実行型の取引です。今日のビットコインでは、スマートコントラクトはビットコインスクリプトを使用してビットコインをロックおよびロック解除することに制限されている。この制限は、ユーザーが将来の取引で資金をどのように使用するかを制御できるようにすることで、ビットコインのスマートコントラクト機能を強化することを目的としています。スクリプトが取引データをイントロスペクトできるようにすることで、基本的にそのデータをコントラクトロジックで使用できるようにしています。

OP_TXHASH：トランザクションの入力（または出力）のハッシュを提供し、Scriptにトランザクションデータに基づいて条件を検証および強制する機能を与える。 OP_CSFS + OP_CAT: これら2つのオペコードにより、Scriptは（トランザクション自体だけでなく）任意のデータの署名をチェックできる。つまり、スクリプトはトランザクションデータと外部情報に基づいて条件を検証できるため、ビットコインスクリプト内での検証操作の可能性が広がります。 これら2つのオペコードは意図的に広く設計されているため、複雑な検証プロセスやイントロスペクション機能をサポートすることができます。その他は意図的に狭く、より制限的な制約で設計されています。

OP_CHECKTEMPLATEVERIFY（CTV）：トランザクションの出力を後続の支出トランザクションのテンプレートに埋め込むことを可能にし、より制限的な制約を可能にします。 OP_VAULT：セーフ・コントラクトに特有の制限を有効にし、ユーザーがトランザクションの宛先を指定することを可能にするが、時間遅延が終了するまで実際に資金を移動させない。

また、イントロスペクション機能を有効にするための直接的なオペコードではないOP_CATもあります......OP_CAT:は、スクリプトがスタックの2つの要素を前後にスプライスすることを可能にし、スクリプト内の情報の断片を組み合わせるために使用することができます。

OP_CAT: あらゆる可能性を解放する ビットコインスクリプトでは、トランザクションデータをイントロスペクトできる主なオペコードは、CHECKLOCKTIMEVERIFY、

OP_CAT: あらゆる可能性を解放する ビットコインスクリプトでは、トランザクションデータをイントロスペクトできる主なオペコードは、CHECKLOCKTIMEVERIFY、

CHECKSEQUENCEVERIFY（相対時間ロック）、およびCHECKSIG（署名チェック）です。

さらに、CHECKSIGVERIFY、CHECKSIGADD、CHECKMULTISIG、CHECKMULTISIGVERIFYなどの亜種があります。CHECKSIGも同様ですが、スタックから署名と公開鍵を取得できる点が異なります。

前述では、連結を2つの要素を分割する関数として理解したが、要素を分割するために使うこともできる。

OP_CAT（連結）からOP_SPLIT関数を導き出すにはどうすればよいでしょうか？"かさばるオブジェクトがある場合、ユーザーに両方のフラグメントをコストで提供するよう求めることで、それらを半分に分割することができます。この2つのフラグメントをCATして、等しいかどうかをチェックすることができます。このようにして、あらゆる操作を逆にすることができる。CATを使えば、署名を半分に分けることができる。"

ここで何が起こっているのか？ユーザーは最初に署名、公開鍵、署名されるトランザクションを提供し、署名を半分に分割して、トランザクションデータでそれぞれの部分を別々にチェックすることができる。このテクニックは、署名と公開鍵が有効なトランザクションの一部であることを検証するため、スプリットまたはスプライスと見なすことができる。(訳者注：この文脈での「データを半分に分割できる」とは、スクリプトの実行中にデータの一部 を2つに分割できるという意味ではなく、2つのデータを証人データとして別々に渡し、CAT を使用してつなぎ合わせ、完全なデータに対して実行されるチェックを実行するという意味である。この方法を使えば、2つのデータを渡す前に、その2つのデータに対して追加のチェックを行うことができる)。イントロスペクションとの関係は？「Taprootでは、すでにSchnorrシグネチャを持っています。OP_CATとSchnorr署名を使ってオペコードを検証することで、非再帰的な制限句が得られることが証明された。無造作に塗りつぶされたトランザクションのハッシュではなく、スタック内のすべてのトランザクションデータのSHA2ハッシュである。"

スタックに残っているトランザクションの入力または出力のSHA2ハッシュを取得する方法。OP_CATを使用することで、トランザクションの特定の部分に対する制約をアンロックスクリプトの要件にしている。OP_CATを使うことで、トランザクションの特定の部分に対する制約をロック解除スクリプトの要件にしているのだ。送信者のアドレスやトランザクションの送信金額を制約することができ、トランザクションのハッシュが資金をロック解除するキーとして機能する。

安全性

同じトリックを使って、トランザクションのイントロスペクションを行う。記事中のPoelstraの推論に沿って、Rijndaelという開発者は、OP_CATだけでPurrfect Vaults（「完璧な金庫」）を実装できることを実証した。 ユーザーは次に資金が移動するアドレスを指定することができ、鍵が漏洩した場合に資金を回収するメカニズムを提供し、秘密鍵を盗む動機を減らすことができます。

スクリプト内のメルケル・ツリー

今日のビットコインでは、データ構造である「メルケル・ツリー」が、データの検証、同期、およびトランザクションとブロックをトランザクションとブロックをある意味で「結合」するために使用される。一方、OP_CATはスタック上の2つの変数をスプライスすることができ、公開鍵のSHA256ハッシュと併用することで、スクリプトに簡単なメルケル・ツリー検証手順を実装することができる。このアプローチは、もともと2015年にPieter Wuilleによって提案され、Liquidに実装されました。

ツリー署名

公開鍵の数に対して対数サイズであり、n-of-mを超える利用条件をエンコードできるマルチ署名スクリプトを提供します。一例として、1KB未満のトランザクションでは、1000の公開鍵によるツリー署名をサポートできる。また、支出条件の論理的な一般化も可能になる。

再帰的な制限支出条件

再帰的な制限トランザクションをデコードし、その特定の部分に制約を課すことができれば、複数の条件にまたがる条件を作成できます。この概念は "再帰制約 "と呼ばれます。

OP_CATは、わずか10行のコードでパワーを与えてくれるユニークなプロトコルです。トランザクションデータの可視性、より優れた数学機能、および線形実行モデルです。OP_CATは一見すると平凡に見えるかもしれないが、クリエイティブに活用できる膨大な可能性を秘めている。また、量子コンピューターに強いLamport署名など、この記事の範囲を超えた機能を実現するためのブリコラージュとして使用することもできます。

それは安全ですか？

最初に OP_CAT が削除される前に、OP_DUP (スタックのコピー) と組み合わせて、スタック内で最初に操作されるオブジェクトが 1 バイトであっても、このオペコードのペアを繰り返し適用することで、スタックオブジェクトのサイズはメモリが破裂するまで急速に拡大します。これはDoS攻撃として利用できる。新しい提案は、スタック要素に520バイトの制限を課すことで、この攻撃を簡単に防ぎます。

無期限に実行される契約を作成するリスクはありますか？

質問の意味が、OP_CAT のスクリプトの線形実行モデルへの変更が、スクリプトがリソース使用量を静的に制約できなくなる (スクリプトのボリュームの線形関数になる) ことを意味するかどうかであれば、答えはノーです。

制限条項は、ビットコイン上で他のコインを発行する市場をもたらすでしょうか？

再帰型の制限条項があれば、技術的には、NFT、分散型取引所、e-catsなどを含む複雑なレイヤー2アプリを開発することができます。しかし、それを作るのは容易ではない。これが大きな市場を生み出すとは考えにくい。

CATで財産を永久に「汚す」ことはできるのか？

DyedコインとNFTの場合、資産を発行することで実際にサトシを「燃やし」、「レイヤー2」資産の所有権を象徴する印をつけます。このプロセスは「汚染」と呼ばれる。ビットコインのウォレットはこれを理解できない（開発者がこれを可能にするコードを追加しない限り）。最終的に手にしたコインは、ビットコインのウォレットにも受け入れられない。もしかしたらeCatウォレットか何かでは受け入れられるかもしれませんが、ビットコインユーザーの大多数には関係ありません。

ビットコインのMEV問題を引き起こすか？

ビットコインとイーサの重要な違いの1つは、トランザクションの可視性です。イーサとは異なり、ビットコインのコントラクトのすべての側面が必ずしも透明ではないため、ビットコインのマイナーには、コントラクトの内部状態を確認し、特定のアクションを先取りして実行するイーサのマイナーのような能力はありません。

OP_CATの主な懸念は、経済的インセンティブに影響を与える可能性にあり、その結果「マイナー抽出可能価値（MEV）」が発生します。前回の投稿では、このトピックについて詳しく説明しました。多くのユーザーにとっての懸念は、レイヤー2契約を技術的に可能にすれば、MEVが必然的に発生するということです。

しかし、本当にそうなのでしょうか？具体的には、ビットコイン上でレイヤー2コインを発行できるようになれば、必ず採用されるということなのでしょうか？単純なスワップ契約や比較的非効率なNFTを開発することは考えられるが、自動化されたマーケットメイカーを持つ分散型取引所を開発するような複雑なことは不可能に近い。

OP_CATは比較的完璧ですか？

ビットコイナーたちの一部は、「治癒主義者」と呼ばれ、ビットコインを現在の状態に維持することを支持し、プロトコルのアップグレードには懐疑的です。彼らは特に、制限条項の導入のような大きな変更がネットワークの非中央集権性を低下させることを懸念している。彼らの擁護は、ビットコインの当初のビジョンに固執することが最善であるという信念に基づいている。

皮肉なことに、OP_CATはオリジナルのビットコインの一部であったため、まったく正反対の意見になっている。OP_CATを復活させる方が、サトシ・ナカモトのオリジナルのビジョンに沿うという意見もある。

再帰的制限句に付随する安全管理機能のいくつかを求めるのであれば、OP_CATは良いものですが、本格的なLispスタイルのスクリプト言語ほどではありません。問題は、そのようなものを導入するのは大きな変更であり、すぐに普及する見込みがないということだ。あるいは、OP_CTVやOP_VAULTのような非再帰的な制限句のシンプルさを好むかもしれません。

非再帰的制限節はよりシンプルで、制御不能な制限の連鎖を作るリスクもなく、分析も容易です。しかし、ある種の再帰的制限句が必ず現れるとしたらどうだろう？ここ数年、開発者は、トランザクション検証ロジックのほとんどすべての拡張機能を使用して、OP_CATの機能をエミュレートできることに気づいている。スクリプトの世界では、スタック要素のサイズによって2つの世界に分けられる。4バイトより大きい要素については、等しいかどうかをチェックし、公開鍵や署名にデコードし、ハッシュ化することができる。4バイト以下の要素に対しては、演算を行うことができる。BitVM上で動作するRISC-Vプロセッサを使えば、何でもできる。OP_CATの機能（スタック要素の分割やつなぎ合わせ）をエミュレートできるものであれば、この2つの世界を統合することができ、スクリプトで「何でもできる」ようになります。

アンドリュー・ポエルストラ（Andrew Poelstra）のような研究者の中には、ごく少数の新しいオペコードで再帰型制約を作ることができると期待している人もいます。もしこれが本当なら、これを行うための最良の方法を見つけ出す必要がある。 OP_CATは最もエレガントなツールではありませんが、機能/複雑さの比率が最も高いため、開発者は驚くような新機能を生み出すことができるでしょう。BTCの未来にさらなる可能性を。