从比特币应用编程出发，万字详解CKB的可编程性

以下の内容はNervos Talkフォーラムから転載されたもので、著者はAjian（ビットコインコンテンツプラットフォームBTC Studyの編集者）です。

概要

理解一个系统的可编程性要求我们辨识这个系统在结构上的特征。对基于比特币脚本的应用编程的探索，有助于我们理解 CKB Cell 的基本结构及其编程范式。不仅如此，它还能将 CKB 的编程元件分解为恰当的部分，并帮助我们理解每一部分所带来的可编程性增益。

一. イントロダクション

“プログラマビリティ（programmability）”は、ブロックチェーンシステムを比較する際に人々がしばしば採用する次元の一つです。しかし、プログラマビリティについての記述方法にはしばしば意見の相違があります。一般的な表現方法の1つは、「XXブロックチェーンはチューリング完全なプログラミング言語をサポートしています」というものであり、または「XXブロックチェーンは汎用プログラミングをサポートしています」というものであり、これらの文言はここでの「XXブロックチェーン」が非常に優れたプログラマビリティを持っていることを意味しています。これらの文言には一定の意味があります：チューリング完全なプログラミングをサポートするシステムは通常、そうでないシステムよりもプログラミングしやすい傾向にあります。ただし、スマートコントラクトシステムの構造的特徴は複数あり、この文言はそのうちの1つに過ぎず、それだけでは十分な理解を得ることはできません：開発者はこれから指針を得られず、一般ユーザーもこれによって詐欺を見分けることはできません。

スマートコントラクトシステムの構造上の特徴には、01928374656574839201が含まれます。

ステータス表現（契約）の基本形式（アカウント vs. トランザクション出力）
計算機能のプログラミングを許可するかどうか（「チューリング完全」という言葉はこの点に関連しています）
実行プロセスは新しいデータを作成するか、単にブール値を返しますか？（計算 vs. 検証）
合約内での追加状態の記録を許可しますか？
01928374656574839201019283746565748392010192837465657483920101928374656574839201019283746565748392010192837465657483920101928374656574839201

所以，在 “可否编程任意计算” 之外，至少还有四个方面的特征会影响一个スマートコントラクトシステムのプログラム可能性。甚至可以说，这些其它方面的特征は更为重要的、因为它们更深层地决定了什么容易实现、什么难以实现；什么是较为经济的实现、而什么是较为低效的实现。

例を挙げると、人々はしばしばイーサリアムをプログラム可能性が高い例として引き合いに出しますが、イーサリアムの基本形式はアカウントであり、P2Pの契約（例えば、支払いチャネル、一対一の賭け契約）をプログラムするのは難しいです。それが全く不可能ではないというわけではありませんが、困難を伴います。イーサリアムエコシステムでは、支払いチャネル/ステートチャネルのプロジェクトは過去に存在しましたし、理論的な探求もたくさんありましたが、今日ではこれらのプロジェクトは活発ではなくなってしまいました。これは開発者の努力不足に帰するものでは明らかにありません。現在、イーサリアムで活発なプロジェクトは、"ファンドプール"形式を採用しており、"P2P契約"形式ではないのは偶然ではありません。同様に、現在の人々はおそらくイーサリアムのプログラム可能性に満足していますが、"アカウントの抽象化"（ウォレットの概念の一般化とも言えます）を実現する場合、アカウントモデルは先天的に不足していると言えます。

同様に、CKBのプログラム可能性を探求する際には、CKBスマートコントラクトシステムのこれらの構造的特徴を理解する必要があります。私たちがすでに知っているように、CKBは任意の計算をプログラムでき、契約内で追加の状態を記録することができ、また、契約が実行される際に別の契約の状態にアクセスすることもできます。しかし、その契約の形式はトランザクションの出力（「セル」と呼ばれる）であり、これにより、CKBとEthereumとの間に根本的な違いが生じます。したがって、Ethereumのスマートコントラクトシステムやその中の契約インスタンスの理解は、CKBがこれらの構造的特性をどのように実現しているかを理解するのに役立たず、CKBのプログラム可能性を認識するのにも役立ちません。

幸運なことに、ビットコイン上のスマートコントラクトは、私たちがCKBのプログラム可能性を理解するための最良の基礎を提供しているようです。これは、ビットコインの状態表現の基本的な形式がトランザクションの出力（UTXOと呼ばれる）であるだけでなく、ビットコインコミュニティが提案した「契約（covenants）」という概念を利用することで、CKBが上記の構造特性を持つ理由を理解し、最終的な効果を適切に分割し、それぞれのプログラム可能性の利益を識別することができます。

二. CKB v.s. BTC：何が追加されましたか？

