制限条項の詳細:ビットコインのプログラム可能性を実現する

最近、ビットコインコミュニティではOP_CATなどのオペコードの再活性化についての議論が盛んになっています。Taproot WizardはQuantum Cats NFTを発表し、BIP-420の番号を取得したと主張することで、多くの人々の注目を集めています。支持者は、OP_CATを有効にすることで「制限条項」を実現し、ビットコインのスマートコントラクトまたはプログラム可能性を実現できると主張しています。

"制限条項"という言葉に気づき、少し検索すれば、これはもう一つの大きなウサギの穴であることがわかります。開発者たちは何年にもわたって、OP_CATの他にも、OP_CTV、APO、OP_VAULTなどの制限条項を実現する技術について議論してきました。

さて、ビットコインの「制限条項」とは一体何なのでしょうか？なぜこれほど多くの開発者が数年にわたって関心と議論を持ち続けることができるのでしょうか？ビットコインのどのようなプログラム可能性が実現できるのでしょうか？その背後にある設計原理はどのようなものなのでしょうか？この記事では概観的な紹介と議論を試みます。

! 詳細な契約:ビットコインのプログラマビリティを実現する方法は?

"制限条項"とは何ですか

制限条項(契約)は、将来のビットコイン取引に条件を設定できるメカニズムです。

現在のビットコインスクリプトには制限条件も含まれており、例えば支払い時に合法的な署名を入力したり、適切なスクリプトに送信する必要があります。しかし、ユーザーがロックを解除できれば、そのUTXOを任意の希望する場所に使うことができます。

そして制限条項とは、ここでの解除方法に基づいて、UTXO後の支出を制限するなど、さらに制限を加えることです。これは「特定用途専用」の効果を実現することを意味します。また、1つの取引に送信される他の入力条件なども含まれます。

より厳密に言えば、現在のビットコインスクリプトにも一定の制限条項があり、例えば操作コードに基づくタイムロックは、内省取引のnLockまたはnSequenceフィールドを通じて取引の消費前の時間制限を実現していますが、基本的には時間に関する制限に限られています。

では、開発者や研究者がなぜこれらの制限チェックを設計するのでしょうか?制限条項は単に制限のための制限ではなく、取引実行のルールを設定するためのものです。このようにして、ユーザーはあらかじめ設定されたルールに従って取引を実行し、予定されたビジネスプロセスを完了することができます。

したがって、直感に反して、これによりより多くのアプリケーションシーンを解放することができます。

! 詳細な契約:ビットコインのプログラマビリティを実現する方法は?

アプリケーションシーン

Staking のペナルティを確保する

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

Babylonのビットコインステーキングプロセスは、ユーザーが自分のBTC資産をメインチェーン上の特別なスクリプトに送信することです。支出条件には2つの種類が含まれます:

• 通常の場合:一定の時間が経過した後、ユーザーは自分の署名を使用してロックを解除でき、つまりアンステークのプロセスが完了します。
• 例外:セキュリティのためにバビロンがリースしているPoSチェーンで、ユーザーが二重署名またはその他の悪EOTS(extractable行為を行っている場合、ワンタイム署名を通じて、署名)を一度に抽出し、資産のこの部分のロックを解除することができます。 また、ネットワークでのエグゼクティブの役割により、資産の一部がバーニングアドレスに送られることが強制されます(slash)

ここでの"強制送信"に注意してください。これは、UTXOを解除できる場合でも、その資産を任意の場所に送信できず、燃やすしかないことを意味します。これにより、悪意のあるユーザーが既知の署名を使用して資産を自分に転送し、罰を逃れることができないように保証されます。

この機能は OP_CTV などの制限条項が実現した後、ステーキングスクリプトの「異常事態」ブランチに OP_CTV などのオペコードを追加して制限を実現できます。

そして、OP_CTVが有効になる前に、バビロンはユーザーと委員会が共同で実行する方法を用いて、制限条項の強制執行効果を模擬的に実現する必要があります。

! 詳細な契約:ビットコインのプログラマビリティを実現する方法は?

混雑抑制

一般的に、混雑はビットコインネットワーク上で手数料が非常に高く、取引プールに多くの取引が積み上がっている場合を指します。そのため、ユーザーが取引を迅速に確認したい場合は手数料を引き上げる必要があります。

その時、もしユーザーが複数の受取人に対して複数の取引を送信する必要がある場合、手数料を引き上げ、高いコストを負担しなければならなくなります。同時に、ネットワーク全体の手数料率もさらに押し上げることになります。

制限条項がある場合の解決策の一つは、送信者がまず一括送信の取引に対して約束することです。この約束により、すべての受信者は最終的な取引が行われることを信じることができ、手数料率が低いときに具体的な取引を送信することができます。

ブロック空間の需要が非常に高いとき、取引は非常に高価になります。OP_CHECKTEMPLATEVERIFYを使用することにより、大量決済処理業者はすべての支払いを単一の O(1) トランザクションに集約して確認することができます。その後、しばらくしてブロック空間の需要が減少すると、支払いはそのUTXOから拡張されることができます。

このシーンは、OP_CTVという制限条項が提案した比較的典型的な適用事例です。

###ボールト

保管庫(vault)はビットコインアプリケーションの中で広く議論されているアプリケーションシーンの一つで、特に制限条項の分野においてです。日常的な操作では資金の保管と資金の使用ニーズの間でバランスを取らざるを得ないため、人々は資金の安全を保証できる保管金庫のアプリケーションを望んでいます。たとえアカウントがハッキングされ(私鍵)が漏洩しても、資金の使用を制限できることが求められます。

実現制限条項に基づく技術により、保管庫類のアプリケーションは比較的容易に構築できます。

