CKB コミュニティ メンバー Retric が Nostr バインディング プロトコルを提案
元の記事は Github に公開されました https://github.com/RetricSu/nostr-binding/blob/main/docs/lightpaper-zh.md
この記事では、Nostr プロトコルの基本データ構造を CKB ブロックチェーンにバインドするプロトコルを提案します。このバインディングを通じて、Nostr ネイティブ データが CKB ブロックチェーン上の UTXO/Cell の特性を継承できるようになり、オンチェーン メカニズムに基づいた Nostr プロトコルに新しい可能性をもたらします。潜在的なユースケースの 1 つは、Nostr でネイティブ アセットを発行することです。 Nostr バインディング プロトコルは、dApps に新しい開発パラダイムももたらします。 dApp を 2 つのシステム (1 つはオフチェーン サーバー、もう 1 つはオンチェーン スマート コントラクト) に分割するのではなく、異なるレベルのデータを含む一貫したシステムを使用して dApp を構築します。これはイーサリアムのモデルとは根本的に異なります。
Web5 の 3 層構造:
ノストラについて
Nostr は、リレークライアント モデルを使用してグローバル ネットワーク全体に標準メッセージを配布する、シンプルでオープンなメッセージ配布プロトコルです。リレークライアント モデルはブロックチェーンの P2P ネットワークに似ていますが、より安価で、より柔軟で、より実用的 (そしてより集中化され) で、消費者グレードのアプリケーションの大量導入に適しています。標準メッセージは Nostr の核となるイノベーションです。 Nostr では、さまざまなデータを記述するための標準的なメッセージ フォーマット (このメッセージ フォーマットはプロトコルの基本データ構造でもあります) を JSON に基づいて定義しています。それは「イベント」と呼ばれます。
イベントの構造:
イベントは任意のコンテンツを含むデータであり、ユーザーによって署名されているため、中継サーバーを信頼せずにクライアント側で検証できます。 Nostr プロトコルで公開するすべてのメッセージは、さまざまな種類と要件のイベントです。 Nostr について詳しくは、NIP から学ぶことができます。
CKBについて
CKB は、UTXO と POW のような設計を持つビットコインの第 2 層ネットワークです。 CKB の基本的なデータ構造は Cell と呼ばれます。 Cell は、強力なプログラマビリティを備えた汎用 UTXO です。
セル構造:
スクリプトの構造:
CKB の詳細については、docs.nervos.org を参照してください。
バインディング
いわゆるバインディングとは、Nostr Event と CKB Cell の間に 1 対 1 のマッピング関係を作成することです。イベントは資産の詳細を定義するために使用され、このイベントにマップされるセルは所有権の保護やその他のブロックチェーン固有の機能を提供するために使用されます。この 1 対 1 マッピングを作成するには、Nostr イベントが CKB セルを指すようにする必要があり、その逆も同様です。 Nostr および CKB プロトコルは単純であるため、このバインディングの作成は非常に簡単です。
必要なのは 2 つのスクリプトだけです
Nostr バインディング プロトコルに 2 つの CKB スクリプトを導入しました。 1 つ目は Nostr バインディング スクリプトです。これは、Nostr プロトコルから CKB にイベントをバインドするためのメソッドを定義するタイプ スクリプトです。これは非常に単純なスクリプトですが、バインドのコア ロジックをカバーしています。 2 つ目は Nostr ロック スクリプトです。これは、Nostr イベントをロック解除署名として使用するロック スクリプトです。これは、CKB に基づいて Nostr dApps を構築するユーザー エクスペリエンスとプロセスを簡素化するために使用されます。
Nostrバインディングスクリプト
Nostr バインディング スクリプトは、Nostr プロトコルからの特定の特別なイベントをチェーンにバインドするためのルールを定義するために使用されるタイプ スクリプトです。 Nostr バインディング スクリプトは、このスクリプトをタイプ スクリプトとして使用するセルが、CKB ブロックチェーンに存在し、特定の Nostr イベントにバインドされる唯一のライブ セルであることを保証します。
バインディングスクリプト:
TYPE_ID は、ブロックチェーン内の 1 つのライブ Cell のみがこのタイプ ハッシュを持つことを保証するために使用されます。
NOSTR_EVENT_ID は、セルが一意の Nostr イベントのみを指すようにするために使用されます。
Nostr バインディング スクリプトを Type Script として使用するセルは、Nostr Event のバインディング セルです。
Nostr によってバインドされたイベント構造:
Nostr アセット イベントの cell_type_id タグにより、イベントが一意の CKB セルのみを指すことが保証されます。
Nostr アセット イベント ユーザーが作成したアセットを提示します。 Nostr アセット メタデータ 同じアセット コレクションを記述するために使用されるイベント メタデータ。
Nostr アセット メタデータ イベント構造:
Nostr ロック スクリプト
Nostr ロック スクリプトは、ロック解除の証拠として Nostr イベントを使用するロック スクリプトです。これは、CKB に基づいて Nostr dApps を構築するユーザー エクスペリエンスとプロセスを簡素化するために使用されます。
Nostr ロック スクリプトの構造:
args は Nostr アカウントの公開キーに設定されます。最後の 4 バイトに POW 値を追加することもできます。これは、イベントのロックを解除するには特定の POW 難易度を満たす必要があることを意味します。
args が 32 バイトすべて 0 の場合、誰もロックを解除できないことを意味します。
最初の 32 バイトがすべて 0 で、最後の 4 バイトがゼロ以外の場合、ロック解除イベントが特定の POW 難易度値を満たしている限り、どの Nostr アカウントでもロックを解除できることを意味します (これは公正な目的で使用できます)。発行）
Nostr はイベント構造のロックを解除します。
Nostr ロック スクリプトを使用して CKB セルのロックを解除するには、トランザクションの監視フィールドに Nostr ロック解除イベントを指定する必要があります。ユーザーは複数のロック解除イベントを生成できますが、イベントはチェーンにアップロードされるときに対応する CKB トランザクションをタグに記録するため、残りのイベントは自動的に無効になるため、リプレイの危険はありません。
Nostr ロック スクリプトはマルチ署名もサポートできます。そのロック スクリプト引数には Nostr イベント ID を指定できます。このイベントのタグ フィールドには、すべての所有者の M P 公開キーが記録されます。ロックを解除するには、証明として Nostr ロック解除イベントを提供するために少なくとも N (N<=M) の Nostr アカウントが必要です。
Nostr ロック スクリプトの助けを借りて、ユーザーは Nostr エコロジカル クライアントとブラウザ プラグインを使用して直接署名し、CKB トランザクションのロックを解除するための署名証明としてロック解除されたイベントを生成できるため、これらのオフチェーン Nostr エコロジカル ツールの開発者は、次のことを知ることができます。 CKB とブロックチェーン関連のコードを導入します。同時に、ユーザーはブロックチェーンについてほとんど「気にしない」ことができます。プロジェクト関係者や他のボランティアは特別なリレーを実行して、Nostr ネットワーク内に新しいロック解除イベントがあるかどうかを監視し、ある場合はトランザクションを解析してロック解除のために CKB チェーンに送信するのを支援できます。取引手数料は、残高の一部を手数料として留保するセルを通じて支払うことができます。
資産を発行する
直接結合
ユーザー: Nostr アカウントと CKB が必要です
CKB セルのインデックスを作成し、セルの TYPE_ID を計算します。
TYPE_ID を使用して Nostr 署名を含む Nostr アセット イベントを生成する
Nostr アセット イベントを使用して CKB バインディング トランザクションを生成し、チェーンに送信します。
RGB++による
ユーザー: Nostr アカウント、ビットコイン ウォレット、サトシが必要です
UTXO にインデックスを付け、RGB++ を通じてマッピング Cell を生成し、Cell の TYPE_ID を計算します。
TYPE_ID を使用して Nostr 署名を含む Nostr アセット イベントを生成する
Nostr アセット イベントを使用して CKB バインディング トランザクションを生成し、チェーンに送信します。
移行
Nostrでロックする場合
ユーザー: Nostr アカウントが必要です
CKB の Nostr ロック スクリプトを使用して、ロックを解除したいセルにインデックスを付けます。
CKB トランザクションを構築し、このセルを他のロック スクリプトに置き換えます。
ステップ 2 の結果を使用して、Nostr クライアント/ブラウザー拡張機能を介して Nostr ロック解除イベントを生成します。
Nostr ロック解除イベントを特別なリレー グループに送信し、チェーンに送信します。
他のロックを使用する場合
ユーザー: 他のロックに対応するウォレットが必要です。Nostr 関連の操作は必要ありません。
CKB/RGB++ で通常のプロセスに従うだけで、転送のロックが解除されます。
スケーラビリティの問題
Nostr バインディング プロトコルの主な利点は、非常にシンプルで簡単であることです。また、そのシンプルさにより、クライアント開発者がその上に製品を構築することも容易になります。一方、Nostr バインディング プロトコルの欠点は、スケーラビリティの問題です。このシンプルな設計では、Nostr トークンのスループットは CKB ブロックチェーンにバインドされているため、CKB ブロックチェーンがボトルネックになります。 Nostr が大量導入を目的とした、より柔軟なソーシャル ネットワークとして設計されていることを考慮すると、将来、多数のユーザーがこれらのネイティブ アセットを操作する場合、このスループットが問題になる可能性があります。
ただし、この問題を解決するにはいくつかのオプションがあります。
CKBライトニングネットワークと統合
Nostr バインディング プロトコルによって作成された Nostr ネイティブ アセットは通常の CKB アセットとして扱うことができるため、CKB ライトニング ネットワークが開始されたら、それを使用して Nostr バインディング プロトコルを拡張できます。 Nostr バインディング プロトコル自体は変更する必要がなく、無料の機能です。ただし、CKB ライトニング ネットワークの開始を待つ必要があるという欠点があります。
シンプルだが便利な支払いチャネルの実装
CKB ライトニング ネットワークの開始前のもう 1 つのオプションは、スピルマン チャネルなどの非常にシンプルだが便利な支払いチャネルを実装することです。スピルマン チャネルは、実装が簡単な一方向の支払いチャネルです。チャネルには支払者と受取人が存在します。この種の支払いチャネルはブロックチェーンにとってはあまり役に立たないかもしれませんが、Nostr バインディング プロトコルの場合、コンテンツ作成者とそのフォロワーの間のサブスクリプション モデルに完全に適合します。
1 対 1 バインディングの代わりに N 対 1 バインディング
1 対 1 バインディングを作成する代わりに、Nostr イベントと CKB セルの間に N 対 1 バインディングを作成できます。言い換えれば、スケーラビリティのために複数のイベントを 1 つのセルにバンドルします。これにより、オンチェーンのマッピング ストレージのコストがオフチェーンの Nostr Event よりもはるかに小さくなります。ただし、N 対 1 バインディングの問題は、バンドルされたイベントの所有権を制御および分割するための新しいパターンを設計する必要があることです。これはより複雑になり、追加の設計と実装作業が必要になります。
RGBスタイルソリューション
究極のスケーラビリティを実現するもう 1 つの方法は、CKB セルをワンタイム シールとして使用し、Nostr プロトコルを RGB プロトコルと同様の実装層にする、RGB スタイルのソリューションを作成することです。このソリューションでは、トークン標準のみの実装を選択し、元の RGB プロトコルから一般的なスマート コントラクトのアイデアを除外することで、ワークフローを簡素化します。
よくある質問
ノストルを選ぶ理由
Nostr は、暗号化に基づく大規模アプリケーションにとって理想的なレイヤーです。これは、非常にシンプルでわかりやすく、実用的で、偏りがなく、統合が容易な情報配布プロトコルです。多くの Web3 プロジェクトでは、まったく異なる価値観と哲学を持つ Arweave や IPFS などを使用することがあります。 Nostr は、完全に分散化された P2P ネットワークへのこだわりや、Web3 の世界に長年存在してきたトークンエコノミクスやインセンティブ メカニズムへの過剰なコミットメントがなく、非常に緩やかなプロトコルと考えることができます。これにより、Nostr はより実用的で、批判的ではなくなります。
なぜブロックチェーン資産を使用しないのでしょうか?
ユーザーが Nostr ネットワーク内の既存のブロックチェーン トークンを直接使用するのではなく、イベントに基づいて Nostr ネットワーク内で独自のネイティブ アセットを発行できるようにすることは、主に、値が作成されない場合、トークンには価値がないという単純な事実に基づいています。消費者向け製品の場合、ほとんどのブロックチェーン資産は、製品に価値を追加するのではなく、製品のワークフローに摩擦を引き起こすだけです。トークンメカニズムを製品に強制的に組み込むよりも、ユーザーの視点を見て、何が必要で、ブロックチェーンがどのように役立つかを考える方が良いでしょう。私たちは、ネイティブのイベントベースのアセットがこの方法論に適合すると信じています。アプリケーション開発者とユーザーは、既存のブロックチェーン資産やルールを強制的に受け入れるのではなく、独自の観点から資産を使って何ができるかを確認できます。さらに、イベントベースのアセットは Nostr プロトコルとシームレスに連携する可能性が高く、既存の Nostr エコシステム製品やツールに新しい遊び方をもたらします。
CKBを選ぶ理由
CKB を使用したバインディング プロトコルの実装は、プログラム可能であるため、はるかに簡単です。ビットコインはさらに難しいです。さらに、CKB が BTC に結合される独自の方法を考えると、最初に CKB に結合し、次に BTC に結合する方が簡単になります。
結論
全体として、Nostr はシンプルで実用的な情報配布プロトコルとして、消費者向けアプリケーションの大規模な導入に非常に適しています。 CKB のプログラム可能性とビットコインとのバインディング関係により、Nostr バインディング プロトコルを実装するのに理想的な選択肢となります。同時に、Nostr Event に基づいてネイティブ アセットを発行することで、アプリケーションに基づいて新しい製品メカニズムを設計でき、Nostr が他の従来のインターネット アプリケーションと競合し、独自の PMF を見つけることができます。