基本構造

作为比特币状态表达的基本形式，比特币的 UTXO（"未使用トランザクション出力"）有两个字段：

数额，以聪（Satoshi）为单位，表示该 UTXO 具备的比特币价值；
数量はサトシ（Satoshi）単位で、UTXOが持つBTCの価値を表します；
スクリプト公開鍵、またはロックスクリプトとも呼ばれ、この資金を使うために必要な条件、つまりこの資金をアンロックするための条件を設定するスマートコントラクトプログラムを示します。

後続のスマートコントラクトシステムと比較して、ビットコインスクリプトはかなり制限されています。

プログラムの任意の計算を許可しません。検証に使用できる実用的な計算はわずかです（署名チェック、ハッシュ原像チェック、時間チェック）。
契約内での追加の状態の記録は許可されていません。（例えば、スクリプトを使用して一回の支出の比率/上限を制限することや、トークンを隠すことはできません）
実行中に別の契約の状態にアクセスすることは許可されていません（各スクリプトは独立した宇宙であり、相互に依存しません）。

このスクリプトは限定されていますが、驚くべきアプリケーションを作成する能力に欠けていません。それはまた、CKBのプログラム可能性を探求するための基盤でもあります。後のセクションでは、ビットコインのスクリプトプログラミングの2つの例を紹介します。

与之相对的，CKB 的状态单元称为 “Cell”，有四个字段：

Capacity，类似于 UTXO 的数额，表达的是该 Cell 可以占据的空间大小，以字节（Bytes）为单位；
Lock ，UTXO のスクリプト公開鍵に似ていますが、この Cell の所有権を定義します。Lock を通過するデータのみがこの Cell を「更新」できます（またはこの Cell を解放し、この Capacity を使用して新しい Cell をミントすることもできます）。
Data, データ, 01928374656574839201, 其体积受 Capacity 的限制；
Type, 可选のスクリプト、Data の更新に条件を設定するために使用されます。

此外，Lock 和 Type 还可以编程任意计算。你可以编程出任意的签名验证アルゴリズム，也可以编程出任意一种哈希アルゴリズム的原像检查，等等等等。

読者は簡単に見ることができます、Cell は UTXO に比べてプログラム可能性が向上しています：

Cellは、特定の計算だけでなく、任意の計算をプログラムできます。所有権の検証もより柔軟になります。
DataおよびTypeフィールドのため、Cellは追加の状態を記録することができます。これにより、Cellは「ユーザー定義トークン（UDT）」と呼ばれるものを保持することができます。

結合Cell自身の「トランザクションの出力」の構造と、これらの2つのポイントによってもたらされる利点は非常に大きいですが、上記の説明だけでは、Cellが「実行時に別の契約の状態にアクセスする方法」をどのように実現しているかはわかりません。そのため、私たちは長い間ビットコインコミュニティで議論されている「制約条項（covenants）」という概念を借りる必要があります。

制約条項と内省

限制条款の本意は、一定の場所にお金を使うことを制限することです。現在のBitcoin（まだ制限条項の提案が行われていません）では、資金がロック解除されると、任意の場所（任意のスクリプト公開鍵に支払うことができる場所）に使うことができます。しかし、制限条項のアイデアは、ある方法でその資金が特定の場所にのみ使用されるように制限することができるというものです。例えば、あるUTXOはあるトランザクションのみで使用されることができるように制限されている場合、誰かがそのUTXOに署名を提供できたとしても、そのUTXOが使用される場所はそのトランザクションによって決定されます。この機能は少し奇妙に思えるかもしれませんが、興味深い応用が可能です。後のセクションで詳しく説明します。重要なのは、これがCKBのプログラム可能性をより深く理解するための鍵であるということです。

Rusty Russellさんは正しく指摘していますが、制限条項はトランザクションの「内省」能力と理解できます。つまり、UTXO AがトランザクションBで使用される場合、スクリプトプログラムはトランザクションBの一部（または全部）を読み取り、それらが事前にスクリプトに求められるパラメータと一致するかどうかを確認することができます。例えば、トランザクションAの最初の出力のスクリプト公開鍵は、UTXO Aのスクリプト公開鍵と一致しているかどうか（これが制限条項の最初の意味です）を確認します。

敏感な読者は、完全な内省能力を持っていれば、1つのトランザクションの入力から同じトランザクションの別の入力の状態を読み取ることができることに気付くでしょう。これにより、「実行時に別の契約の状態にアクセスする能力」が実現されます。実際、CKBセルはこのように設計されています。

基于此，我们又可以将这种完全的内省能力分成四种情形：