OP_VAULTの設計方案を例に挙げると、保管庫の資金を使用する際には、まず取引をブロックチェーンに送信する必要があります。この取引は、保管庫を使用する意図、つまり「トリガー」を示し、その中に条件を設定します:

• もしすべてが正常であれば、2回目の取引は最終的な出金の取引です。N個のブロックを待った後、資金を任意の場所でさらに使うことができます。
• もしこの取引が盗まれた(、または"スパナ攻撃"によって脅迫された)場合、N個のブロックの出金取引が送信される前に、すぐに別の安全なアドレス(に送信し、ユーザーがより安全に保管できる)。

注意が必要なのは、制限条項がない場合でも、保管庫アプリケーションを構築できるということです。実行可能な方法は、将来の支出のために署名を準備するために秘密鍵を使用し、その後この秘密鍵を破棄することです。しかし、依然として多くの制限があります。例えば、この秘密鍵が(のように破棄されていることを確認する必要があります。これはゼロ知識証明のtrusted setupプロセス)と似ています。また、金額や手数料が事前に決定されている(ため、事前署名が必要)で柔軟性に欠けるなどです。

! 詳細な契約:ビットコインのプログラマビリティを実現する方法は?

より強固で柔軟な状態チャネル

一般的に、ライトニングネットワークを含むステートチャネルは、メインチェーンとほぼ同等のセキュリティを持つと考えられています(ノードが最新の状態を観察でき、正常に最新の状態をオンチェーンで発行できる場合)。しかし、制限条項がある場合、新しいステートチャネルの設計アイデアは、ライトニングネットワークの上でより堅牢または柔軟になる可能性があります。その中で比較的有名なのはEltoo、Arkなどです。

Eltoo (はLN-Symmetry)とも呼ばれ、典型的な例の一つです。この技術的な提案は「L2」の音を取り入れ、ライトニングネットワークに対して実行層を提供し、後のチャネル状態が以前の状態を置き換えることを可能にします。これにより、ペナルティメカニズムなしで、敵が悪用するのを防ぐために複数の以前の状態を保存しなければならないライトニングネットワークノードのような状況を回避できます。上記の効果を実現するために、EltooはSIGHASH_NOINPUTという署名方式を提案しました。つまり、APO(BIP-118)です。

Arkは、ライトニングネットワークの入出力流動性やチャネル管理の難易度を下げることを目的としています。それはjoinpool形式のプロトコルであり、複数のユーザーが一定の時間内にサービスプロバイダーを取引相手として受け入れることができ、オフチェーンで仮想UTXO(vUTXO)の取引を行いますが、オンチェーンで一つのUTXOを共有することによりコストを削減します。保管庫に似て、Arkも現在のビットコインネットワーク上で実現可能です。しかし、制限条項を導入した後、Arkは取引テンプレートに基づいて必要なインタラクションの量を減らし、より信頼のない一方的な退出を実現できます。

! 詳細な契約:ビットコインのプログラマビリティを実現する方法は?

制限条項の技術概要

上記のアプリケーションからわかるように、制限条項はある種の技術というよりも効果のようなものであるため、実現するための技術的手段は多様です。分類すると、以下のようなものが含まれます:

• タイプ:汎用、特殊用途
• 実装:オペコードベース、シグネチャベース
• Recursive: 再帰的、非再帰的

その中で、再帰とは、いくつかの制限条項の実装が、次の出力を制限することで次の出力をさらに制限できることを指し、追加された制限が1つの取引を超え、より高い取引の深さを達成できることを実現できます。

いくつかの主流の制限条項の設計には、

• OP_CTV:汎用、オペコードベース、非再帰的
• OP_VAULT: 専用、オペコードベース、非再帰的
• APO: 汎用、シグネチャベース、非再帰的
• OP_CAT:汎用、オペコードベース、再帰*
• OP_CSFS:汎用、シグネチャベース、再帰的

*OP_CATを組み合わせると

! 詳細な契約:ビットコインのプログラマビリティを実現する方法は?

制限条項の設計

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

原因は主に現在のビットコインのスクリプトが取引そのものの内容を読み取ることができないためであり、つまり取引の"内省"(introspection)です。

もし私たちが取引の内省を実現できれば——取引のあらゆる内容(を確認し、出力)を含めることができれば、制限条項を実現できるでしょう。

したがって、制限条項の設計思想は主に内省をどのように実現するかに関するものである。

! 詳細な契約:ビットコインのプログラマビリティを実現する方法は?

オペコードベース vs 署名ベース

最も単純で直接的な考えは、1つまたは複数のオペコード(、すなわち1つのオペコード + 複数のパラメータ、または異なる機能のオペコード)を追加して、取引の内容を直接読み取ることです。これがオペコードに基づくアプローチです。

もう一つの考え方は、スクリプト内で取引自体の内容を直接読み取ってチェックしなくても、取引内容のハッシュを利用できるということです。もしこのハッシュがすでに署名されていれば、スクリプト内で OP_CHECKSIG などを改造することで、この署名のチェックを実現できるため、間接的に取引の内省や制限条項を実現できます。この考え方は署名に基づく設計方式です。主に APO や OP_CSFS などが含まれます。

APO ###

SIGHASH_ANYPREVOUT(APO)は提案中のビットコインの署名方式です。署名の最も簡単な方法は取引の入力出力すべてにコミットすることですが、ビットコインにはより柔軟な方法、つまりSIGHASHがあり、取引の入力または出力のいずれかに選択的にコミットすることができます。

APOのSIGHASHは出力のみを署名し、入力部分は署名しません。これはつまり、APO方式で署名された取引は、