以下のコンテンツは、Ajian (ビットコイン コンテンツ プラットフォーム BTC Study の編集長) によって書かれた、Nervos Talk フォーラムからの転載です。
システムのプログラマビリティを理解するには、システムの構造的特徴を特定する必要があります。ビットコイン スクリプトに基づくアプリケーション プログラミングの探求は、CKB Cell の基本構造とそのプログラミング パラダイムを理解するのに役立ちます。それだけでなく、CKB のプログラミング要素を適切な部分に分割し、各部分がもたらすプログラマビリティの向上を理解するのにも役立ちます。
「プログラマビリティ」は、ブロックチェーン システムを比較するときによく取り上げられる側面です。ただし、プログラマビリティの説明方法については意見の相違がよくあります。一般的な表現は、「XX ブロックチェーンはチューリング完全プログラミング言語をサポートする」または「XX ブロックチェーンは一般的なプログラミングをサポートする」ですが、これは、ここでの「XX ブロックチェーン」が強力なプログラマビリティ セックスを持っていることを意味することを意図しています。これらの記述の含意にはある程度の真実があります。チューリング完全プログラミングをサポートするシステムは、一般に、サポートしないシステムよりもプログラミングが簡単です。ただし、スマート コントラクト システムの構造的特徴には多くの側面があり、この声明ではそのうちの 1 つについてのみ触れているため、開発者はそこから指針を得ることができず、一般のユーザーは区別することができません。それからの詐欺。
スマートコントラクトシステムの構造上の特徴は次のとおりです:
つまり、「任意の計算をプログラムできるかどうか」に加えて、スマート コントラクト システムのプログラマビリティに影響を与える 4 つの特性があります。これらの他の特性は、何が実装しやすく、何が実装しにくいかをより深いレベルで決定するため、より重要であるとさえ言えます。
たとえば、優れたプログラム可能性の例としてイーサリアムが挙げられますが、イーサリアムにおける状態表現の基本的な形式はアカウントであり、ピアツーピア契約 (たとえば、支払いチャネル、 -1 対 1 の賭け契約) ——それは絶対に不可能ではありませんが、ただ感謝できないだけです。イーサリアムのエコシステムには、支払いチャネル/ステータス チャネルを実装しようとするプロジェクトが一度もなかったわけではありません。理論的な議論も数多くありますが、これらのプロジェクトは現在活動していないように見えます。これは明らかに開発者の努力の欠如に起因するものではありません。現在イーサリアム上で活動しているプロジェクトがすべて「ポイントツーポイント契約」ではなく「資金プール」の形をとっているのは偶然ではありません。同様に、人々はイーサリアムのプログラマビリティに非常に満足しているかもしれませんが、「アカウントの抽象化」（ウォレットの概念の一般化とも理解できます）を実現することになると、アカウント モデルには本質的に欠陥があります。
同様に、CKB のプログラマビリティを調査するには、これらの側面における CKB スマート コントラクト システムの構造的特徴を理解する必要があります。私たちがすでに知っていることは、CKB では任意の計算のプログラミングが可能であり、コントラクト内の追加の状態の記録が可能であり、あるコントラクトが実行中に別のコントラクトの状態にアクセスできるということです。ただし、その契約の形式はトランザクションの出力 (「セル」と呼ばれます) であるため、イーサリアムとは根本的に異なります。したがって、イーサリアム スマート コントラクト システムとその中のコントラクト インスタンスを理解しても、CKB がこれらの構造的機能をどのように実装するかを理解するのには役立ちません。また、CKB のプログラム可能性を理解するのにも役立ちません。
幸いなことに、ビットコインのスマート コントラクトは、CKB のプログラマビリティを理解するための最良の基盤を提供しているようです。これは、ビットコインの状態表現の基本形式もトランザクションの出力 (「UTXO」と呼ばれます) であるためだけでなく、ビットコイン コミュニティによって提案された概念「コベナンツ」の助けを借りて、CKB がは上記の構造上の特徴を持ち、最終的なエフェクトをいくつかの部分に適切に分割し、それらを 1 つずつ識別することによってもたらされるプログラマビリティの向上を実現します。
ビットコインの状態表現の基本形式として、ビットコインのUTXO（「未使用トランザクション出力」）には2つのフィールドがあります。
この種のスクリプトは制限されていますが、素晴らしいアプリケーションをプログラムする能力に欠けているわけではなく、CKB のプログラマビリティを探求するための基礎でもあります。後ほど特別セクションを設けて、ビットコイン スクリプト プログラミングの 2 つの例を紹介します。
対照的に、CKB の状態単位は「セル」と呼ばれ、次の 4 つのフィールドがあります。
Cell は、特定の計算のみをプログラムするのではなく、任意の計算をプログラムできます。
データ フィールドとタイプ スクリプト フィールドにより、より柔軟になります。 、セルは追加のステータスを記録できます。これにより、セルはいわゆる「UDT (ユーザー定義トークン)」を運ぶことができます。
ロック スクリプトが他の (入力および出力) ロック スクリプトを読み取る
ロック スクリプトが他の (入力および出力) タイプ スクリプト (およびデータ) を読み取る
最初の概念は、OP_IF、OP_ELSE などのビットコイン スクリプトのプロセス制御オペコードです。これらのオペコードは、コンピューター プログラミングにおける IF と何ら変わりません。その機能は、さまざまな入力に基づいてさまざまなステートメントを実行することです。ビットコイン スクリプトのコンテキストでは、これは、タイムロック機能と組み合わせて、資金の複数のロック解除パスを設定できることを意味し、アクションに優先順位を割り当てることができることを意味します。
有名な「ハッシュ タイム ロック コントラクト (HTLC)」を例に挙げます。このスクリプトは次のように現地語に翻訳されます。
または、ボブは特定のハッシュ値 H の背後にある元の画像を明らかにし、次に独自の署名を与えることができます。資金を使う
あるいは、アリスは一定期間 T 後に署名とともに資金を使うことができます。
この「どちらか...または...」効果は、プロセス制御オペコードを通じて実現されます。
HTLC の最も顕著な利点は、複数の操作をまとめてアトミック性を実現できることです。たとえば、アリスがボブと BTC を CKB に交換したい場合、ボブはまずハッシュ値を指定して、Nervos ネットワーク上に HTLC を作成します。次に、アリスは同じハッシュ値を使用してビットコイン上に HTLC を作成します。あるいは、ボブは、アリスがビットコインで支払った BTC を取得し、元の画像も公開して、アリスがネルボス ネットワークで CKB を取得できるようにします。あるいは、ボブが元の画像を公開しない場合、両方の契約が期限切れになり、アリスとボブの両方が投資した資金を取り戻すことができます。
Taproot ソフト フォークのアクティブ化後、複数のロック解除パスのこの機能は、MAST (マークル抽象構文ツリー) の導入によってさらに強化されました。ロック解除パスをマークル ツリー上のロック解除パスに変換できます。各リーフは独立しています。したがって、そのようなフロー制御オペコードを使用する必要はありません。また、1 つのパスを公開するときに他のパスを公開する必要がないため、経済的な問題を心配することなく、より多くのロックされていないパスを出力に追加できます。
2つ目のコンセプトは「コミットメントトランザクション」です。コミットされたトランザクションの考え方は、特定の状況下では、たとえブロックチェーンによって確認されなかったとしても、有効なビットコイントランザクションは依然として真実であり、拘束力があるということです。
たとえば、アリスとボブは共同で UTXO を所有しており、この UTXO には両方の署名を使用する必要があります。この時点で、アリスはそれを使用するためのトランザクションを作成し、値の 60% をボブに転送し、残りの値を自分に転送します。アリスはトランザクションに自分の署名を入力して、それをボブに送信します。そうすれば、ボブにとって、トランザクションをビットコインネットワークにブロードキャストしたり、トランザクションをブロックチェーンによって確認したりする必要はなくなり、トランザクションの支払い効果も現実的で信頼できるものになります。アリスはこの UTXO を自分で使うことができず (したがって、再度使うこともできません)、アリスが提供した署名は有効であるため、ボブはいつでも自分の署名を追加して、支払いを守るためにトランザクションをブロードキャストできます。言い換えれば、アリスはこの有効な (オンチェーンではない) トランザクションを通じてボブに「信頼できるコミットメント」を提供します。
コミットメントトランザクションは、ビットコインアプリケーションプログラミングの中核概念です。前に述べたように、ビットコインのコントラクトは検証に基づいており、ステートレスであり、クロスアクセスは許可されていません。しかし、コントラクトに状態が含まれていない場合、これらの状態はどこに保存され、コントラクトを安全に進める（状態を変更する）にはどうすればよいのでしょうか?コミットメントトランザクションは簡単な答えを与えます。契約の状態はトランザクションの形式で表現できるため、契約の参加者はブロックチェーン上に状態を表示することなく、自分自身で状態を保存できます。また、契約の状態の変更の問題も次のように変換できます。コミットされたトランザクションを安全に更新する方法の問題に加えて、契約を締結することの危険性を懸念する場合（たとえば、支出前に両当事者が署名する必要がある契約を締結すると、相手方が契約を締結しないというリスクに直面することになります。）応答して行き詰まってしまう) の場合、事前に契約を完了するコミットメント トランザクションを生成して署名するだけで、リスクが排除され、他の参加者への信頼も排除されます。
ライトニング チャネルは、ブロックチェーンによる支払いの確認なしに、二者が無制限に何度でも相互に支払うことができる 1 対 1 の契約です。ご想像のとおり、Promise トランザクションが使用されます。
「コミットメントトランザクション」を説明するセクションでは、支払いチャネルを紹介しました。ただし、この契約では 2-of-2 マルチ署名のみが使用されているため、片方向の支払いのみが可能です。つまり、アリスが常にボブに支払うか、ボブが契約の残高がなくなるまでアリスに支払うかのどちらかです。双方向支払いの場合、特定のステータス更新の後、一方の当事者の残高が以前よりも少なくなる可能性がありますが、相手方は最後にコミットされたトランザクションに署名済みであることを意味します。これを阻止する方法はありますか? TA が最新のコミットメント トランザクションのみをブロードキャストできるように、古いコミットメント トランザクションをブロードキャストしますか?
この問題に対するライトニングチャネルの解決策は「LN-ペナルティ」と呼ばれます。ここで、アリスとボブがそれぞれチャネルに 5 BTC を持っていると仮定します。アリスはボブに 1 BTC を支払いたいので、次のようなコミットメント トランザクションに署名し、ボブに送信します。
#0、10 BTC を入力します: Alie-Bob 2-of-2 マルチ署名出力 (つまり、チャネル コントラクト)
出力 #0、4 BTC: アリスの単一署名
出力 #1、6 BTC: アリスとボブの共同一時公開鍵 #1 の単一署名または T1 タイム ロック、ボブの単一署名
ボブはまた、コミットメント トランザクション (上記のトランザクションに対応する) に署名し、それをアリスに送信します:
入力 #0、10 BTC: Alie-Bob 2-of-2 マルチ署名出力 (つまり、チャネル コントラクト)
出力 #0、6 BTC: ボブの単一署名
出力 #1、4 BTC: または Bob -Alice共同一時公開鍵 #1 単一署名または T1 タイムロック、アリス単一署名
ここでのトリックは、自分の公開鍵と相手が提供した公開鍵を使用して生成されるこの「共同一時公開鍵」にあります。たとえば、アリスとボブの共同一時公開鍵は、アリス自身の公開鍵の 1 つとボブから提供された公開鍵を使用し、それぞれにハッシュ値を乗算して加算することによって取得されます。このような公開キーが生成されると、その秘密キーは誰も知りません。ただし、ボブが提供した公開鍵の秘密鍵をアリスに伝えると、アリスは共同一時公開鍵の秘密鍵を計算できます。 ——これが、Lightning Channel が古い状態をどのように「元に戻す」ことができるかという鍵です。
次回、双方がチャネルステータスを更新する（支払いを開始する）場合、両当事者は、前のラウンドで相手方に与えられた一時公開鍵の秘密鍵を交換します。このようにして、参加者は、受け取った最後のコミットメント トランザクションをあえてブロードキャストする必要がなくなりました。このコミットメント トランザクションの出力には、自分自身に値を割り当てるためのパスが 2 つあり、一時的な公開キー パスの秘密キーは相手にすでに知られています。古いコミットメント トランザクションがブロードキャストされると、相手方はこの共同一時秘密キーをすぐに使用して、この出力内のすべての資金を奪うことができます。 – これが「LN-ペナルティ」の意味です。
具体的には、対話の順序は次のとおりです。支払いを開始する当事者は、最初に相手方に新しい一時公開鍵を要求し、次に新しいコミットされたトランザクションを構築して相手方に渡します。一時的な公開鍵を受け取って自分自身を相手に送信します。この対話シーケンスにより、参加者は常に最初に新しいコミットメント トランザクションを取得し、その後、前のラウンドで取得したコミットメント トランザクションを無効にするため、トラストフリーになります。
要約すると、ライトニング チャネルの主な設計は次のとおりです。
両当事者は常にコミットメント トランザクションを使用して契約の内部ステータスを表現し、金額の変化を使用して支払いを表します
コミットメント トランザクションには常に同じ入力コストがかかります。両方の当事者が同時に行う必要があります (署名された入力を提供する)。そのため、すべてのコミットメント トランザクションは互いに競合し、最終的にブロックチェーンによって確認できるのは 1 つだけです
2 つの参加者の署名は同じコミットメント トランザクションではありません。それらはペアになっていますが) ; そして、署名するトランザクションは常に自分自身にとって有益です。つまり、参加者が受け取るコミットされたトランザクションは常に自分自身にとって有害です。この欠点は、それ自体に値を割り当てる出力に反映されます。パスのロック解除: 一方のパスは自分の署名でロックを解除できますが、もう一方のパスは相手の公開鍵を使用し、自分の一時秘密鍵の 1 つが公開されていない場合にのみ保護されます。各支払いでは、両当事者は、前のラウンドで相手方が使用した一時秘密鍵に対して新しいコミットメント トランザクションを交換します。そのため、一時秘密鍵を渡した当事者は、古いコミットメント トランザクションをブロードキャストすることを敢えてしません。 、最後にコミットされたトランザクションは「キャンセル」され、契約のステータスが更新されます（実際には、これらのコミットされたトランザクションはすべて有効なトランザクションであり、ブロックチェーンにブロードキャストできますが、参加者はそれらを罰することを強制されます。あえてもう一度ブロードキャストします）。
どちらの当事者も、相手方当事者が署名した約束された取引でいつでも契約を撤回できますが、双方が協力する意思がある場合は、双方が直ちにお金を取り戻すことができるように、新しい取引に署名することができます。
最後に、HTLC はコミットメント トランザクションに配置することもできるため、ライトニング チャネルで支払いを転送することもできます。アリスが前後に接続されたライトニング チャネルからなるパスを見つけてダニエルに到達できると仮定すると、ダニエルとのチャネルを開くことなくトラストフリーのマルチホップ支払いを実現できます。これはライトニング ネットワークです:
アリス -- HTLC --> キャロル -- HTLC --> アリス
アリスがそのようなパスを見つけてダニエルに支払いたいとき、彼女はダニエルにハッシュ値を要求し、それに基づいて HTLC を構築してボブに渡します。ボブはメッセージをキャロルに転送して同じ HTLC を提供するよう促し、メッセージはキャロルにメッセージをダニエルに転送して同じ HTLC を提供するように促します。このニュースがダニエルに届くと、彼は元の画像をキャロルに公開し、それによって HTLC の値を取得し、契約ステータスを更新します。キャロルも同様に、ボブの支払いを取得して、チャネルのステータスを更新します。最後に、ボブは元の画像を公開して、アリスへのステータス。 HTLC の特性により、この一連の支払いは同時に成功するか失敗するかのどちらかであるため、トラストレスです。
ライトニングネットワークは次々とチャンネルで構成されており、各チャンネル(契約)は互いに独立しています。つまり、アリスは自分のチャネルでボブと何が起こったかを知る必要があるだけで、他の人のチャネルで発生したインタラクションの数や、これらのインタラクションがどの通貨を使用したか、さらにはチャネルを使用しているかどうかを気にする必要がありません。 。
ライトニング ネットワークのスケーラビリティは、ライトニング チャネル内の支払い速度が両当事者のハードウェア リソース投資によってのみ制限されるという事実だけでなく、状態の分散ストレージにより単一ノードで最小のコストで最大のレバレッジを活用します。
プルデント ログ コントラクト (DLC) は、「アダプター署名」と呼ばれる暗号化技術を使用して、ビットコイン スクリプトで外部イベントに依存する金融契約をプログラムできるようにします。
アダプター署名を使用すると、秘密キーを追加した後でのみ署名を有効な署名にすることができます。 Schnorr 署名を例にとると、Schnorr 署名の標準形式は (R, s) です。ここで:
R = r.G # 署名で使用されるノンス値 r は、楕円曲線生成ポイントで乗算されます。 r の公開鍵であると言われます
s = r + Hash(R || m || P) * p # p は署名秘密鍵、P は公開鍵です
署名の検証とは s.G = r.G を検証することを意味します+ Hash(R || m || P) * p.G = R + Hash(R || m || P) * PK
データのペア (R, s') が与えられたとします。ここで:
R = R1 + R2 = r1.G + r2.G
s ' = r1 + Hash(R || m || P) * p
明らかに、これは有効な Schnorr 署名ではなく、署名検証式を通過できません。ただし、TA が R2 の秘密鍵 r2 を有効な署名にできることを知っている限り、検証者に証明できます:
s'.G + R2 = R1 + Hash(R || m || P) * P + R2 = R + Hash(R || m || P) * P
アダプター署名により、署名の有効性が秘密データに依存し、検証可能になります。しかし、これは金融契約とどのような関係があるのでしょうか?
アリスとボブがフットボールの試合の結果に賭けたいとします。アリスとボブは、それぞれグリーン ゴブリンとアリーナに 1 BTC を賭けます。さらに、サッカー解説ウェブサイト Carol は、サッカーの試合結果が発表されるときに、ノンス R_c を使用して結果の署名 s_c_i を公開することを約束します。
考えられる結果は 3 つあることがわかります (したがって、キャロルの署名には 3 つの可能性があります):
これを行うために、2 人は結果ごとにコミットメント トランザクションを作成します。たとえば、最初の結果に対して作成されたコミットメント トランザクションは次のようになります。
入力 #0、2 BTC: Alie-Bob 2-of-2 マルチシグネチャ出力 (つまり、ベット コントラクト)
出力 #0、2 BTC: アリスの単一署名
ただし、このトランザクションのためにアリスとボブによって作成された署名は (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 つのトランザクションについても同様です。このようにして、アリスとボブは、相手方を信頼することなく、この契約の実行を外部イベントに依存させます (正確には、アサーション マシンによる署名の形での外部イベントのブロードキャストに依存します)。先物やオプションなど、大小を問わず金融契約をこの方法で実装できます。
他の実装形態と比較して、慎重なログコントラクトの最大の特徴はそのプライバシーです: (1) アリスとボブはキャロルのデータを使用していることをキャロルに伝える必要がなく、これはコントラクトの実行に影響を与えません。すべて; (2) チェーン オブザーバー (キャロルを含む) は、アリスとボブの契約を通じてトランザクションを実行することによって、どの Web サイト サービスを使用しているかを判断できず、さらには、自分たちの契約が (ライトニング チャネルではなく) 賭けの契約であると判断することさえできません。
ビットコインコミュニティの開発者は、制限条項として分類できるさまざまな提案を提案しています。現在の観点から見ると、最も有名な提案は OP_CHECKTEMPLATEVERIFY (OP_CTV) です。その概念は比較的単純ですが、かなりの柔軟性を保持しているため、シンプルさを支持するビットコイン コミュニティに歓迎されています。 OP_CTV の考え方は、スクリプト内でハッシュ値をコミットして、そのハッシュ値で表されるトランザクションによってのみ資金を使用できるように制限することです。このハッシュ値はトランザクションとほとんどのフィールドの出力をコミットしますが、コミットはしません。トランザクションの入力は、入力数量のみをコミットします。
「輻輳制御」は、OP_CTV の特性を反映できる良い例です。その基本的なアプリケーション シナリオは、多数のユーザーが取引所 (信頼を必要とする環境) から資本プールに撤退するのを支援することです。この資本プールは OP_CTV を使用して将来の支出方法を計画するため、ユーザーがこの信頼から抜け出すことができるようになります。資金プールは誰の助けも必要としない無料の環境。また、この資金プールは UTXO としてのみ表示されるため、オンチェーン トランザクションの需要が高い場合 (出力数が n から 1 に減少)、多額の手数料を支払う必要がなくなります。 ; また、n 個のトランザクションから 1 個のトランザクションに減少します。プール内のユーザーは機会を待ってからプールから撤退できます。
アリス、ボブ、キャロルがそれぞれ取引所から 5 BTC、3 BTC、2 BTC を引き出したいとします。その後、取引所は 3 つの OP_CTV ブランチで 10 BTC の出力を行うことができます。アリスがお金を引き出したいと仮定すると、彼女はブランチ 1 を使用できます。このブランチの OP_CTV によって使用されるハッシュ値によって表されるトランザクションは 2 つの出力を形成し、1 つの出力はアリスに 5 BTC を割り当てます。また、OP_CTV を使用して、ボブが 3 BTC を引き出し、残りの 2 BTC をキャロルに送信することのみを許可するトランザクションをコミットします。
ボブまたはキャロルがお金を引き出したい場合も同じことが当てはまります。お金を引き出すときは、対応する OP_CTV チェックに合格できるトランザクションのみを使用できます。つまり、対応する金額のみを支払うことができ、残りの資金はロックされた資金プールに入力されます。 OP_CTV により、ユーザーが資金を引き出す順序に関係なく、残りのユーザーがトラストレスにプールから引き出すことができるようになります。
抽象的に言えば、ここでの OP_CTV の役割は、契約が終了するまでのパスを計画することです。これにより、ここでの資本プール契約は、どのパスを選択しても、どの状態であっても、トラストフリーエグジットの属性を維持できます。それは届きます。
この種の OP_CTV には、「隠された一方向支払いチャネル」という非常に興味深い使用法もあります。アリスがそのようなプールを形成し、次のようなスクリプトを使用して出力に資金をトラストレスレスに引き出すことができることを保証するとします:
アリスとボブが一緒に過ごすか、またはしばらくしてからアリスが一人で過ごすことができます
アリスがそうする場合ボブに公開しないと、ボブはそのような出力が存在することを知りません。アリスがそれをボブに公開すると、ボブはこの出力を時間制限のある一方向の支払いチャネルとして使用でき、アリスはその資金をボブに支払うことなくすぐに使用できます。ブロックチェーン上の確認を待たなければなりません。ボブは、アリスが自分でトランザクションを費やす前に、コミットされたトランザクションをチェーン上で取得できるようにするだけで済みます。
OP_VAULT は、「Vault」を構築するために特別に提案された制限条項の提案です。
Vault 契約は、より安全でより高度な自己保管形式となるように設計されています。現在のマルチシグネチャ契約では単一の秘密鍵の単一障害点を回避できますが、攻撃者がしきい値数の秘密鍵を取得した場合、ウォレットの所有者は何もできなくなります。 Vault は、資金に単一の使用制限を課すことを望んでいます。同時に、通常のルートを使用して引き出し操作を行う場合、待機期間が強制され、緊急ウォレットによって引き出し操作が中断される可能性があります。回復作戦。たとえそのような契約が侵害されたとしても、ウォレットの所有者は（緊急回復ブランチを使用して）対策を開始することができます。
理論的には、OP_CTV はそのような契約をプログラムすることもできますが、多くの不都合があります。その 1 つは手数料です。トランザクションをコミットする一方で、トランザクションに対して支払われる手数料もコミットします。このような契約の目的を考えると、契約を締結してからお金を引き出すまでに非常に長い時間がかかるため、適切な料金を予測することはほとんど不可能です。 OP_CTV はインプットを制限していないため、インプットを増やすことで手数料を増やすことはできますが、提供されたインプットはすべて手数料となるため、もう 1 つの方法は CPFP、つまり引き出した資金を手数料に充てるという方法です。新しいトランザクションで提供されます。さらに、OP_CTV の使用は、そのような安全な契約をバッチで撤回できない (もちろん、バッチで復元できない) ことも意味します。
OP_VAULT 提案は、新しいオペコード (OP_VAULT および OP_UNVAULT) を提案することでこれらの問題を解決しようとします。 OP_UNVAULT はバッチリカバリ用に設計されているため、今は説明しません。 OP_VAULT のアクションは次のようなものです。これをスクリプト ツリーのブランチに配置すると、このブランチを使用するときに、特定のパラメーターなしで実行可能なオペコード (OP_CTV など) を約束するために使用できます。ただし、他のブランチは変更できません。したがって、手数料を設定する必要はなく、このブランチを使用するときに手数料を設定できます。このブランチにもタイム ロックがあると仮定すると、場所を変更することしかできないため、最終的にタイム ロックが適用されます。新しいスクリプト ツリー上のブランチや他のブランチ (緊急復旧ブランチを含む) は変更されないため、そのような撤回操作を中断することができます。
さらに、言及する価値のある点が 2 つあります: (1) OP_VAULT オペコードの動作は、別の制限提案 OP_TLUV に似ています。Jeremy Rubin は、これがすでにある種の「計算」の概念を生み出していると正しく指摘しました。エクステント: OP_TLUV /OP_VAULT はまず、ユーザーが新しいトランザクションを通じてオペコードにパラメーターを渡すことをオペコードに約束し、それによってスクリプト ツリーのリーフ全体を更新します。これは「特定の条件に基づいて受信データを検証する」ことではなくなります。受信データに基づいて意味のある新しいデータを生成します。ただし、実行できる計算は比較的限られています。
完全な OP_VAULT プロポーザルでは、より良い結果を達成するために、mempool ポリシーに関するいくつかのプロポーザル (v3 形式のトランザクションなど) も利用されます。これは、「プログラミング」が私たちが思っているよりもはるかに多くの意味を持ち得ることを思い出させます。 (同様の例は、Nervos Network のオープン トランザクションです。)
上の 2 つの章では、より制限された構造 (ビットコイン UTXO) で CKB を使用する方法を紹介しました。この構造にイントロスペクション機能を追加しようとする試みも導入されています。
UTXO これらのアプリケーションをプログラムする能力が不足しているわけではありませんが、読者は次のような欠点や最適化できる領域を簡単に検出できます。
実際、ビットコイン コミュニティは、基本的に Sighash 提案 (BIP-118 AnyPrevOut) に関連するこれらの質問に対する答えを見つけ出しました。
ただし、CKB でプログラミングしている場合は、BIP-118 が現在利用可能です (この Sighash タグは、署名をイントロスペクトして具体的に検証する機能を使用してシミュレートできます)。
ビットコインプログラミングを学ぶことで、「トランザクション出力」形式をプログラムする方法（CKBで何をプログラムできるか）だけでなく、これらのアプリケーションを改善する方法（これらのアプリケーションをCKBでプログラムすると何ができるか）もわかります。CKBの機能を使用して、それらを改善してください）。 CKB 開発者にとって、ビットコイン スクリプトに基づくプログラミングは学習の教科書、または近道とさえ考えることができます。
以下では、CKB プログラミングの各モジュールのプログラマビリティを 1 つずつ分析します。今は内省的な能力については考えないことにしましょう。
前述したように、UTXOは任意の計算をプログラムすることができません。 Lock Script は可能です。つまり、Lock Script は、上記のライトニング チャネルと DLC を含む (ただしこれらに限定されない)、UTXO プログラミングに基づいてすべてを (制限が適用される前に) プログラムできることを意味します。
さらに、あらゆる計算を検証するこの機能により、Lock Script はより多くの認証方法を使用できるようになり、UTXO よりも柔軟性が高くなります。たとえば、一方が ECDSA 署名を使用し、もう一方が RSA 署名を使用する Lightning チャネルを CKB に実装できます。
実際、これは人々が CKB で検討し始めた最も初期の領域の 1 つです。ユーザーの自律的な管理下でこの柔軟な ID 検証機能を使用して、いわゆる「アカウントの抽象化」、つまりトランザクションの有効性を実現します。認可と制御の復元は両方とも可能です。柔軟で事実上無制限です。原則として、これは「複数の支出ブランチ」と「任意の認証方法」の組み合わせです。実装例には、JoyID Wallet、UniPass などがあります。
さらに、Lock Script は eltoo 提案を実装することもでき、それにより、最新のコミットされたトランザクションを保持するだけで済むライトニング チャネルを実現できます (実際、eltoo はすべてのポイントツーポイント コントラクトを簡素化できます)。
上で述べたように、Type Script の主な用途の 1 つは、UDT をプログラムすることです。 Lock Script と組み合わせると、UDT ベースの Lightning チャネル (および他のタイプのコントラクト) を実装できることになります。
実際、Lock Script と Type Script の分離はセキュリティのアップグレードとみなすことができます。Lock Script は管理メソッドまたは契約プロトコルの実装に重点を置き、Type Script は UDT の定義に重点を置きます。
さらに、UDT 定義に基づいてチェックを開始できるため、UDT は CKB と同様の方法で契約に参加できます (UDT は第一級市民です)。
例: 著者はかつて、ビットコインでトラストレスNFT担保融資を実装するプロトコルを提案しました。このプロトコルの鍵は、入力の値が出力の値より小さいコミットメント トランザクションです (したがって、まだ有効なトランザクションではありません)。ただし、このトランザクションに十分な入力が提供されると、それは A になります。有効な取引: 貸し手が返済できるようになると、貸し手は質入れされた NFT を自分のものとして保持することはできません。ただし、このコミットメントトランザクションのトラストレスな性質は、インプットとアウトプットの金額をチェックするトランザクションに基づいているため、貸し手と貸し手の両方が別の通貨（たとえば、プロトコルによって発行されたRGB USDT）、ビットコインのコミットメントトランザクションは、貸し手が十分な量のUSDTを返す限り、NFTを取り戻すことができることを保証できません。ビットコイントランザクションはUSDTのステータスをまったく知らないためです。 ！ (修正: つまり、USDT の返済を条件とするコミットメント取引を構築することは不可能です。)
UDT の定義に基づいて小切手を開始できれば、貸し手は別のコミットメント取引に署名することが可能になります。 、貸し手がUSDTを使用して支払いを返済できるようになります。トランザクションでは、USDT の入力量と USDT の出力量をチェックし、ユーザーは USDT を使用して信頼性のない返済を行うことができます。
修正: 担保として使用されるNFTと返済に使用されるトークンが同じプロトコル(RGBなど)を使用して発行されると仮定すると、ここでの問題はRGBプロトコルに基づいてコミットメントトランザクションを構築できるため、状態遷移とNFTの返済は同時に発生する可能性があります（2つの状態遷移はRGBプロトコル内のトランザクションにバインドされています）。ただし、RGB トランザクションはビットコイン トランザクションにも依存しているため、ここでのコミットメント トランザクションの構築は多少困難になります。全体として、問題は解決できますが、トークンは第一級市民です。
次に、内省の能力について考えてみましょう。
ロック スクリプトは他のロック スクリプトを読み取ります
これは、提案された制限が実装された後、ビットコイン UTXO での完全なプログラミングの可能性を意味します。前述の安全なコントラクトと、OP_CTV に基づくアプリケーション (輻輳制御など) が含まれます。
XueJie はかつて非常に興味深い例を述べました: CKB にコレクション アカウントの Cell を実装することができます。この Cell をトランザクションの入力として使用する場合、出力される Cell (同じロック スクリプトを使用する Cell) の容量が大きい場合、次のようになります。入力では署名を提供する必要はなく、トランザクションの有効性に影響しません。実際、そのような細胞は内省する能力がなければ不可能です。この種の回収口座 Cell は資金をプールできるため、機関向けの回収方法として非常に適しています。欠点はプライバシーが低いことです。
この機能の興味深い応用例は株式トークンです。ロック スクリプトは、他の入力のトークンの数に基づいて独自のキャパシティを使用できるかどうか、およびキャパシティをどこで使用できるかを決定します (ロック スクリプトをイントロスペクトする機能が必要です)。
確かではありませんが、役に立つと考えられます。たとえば、タイプ スクリプトでトランザクションの入出力をチェックできるロック スクリプトは変更されません。
トレーディング カード? n 個のトークンを集めると、より大きなトークンと交換できます: )
以前のプログラム可能な任意のコンピューティング スマート コントラクト システム (イーサリアムなど) と比較して、Nervos ネットワークは異なる構造を採用しています。多くの場合、神経ネットワークを理解するための基礎を形成するのは困難です。この記事では、CKB Cell - BTC UTXO よりも制限された構造のアプリケーション プログラミングから始めて、CKB Cell のプログラマビリティを理解する方法を提案します。さらに、「イントロスペクション」の概念を使用して Cell の「クロスコントラクト アクセス」機能を理解することで、イントロスペクション機能が使用される状況を分類し、その具体的な用途を決定できます。
改訂:
1. Cell のクロスアクセス機能 (つまり、イントロスペクション機能) に関係なく、ロック スクリプトはステートおよびエクストリーム プログラミング機能を備えたビットコイン スクリプトとみなすことができます。したがって、すべてのビットコイン ベースのプログラムはこれに基づいてプログラムできます。スクリプトの単独の適用;
2. Cell のクロスアクセス機能 (つまり、イントロスペクション機能) に関係なく、ロック スクリプトとタイプ スクリプトの区別は、UDT のアセット定義と保存方法を分離するものであると考えられます。さらに、状態を公開できる型スクリプト (およびデータ) は、UDT が第一級市民であるという効果を実装します。
以上がビットコインアプリケーションプログラミングを起点にCKBのプログラマビリティを1万語で詳しく解説の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