读取其它（输入和输出）的 Lock は、01928374656574839201 に保持されます。
Lock 01928374656574839201其它（输入和输出）的 Type （以及 Data）
读取其它（输入和输出）的 Lock 01928374656574839201
读取其它（输入和输出）的 Type （以及 Data）を入力してください。

これにより、特定の仮定（LockとTypeの機能の役割分担）のもとで、各部分の内省能力が異なるアプリケーションシナリオで果たす役割を分析し、各部分がもたらすプログラム可能性の増加を分析することができます。

以下の2つのセクションでは、（まだ制約条項が提案されていない）Bitcoinのスクリプトプログラミングについて学び、制約条項の提案が実現することで、CKBセルのプログラミングを具体的に理解し、さらに改善する方法を理解します。

三. ビットコインスクリプトプログラミング

本节将使用 “ライトニングネットワーク” 和 “谨慎日志合约（DLC）” 作为基于比特币脚本的应用编程的案例。在展开之前，我们要先了解两个概念。

OP_IF および "コミットメントトランザクション"

第1の概念は、ビットコインスクリプト内のフロー制御オペコード、例えば：OP_IF、OP_ELSEです。これらのオペコードは、コンピュータプログラミングのIFとほとんど変わりません。それらの機能は、異なる入力に基づいて異なるステートメントを実行することです。ビットコインスクリプトの文脈では、これは資金の複数のアンロックパスを設定できることを意味します。タイムロック機能と組み合わせると、行動の優先権を割り当てることができます。

以著名的 “ハッシュドタイムロックコントラクト（HTLC）” 为例，这种脚本翻译成大白话就是：

要么，Bob 可以揭晓某个哈希值 H 背后的原像，再给出自己的签名，即可花费这笔资金；

要么，Alice 可以在一段时间 T 过后，凭借自己的签名花费这笔资金。 -> それとも、Alice は一定期間 T 経過後に自分の署名でその資金を使うことができます。

この「要么……要么……」の効果は、プロセス制御オペコードによって実現されています。

HTLCの最も注目すべき利点は、複数の操作を一緒に束ねてアトミックに実行できることです。例えば、アリスはBTCとCKBを交換するためにボブと取引をしたいとします。その場合、ボブは最初にハッシュ値を提供し、Nervos Network上でHTLCを作成します。その後、アリスは同じハッシュ値を使用してビットコイン上でHTLCを作成します。それとも、ボブがアリスが支払ったBTCを受け取り、同時に元のイメージを明らかにしてアリスがCKBをNervos Network上で引き出すことを許可します。それとも、ボブが元のイメージを明らかにしない場合、両方の契約が期限切れになり、アリスとボブはそれぞれ自分の投資額を取り戻すことができます。

Taproot 軟フォークがアクティブになった後、この多重ロック解除パスの特性は、MAST（Merkle Abstract Syntax Trees）の導入によりさらに強化されました。解除パスをMerkleツリーの葉に変換することができるため、各葉は独立しており、このようなフロー制御オペコードを使用する必要がなくなりました。また、1つのパスを公開する際に他のパスを公開する必要がないため、経済性の問題を心配することなく、出力にさらに多くの解除パスを追加することができます。

第二の概念は「コミットメント取引」です。コミットメント取引のアイデアは、いくつかの場合において、有効なBTC取引はブロックチェーンの確認を受けなくても実際には拘束力があるというものです。

例えば、AliceとBobは共同で1つのUTXOを所有しており、そのUTXOを使用するには彼ら二人の署名が必要です。その時、AliceはそのUTXOを使用する取引を作成し、そのうち60%の価値をBobに移し、残りの価値を自分に移します。Aliceはその取引に自分の署名を提供し、そしてBobに送信します。したがって、Bobにとっては、この取引をビットコインネットワークにブロードキャストする必要もなく、この取引がブロックチェーンで確認される必要もありません。この取引の支払い効果は実際であり、信頼できます。なぜなら、AliceはこのUTXOを単独で使用することができず（したがって二重支払いすることができず）、またAliceが提供した署名が有効であるため、Bobはいつでも自分の署名を追加し、そしてその取引をブロードキャストして支払いを実行することができます。つまり、Aliceはこの有効な（チェーン上でない）取引によって、Bobに「信頼できる約束」を提供しています。

承诺取引は、Bitcoinのプログラミングの中核となる概念です。前述のように、Bitcoinの契約は検証され、ステートレスでクロスアクセスを許可しないものですが、契約に状態がない場合、その状態はどこに保存され、契約の安全な推進（状態の変更）はどのように行われるのでしょうか？承諾取引は明確な答えを提供します：契約の状態は取引の形式で表現することができ、したがって、契約の参加者は状態を自分自身で保存することができ、ブロックチェーンに公開する必要はありません。また、契約の状態の変更は、承諾取引の安全な更新方法に転換することもできます。さらに、契約に参加することが危険だと心配している場合（例えば、相手が応答しないためにスタックする可能性がある、両当事者の署名が必要な契約に参加する場合など）、契約を使用して事前に取引を生成し、署名を取得するだけで、リスクを回避し、他の参加者に対する信頼を排除することができます。

