jakiro
著者：Jeffrey Hu＆amp; Hashkey Capital
最近、BitcoinコミュニティでOP_CATなどのOPCODEの再認識について議論の波が始まりました。Taproot Wizardは、Quantum Cats ‘NFTを発射し、BIP-420番号などを取得したと主張することで、多くの注目を集めています。サポーターは、OP_CATを有効にすることで、「契約」を実装したり、ビットコインのスマートコントラクトを実装したり、プログラマ性を実装できると主張しています。
「制限条項」という用語に気付いて検索した場合は、これは別の大きなウサギの穴であることがわかります。開発者は何年もそれについて話し合ってきました、OP_CATに加えて、OP_CTV、APO、OP_VAULTなどの制限を実装するテクノロジーもあります。
それで、ビットコインの「制限付き条件」とは正確には何ですか？何年もの間、多くの開発者が注目と議論を続けることができるのはなぜですか？ビットコインでどのようなプログラマ性を達成できますか？その背後にあるデザインの原則は何ですか？この記事では、概要の紹介と議論を示します。
「制限付き条件」とは何ですか
中国語で「制限された条項」として翻訳される契約は、時には「契約」と翻訳されることもあり、将来のビットコイントランザクションの条件を設定できるメカニズムです。
現在のビットコインスクリプトには、支出時に法的署名を入力する、準拠したスクリプトの送信などの制限も含まれています。しかし、ユーザーがロックを解除できる限り、彼は自分が望むどこでもUTXOを使うことができます。
制限条項は、この制限のロックを解除する方法について、より多くの制限を作成することです。たとえば、UTXOの後にコストを制限することは、「特別な資金と特別な目的」と同様の効果を達成することです。最終分析では、制限条項は、ビットコインスクリプトのトランザクションコストを直接制限する可能性があり、それにより、スマートコントラクトの効果と同様のトランザクションルールを達成できます。
より厳密には、現在のビットコインスクリプトには、特定の制限もあります。たとえば、オペコードに基づく時間ロックは、トランザクションのNLOCKまたはNシーケンスフィールドを内省することにより、時間制限を実装するために使用されますが、基本的には時間制限に限られています。
では、なぜ開発者と研究者がこれらの制限チェックを設計するのでしょうか？制限条項は制限のために制限されているだけでなく、トランザクションの実行に関するルールを設定しているためです。このようにして、ユーザーはプリセットルールに従ってトランザクションのみを実行して、所定のビジネスプロセスを完了することができます。
したがって、これがより多くのアプリケーションシナリオのロックを解除できることは、より直感に反しています。
契約アプリケーションシナリオ
罰を確実にしてください
制限の最も直感的な例の1つは、ビットコインのステーキングプロセスにおけるバビロンのスラッシュトランザクションです。
バビロンのビットコインステーキングプロセスは、ユーザーがメインチェーンでBTCアセットを特別なスクリプトに送信することです。
・ハッピーエンド：一定の期間の後、ユーザーは自分の署名でロックを解除できます。つまり、アンステークプロセスが完了します。
・悪い結末：ユーザーがバビロンによってレンタルされたPOSチェーンでのダブル署名などの邪悪な行動をコミットする場合、EOTS（抽出可能な1回限りのシグネチャを介して、一度に署名を抽出できます）。それらのネットワークから、実行の役割は資産の一部を燃焼アドレスに強制します（スラッシュ）
（出典：Bitcoin Staking：21mのビットコインのロックを解除して、実証の経済を確保する）
ここでは「強制送信」に注意してください。つまり、UTXOのロックを解除できる場合でも、資産は他の場所に任意に送信できず、燃やすことができます。これにより、邪悪なユーザーは、罰を逃れるために、既知の署名で最初に資産を彼に戻すことができません。
この関数がOP_CTVなどの制限に実装されている場合、OP_CTVなどのOPCODEをステイクスクリプトの「悪いエンディング」ブランチに追加して、制限を実装できます。
OP_CTVが有効になる前に、バビロンは、ユーザー +委員会によって共同で実装される回避策を通じて、制限条項の施行の実装をシミュレートする必要があります。
混雑制御
一般的に言えば、混雑とは、ビットコインネットワークのハンドリング料金が非常に高い場合を指し、トランザクションプールにパッケージ化されるのを待っているトランザクションが蓄積されます。したがって、ユーザーがトランザクションをすばやく確認したい場合、処理料を引き上げる必要があります。
この時点で、ユーザーが複数のトランザクションを複数の受取人に送信する必要がある場合、処理料を引き上げ、比較的高いコストを負担する必要があります。同時に、ネットワーク全体の取り扱い料金をさらに引き上げます。
制限がある場合、1つの解決策は、送信者を送信することです。最初にバッチセントトランザクションにコミットできます。この約束は、すべての受信者に最終取引が実行されると信じさせることができ、特定の取引を送信する前に手数料が低くなるまで待つことができます。
下の図に示すように、ブロックスペースの需要が高くなると、トランザクションは非常に高価になります。OP_CHECKTEMPLATEVERIFYを使用することにより、大量支払いプロセッサは、すべての支払いを確認のために複雑さo（1）の単一のトランザクションに集約できます。その後、しばらくすると、ブロックスペースに対する人々の需要が減少すると、そのUTXOから支払いを拡大できます。
（出典：https：//utxos.org/uses/scaling/）
このシナリオは、OP_CTVの制限条項によって提案されている典型的なアプリケーションケースです。https://utxos.org/uses/で利用可能なアプリケーションケースがあります。無料のマイニングプール、ボールト、より安全なハッシュされた時間ロックされた契約（HTLC）制限など。
ボールト
Vaultは、特に制限された条項の分野で、ビットコインアプリケーションで広く議論されているアプリケーションシナリオです。日常業務は必然的に資金の貯蔵と資金の使用のニーズのバランスをとる必要があるため、人々は、金庫の親権のためのアプリケーションがあることを望んでいます。資金のセキュリティを確保することができ、アカウントがハッキングされたとしても（秘密鍵が漏れています）、資金の使用を制限できます。
制限を実装するためのテクノロジーに基づいて、Vaultアプリケーションは比較的簡単に構築できます。
op_vaultの設計計画を例に取ります。金庫に資金を使うときは、最初にリンクにトランザクションを送信する必要があります。このトランザクションは、金庫を使う意図、つまり「トリガー」を示し、そこに条件を設定します。
すべてが問題ない場合、2番目のトランザクションは最終撤回です。Nブロックを待った後、どこでも資金をさらに使うことができます。
トランザクションが盗まれたことがわかった場合（または「レンチ」に攻撃されたときに強制された）場合、Nブロックでの引き出しトランザクションの前にすぐに別の安全なアドレスに送信できます（ユーザーはより安全に保つことができます）
（OP_VAULTプロセス、出典：BIP-345）
それはそれに注意する必要があります制限がなければ、ボールトアプリケーションを構築することもできます、実行可能な方法は、秘密鍵を使用して将来費やす署名を準備し、秘密鍵を破壊することです。しかし、まだ多くの制限があります。たとえば、この秘密鍵が破壊されていることを確認する必要があります（ゼロ知識証明の信頼できるセットアッププロセスと同様）、金額と取り扱い手数料は事前に決定され、したがって柔軟性がありません。
（OP_VAULTと事前に署名したボールトプロセスの比較、出典：BIP-345）
より堅牢で柔軟な状態チャネル
通常、Lightningネットワークを含む状態チャネルは、メインチェーンとほぼ同じセキュリティを持っていると考えることができます（ノードが最新の状態を観察し、最新の状態を通常リンクに公開できることを保証する場合）。ただし、制限が実施されているため、Lightningネットワークの上に、いくつかの新しい州のチャネル設計のアイデアがより堅牢または柔軟になります。その中で、より有名なものには、エルトゥー、アークなどが含まれます。
Eltoo（LN音楽とも呼ばれます）は、最も典型的な例の1つです。この技術的なソリューションは、「L2」の同音異義語を取り、Lightningネットワークの実行レイヤーを提案し、その後のチャネル状態が罰のメカニズムを必要とせずに以前の状態を置き換えることができます。避難所のノード。上記の効果を達成するために、EltooはSighash_noinputの署名方法、つまりAPO（BIP-118）を提案しました。
ARKは、インバウンド流動性とLightning Networkのチャネル管理の難しさを減らすことを目指しています。これは、JoinPoolプロトコルの形式です。複数のユーザーは、特定の期間内にサービスプロバイダーをカウンターパーティとして受け入れて、Virtual UTXO（VUTXO）トランザクションをオフチェーンで行うことができますが、コストを削減するためにUTXOを共有できます。ボールトと同様に、ARKは現在のビットコインネットワークにも実装できますが、制限を導入した後、ARKはトランザクションテンプレートに基づいて必要な相互作用の量を減らすことができます。
契約技術の概要
上記のアプリケーションから、Covenants制限条項は特定のテクノロジーよりも効果のようなものであることがわかります。そのため、実装する多くの技術的な方法があります。分類された場合、次のことを含めることができます。
タイプ：一般的なタイプ、特別なタイプ
実装方法：opcodeに基づいて、署名ベース
再帰：再帰的で、再帰的
その中で、再帰は次のとおりです。制限のいくつかの実装があり、次のトランザクションを制限することにより、次のトランザクションの出力を制限できます。
主流の制限設計には次のものがあります。
契約の設計が条件を制限します
前の紹介からわかるように、現在のビットコインスクリプトは、主にロック解除の条件を制限しており、UTXOがさらに費やされる方法を制限しません。制限条項を実装するには、逆に考えなければなりません。現在のビットコインスクリプトが契約制限条項を実装できないのはなぜですか？
主な理由は、現在のビットコインスクリプトがトランザクション自体のコンテンツ、つまりトランザクションの「内省」を読み取ることができないことです。
トランザクションの内省を実装できる場合 – トランザクション（出力を含む）について何かをチェックすると、制限条項を実装できます。
したがって、制限された条項の設計のアイデアは、主に内省を達成する方法に焦点を当てています。
署名に基づいてオペコードvsに基づいています
最も単純で粗いアイデアは、1つ以上のオペコード（つまり、1つのオペコード +複数のパラメーター、または異なる関数を持つ複数のオプコード）を追加して、トランザクションのコンテンツを直接読み取ることです。これは、操作コードに基づいたアイデアです。
別のアイデアは、スクリプト内のトランザクション自体のコンテンツを直接読み取り、チェックする代わりに、トランザクションコンテンツのハッシュを使用できることです。このハッシュが署名されている場合は、たとえば、実装してスクリプトのOP_CHECKSIGを変更するだけです。この署名の検査では、トランザクションの内省と制限条項を間接的に実現できます。このアイデアは、署名デザインに基づいています。主にAPOおよびOP_CSFなどが含まれます。
apo
Sighash_anyprevout（apo）は、提案されているビットコイン署名方法です。署名する最も簡単な方法は、トランザクションの入力と出力の両方にコミットすることですが、ビットコインにはより柔軟な方法、つまり、トランザクションの入力または出力に選択的にコミットするSighashもあります。
現在、Sighashとその組み合わせは、トランザクション入力と出力範囲に署名します（ソース「マスタリングビットコイン、2番目」
上記の図に示すように、すべてのデータに適用されるすべてを除き、署名方法は、出力に基づいているすべての入力のみに適用することであり、同じ入力シリアル番号に適用される出力のみに基づいています。さらに、Sighashを組み合わせることもでき、AnyOneCanPay修飾子が重ねられた後の1つの入力にのみ適用されます。
ApoのSighashは、出力にのみ署名し、入力部分ではありません。これは、APOによって署名されたトランザクションは、後で条件を満たす任意のUTXOに添付できることを意味します。
この柔軟性は、APOが制限を実装するための理論的根拠です。
1つ以上のトランザクションを事前に作成できます
これらのトランザクション情報を通じて、1つの署名のみを取得できる公開キーを構築できます。
このようにして、公開キーアドレスに送信された資産は、事前に作成された取引を通じてのみ使用できます
この公開鍵には対応する秘密鍵がないため、これらの資産は事前に作成されたトランザクションによってのみ使用できることが保証されていることは注目に値します。次に、これらの事前に作成されたトランザクションの資産がどこにあるかを指定し、それにより制限条項を実装できます。
Ethereumのスマートコントラクトを比較することで、さらに理解できます。スマート契約を通じて達成できるのは、EOAの署名で自由に使うのではなく、特定の条件を通じて契約住所からのみお金を引き出すことができるということです。この観点から、ビットコインは署名メカニズムの改善を通じてこの効果を達成できます。
しかし、上記のプロセスの問題は、計算中に循環依存性があることです。これは、トランザクションを事前に署名して作成するために入力コンテンツを知る必要があるためです。
この署名方法を実装するためのapoとsighash_noinputの重要性は、この循環依存関係の問題を解決できることです。
op_ctv
OP_CHECKTEMPLATEVERIFY（CTV）、またはBIP-119は、OPCODEを改善する方法を採用しています。コミットハッシュをパラメーターとして使用し、オペコードを実行するトランザクションには、そのコミットメントに一致する一連の出力が含まれることが必要です。CTVを通じて、ビットコインユーザーはビットコインの使用方法を制限することができます。
この提案はもともとop_checkoutputshashverify（coshv）の名前で開始されました、そして輻輳制御トランザクションを作成する能力に焦点を当てるのは早い段階で、提案に対する批判は、十分に普遍的ではなく、あまりにも具体的な矛盾制御のユースケースに焦点を合わせました。
上記の輻輳制御のユースケースでは、送信者アリスは10の出力を作成し、10の出力をハッシュし、生成された概要を使用して、COSHVを含むTapEleafスクリプトを作成できます。アリスは、参加者のパブリックキーを使用してTaprootの内部キーを形成して、Taprootスクリプトパスを漏らすことなく一緒に費やすことができます。
その後、アリスは各受信者に10個すべての出力のコピーを提供し、それぞれがアリスのセットアップトランザクションを検証できるようにします。後でこの支払いを費やしたい場合、どちらかが約束された出力を含むトランザクションを作成できます。
プロセス全体を通して、アリスが設定されたトランザクションを作成して送信すると、アリスは、電子メールやクラウドドライブなどの既存の非同期通信方法を通じて、これらの10コピーの出力を送信できます。これは、受信者がオンラインであるか、相互に対話する必要がないことを意味します。
（出典：https：//bitcoinops.org/en/newsletters/2019/05/29/#proposed-transaction-output-commitments）
APOと同様に、アドレスは支出条件に応じて構築することもでき、「ロック」は、他のキー、時間ロック、および構成可能なロジックの追加など、さまざまな方法で作成できます。
（出典：https：//twitter.com/owenkemeys/status/1741575353716326835）
これに基づいて、CTVは、ハッシュ後の支出トランザクションが定義と一致するかどうか、つまりトランザクションデータを「ロック」を開くキーとして使用できるかどうかを確認できることを提案しました。
上記の10の受信者の例を引き続き拡張できます。レシーバーはさらに、TXの次のバッチバッチに送信するためにTXを送信するために署名されたがブロードキャストされていないアドレスキーなどをさらに設定できます。 – 構造のようなもの。アリスは、チェーン上の1つのUTXOブロックスペースのみを使用して、複数のユーザーが関与するアカウントバランスの変更を構築できます。
出典：https：//twitter.com/owenkemeys/status/1741575353716326835
そして、葉の1つが稲妻、コールドストレージ、またはその他の支払いパスである場合はどうなりますか？このツリーは、単一次元および多層支出ツリーから多次元および多層支出ツリーに拡張され、サポートできるシナリオはより豊かで柔軟になります。
出典：https：//twitter.com/owenkemeys/status/1741575353716326835
CTVは導入以来、2019年にCOSHVからの名前の変更を受け、2020年にBIP-119を割り当てられ、CTV契約の作成に使用されるプログラミング言語であるSapioの出現は、コミュニティで多くの議論と更新を受けています。 22年と23年、およびそのアクティベーション計画に関する議論は、コミュニティが多く議論したソフトフォークアップグレード提案の1つです。
op_cat
OP_CAT最初に導入されたこれは、現在非常に関係しているアップグレード提案でもあります。シンプルに見えますが、OP_CATはスクリプトに多くの関数を柔軟性で実装できます。
最も直接的な例は、マークルツリーに関連する操作です。メルクルの木は、2つの要素が最初にスプライスされ、次にハッシュされると理解できます。現在、BitcoinスクリプトにはOP_SHA256などのハッシュ操作コードがあります。したがって、OP_CATを使用して2つの要素をスプライスできる場合、スクリプトにMerkleツリーの検証関数を実装できます。能力。
別の実装基準には、Schnorrの署名の拡張も含まれます。スクリプトの支出署名条件は、ユーザーの公開鍵と公開のノンセのスプライシングに設定できます。 。つまり、NonCEへのコミットメントはOP_CATを通じて達成され、それにより署名されたトランザクションの有効性が確保されます。
OP_CATのその他のアプリケーションシナリオには、Bistream、ツリーシグネチャ、量子抵抗性のLamport Signatures、Vaultsなどが含まれます。
OP_CAT自体は新機能ではなく、ビットコインの最も初期のバージョンに存在していましたが、攻撃によって悪用される可能性があるため、2010年に無効になっています。たとえば、OP_DUPとOP_CATの再利用は、そのようなスクリプトを処理するときにノード全体を簡単に爆発させることができます。このデモを参照してください。
しかし、OP_CATが再び有効になっている場合、前述のスタック爆発の問題に遭遇しますか？現在のOP_CATの提案には、各スタック要素が520バイトを超えないことを適格にするTapscriptを有効にすることのみを伴うため、以前のスタック爆発の問題はありません。一部の開発者はまた、中本atoshiの直接的な無効化OP_CATは厳しすぎる可能性があると考えています。ただし、OP_CATの柔軟性のため、現在脆弱性を引き起こす可能性のあるアプリケーションシナリオを現在排除することはできません。
したがって、アプリケーションシナリオと潜在的なリスクを組み合わせて、OP_CATは最近多くの注目を集めており、PRレビューもありました。これは現在最も人気のあるアップグレード提案の1つです。
結論
上記の紹介に示すように、「自己規律は自由をもたらします」制限条項は、ビットコインスクリプトのトランザクションコストを直接制限する可能性があり、それにより、スマートコントラクトの効果と同様のトランザクションルールを達成できます。BITVMなどのオフチェーンメソッドと比較して、このプログラミング方法は、ビットコインでよりネイティブに検証でき、メインチェーン（混雑制御）、オフチェーンアプリケーション（状態チャネル）、およびその他の新しいアプリケーションの方向を改善することもできます（ステーキング処罰など）。
制限された条項の実装技術をいくつかの基礎となるアップグレードと組み合わせることができる場合、プログラマ性の可能性をさらに解き放ちます。たとえば、レビューにおける64ビットオペレーターの最近の提案は、提案されたOP_TLUVまたはその他の制限とさらに組み合わせることができ、トランザクション出力の数に基づいてプログラムできます。
しかし、制限は予定外の虐待や抜け穴にもつながる可能性があるため、コミュニティはこれについてより慎重です。さらに、制限条項のアップグレードには、コンセンサスルールを含むソフトフォークのアップグレードも必要です。Taprootがアップグレードされた状況を考えると、制限条項に関連するアップグレードも完了するまでに時間がかかる場合があります。
