例えば、アリスとボブがUTXOを共有しているとしますが、そのUTXOを利用するには、両者が署名する必要があります。 この時点で、アリスはそれを使用するトランザクションを構築し、その価値の60%をボブに、残りを自分に転送します。 Alice はトランザクションに独自の署名を提供し、それを Bob に送信します。 まあ、ボブにとって、それはビットコインネットワークにブロードキャストされる必要はなく、ブロックチェーンによって確認される必要はなく、このトランザクションの支払い効果も現実的で信頼できるものです。 アリスはUTXOを自分で使うことができない(したがって繰り返し使うことができない)ため、またアリスから提供された署名は有効であるため、ボブはいつでも自分の署名を追加し、トランザクションをブロードキャストして支払いを受けることができます。 言い換えれば、アリスは、この有効な(オフチェーンの)取引を通じて、ボブに「信頼できるコミットメント」を提供したのです。
さらに、2つの点に言及する価値があります:(1)OP_VAULTオペコードは、別の制限提案OP_TLUVと同様に動作します。 Jeremy Rubin氏は、これがある程度「計算」の概念を生み出したと正しく指摘しています。 OP_TLUV/OP_VAULTはまず、コンシューマが新しいトランザクションでオペコードにパラメータを渡すことでスクリプトツリーリーフ全体を更新できるようにするオペコードを約束します。 もはや「特定の基準に基づいて受信データを検証する」ことではなく、「受信データに基づいて新しい意味のあるデータを生成する」ことが目的ですが、可能にできる計算は限られています。
ビットコインアプリケーションプログラミングからのCKBのプログラマビリティを理解する
原作者:Ajian
まとめ
システムのプログラマビリティを理解するには、システムの構造的特徴を特定する必要があります。 ビットコインスクリプトベースのアプリケーションプログラミングの調査は、CKBセルの基本構造とそのプログラミングパラダイムを理解するのに役立ちます。 それだけでなく、CKBのプログラミングコンポーネントを適切な部分に分解し、各部分がもたらすプログラミング可能性の向上を理解するのに役立ちます。
I. はじめに
「プログラマビリティ」は、ブロックチェーンシステムを比較する際によく使われる次元です。 ただし、プログラマビリティの記述方法については、しばしば意見が分かれています。 一般的な表現は、「XXブロックチェーンはチューリング完全プログラミング言語をサポートしています」、または「XXブロックチェーンは汎用プログラミングをサポートしています」であり、ここでの「XXブロックチェーン」は強力なプログラマビリティを持っていることを示すことを目的としています。 チューリング完全プログラミングをサポートするシステムは、そうでないシステムよりも一般的にプログラミングが簡単であるという、これらの言明の含意にはいくつかの真実があります。 しかし、スマートコントラクトシステムの構造的特徴には多くの側面があり、この記述はそのうちの1つにしか触れていないため、開発者がそれに導かれず、一般ユーザーが不正を見分けるのに頼ることができないという事実により、十分に深く理解されるには十分ではありません。
スマートコントラクトシステムの構造的特徴には、以下のようなものがあります。
したがって、「プログラム可能な任意の計算」に加えて、スマートコントラクトシステムのプログラマビリティに影響を与える特性が少なくとも4つあります。 これらの他の機能は、達成しやすいものと達成するのが難しいものをより深いレベルで決定するため、より重要であるとさえ言えます。 より経済的な実装と非効率な実装はどれですか。
例えば、イーサリアムは優れたプログラマビリティの例としてよく引き合いに出されますが、イーサリアムにおける状態表現の基本形はアカウントであるため、ピアツーピア契約(ペイメントゲートウェイ、1対1のベッティング契約など)のプログラミングは困難です。 イーサリアムのエコシステムがペイメントチャネル/ステートチャネルを実装しようとすることは珍しくなく、多くの理論的な議論が行われてきましたが、これらのプロジェクトはもはや活発ではないようです。 現在、イーサリアムで活動しているプロジェクトが「ピアツーピア契約」ではなく「プール」の形をとっているのは偶然ではありません。 同様に、人々はイーサリアムのプログラマビリティに満足しているかもしれませんが、アカウントモデルは「アカウントの抽象化」(ウォレットの概念の一般化としても理解できます)の実現には本質的に不十分です。
同様に、CKBのプログラマビリティを探るには、これらの側面におけるCKBスマートコントラクトシステムの構造的特徴を理解する必要があります。 すでにわかっていることは、CKBでは任意の計算をプログラムでき、コントラクト内に追加の状態を記録でき、実行時にあるコントラクトが別のコントラクトの状態にアクセスできるということです。 しかし、コントラクトの形式はトランザクションのアウトプット(「セル」と呼ばれる)であり、イーサリアムとは根本的に異なります。 したがって、イーサリアムのスマートコントラクトシステムとその中のコントラクトインスタンスを理解しても、CKBがこれらの構造的特徴をどのように実装しているかを理解することはできず、CKBのプログラマビリティを理解することにも役立ちません。
幸いなことに、ビットコインのスマートコントラクトは、CKBのプログラマビリティを理解するための最良の基盤を提供するようです。 これは、ビットコインの状態表現の基本形式がトランザクションの出力(「UTXO」と呼ばれる)でもあるだけでなく、ビットコインコミュニティによって提案された「コベナンツ」と呼ばれる概念の助けを借りて、CKBがこれらの構造的特性を持っている理由を理解し、最終的な効果をいくつかの部分に適切に分解し、それぞれがもたらすプログラマビリティの向上を特定できるためです。
II. CKB v.s. BTC:さらに?
(1) 基本構造
ビットコインの状態表現の基本形式として、ビットコインのUTXO(「未使用トランザクション出力」)には2つのフィールドがあります。
後に登場するスマートコントラクトシステムと比較して、ビットコインスクリプトはかなり制限されています。
*任意の計算をプログラミングすることはできません。 検証に使用できる実用的な計算はごくわずかです(署名チェック、事前ハッシュチェック、時間チェック) *契約内に追加の状態を記録することはできません。 (たとえば、スクリプトを使用して、一度に費やす金額の比例/最大額を制限することはできません。 また、トークンを隠す方法もありません)
この種のスクリプトは、限定的ではありますが、すばらしいアプリケーションをプログラミングする能力に欠けるわけではなく、CKB プログラマビリティの探求の基盤となっています。 後で、ビットコインスクリプトプログラミングの2つの例を紹介するセクションがあります。
対照的に、CKBの状態単位は「セル」と呼ばれ、次の4つのフィールドがあります。
さらに、ロックとタイプは任意の計算用にプログラムできます。 任意の署名検証アルゴリズムをプログラムしたり、プリイメージ チェック用の任意のハッシュ アルゴリズムをプログラムしたりできます。
CellがUTXOよりもプログラマビリティがどのように向上しているかは、読者にとって容易に理解できます。
*セルは、いくつかの特定の計算ではなく、任意の計算でプログラムできます。 その所有権の確認はより柔軟になります。
セル自体の「トランザクション出力」構造と合わせると、これら2つの点自体の利点は非常に大きいのですが、上記の説明だけでは、セルが「あるコントラクトが実行時に別のコントラクトの状態にアクセスする」ということをどのように実現しているのかはわかりません。 これを行うには、ビットコインコミュニティで長い間議論されてきた概念である「コベナンツ」を利用する必要があります。
(2) 制限とイントロスペクション
制限条項の本来の目的は、金額を使用できる場所を制限することです。 現在のビットコイン(制限が提案されていない)では、ロックが解除されると、1つの金額をどこでも使用できます(任意のスクリプト公開鍵に支払うことができます)。 しかし、制限条項の考え方は、特定の場所に限定する方法で使うことができるというもので、例えば、あるUTXOは特定のトランザクションによってのみ使用されるため、誰かがUTXOの署名を提供することができたとしても、それが使用できる場所は、そのトランザクションによってすでに決定されています。 これは少し奇妙に思えるかもしれませんが、後のセクションで説明するいくつかの興味深いアプリケーションにつながる可能性があります。 重要なことは、CKBのプログラマビリティをさらに理解するための鍵となることです。
Rusty Russellは、制限は取引のための「イントロスペクション」能力として理解できると正しく指摘しており、つまり、UTXO AがトランザクションBによって使用されると、スクリプトオペレーターはトランザクションBの一部(またはすべて)を読み取り、それらがスクリプトによって事前に要求されたパラメータと一致することをチェックすることができます。 例えば、トランザクションAの最初のアウトプットのスクリプト公開鍵が、UTXO Aのスクリプト公開鍵で要求されるものと一致するかどうか(これが本来の制約の意味です)。
賢明な読者は、完全なイントロスペクションを行うことで、あるトランザクションの入力が同じトランザクションの別の入力の状態を読み取ることができることに気付くでしょう。 実際、CKB Cellはまさにそのように設計されました。
これに基づいて、この完全な内省能力を4つのシナリオに分けることができます。
*ロックは、他の(入力および出力)ロックを読み取ります *ロックは、他のタイプ(およびデータ)を読み取ります(入力と出力) *型は他の(入力および出力)ロックを読み取ります *タイプは、他のタイプ(入力と出力)のタイプ(およびデータ)を読み取ります
これにより、特定の仮定(LockとTypeの機能の分割)、つまり各部分がもたらすプログラマビリティの向上の下で、さまざまなユースケースにおける各部分のイントロスペクション機能の役割を分析できます。
次の2つのセクションでは、ビットコインスクリプトの現在の(そしてまだ提案されていない)プログラミングと、提案された制限が達成すると予想される機能を見て、CKBセルをプログラムしてより良くする方法を具体的に理解します。
III. ビットコインスクリプトプログラミング
ここでは、ビットコインスクリプトに基づくアプリケーションプログラミングの例として、「ライトニングチャネル/ライトニングネットワーク」と「コーションジャーナル契約(DLC)」を使用します。 その前に、2つのことを取り上げましょう。
(1) OP_IF と「コミットメント・ディール」
最初の概念は、ビットコイン スクリプトのフロー制御オペコード (OP_IF、OP_ELSE など) です。 これらのオペコードは、コンピュータプログラミングのIFと変わらず、その目的は、異なる入力に基づいて異なるステートメントを実行することです。 ビットコインスクリプトのコンテキストでは、これは資金に複数のロック解除パスを設定できることを意味します。 タイムロック機能と組み合わせることで、アクションに優先順位を割り当てることができます。
有名な「ハッシュタイムロックコントラクト(HTLC)」を例にとると、これは俗語に訳されます。
この「または... または...」 この効果は、プロセス制御オペコードによって実現されます。
Taprootソフトフォークのアクティベーション後、MAST(Merkle Abstract Syntax Tree)の導入により、このマルチロックパス機能がさらに強化されました: ロック解除パスをマークルツリー上のリーフに変えることができ、各リーフは独立しているため、このようなフロー制御オペコードを使用する必要はなくなりました。 また、1 つのパスが他のパスを公開せずに明らかにされるため、経済性を気にすることなく、より多くのロック解除パスを出力に追加できます。
2つ目のコンセプトは「コミットメント取引」です。 コミットされたトランザクションの考え方は、場合によっては、有効なビットコイントランザクションは、ブロックチェーンによって確認されていなくても、同じように現実的で拘束力があるということです。
例えば、アリスとボブがUTXOを共有しているとしますが、そのUTXOを利用するには、両者が署名する必要があります。 この時点で、アリスはそれを使用するトランザクションを構築し、その価値の60%をボブに、残りを自分に転送します。 Alice はトランザクションに独自の署名を提供し、それを Bob に送信します。 まあ、ボブにとって、それはビットコインネットワークにブロードキャストされる必要はなく、ブロックチェーンによって確認される必要はなく、このトランザクションの支払い効果も現実的で信頼できるものです。 アリスはUTXOを自分で使うことができない(したがって繰り返し使うことができない)ため、またアリスから提供された署名は有効であるため、ボブはいつでも自分の署名を追加し、トランザクションをブロードキャストして支払いを受けることができます。 言い換えれば、アリスは、この有効な(オフチェーンの)取引を通じて、ボブに「信頼できるコミットメント」を提供したのです。
コミットされたトランザクションは、ビットコインアプリケーションプログラミングのコアコンセプトです。 前述のように、ビットコインの契約は検証ベースでステートレスであり、クロスアクセスを許可していません。 ただし、コントラクトに状態がない場合、それらの状態はどこに格納され、コントラクトを安全に進める(状態を変更する)にはどうすればよいでしょうか。 コミットメントトランザクションは、コントラクトの状態をトランザクションの形で表現できるため、コントラクトの参加者はブロックチェーンに表示することなく、自分で状態を保存することができます。 コントラクトの状態を変更するという問題は、コミットされたトランザクションを安全に更新する方法の問題に変換することもできます。 また、契約を締結することの危険性が懸念される場合(例えば、双方が署名しないと決済できない契約書を締結し、相手が反応せず、行き詰まるリスクがある場合など)は、事前に契約にコストがかかるコミットメントトランザクションを生成し、署名を得るだけで、リスクを軽減し、他の参加者への信頼をなくすことができます。
(2) ライトニングチャネルとライトニングネットワーク
ライトニングチャネルは、ブロックチェーンによって1つの支払いが確認されることなく、2つの当事者がお互いに無制限に支払うことができる1対1の契約です。 ご想像のとおり、コミットメント取引を使用しています。
「コミットされたトランザクション」の説明セクションでは、すでに支払いチャネルを紹介しました。 しかし、この種のコントラクトは、2-of-2マルチシグのみを利用するため、片道の支払いしかできません。 つまり、アリスが常にボブに支払うか、ボブが契約の残高を使い切るまで常にアリスに支払うかのいずれかです。 双方向の支払いの場合、ステータス更新後、一方の当事者の残高が以前よりも少なくなる可能性があるが、TAは他方の当事者が署名した最後のコミットされたトランザクションを持っていることを意味します-TAが古い約束をブロードキャストし、TAが最新のコミットメントトランザクションのみをブロードキャストするのを止めるにはどうすればよいでしょうか?
ライトニングチャネルに関するこの問題の解決策は、「LN-Penalty」と呼ばれます。 ここで、アリスとボブがそれぞれ5BTCをチャンネルに持っているとしましょう。 ここで、アリスはボブに1BTCを支払いたいので、約束された取引に署名し、ボブに送ります。
また、ボブはコミットメント(上記のトランザクションに対応)に署名し、それをアリスに送信します。
ここでのトリックは、この「共同一時公開鍵」にあり、これは、自分の公開鍵の1つと、相手から提供された公開鍵を使用して生成され、例えば、アリスとボブの共同一時公開鍵は、アリスが自分の公開鍵とボブから提供された公開鍵の1つを使用して取得し、それぞれにハッシュ値を掛けたものです。 このような公開鍵が生成されると、その秘密鍵は誰にもわかりません。 ただし、Bob が提供した公開キーの秘密キーを Alice に伝えると、Alice はフェデレーション一時公開キーの秘密キーを計算できます。 - これは、ライトニングチャネルが古い状態を「元に戻す」ことができるという事実の鍵です。
次に 2 つの当事者がチャネル ステータスを更新する (支払いを開始する) ときに、2 つの当事者は、前のラウンドで互いに与えられた一時的な公開キーの秘密キーを交換します。 このようにして、参加者は、受け取った最後の約束されたトランザクションをあえてブロードキャストしなくなります:自分のパーティに値を割り当てるこの約束されたトランザクションの出力には2つのパスがあり、一時的な公開鍵パスの秘密鍵はすでに相手に知られています。 したがって、古いコミットメントトランザクションがブロードキャストされると、相手方はすぐにこの共同一時秘密鍵を使用して、この出力のすべての資金を受け取ることができます。 - これが「LN-ペナルティ」の意味です。
具体的には、支払いを開始する当事者は、まず相手方に新しい一時公開鍵を要求し、次に新しいコミットメントトランザクションを構築して相手方に渡すという、対話の順序です。 約束された取引を受けた当事者は、前回のラウンドで渡した一時的な公開鍵の秘密鍵を相手に公開しました。 この一連の相互作用により、参加者は、前のラウンドで受け取ったコミットメントトランザクションを無効にする前に、常に新しいコミットメントトランザクションを取得するため、トラストレスになります。
要約すると、ライトニングチャネルの主な設計は次のとおりです。
1.両当事者は、常にコミットメントトランザクションを使用して契約内の状態を表現し、金額の変更を使用して支払いを表現します。 2. コミットメント取引は、常に同じインプット(両当事者が同時に署名を提供する必要があるインプット)のコストがかかるため、すべてのコミットメント取引は互いに競合しており、ブロックチェーンで確認できるのは1つだけです。 3. 2 人の参加者が同じコミットメント トランザクションに署名していない (ペアになっているが)。 そして、彼らが署名するものは、常に彼ら自身にとってより有利な取引であり、言い換えれば、参加者が受け取る約束された取引は常に彼ら自身にとって不利なものです。 4.これの欠点は、それ自体に値を割り当てる出力には2つのロック解除パスがあることです:1つのパスは独自の署名でロック解除できますが、しばらく待つ必要があります。 もう一方のパスは、相手の公開キーを使用し、一時的な秘密キーの 1 つが公開されていない場合にのみ保護されます。 5.各支払いにおいて、両当事者は、前のラウンドで相手方が使用した一時的な秘密鍵を新しいコミットメントトランザクションと交換し、一時的な秘密鍵を引き渡した当事者が古いコミットメントトランザクションをあえてブロードキャストしないようにするため、以前のコミットメントトランザクションを「キャンセル」し、契約のステータスを更新します。 (実際には、これらの約束されたトランザクションはすべて有効なトランザクションであり、ブロックチェーンにブロードキャストできますが、参加者は罰せられ、あえてもうブロードキャストされません) 6. いずれの当事者も、他方当事者が署名した誓約により、いつでも契約を撤回することができます。 ただし、両当事者が協力する意思がある場合は、新しい契約に署名して、両当事者がすぐにお金を取り戻すことができます。
最後に、HTLCはコミットされたトランザクションにも配置できるため、Lightningチャネルは支払いを転送することもできます。 アリスがダニエルに到達するために前後に接続するライトニングチャネルで構成されるパスを見つけることができると仮定すると、ダニエルとチャネルを開かなくてもトラストレスなマルチホップ支払いを実現できます。 これはライトニングネットワークです。
アリスがそのようなパスを見つけてダニエルにお金を払おうとすると、アリスはダニエルにボブのHTLCを構築するためのハッシュを要求し、ボブにキャロルにメッセージを転送して同じHTLCを提供するように促します。 このメッセージにより、キャロルはメッセージをダニエルに転送し、同じHTLCを提供するように求められます。 その知らせがダニエルに届くと、ダニエルはキャロルにプリイメージを明かし、それが彼にHTLCの価値を与え、契約の状態を更新します。 キャロルも同じことをして、ボブから支払いを受け、チャンネルのステータスを更新しました。 最後に、Bob はプリイメージを Alice に公開し、ステータスを更新します。 HTLCの性質上、この一連の支払いは一緒に成功するか失敗するかのどちらかであり、そのため、信頼できません。
ライトニングネットワークは、それぞれが互いに独立しているチャネルから次々と構成されています。 つまり、Alice は、他の人のチャンネルで何回やり取りが行われたか、それらのやり取りがどの通貨を使用しているか、または実際にチャンネルを使用しているかどうかに関係なく、Bob とのチャンネルで何が起こっているかを知るだけで済みます。
ライトニングネットワークのスケーラビリティは、ライトニングチャネル内の支払い速度が両当事者によるハードウェアリソースの投資によってのみ制限されるという事実に反映されているだけでなく、状態の分散型ストレージにより、単一のノードが最小のコストで最大のレバレッジを活用できることにも反映されています。
(3) 仕訳帳契約書に注意する
注意ジャーナリングコントラクト(DLC)は、「アダプター署名」と呼ばれる暗号化技術を使用して、ビットコインスクリプトが外部イベントに依存する金融コントラクトをプログラムできるようにします。
アダプター署名を使用すると、秘密キーが追加された後にのみ、署名を有効な署名にすることができます。 シュノア署名を例にとると、シュノール署名の標準形式は (R, s) です。
ここで、データのペア(R、s')を与えるとしましょう。
明らかに、これは有効なシュノア署名ではなく、検証式に合格しませんが、R 2、r 2の秘密鍵を知っているだけで、有効な署名になり得ることを検証者に証明できます。
アダプター署名は、署名の有効性をシークレット・データに依存し、検証可能にします。 しかし、これは金融契約と何の関係があるのでしょうか?
アリスとボブが球技の結果に賭けたいとしましょう。 アリスとボブは、グリーンゴブリンとアリーナがそれぞれ勝つことに賭け、1BTCを賭けます。 さらに、サッカーのレビューサイトであるキャロルは、試合結果が発表されたときに、ノンスR_cを使用して、署名されたs_c_iの結果を投稿することを約束しました。
ご覧のとおり、3つの可能な結果があります(したがって、キャロルの署名には3つの可能性があります)。
グリーンゴブリンが勝利、アリスが1BTCを獲得
Alinaが勝ち、ボブが1BTCを獲得
引き分け、2つの資金は同じように返されます
これを行うために、2 人は結果ごとにコミットメント契約を作成します。 たとえば、最初の結果に対して作成したコミットメント トランザクションは、次のようになります。
ただし、Alice と Bob がこのトランザクション用に作成した署名は、(R, s) ではなく、アダプター署名 (R, s') です。 言い換えれば、両当事者がお互いに与えた署名は、契約のロックを解除するために直接使用することはできませんが、秘密の価値を明らかにする必要があります。 この秘密の値は、キャロルの署名である s_c_ 1.G のプリイメージです。 キャロルの署名ノンス値が決定された(R:_c)ので、s_c_ 1.Gは構築できます(s_c_ 1.G = R_c + Hash(R_c ||)。 「グリーンゴブリンの勝利」 || PK_c) * PK_c)。
結果が判明すると、グリーンゴブリンが勝ったと仮定すると、キャロルは署名(R_c, s_c_ 1)を発行し、アリスかボブのどちらかが相手のアダプタ署名を完成させ、自分の署名を追加して上記の取引を有効な取引とし、それをネットワークにブロードキャストして決済効果を発動させます。 しかし、グリーンゴブリンが勝てない場合、キャロルはs_c_ 1をポストせず、コミットメント取引は有効な取引ではありません。
そして、他の2つの取引も同様です。 このようにして、Alice と Bob は、取引相手を信頼することなく、コントラクトの実行を外部イベント (正確には、署名の形でアサータ マシンによる外部イベントのブロードキャスト) に依存させます。 先物やオプションなどの大小の金融契約は、この方法で実装できます。
他の実装形式と比較して、慎重なログ契約の最も重要な特徴は、そのプライバシーです:(1)アリスとボブは、キャロルのデータを使用していることをキャロルに伝える必要はなく、契約の実行にはまったく影響しません。 (2) オンチェーンのオブザーバー(キャロルを含む)は、アリスとボブの契約締結を通じて、どのウェブサイトを使用しているか、または契約が賭け契約(ライトニングチャネルではない)であるかどうかを判断することはできません。
IV. 制限の適用の概要
(a) OP_CTVと輻輳制御
ビットコインコミュニティの開発者は、制限条項として分類できる多くの提案を行いました。 現時点では、最もよく知られている提案の1つがOP_CHECKTEMPLATEVERIFY(OP_CTV)で、シンプルでありながらシンプルなコンセプトで柔軟性があることでビットコインコミュニティに人気があります。 OP_CTVの考え方は、スクリプトでハッシュをコミットして、このハッシュで表されるトランザクションによってのみ資金を使用できるように制限することです。 このハッシュは、トランザクションの出力とほとんどのフィールドを約束しますが、トランザクションの入力ではなく、入力の数のみを約束します。
「輻輳制御」は、OP_CTVを実証する方法の良い例です。 その基本的なユースケースは、多数のユーザーが取引所(信頼を必要とする環境)からプールに抜けるのを支援することです。 このプールは OP_CTV を使用して将来の使用方法を計画するため、ユーザーは誰の助けも借りずに信頼できないプールを終了できます。 また、このプールはUTXOとしてのみ動作するため、オンチェーントランザクションの需要が高い場合(nアウトプットから1アウトプットまで; また、n トランザクションから 1 トランザクションに減らされました)。 プール内のユーザーは、プールを終了する機会を待つことができます。
アリス、ボブ、キャロルがそれぞれ取引所から5BTC、3BTC、2BTCを引き出したいとします。 その後、取引所は3つのOP_CTVブランチで10BTCの出力を行うことができます。 アリスがお金を引き出したいとしましょう、彼女はブランチ1を使用できます。 ブランチのOP_CTVで使用されるハッシュ値で表されるトランザクションは、2つのアウトプットを形成し、そのうちの1つは5BTCをAliceに割り当てることです。 もう1つのアウトプットはプールで、これもOP_CTVを使用してトランザクションにコミットし、ボブが3BTCのみを引き出し、残りの2BTCをキャロルに送ることができます。
ボブやキャロルがお金を引き出したいと思っても同じです。 お金を引き出すとき、彼らは対応するOP \ _CTVチェックに合格できるトランザクションのみを使用することができ、つまり、対応する金額を自分自身に支払うことしかできず、任意にお金を引き出すことはできません。 残りの資金はOP_CTVロックでプールに入るため、残りのユーザーは、引き出される順序に関係なく、信頼できないほどプールから外すことができます。
要約すると、ここでのOP_CTVの役割は、コントラクトのコントラクトの寿命が尽きるまでのパスを計画し、ここでのプールコントラクトが、どのパスをたどっても、どの状態になっても、トラストレスな出口の属性を維持できるようにすることです。
また、このOP_CTVには、「隠されているが明らかにされていない一方通行の支払いチャネル」という非常に興味深い使い方があります。 アリスがそのような資金プールを形成し、次のスクリプトを使用して資金をトラストレスにアウトプットに引き出すことができることを保証するとします。
アリスがボブにそれを明かさなかったら、ボブはそのような出力が存在することを知らなかったでしょう。 アリスがボブにそれを明らかにすると、ボブはその出力を時間的制約のある一方向の支払いチャネルとして使用し、アリスはブロックチェーンからの確認を待たずにボブにすぐに支払うことができます。 ボブは、アリスが自分でコミットメントトランザクションを使う前に、コミットメントトランザクションをオンチェーンにするようにアリスに依頼するだけです。
(b) OP_Vault と安全
OP_VAULTは、「保管庫」を構築するために特別に設計された制限条項の提案です。
Vault契約は、より安全で高度なセルフカストディの形態になるように設計されています。 現在のマルチシグコントラクトでは、1つの秘密鍵の単一障害点を回避できますが、攻撃者がしきい値の秘密鍵を取得した場合、ウォレットの所有者は無力です。 Vault は、資金に 1 つの使用制限を課したいと考えています。 同時に、通常のルートを使用してお金を引き出す場合、引き出し操作には待機期間が強制されます。 また、待機期間中は、ウォレットの緊急復旧操作によって引き出し操作を中断できます。 そのような契約が破られた場合でも、ウォレットの所有者は(緊急復旧ブランチを使用して)対抗操作を開始できます。
理論的には、OP \ _CTVもそのような契約をプログラムすることができますが、多くの不便があり、そのうちの1つは手数料です:トランザクションにコミットしながら、トランザクションが支払う手数料も約束します。 この契約の目的を考えると、契約を設定してからお金を引き出すまでの時間間隔は非常に長くなければならないため、適切な手数料を予測することはほとんど不可能です。 OP_CTVはインプットを制限しないので、インプットを増やすことで手数料を増やすことができますが、提供されたインプットはすべてコミッションになるので非現実的です。 もう一つの方法はCPFPで、これは引き出した資金を使うことによって新しい取引に手数料を提供することです。 さらに、OP_CTVを使用すると、そのようなVault契約を一括で取り消すことはできません(もちろん、一括で復元することもできません)。
OP_VAULT プロポーザルは、新しいオペコード (OP_VAULT と OP_UNVAULT) を提案することで、これらの問題に対処しようとします。 OP_UNVAULT はバッチの回復性を考慮して設計されているため、ここでは説明しません。 OP_VAULT は次のように振る舞います: スクリプトツリーのブランチに配置すると、特定のパラメータなしで使用可能なオペコード (OP_CTV など) にコミットするために使用できます。 このブランチを使用する場合、トランザクションは特定のパラメーターで渡すことができますが、他のブランチでは渡すことができません。 その結果、プリセット料金を設定する必要はなく、ブランチが使用されるときに設定できます。 ブランチにもタイムロックがあると仮定すると、タイムロックが適用されます。 最後に、変更できるのは現在のブランチのみであり、新しいスクリプトツリーの他のブランチ(緊急リカバリブランチを含む)は変更されないため、そのような引き出しを中断することが許可されています。
さらに、2つの点に言及する価値があります:(1)OP_VAULTオペコードは、別の制限提案OP_TLUVと同様に動作します。 Jeremy Rubin氏は、これがある程度「計算」の概念を生み出したと正しく指摘しています。 OP_TLUV/OP_VAULTはまず、コンシューマが新しいトランザクションでオペコードにパラメータを渡すことでスクリプトツリーリーフ全体を更新できるようにするオペコードを約束します。 もはや「特定の基準に基づいて受信データを検証する」ことではなく、「受信データに基づいて新しい意味のあるデータを生成する」ことが目的ですが、可能にできる計算は限られています。
(2) フルOP_VAULTプロポーザルは、より良い結果を得るために、mempoolポリシーに関するいくつかの提案(v3トランザクションなど)も利用します。 このことは、「プログラミング」の意味が私たちが思っているよりも広いことを思い出させてくれます。 (同様の例は、Nervos NetworkのOpen Transactionです。 ）
V. CKBを理解する
上記の2つのセクションでは、より制約のある構造(ビットコイン UTXO)で興味深いアプリケーションをスクリプト化する方法について説明します。 このような構造に内省を加えようとする提案も提示されました。
UTXOはこれらのアプリケーションをプログラムすることができますが、読者は次のような欠点や最適化できる領域を簡単に見つけることができます。
※LN-Punishmentでは、チャネル参加者は、相手の不正に対処するために、過去にコミットした各トランザクションとそれに対応するペナルティの秘密値を保存する必要があり、ストレージの負担となります。 直近のコミットメントトランザクションのみが有効になり、古いコミットメントトランザクションは有効にならないことを保証する仕組みがあれば、この負担をなくすことができ、また、古いコミットメントトランザクションを誤ってオンチェーンに置いたことでノードが誤ってペナルティを受けるという問題も解消できます。 ※DLCでは、イベントの結末が多々あることが想定されており、事前に双方が生成して引き渡さなければならない署名が多く、これも大きな負担となっています。 また、DLC契約の収入は公開鍵に直接紐づいているため、そのポジションを譲渡するのは簡単ではありませんが、契約のポジションを譲渡する方法はありますか?
実際、ビットコインコミュニティは、基本的にSighashの提案(BIP-118 AnyPrevOut)に関連するこれらの質問に対する答えを考え出しました。
しかし、CKBでプログラミングするのであれば、BIP-118が利用可能になります(このようなSighashタグは、内省的かつ意図的に署名を検証する機能でシミュレートできます)。
ビットコインのプログラミングを学ぶことで、「トランザクション出力」(CKBでプログラムできるもの)の形式でプログラムする方法だけでなく、これらのアプリケーションを改善する方法(およびCKBでプログラムする場合にCKBの機能を使用してそれらを改善する方法)も知っています。 CKB開発者にとって、ビットコインスクリプトに基づくプログラミングは、学習教材として、あるいはショートカットとしても使用できます。
以下では、CKBプログラミングの各モジュールのプログラマビリティを1つずつ分析してみましょう。 今のところ、内省について考えるのはやめましょう。
(1) プログラム可能な任意計算ロック
前述したように、UTXOは任意に計算するようにプログラムすることはできません。 一方、Lockは、LockがUTXOに基づいて(制限の展開前に)上記のライトニングチャネルやDLCを含むがこれらに限定されないすべてをプログラムできることを意味します。
さらに、この任意の計算を検証する機能により、認証方法の点でも UTXO よりも柔軟性があります。 たとえば、一方の当事者が ECDSA に署名し、もう一方の当事者が RSA を使用するライトニング チャネルを CKB に実装できます。
実際、これはCKBで人々が探求し始めた最初の分野の1つであり、ユーザーのセルフカストディでこの柔軟な認証機能を使用して、「アカウントの抽象化」と呼ばれるものを可能にします。 原則として「複数の分岐」と「任意の認証方法」の組み合わせです。 実装の例としては、joyid wallet、UniPassなどがあります。
さらに、Lockはeltooプロポーザルを実装できるため、コミットされた最新のトランザクションのみを保持する必要があるライトニングチャネルが可能になります(実際、eltooはすべてのピアツーピアコントラクトを簡素化できます)。
(2) プログラム任意計算型
前述したように、Type の大きな用途の 1 つは UDT のプログラミングです。 Lockと組み合わせることで、UDTベースのライトニングチャネル(およびその他のタイプのコントラクト)を実装できます。
実際、LockとTypeの分割はセキュリティのアップグレードと見なすことができ、Lockは管理方法や契約上の合意の実装に焦点を当て、TypeはUDTの定義に焦点を当てています。
さらに、UDTの定義に基づいてチェックを開始できるため、UDTはCKBと同様の方法で契約に参加できます(UDTは第一級市民です)。
たとえば、著者はかつて、ビットコインでトラストレスなNFT担保融資を実装するためのプロトコルを提案しました。 このようなプロトコルの鍵となるのは、インプットの値がアウトプットの値よりも小さい(したがって、まだ有効なトランザクションではない)コミットされたトランザクションですが、トランザクションに十分なインプットが提供されると、それは有効なトランザクションであり、貸し手が返済できるようになると、貸し手はステークされたNFTを自分で受け取ることはできません。 しかし、このコミットメント取引のトラストレスは、インプットとアウトプットの量をチェックする取引に基づいているため、貸し手はローンの返済にビットコインしか使えません - 貸し手と貸し手の両方が別の通貨(RGBプロトコルで発行されたUSDTなど)を受け入れる意思があるとしても、ビットコイン取引はUSDTのステータスを把握していないため、貸し手がUSDTの全額を返す限り、ビットコインコミットメント取引は貸し手がNFTを取り戻すことを保証するものではありません。 (改定:言い換えれば、USDTの返済を条件とするコミットされたトランザクションを構築することはできません。 ）
UDTの定義に基づいてチェックを開始できれば、貸し手がUSDTを使用してローンを返済できるようにする別のコミットされたトランザクションに貸し手に署名してもらうことができます。 このトランザクションでは、USDTの入力額と出金額がチェックされ、ユーザーはUSDTでトラストレスな返済を行うことができます。
次に、内省について考えてみましょう。
(3) ロックは他のロックを読み込む
これは、提案された制限が実装された後のビットコインUTXOでのプログラミングの可能性の全範囲を意味します。 これには、上記のVaultコントラクトや、OP_CTVベースのアプリケーション(輻輳制御など)が含まれます。
XueJieはかつて非常に興味深い例を挙げました:この種のセルをトランザクションの入力として使用する場合、CKBにコレクションアカウントセルを実装できますが、出力セル(同じロックを使用するセル)の容量が多い場合、入力は署名を提供する必要がなく、トランザクションの有効性に影響を与えません。 実際、この種の細胞は、内省する能力なしには不可能です。 この回収口座セルは、資金をプールするだけでなく、プライバシーの感覚が悪いというデメリットがあるため、制度的なお金の受け取り方法として理想的です。
(4) ロックは他の型(およびデータ)を読み込む
この機能の興味深い用途は、ステークトークンです。 Lockは、他のインプットのトークン数と、それをどこで使用できるかに基づいて、独自の容量を使用できるかどうかを決定します(ロックをイントロスペクトする機能が必要です)。
(5) 型は他のロックを読み取る
よくわかりませんが、有用であると想定できます。 たとえば、トランザクションの入力と出力のロックが変更されないことを [タイプ] で確認できます。
(6) 型 Scirpt は他の型 (およびデータ) を読み込みます
トレーディングカード? より大きなトークンと引き換えにn個のトークンを集める:)
VI. まとめ
イーサリアムのような任意の計算でプログラムできる以前のスマートコントラクトシステムと比較して、Nervos Networkは異なる構造を取ります。 その結果、過去のスマートコントラクトシステムの知識に基づいてNervos Networkを理解することはしばしば困難です。 本稿では、CKB Cellよりも制限の厳しい構造であるBTC UTXOのアプリケーションプログラミングから始めて、CKB Cellのプログラマビリティを理解する手法を提案する。 また、「イントロスペクション」という概念を用いて、細胞の「クロスコントラクトアクセス」能力を理解することで、イントロスペクション能力が使われる場面を分け、具体的な用途を決定することができます。
リセンション:
1.セルのクロスアクセス機能(つまり、イントロスペクション機能)に関係なく、ロックは、極限に達した状態およびプログラミング機能を備えたビットコインと見なすことができるため、すべてのビットコインベースのアプリケーションをこれに基づいてのみプログラムできます。 2.セルのクロスアクセス機能(すなわち、イントロスペクション機能)に関係なく、ロックとタイプの区別は、セキュリティのアップグレードと見なすことができます:UDTの資産定義と保管方法を分離します。 また、UDTの効果を発揮する公開可能な状態のタイプs(およびデータ)は、第一級市民です。
上記の2つのポイントは、「BTC + RGB」と同じパラダイムを持つことを意味しますが、より多くのプログラミング機能を備えています。
これらの利用の具体例はあまりないが、これは筆者がCKBの生態を理解していないことによるものである。 時間が経つにつれて、ますます多くの想像力がそれに投資され、今日では想像もつかないようなアプリケーションが組み立てられると考えられています。
謝辞
記事の執筆中にフィードバックをくれた Retric、Jan Xie、Xue Jie に感謝します。 もちろん、テキストのすべての間違いについては私が責任を負います。
参考文献
アカウント、厳密なアクセスリスト、UTXO
ビットコインの制限:レビューのための分類
セルモデル
Nervos CKBの概要
ビットコインのプログラマビリティ
アカウント抽象化(2022)
ビットコインマーケル化抽象構文木とは何ですか?
BIP 345: OP_VAULT提案
TLUV制限オペコードの概要
コントラクトを構築するコンポーネントは、ビットコインでアップグレードされます
エルトゥーは次のように説明している
コミットされた取引に基づくNFT担保付き貸付契約 · btc-study/OP_QUESTION · ディスカッション #7
元の記事へのリンク