ライトニングチャネルとライトニングネットワーク

闪电通道は1対1の契約であり、この契約では、両当事者は相互に無制限に支払いを行うことができますが、いかなる支払いもブロックチェーンの確認を必要としません。おそらく予想されているように、これにはコミットメントトランザクションが使用されています。

「承诺トランザクション」の部分を説明している中で、私たちは支払いチャネルというものを紹介しました。ただし、2-of-2 マルチシグネチャの契約を使用するこの方法は、単方向の支払いのみを実現することができます。つまり、常にアリスからボブへの支払いか、ボブからアリスへの支払いかのどちらかであり、契約内の残高が尽きるまで続きます。もしも双方向の支払いを行う場合、ある状態の更新後、一方の残高が以前よりも少なくなってしまうかもしれませんが、その時点で相手方の署名を受けた以前の承約トランザクションを所有している場合、古い承約トランザクションをブロードキャストすることを防止し、最新の承約トランザクションのみをブロードキャストする方法はありますか？」

闪电通道解决这个问题的办法叫做 "LN-Penalty"。现在，假设 Alice 和 Bob 在一条通道中各拥有 5 BTC；现在 Alice 要给 Bob 支付 1 BTC ，于是签名这样一笔承诺交易，并发送给 Bob：

入力＃0、10 BTC：Alie-Bob 2-of-2マルチシグ出力（つまりチャネル契約）

出力 #0、4 BTC： Alice 単一署名

出力 #1、6 BTC：Alice-Bob の一時的な公開鍵 #1 の単一署名またはT1時間ロック、Bob の単一署名のいずれかが必要です。

Bob も署名して（前述のトランザクションに対応する）コミットメントトランザクションを Alice に送信します：

入力#0、10 BTC：Alie-Bob 2-of-2 マルチサイン出力（つまり、チャネル契約）

出力 #0、6 BTC：Bob シングルサイン

出力＃1、4 BTC：Bob-Aliceが一時的な公開鍵＃1で単独で署名するか、T1タイムロックでAliceが単独で署名します。

ここでのヒントは、この「共同一時公開鍵」にあります。これは、自分の公開鍵と相手から提供された公開鍵を使用して生成されるもので、例えば、Alice-Bobの共同一時公開鍵は、Aliceが自分の公開鍵とBobが提供した公開鍵をそれぞれハッシュ値に乗じて加算したものです。このような公開鍵は生成される際には誰もその秘密鍵を知りません。しかし、もしBobが提供した公開鍵の秘密鍵をAliceに教えてしまったら、Aliceはこの共同一時公開鍵の秘密鍵を計算できます。これが、旧状態を「取り消す」ための重要な点です。

在次の支払いを開始する際、両者は前回相手に渡した一時的な公開鍵の秘密鍵を交換します。これにより、参加者は自分が前回の約束取引をブロードキャストすることができなくなります：この約束取引は、自分の値の出力に2つのパスがあり、一方のパスの一時的な公開鍵の秘密鍵は相手に知られています。したがって、古い約束取引をブロードキャストすると、相手はすぐにこの共同一時的な秘密鍵を使用して、この出力の資金をすべて取得できます。これが「LNペナルティ」の意味です。

具体的には、相互作用の順序は次のとおりです：支払いを行う側はまず相手に新しい一時的な公開鍵を要求し、その後新しいコミットトランザクションを構築して相手に渡します。コミットトランザクションを受け取った側は前回の一時的な公開鍵での秘密鍵を相手に開示します。このような相互作用の順序により、参加者は常に新しいコミットトランザクションを最初に受け取り、前のラウンドで受け取ったコミットトランザクションを無効にするため、信頼が不要です。

综上所述，闪电通道的关键设计有：

双方は常に約束された取引を使用して契約内の状態を表し、支払いを金額の変化で示します。

承诺交易总是花费同一个输入（需要双方同时提供签名的输入），因此所有承诺交易都是相互竞争的，最终只有一笔能够得到区块链的确认；

参加者の署名は、同じ約束取引ではなく（ペアであるとはいえ）、常に自分自身に有利な取引に署名しています。つまり、参加者が受け取る約束取引は常に自己にとって不利です。

この不利な点は、自分の値を割り当てるための出力に2つのアンロック経路があることに現れています: 1つの経路は自分の署名でアンロックできますが、時間が経過する必要があります。もう1つの経路は相手の公開鍵を使用し、自分の一時的な秘密鍵が公開されない場合にのみ保護されます。

新しい一時的な秘密鍵を交換するために、支払いごとに両者は前回使用された一時的な秘密鍵を新しい約束取引で交換します。したがって、一時的な秘密鍵を渡した側は古い約束取引をブロードキャストしなくなり、前回の約束取引が「取り消され」、契約の状態が更新されます。（実際には、これらの約束取引は有効な取引であり、ブロックチェーンにブロードキャストすることができますが、参加者は罰を受けるために再度ブロードキャストすることができません）

任意の当事者はいつでも、相手の署名済みの約束取引を使用して契約から脱退することができます。ただし、両当事者が協力する意志がある場合、彼らは新しい取引に署名することができ、それによって両者ともに自分のお金を即座に取り戻すことができます。

最後に、プロミス取引にもHTLCを埋め込むことができるため、ライトニングチャネルも支払いを転送することができます。Aliceがライトニングチャネルを前後に接続した経路を見つけてDanielに到達できると仮定すると、Danielとのチャネルを開設する必要なく、信頼なしにマルチホップ支払いを実現できます。これがライトニングネットワークです。

Alice -- HTLC --\u003e Bob -- HTLC --\u003e Carol -- HTLC --\u003e Daniel

Alice < -- 原像 -- Bob < -- 原像 -- Carol < -- 原像 -- Daniel

当アリスはこのような経路を見つけ、ダニエルに支払いを求める場合、彼女はダニエルにハッシュ値を要求し、それを使用してボブにHTLCを作成し、ボブにキャロルにメッセージを転送し、同じHTLCを提供するように促します。メッセージには、キャロルがダニエルにメッセージを転送し、同じHTLCを提供するように指示されます。メッセージがダニエルに届くと、彼はキャロルに元の画像を明らかにして、HTLCの価値を取得し、契約の状態を更新します。キャロルも同様に行動し、ボブからの支払いを受け取り、チャネルの状態を更新します。最後に、ボブはアリスに元の画像を明らかにし、状態を更新します。HTLCの特性により、この一連の支払いは成功するか、失敗するかのいずれかであり、信頼関係は必要ありません。

闪电网络は、一つのチャネルが別のチャネルと組み合わされて構成されており、各チャネル（契約）は独立しています。これは、アリスがボブとのチャネル内で何が起こっているかだけを知っていればよいことを意味します。他の人々のチャネルで何回の相互作用が行われたか、どの通貨が使用されたか、さらにはそれらの相互作用が本当にチャネルを利用しているかどうかを気にする必要はありません）。

闪电ネットワークの拡張性は、単一のチャネル内の支払い速度が両当事者のハードウェアリソースにのみ依存するだけでなく、状態の分散ストレージにより、個々のノードは最小のコストで最大のレバレッジを発揮することができます。

慎重なログ契約

谨慎日志合约（DLC）使用了一种叫做 “适配器签名（adaptor signature）” 的密码学技巧，使得比特币脚本可以编程出依赖于外部事件的金融合约。

适配器署名は、署名が有効になるには、秘密鍵が追加された後にのみ署名が有効になるようにすることができます。Schnorr署名を例に取ると、Schnorr署名の標準形式は（R、s）であり、その中に：

R = r.G # サインに使用されるnonce値rを楕円曲線生成点Gと乗算したもの、つまり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署名ではなく、検証式を通過することができませんが、私はバリデータに対して証明することができます。R2の秘密鍵r2を知っているだけで、それを有効な署名にすることができます。

s'.G + R2 = R1 + Hash(R || m || P) * P + R2 = R + Hash(R || m || P) * P

适配器签名让一个签名的有效性依赖于一个秘密数据，并且是可验证的。但是，这跟金融合约有什么关系呢？

偽の Alice と Bob がサッカーの結果に賭けたいとします。Alice と Bob はそれぞれグリーンズとアリナを勝者として賭け、賭け金は 1 BTC です。そして、スポーツサイトの Carol は、試合結果が発表された時に、結果に対する署名 s_c_i を nonce R_c と共に公開することを約束しています。

結果は3つの可能性があることがわかります（したがって、Carolの署名には3つの可能性があります）。

緑の魔術師が勝利し、Aliceは1 BTCを獲得しました。
アリーナが勝ちました、Bob は1 BTCを獲得しました
引き分け、2人の資金が元のルートに戻ります。

为此，两人为每一种结果创建一笔承诺交易。例如，他们为第一种结果创建的承诺交易是这样的：

入力 #0、2 BTC： Alie-Bob 2-of-2 マルチサイン出力（つまり、賭け契約）

出力 #0、2 BTC： Alice 個別署名

しかし、AliceとBobが作成したトランザクションの署名は(R, s)ではなく、アダプタ署名(R, s')です。つまり、お互いに渡す署名は直接このコントラクトをアンロックするために使用することはできず、秘密の値を公開する必要があります。この秘密の値はs_c_1.Gの原像であり、つまりCarolの署名です！Carolの署名のnonce値は既に確定しています（R_cです）、そのため、s_c_1.Gは構築することができます（s_c_1.G = R_c + Hash(R_c || '绿魔胜出' || PK_c) * PK_c）。

当結果が発表されると、グリーンウィザードが勝利したと仮定すると、Carolは署名(R_c, s_c_1)を公開します。その場合、AliceでもBobでも、相手のアダプタ署名を補完し、自分の署名を加えて上記取引を有効な取引にし、ネットワークにブロードキャストして決済効果を引き起こすことができます。しかし、グリーンウィザードが勝利しなかった場合、Carolはs_c_1を公開しないため、この約束取引は有効な取引になることはありません。

以此类推，另外两笔交易也是如此。就这样，Alice 和 Bob 让这个合约的执行依赖于外部事件（准确来说是依赖于断言机对外部事件的播报，其形式是个签名），而且不需要信任对手方。大大小小的金融合约，比如期货、オプション，都可以用这种方式来实现。

他の形式の実装と比較して、慎重なログ契約の最も重要な特徴はプライバシーです：（1）AliceとBobは、彼らがCarolのデータを使用していることをCarolに通知する必要はありません。これは契約の実行に全く影響しません。（2）オンチェーンの観察者（Carolを含む）は、AliceとBobの契約の実行取引を通じて、彼らがどのウェブサイトのサービスを利用しているかを判断することはできませんし、彼らの契約が賭けの契約であるか（ライトニングネットワークではなく）どうかさえ判断することはできません。

4. 制限条項の概要

OP_CTV と渋滞制御

比特币社区の開発者は、制限条項として分類されるさまざまな提案を行いました。現在では、最も有名な提案は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を割り当てることです。もう 1 つの出力はプールで、これも OP_CTV を使用してトランザクションにコミットするため、Bob は 3 BTCだけを取り出し、残りの 2 BTCを Carol に送信できます。

BobまたはCarolは引き出しをしたい場合も同様です。彼らは引き出し時に、対応するOP_CTVのチェックを通過できるトランザクションのみを使用することができ、つまり自分に対して対応する金額を支払うことしかできません。残りの資金はOP_CTVロックを使用した資金プールに再度入ることになります。これにより、ユーザーの引き出しの順序に関係なく、残りのユーザーは信頼せずにプールから退出することができます。

抽象的に言えば、OP_CTVの役割は、契約が終了するまでの経路を契約に計画することであり、ここでの資金プール契約がどの経路をたどり、どの状態に到達しても、信頼性のある終了が保証されるようにすることです。

この OP_CTV にはもう一つ非常に興味深い使用法があります。「隠れた片方向の支払いチャネル」というものです。Alice がこのような資金プールを形成し、資金が次のスクリプトを持つ出力に信頼なく引き出せることを保証すると仮定してみましょう。

要么，Alice和Bob一起花费它，要么01928374656574839201，一段时间后，Alice可以独自花费它

如果 Alice 不向 Bob 揭晓，Bob 就不会知道有这样的输出存在；一旦 Alice 向 Bob 揭晓，Bob 就可以把这个输出当成一个有时效性的单向支付通道，Alice 可以立即用其中的资金给 Bob 支付，而不必等待区块链的确认。Bob 只需在 Alice 可以独自花费它之前，让 Alice 给他的承诺交易上链即可。

OP_Vault 与保险柜 -> #### OP_Vault および保険金庫

OP_VAULTは、「保険金庫（vaults）」を構築するために提案された制限条項です。

保険庫契約は、より安全で高度な自己保管形式を目指しています。現在のマルチシグネチャ契約は、個々の秘密鍵の単一障害点を排除することができますが、攻撃者が閾値の数の秘密鍵を実際に取得した場合、ウォレットの所有者は手を打つことができません。保険庫は、資金に一度の支出制限を課すことを目指しています。同時に、通常の経路からの引き出し時には、引き出し操作に待機期間が強制されます。待機期間中に、引き出し操作は緊急復元ウォレットの操作によって中断される可能性があります。このような契約では、ウォレットの所有者は攻撃された場合でも（緊急復元ブランチを使用して）反撃操作を行うことができます。

理論的には、OP_CTV でもこのような契約をプログラムすることができますが、様々な不便があります。その一つは手数料です：取引を約束すると同時に、その取引で支払われる手数料も約束されます。このような契約の用途を考慮すると、契約の設定と引き出しの時間間隔は非常に長くなるため、適切な手数料を予測することはほとんど不可能です。OP_CTV は入力を制限していないため、手数料を増やすために入力を増やすことができますが、提供された入力はすべて手数料に変わるため、実現不可能です。もう一つの方法は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 policy）のいくつかの提案（たとえば、v3フォーマットのトランザクションなど）も使用され、より良い効果が得られます。これは、私たちが「プログラミング」という言葉の意味が、私たちが想像している以上に広範であることを思い起こさせます（Nervos NetworkのOpen Transactionのような類似の例もあります）。

五. CKBの理解

上記の2つのセクションでは、より制限された構造（Bitcoin UTXO）で興味深いアプリケーションをスクリプトプログラミングする方法と、この構造に内省能力を追加しようとする提案について説明しました。

UTXOは、これらのアプリケーションをプログラミングする能力には欠けていませんが、読者はそれらの欠点や最適化の余地に気付くことが容易です。例えば、

LN-Penalty では、チャネルの参加者は過去のすべてのコミットトランザクションと対応するペナルティ秘密値を保存し、相手の詐欺に対処する必要があり、これはストレージ上の負担となります。もし最新のコミットトランザクションのみが有効になり、古いコミットトランザクションが無効になることを保証するメカニズムがあれば、この負担を軽減し、ノードが誤って古いコミットトランザクションをチェーンにブロードキャストし、それによって誤って罰せられる問題も解消できます。
DLCでは、イベントの可能な結果が多いと仮定されるため、両当事者は互いに事前に生成および提供する必要がある署名も多くなります。これは莫大な負担となります。さらに、DLC契約の収益は公開鍵に直接バインドされているため、その仓位は簡単には移動できません。契約の仓位を移転する方法はありますか？

実際には、ビットコインコミュニティはこれらの問題に対する解決策を提案しており、基本的にはSighash提案（BIP-118 AnyPrevOut）と関連しています。

しかし、もし私たちが CKB 上でプログラミングをしている場合、BIP-118 は実質的にすでに利用可能です（このような Sighash タグを模倣する能力を持つ内省とターゲット検証署名を使用できます）。

通过学习BTC编程，我们不仅知道了 “交易输出” 这种格式下可以如何编程（CKB 能编程什么），还能知道这些应用的改进方法（如果我们在 CKB 上编程这些应用，可以如何运用 CKB 的能力来改进它们）。对于 CKB 开发者来说，简直可以将基于BTC脚本的编程当成一种学习的教材，甚至是捷径。

下記、私たちはCKBプログラミングの各モジュールのプログラム可能性を個別に分析します。内省能力は考慮しません。

プログラム可能性のある任意の計算ロック

上記のように、UTXOはプログラミング可能ではありません。しかし、Lockはプログラミング可能であり、これはLockがUTXOベースのプログラミングに基づいて（制約条件が展開される前に）ライトニングチャネルやDLCなど、前述のものを含むすべてをプログラムできることを意味します。

此外、この検証可能な任意の計算能力により、LockはUTXOよりも多く、より柔軟な身元確認手段を利用できます。たとえば、ECDSA署名を使用する一方が、RSA署名を使用するもう一方の場合など、CKB上で実装することができます。

実際には、これはCKB上で最初に探索された分野の一つです。柔軟な認証機能をユーザーの自己保管に使用し、いわゆる「アカウントの抽象化」を実現します。トランザクションの有効性の承認と制御権の回復は非常に柔軟で、ほとんど制限がありません。原理的には、「複数の支出分岐」と「任意の認証手段」の組み合わせです。実装例には、JoyIDウォレット、UniPassなどがあります。

此外，Lock 也可以実現 eltoo 提案，从而実現只需保留最新一笔承诺交易的闪电通道（実際上，eltoo 可以简化一切点对点合约）。

プログラム可能性のある任意の計算タイプ

如上所述、Typeの大きな用途の1つは、プログラムのUDTです。Lockと組み合わせることで、UDTを対象としたライトニングチャネル（および他の種類の契約）を実現することができます。

实際には、LockとTypeの分割は、セキュリティの向上と見なすことができます：Lockは保管方法または契約型プロトコルの実現に焦点を当てており、TypeはUDTの定義に焦点を当てています。

此外、UDTの定義に基づく起動検査の能力により、UDTはCKBと同様の方法で契約に参加できるようになりました（UDTは一等市民です）。

举个例子：筆者は以前、ビットコイン上で信頼不要なNFT担保ローンを実現するためのプロトコルを提案しました。このプロトコルの鍵は、コミットメントトランザクションです。このトランザクションの入力価値は出力価値よりも低いため（したがって、有効なトランザクションではありません）、しかし、十分な入力を提供できると、有効なトランザクションになります：貸し手が返済できると一度返済が行われてから、貸し手は担保として預けられたNFTを取得することができません。ただし、このコミットメントトランザクションの信頼不要性は、トランザクションの入力と出力の金額の確認に基づいているため、貸し手はビットコインのみを使用して返済することしかできません。たとえ貸し手と貸し手が別の通貨（たとえばRGBプロトコルで発行されたUSDT）を受け入れることを望んでも、ビットコインのコミットメントトランザクションでは、貸し手が十分なUSDTを返済した場合に自分のNFTを取り戻すことを保証することはできません。なぜなら、ビットコイントランザクションはUSDTの状態を知らないからです！（修正：言い換えると、USDTの返済を条件とするコミットメントトランザクションを構築することはできません。）

もしもUDTの定義に基づいて検査を行うことができれば、貸し手は署名された別の約束トランザクションを作成し、貸し手がUSDTを返済に使用できるようにすることができます。トランザクションは入力されたUSDTの数量と出力されたUSDTの数量を検査し、ユーザーがUSDTを返済するための信頼性を確保します。

修正：仮にここで担保として使用されるNFTと返済に使用されるトークンが同一のプロトコル（例：RGB）で発行される場合、問題は解決できます。RGBプロトコルに基づいてコミットメントトランザクションを構築することで、NFTの状態変更と返済を同期させることができます（RGBプロトコル内でトランザクションを使用して2つの状態変更をバインドします）。ただし、RGBのトランザクションもビットコインのトランザクションに依存するため、コミットメントトランザクションの構築には一定の難しさがあります。結論として、問題は解決できますが、トークンは一級市民にはなりません。

次に、私たちは再び内省能力を考慮します。

Lock 01928374656574839201其它 Lock s

これは、比特コインUTXOの上でのあらゆるプログラム可能性が制限条項提案の実装後に意味します。これには、先述の保険箱契約やOP_CTVを基にしたアプリケーション（例：渋滞制御）も含まれます。

XueJie 曾经提过一个非常有趣的例子：你可以在 CKB 上实现一种收款アカウント Cell，在使用这种 Cell 作为取引の入力时，如果它输出の Cell （使用相同 Lock 的 Cell）具备更多のCapacity，那么这个入力无需提供签名也不会影响取引の有效性。実際上，如果没有内省的能力，这种 Cell 是无法实现的。这种收款アカウント Cell 非常适合作为机构の收款方式，因为它可以将资金归集起来，缺点是它的隐私性不佳。

他のタイプ（およびデータ）をロックして読み取ります

この能力の面白い応用の一つは、株式トークンです。Lockは、他の入力に基づいて、自身の能力を利用できるかどうか、およびその能力をどこに使うことができるか（Lockの能力を自己分析する必要があります）を決定します。

他のロックを読み取るタイプ

不確定ですが、有用であると仮定できます。例えば、トランザクションの入力と出力のロックが不変であることは、Typeで確認できます。

Type Scirpt 读取其它 Type s（以及 Data）

集换卡？集齐 n 个 token 可以换取更大的一个 token : )

六. 结论

結論

与此前出現的プログラム可能性のある計算のスマートコントラクトシステム（例：イーサリアム）と比較して、Nervos Networkは異なる構造を採用しています。そのため、従来のスマートコントラクトシステムの理解は、Nervos Networkの基礎となることが難しいことがあります。本文では、より制約のある構造であるBTC UTXOのアプリケーションプログラミングを通じて、CKB Cellのプログラム可能性を理解する方法を提案します。また、「内省」の概念を使用してセルの「クロスコントラクトアクセス」の能力を理解し、内省能力を使用する場合を分類し、具体的な用途を確定します。

修订：

セルのクロスアクセス能力（つまり内省能力）を考慮しない場合、lock sは状態を持ち、プログラミング能力が極限に近いBitcoinと見なすことができます。したがって、これだけでBitcoinに基づくすべてのアプリケーションをプログラムすることができます。
セルのクロスアクセス能力（つまり、内省能力）は考慮しない場合、lock s と type s の分離はセキュリティのアップグレードと見なすことができます：それは UDT の資産定義と保管方法を分割します。さらに、公開可能な状態の type s（および Data）は、UDT が一級市民であることを実現しています。

以上の2点は、「BTC + RGB」と同じパラダイムでありながら、より強力なプログラミング能力を持つものを意味します。