著者: Colby Serpa コンパイラ: DAOrayakiNostr 2.0 は、ライトニング ネットワークがレイヤー 2 として即時オフチェーン支払いを提供するのと同じように、ビットコインの上にレイヤー 2 として構築し、安全なオフチェーン データ ストレージを提供できる可能性があります。この記事では、Nostr リレーがその軽量性を維持しながらデータを同期し、ユーザーがレイヤー 1 ブロックチェーンでは利用できないデータを選択的に削除できるようにする方法について説明します。同時に、ビットコイン ブロックの容量と速度には限界があるため、ビットコイン ブロックチェーンに大量のデータを保存する場合と比較して、Nostr リレーを使用してデータを保存する方がコストが安くなる可能性があります。次の単純なコンピューター サイエンス設計により、標準化された CAP 定理基準の下で Nostr ネットワークの分散特性が向上します。 CAP は、一貫性、可用性、およびパーティション許容度の略です### **Nostr リレーは、設定ファイルが不完全であることを認識せず、リレーに一貫性が欠けています (CAP 定理の C)。 **リレーに一貫性がありません (CAP 定理の C)一貫性とは、各コンピュータ上で同期されたデータベースが同じであることを意味します。 Nostr リレーは、ブロックチェーンがブロックごとにデータを同期する方法と同様の方法で、信頼を最小限に抑えた同期を実行できません。ビットコインのフルノードとは異なり、Nostr リレーによって保存されるデータベースは通常不完全です。特定のユーザーが署名したすべての投稿を盲目的に要求することを除けば、Nostr リレーは欠落しているデータを検出できません。**Nostr の一貫性/同期の問題:**2 人のユーザーがそれぞれの投稿を異なる Nostr リレーにアップロードした場合、Nostr はブロックチェーンのようなものではないため、これら 2 人のユーザーはお互いの投稿を見ることができない場合があります。ブロックチェーンでは、新しいレコードが存在するたびに、すべてのフルノードがブロックチェーンを同期します。すべてのフルノードは、このデータをブロックとしてブロックチェーンに同時に追加します。ビットコイン ブロックチェーン上のすべての完全なノードは、まったく同じブロックチェーンを所有します。Nostr ユーザーが常にお互いの投稿を閲覧できるようにしたい場合は、すべての Nostr リレーがユーザー プロファイル内の欠落データを特定して、他の Nostr リレーまたはユーザーに欠落部分をリクエストできるようにする方法が必要です。### **週次のオンチェーン マークル ルートおよび完全なツリー ハッシュを使用して Nostr リレーを同期する*** 週に 1 回程度、ユーザーはすべての投稿をマークル ツリーに整理できます。* ビットコインの各リーフにトランザクションのハッシュが含まれるのと同様に、マークル ツリーの各リーフには投稿のハッシュが含まれます。* ユーザーがプロフィール全体をマークル ツリーに編成したら、通常のビットコイン トランザクションの下にあるオンチェーンの OP\_RETURN にマークル ルートを公開します。 Nostr 2.0 が機能するためにブロックチェーンのハード フォークを必要としないのはこのためです。 OP\_RETURN は、ビットコイン トランザクションの下にあるセクションで、送信者の署名の前に小さなメモを追加できます。* さらに、ユーザーはツリー全体をハッシュし、マークル ルート (OP\_RETURN 内) とともにチェーンにアップロードします。マークル ルートは、ツリー全体ではなく、最上位のブランチのハッシュにすぎません。ツリー全体のハッシュは、ユーザーと中継者がプロファイル データが欠落しているかどうかを検出できるようにするために不可欠です。* ツリー全体のハッシュを取得するには、テキスト ファイルのルートにマークル ルートを配置します。次に、マークルの枝をルートの下の線に配置します。次に、マークルの葉を枝の下の列に置きます。ツリーが説明どおりに配置されたら、すべてを一度にハッシュします。以下は、上に示したマークル ツリーのツリー全体のハッシュがどのようになるかを示す、ツリー全体のハッシュの例です。ツリー全体のハッシュ (すべてのマークル ツリー データを一度にハッシュ)マークル ルート ハッシュとツリー全体のハッシュは、次の 2 つの重要な機能を提供します。* マークル ルートを使用すると、ブロック全体をダウンロードすることなくトランザクションをダウンロードできるなど、ユーザーと中継者は構成ファイルの一部を一度にダウンロードできます。* ツリー全体のハッシュにより、ユーザーと中継者は保存されている設定ファイルが不完全かどうかを知ることができます。マークル ルートとは異なり、マークル ツリー内のすべてのビットがある場合にのみ、ツリー全体のハッシュが一致します。この安価な方法を使用すると、構成ファイル全体を毎週またはユーザー定義の頻度で更新できます。 Nostr は現在と同様に機能しますが、ユーザーが自分の投稿をすべてのユーザーに見てもらいたい場合は、時折、料金を払って Nostr リレー間でデータを同期することができます。ユーザーと中継者は、一度に 1 つのブランチの投稿をダウンロードできます。各ブランチの後、そのブランチをマークル ルートに最も近い別のブランチでハッシュし、それがチェーン上のマークル ルートと一致するかどうかを確認します (SPV と同様)。これらのブランチをハッシュしてマークル ルートと一致させると、完全なユーザー プロファイルをまだ持っていない場合でも、そのブランチがユーザー プロファイルの一部であることがわかります。ユーザーは、各ブランチの有効性を検証し、ダウンロードされた設定ファイルが完全であることを確認しながら、多くの異なる Nostr トランクから同じ設定ファイルの異なるブランチをダウンロードできます。フォークを 1 つずつダウンロードすることで、多くの分散ネットワークをダウンさせる可能性のある遅延攻撃を防ぐことができます。これが、SPV ライト ウォレットを保護するためにビットコイン ホワイト ペーパーでマークル ルートとフォークが使用されている理由です。**マークルルートがツリー全体のハッシュのように機能できないのはなぜですか? **** Nostr リレーがマークル ルートのみに依存する場合、マークル ルートに最も近いブランチのペアがすべて同じマークル ルートにハッシュされるため、マークル ツリーがいつ完成するかを知ることができません。 **ユーザーのプロファイルが完全であることを確認するために、中継者またはユーザーは更新されたマークル ツリー全体をハッシュし、それがオンチェーンのツリー ハッシュ全体と一致することを確認します。ツリー全体のハッシュが一致すると、ユーザー データが完成します。ツリー全体のハッシュが一致しない場合、リレーまたはユーザーは他のリレーに最新のリーフ番号を伝え、ツリー全体のハッシュが一致するまで欠落しているブランチを要求できます。毎週のように追加されるすべての新しいマークル ルートを追跡するには、Nostr リレーがビットコインのフル ノードになる必要があります。 Nostr 2.0 リレーは、ビットコインと Nostr のセキュリティを強化しながら、ビットコイン ブロックチェーンを保存するために間接的に支払われます。### **Nostr ストレージの制限: ユーザーの経験則**ビットコインのフルノードとは異なり、リレーラーには何を保存するかを選択する権利があるため、Nostr リレーでは一部のユーザー データが失われる可能性があります。したがって、ローカルでバックアップを作成できる場合、ユーザーは Nostr リレーにのみデータを保存する必要があります。 Web5 のセルフホステッド サービスを使用すると、ユーザーはバックアップをすべてのローカル デバイスに同期できるため、Nostr の使用を懸念するユーザーのリスクが軽減されます。結局のところ、データが真に不変であるのはブロックチェーンだけです。とはいえ、Nostr はかなり安全なハイブリッド ソリューションであり、多くのアプリケーションで引き続きうまく機能します。トレードオフは以下のとおりです。### **信頼最小化の 3 層*** 階層 1: 検閲が非常に困難な、不変で高価なデータ ストレージ。 (チェーン上のブロックはすべてのビットコインフルノードを同期します)* Tier 2: 変更可能で安価なデータ ストレージ、中程度に難しい検閲。 (オフチェーン マークル ツリーとオンチェーン ハッシュ、同期 Nostr リレー オンデマンド)* ローカル データ ストレージはすべてのローカル デバイスに同期されるため、簡単に検閲されます。 (ローカル集中化)### **ナカモトのコンセンサスベースのブロックチェーンと Nostr の間の基本的なトレードオフ****特定のアドレスのデータを保存する Nostr リレーが増えるほど、そのデータを検閲することが難しくなります。これは、多くの Nostr リレーがホストする人気のあるデータは、めったにダウンロードされない人気のないデータよりも検閲が難しい可能性があることを意味します。 ****一方、ナカモトコンセンサスブロックチェーンは、データの古さに基づく検閲を防ぎます。ブロックチェーン内に存在するデータが長くなるほど、51% 攻撃を使用してデータを削除することが難しくなります。 **特定のフォークが特定のユーザーに属していることを確認できるため、Nostr リレーはユーザーに小さなデータを配信するたびに料金を支払うことができます。これを実現するには、ユーザーはブロックチェーンのヘッド (SPV など) をダウンロードして、ライト ウォレットの典型的な機能を実行できるようにする必要があります。ユーザーは、ライト ウォレットの SPV 機能を利用して、チェーンから特定のトランザクションをフェッチします。これには、ユーザー プロファイルのマークル ルートとツリー ハッシュ全体が OP\_RETURN に含まれます。ユーザーはリレーに料金を支払い、そのユーザーのプロファイルをブランチごとにダウンロードし、オンチェーンのマークル ルートと一致するようにハッシュすることで各ブランチを検証できるようになりました。データの提供と引き換えにsats（ビットコインの最小単位）をNostrリレーに送信するために、Gregory Maxwell（有名なビットコインコア開発者）のZKCP設計（ゼロ知識条件付き支払い）を使用します。 [1] ZKCSP の進化版: 取得可能性の証明 [2] ライトニングネットワークと組み合わせます。ZKCSP ホワイトペーパーの説明によれば、次のようになります。「...信頼できるサードパーティは必要ありません...また、クライアントのデータがサーバーに正しく保存されたことを証明するために、クライアントがサーバーに料金を支払う、取得可能性の証明の場合に ZKCSP プロトコルを実装しました。」 [2]* ユーザーが複数の金融業者と Lightning スマート コントラクトを開始します。※ユーザーは周囲の金融業者にリクエストを送信します。金融業者はリクエストに署名します。* ユーザーは、金融業者が署名したリクエストを、それらの金融業者に接続されている Nostr リレーに直接送信します。* ユーザーは、正しく要求されたデータが配信された後にのみ Nostr リレーが金融業者から支払いを受けるようにするために、ZKCSP 構造を開始するようになりました。ステップ 3 が発生すると、ユーザーはステップ 4 で ZKCSP の構築を開始する前に、金融業者が署名した元のリクエストに加えて修正を加えます。ユーザーは元のリクエストに追加額を追加し、ユーザーと金融業者の両方の残高から差し引く金額を指定します (これらの金額は同じ金額に金融業者の手数料を加えたものである必要があります)。その後、ユーザーはその金額を元のメッセージに追加します。署名する内容。**ユーザーが所有する衛星よりも多くの衛星を送信するように指定した場合、または Nostr リレーで資金提供者が凍結した以上の衛星を送信するように指定した場合、Nostr リレーは支払いを受け取ることができないため、要求を拒否します。 **このようにして、ユーザーは少数の資金提供者だけで資金を凍結しながら、多くの Nostr リレーに接続することができます。同様のアプローチは、信頼を最小限に抑えた金融業者がユーザーと販売者の間で許可のない仲介者となるライトニング ネットワークでも採用できます。通常の P2P ライトニング ジャンプも Nostr 2.0 で利用できますが、これはルーティングとチャネル バランシングが頻繁に失敗する場合に役立つ可能性があります。### **ホワイトリストによる有料 Nostr リレーのロック解除**Nostr リレーは、これらすべてのユーザーが閲覧するデータを保存したい場合、特定のキーをホワイトリストに登録できます。 Nostr リレーがデータの保存を希望するユーザーをホワイトリストに登録できない場合、Nostr リレーは送信されたデータをすべて保存します。ユーザーがいつでも無料でリレーにデータを送信できれば、ユーザーは Nostr リレーの料金を支払う必要がなくなります。 Nostr は、中継者が料金を支払えないデータの保存を拒否するオプションを持っている場合にのみ、有料オプションを提供できます。無料のリレーはまだ存在しますが、有料のリレーのオプションは現在存在しません。すべての Nostr データを無料で保存しようとする代わりに、有料の Nostr リレーはホワイトリストを使用して、有料ユーザーが毎日閲覧するすべてのデータを選択的に保存できます。一部の Nostr リレーは引き続き無料モデルで動作しますが、大規模な場合、ほとんどの無料リレーは単なる熱狂的な愛好家であるため、これは持続可能ではありません。 Nostr リレーにどのデータを保存するかを決定する機能を与えるホワイトリスト化 (各 Nostr プロファイルに公開キーを安全に割り当てることができたとしても) は不可能です。プロファイルごとに 1 つの公開キーがホワイトリスト機能のロックを解除します。ビットコイン アドレスが Nostr 公開キーになります。このシステムにより、最終的に各設定ファイルに公開キーを割り当てることができます。投稿ごとに新しい公開キーを作成するユーザーには何のメリットもありません...公開キーはすべて自分のプロフィールに関連付けられているためです。これはビットコインアドレスとは異なります。ビットコインとは異なり、ユーザーが同じアプリケーション内で複数の公開鍵を持っていてもプライバシーは向上しません。**Nostr プロファイルの公開キーは、毎週のハッシュ (すべてのユーザーの投稿のマークル ルートおよびツリー ハッシュ全体) を含むビットコイン トランザクションの公開キーと一致する必要があります。 Schnorr 署名を使用する Nostr ユーザーとは異なり、署名にはビットコイン ウォレット (モバイル ウォレット/ライト ウォレットまたはフル ノード) を使用する必要があります。 **この利点は、各 Nostr アカウントがビットコイン アドレス** で表されることです。つまり、ユーザーは 2 つの異なる公開キーを要求せずに、Nostr アカウントに直接支払いを送金できることになります。これにより、システム内の新規ユーザーの認知コストが削減されます。ユーザー名を使用する代わりに、ユーザーは Nostr 上でお互いを見つけるために公開キーまたは DNS を送信する必要があります。 **他の Nostr アプリケーションが異なる公開キーを使用している場合でも、同じ分散 ID (DID) にアタッチできます。これにより、アカウントの識別方法がアプリケーション間で一貫したままになります。ただし、この Nostr コンセンサス ルールでは、各 Nostr アプリケーションのプロファイルごとに公開キーの使用が 1 つだけ制限されます。DHT はピア発見のリーダーボードとして機能します。Relay は、分散ハッシュ テーブル (DHT) を使用して他の Relay を検索できます。リレーは、データが保存されている公開キーをリストすることで、分散ハッシュ テーブル内のホワイトリストを共有できます。このようにして、特定の公開キーのデータのフォークが欠落しているリレーは DHT をスキャンし、それらの欠落しているフォークを保存していると主張する他のリレーの IP アドレスに直接接続できます。その後、リレーはこれらの Nostr リレーから不足しているブランチを直接ダウンロードできます。リレーは、最近およびすべての時点で、それらのリレーがオンチェーンで解決した過去の ZKCSP トランザクションの数を確認することで、最もアクティブなリレーを見つけることもできます。このシステムでは、すべての Nostr リレーがフル ノードになるため、他のリレーの以前のトランザクションを簡単に監査できます。オンチェーン取引には常に取引手数料が必要となるため、これにより信頼の構築にコストがかかることになります。 Nostr リレーが他のリレーの信頼を得るために多くのチャネルを開き、自身との信頼を構築すると、偽の評判を維持するために毎週多額の取引手数料を支払わなければなりません。攻撃者が不足しているブランチの提供に失敗すると、タイムアウトによってリレーが切断されます。したがって、これは一時的でコストのかかる攻撃にすぎません (51% 攻撃が一時的でコストのかかる攻撃であるのと同様です)。各 Nostr リレーの公開キーが DHT 内の IP アドレスの隣にリストされるため、DHT はマイニングほど匿名ではありませんが、十分な規模で、リレーがネットワーク全体にリクエストを盲目的に送信する必要がなくなります。ネットワークに過負荷がかかります。プライバシーをさらに強化したい Nostr 中継者は、VPN またはその他の IP 保護サービスを使用できます。ユーザーは完全なノードではないため、この同じ信頼システムにアクセスできません。ただし、ユーザーはそれを信頼できます。### **愛好家は何百もの Nostr リレーに間接的に接続されています**ユーザーはすべてのブロックヘッダーをライトウォレットに自動的に保存するため、ユーザーは最もアクティブなマイナーが誰であるかを確認できます。マイナーが資金提供者になることで、ユーザーは最も人気のあるマイナーをフィルタリングして除外できるため、ネットワークの存続可能性と相関関係のないランダムな資金提供者に盲目的に資金を結び付ける必要がなくなります。**金融業者 (マイナー) は、ユーザーとリレーの間でデータ自体を渡すことなく、Nostr リレーで自分の衛星をロックするだけで済みます。 **金融業者 (マイナー) は、ユーザーが金融業者が接続されているすべての Nostr リレーと直接対話できるように、ユーザーのリクエストに署名するだけで済みます。ZKCSP + Lightning の場合は上記の 4 ステップです。＃＃＃ **結論は**ユーザーにはオフチェーントランザクションのバンドルされた証明を保存する場所がないため、ライトニングネットワークはビットコインのナカモトコンセンサスブロックチェーンなしでは存在しませんでした。ユーザーがこれらすべての Lightning Network トランザクションをまとめて小さなプルーフをブロックチェーンに入れるのと同じように、私たちはすべての Nostr データをバンドルして小さなプルーフをブロックチェーンに入れます。ライトニング ネットワークが第 2 層で即時決済を提供するのと同じように、Nostr は安全でないサイドチェーンのリスクを負うことなく、第 2 層でデータ ストレージを提供できる可能性があります。 ****ライトニングネットワークと同じアプローチを使用しており、最初のレイヤーにビットコインのナカモトコンセンサスブロックチェーン、2番目のレイヤーにNostr+ZKCSPライトニングを使用します。 **
Nostr2.0: ビットコインレイヤー2チェーンの下のデータストレージレイヤーとして
著者: Colby Serpa コンパイラ: DAOrayaki
Nostr 2.0 は、ライトニング ネットワークがレイヤー 2 として即時オフチェーン支払いを提供するのと同じように、ビットコインの上にレイヤー 2 として構築し、安全なオフチェーン データ ストレージを提供できる可能性があります。
この記事では、Nostr リレーがその軽量性を維持しながらデータを同期し、ユーザーがレイヤー 1 ブロックチェーンでは利用できないデータを選択的に削除できるようにする方法について説明します。同時に、ビットコイン ブロックの容量と速度には限界があるため、ビットコイン ブロックチェーンに大量のデータを保存する場合と比較して、Nostr リレーを使用してデータを保存する方がコストが安くなる可能性があります。
次の単純なコンピューター サイエンス設計により、標準化された CAP 定理基準の下で Nostr ネットワークの分散特性が向上します。 CAP は、一貫性、可用性、およびパーティション許容度の略です
**Nostr リレーは、設定ファイルが不完全であることを認識せず、リレーに一貫性が欠けています (CAP 定理の C)。 **
リレーに一貫性がありません (CAP 定理の C)
一貫性とは、各コンピュータ上で同期されたデータベースが同じであることを意味します。 Nostr リレーは、ブロックチェーンがブロックごとにデータを同期する方法と同様の方法で、信頼を最小限に抑えた同期を実行できません。ビットコインのフルノードとは異なり、Nostr リレーによって保存されるデータベースは通常不完全です。特定のユーザーが署名したすべての投稿を盲目的に要求することを除けば、Nostr リレーは欠落しているデータを検出できません。
Nostr の一貫性/同期の問題:
2 人のユーザーがそれぞれの投稿を異なる Nostr リレーにアップロードした場合、Nostr はブロックチェーンのようなものではないため、これら 2 人のユーザーはお互いの投稿を見ることができない場合があります。ブロックチェーンでは、新しいレコードが存在するたびに、すべてのフルノードがブロックチェーンを同期します。すべてのフルノードは、このデータをブロックとしてブロックチェーンに同時に追加します。ビットコイン ブロックチェーン上のすべての完全なノードは、まったく同じブロックチェーンを所有します。
Nostr ユーザーが常にお互いの投稿を閲覧できるようにしたい場合は、すべての Nostr リレーがユーザー プロファイル内の欠落データを特定して、他の Nostr リレーまたはユーザーに欠落部分をリクエストできるようにする方法が必要です。
週次のオンチェーン マークル ルートおよび完全なツリー ハッシュを使用して Nostr リレーを同期する
マークル ルート ハッシュとツリー全体のハッシュは、次の 2 つの重要な機能を提供します。
この安価な方法を使用すると、構成ファイル全体を毎週またはユーザー定義の頻度で更新できます。 Nostr は現在と同様に機能しますが、ユーザーが自分の投稿をすべてのユーザーに見てもらいたい場合は、時折、料金を払って Nostr リレー間でデータを同期することができます。
ユーザーと中継者は、一度に 1 つのブランチの投稿をダウンロードできます。各ブランチの後、そのブランチをマークル ルートに最も近い別のブランチでハッシュし、それがチェーン上のマークル ルートと一致するかどうかを確認します (SPV と同様)。これらのブランチをハッシュしてマークル ルートと一致させると、完全なユーザー プロファイルをまだ持っていない場合でも、そのブランチがユーザー プロファイルの一部であることがわかります。ユーザーは、各ブランチの有効性を検証し、ダウンロードされた設定ファイルが完全であることを確認しながら、多くの異なる Nostr トランクから同じ設定ファイルの異なるブランチをダウンロードできます。
フォークを 1 つずつダウンロードすることで、多くの分散ネットワークをダウンさせる可能性のある遅延攻撃を防ぐことができます。これが、SPV ライト ウォレットを保護するためにビットコイン ホワイト ペーパーでマークル ルートとフォークが使用されている理由です。
**マークルルートがツリー全体のハッシュのように機能できないのはなぜですか? **
** Nostr リレーがマークル ルートのみに依存する場合、マークル ルートに最も近いブランチのペアがすべて同じマークル ルートにハッシュされるため、マークル ツリーがいつ完成するかを知ることができません。 **
ユーザーのプロファイルが完全であることを確認するために、中継者またはユーザーは更新されたマークル ツリー全体をハッシュし、それがオンチェーンのツリー ハッシュ全体と一致することを確認します。ツリー全体のハッシュが一致すると、ユーザー データが完成します。ツリー全体のハッシュが一致しない場合、リレーまたはユーザーは他のリレーに最新のリーフ番号を伝え、ツリー全体のハッシュが一致するまで欠落しているブランチを要求できます。毎週のように追加されるすべての新しいマークル ルートを追跡するには、Nostr リレーがビットコインのフル ノードになる必要があります。 Nostr 2.0 リレーは、ビットコインと Nostr のセキュリティを強化しながら、ビットコイン ブロックチェーンを保存するために間接的に支払われます。
Nostr ストレージの制限: ユーザーの経験則
ビットコインのフルノードとは異なり、リレーラーには何を保存するかを選択する権利があるため、Nostr リレーでは一部のユーザー データが失われる可能性があります。したがって、ローカルでバックアップを作成できる場合、ユーザーは Nostr リレーにのみデータを保存する必要があります。 Web5 のセルフホステッド サービスを使用すると、ユーザーはバックアップをすべてのローカル デバイスに同期できるため、Nostr の使用を懸念するユーザーのリスクが軽減されます。結局のところ、データが真に不変であるのはブロックチェーンだけです。とはいえ、Nostr はかなり安全なハイブリッド ソリューションであり、多くのアプリケーションで引き続きうまく機能します。トレードオフは以下のとおりです。
信頼最小化の 3 層
ナカモトのコンセンサスベースのブロックチェーンと Nostr の間の基本的なトレードオフ
**特定のアドレスのデータを保存する Nostr リレーが増えるほど、そのデータを検閲することが難しくなります。これは、多くの Nostr リレーがホストする人気のあるデータは、めったにダウンロードされない人気のないデータよりも検閲が難しい可能性があることを意味します。 **
**一方、ナカモトコンセンサスブロックチェーンは、データの古さに基づく検閲を防ぎます。ブロックチェーン内に存在するデータが長くなるほど、51% 攻撃を使用してデータを削除することが難しくなります。 **
特定のフォークが特定のユーザーに属していることを確認できるため、Nostr リレーはユーザーに小さなデータを配信するたびに料金を支払うことができます。これを実現するには、ユーザーはブロックチェーンのヘッド (SPV など) をダウンロードして、ライト ウォレットの典型的な機能を実行できるようにする必要があります。ユーザーは、ライト ウォレットの SPV 機能を利用して、チェーンから特定のトランザクションをフェッチします。これには、ユーザー プロファイルのマークル ルートとツリー ハッシュ全体が OP_RETURN に含まれます。ユーザーはリレーに料金を支払い、そのユーザーのプロファイルをブランチごとにダウンロードし、オンチェーンのマークル ルートと一致するようにハッシュすることで各ブランチを検証できるようになりました。
データの提供と引き換えにsats（ビットコインの最小単位）をNostrリレーに送信するために、Gregory Maxwell（有名なビットコインコア開発者）のZKCP設計（ゼロ知識条件付き支払い）を使用します。 [1] ZKCSP の進化版: 取得可能性の証明 [2] ライトニングネットワークと組み合わせます。
ZKCSP ホワイトペーパーの説明によれば、次のようになります。
「...信頼できるサードパーティは必要ありません...また、クライアントのデータがサーバーに正しく保存されたことを証明するために、クライアントがサーバーに料金を支払う、取得可能性の証明の場合に ZKCSP プロトコルを実装しました。」 [2]
ステップ 3 が発生すると、ユーザーはステップ 4 で ZKCSP の構築を開始する前に、金融業者が署名した元のリクエストに加えて修正を加えます。ユーザーは元のリクエストに追加額を追加し、ユーザーと金融業者の両方の残高から差し引く金額を指定します (これらの金額は同じ金額に金融業者の手数料を加えたものである必要があります)。その後、ユーザーはその金額を元のメッセージに追加します。署名する内容。
**ユーザーが所有する衛星よりも多くの衛星を送信するように指定した場合、または Nostr リレーで資金提供者が凍結した以上の衛星を送信するように指定した場合、Nostr リレーは支払いを受け取ることができないため、要求を拒否します。 **
このようにして、ユーザーは少数の資金提供者だけで資金を凍結しながら、多くの Nostr リレーに接続することができます。同様のアプローチは、信頼を最小限に抑えた金融業者がユーザーと販売者の間で許可のない仲介者となるライトニング ネットワークでも採用できます。通常の P2P ライトニング ジャンプも Nostr 2.0 で利用できますが、これはルーティングとチャネル バランシングが頻繁に失敗する場合に役立つ可能性があります。
ホワイトリストによる有料 Nostr リレーのロック解除
Nostr リレーは、これらすべてのユーザーが閲覧するデータを保存したい場合、特定のキーをホワイトリストに登録できます。 Nostr リレーがデータの保存を希望するユーザーをホワイトリストに登録できない場合、Nostr リレーは送信されたデータをすべて保存します。ユーザーがいつでも無料でリレーにデータを送信できれば、ユーザーは Nostr リレーの料金を支払う必要がなくなります。 Nostr は、中継者が料金を支払えないデータの保存を拒否するオプションを持っている場合にのみ、有料オプションを提供できます。無料のリレーはまだ存在しますが、有料のリレーのオプションは現在存在しません。
すべての Nostr データを無料で保存しようとする代わりに、有料の Nostr リレーはホワイトリストを使用して、有料ユーザーが毎日閲覧するすべてのデータを選択的に保存できます。一部の Nostr リレーは引き続き無料モデルで動作しますが、大規模な場合、ほとんどの無料リレーは単なる熱狂的な愛好家であるため、これは持続可能ではありません。 Nostr リレーにどのデータを保存するかを決定する機能を与えるホワイトリスト化 (各 Nostr プロファイルに公開キーを安全に割り当てることができたとしても) は不可能です。
プロファイルごとに 1 つの公開キーがホワイトリスト機能のロックを解除します。ビットコイン アドレスが Nostr 公開キーになります。
このシステムにより、最終的に各設定ファイルに公開キーを割り当てることができます。
投稿ごとに新しい公開キーを作成するユーザーには何のメリットもありません...公開キーはすべて自分のプロフィールに関連付けられているためです。これはビットコインアドレスとは異なります。ビットコインとは異なり、ユーザーが同じアプリケーション内で複数の公開鍵を持っていてもプライバシーは向上しません。
**Nostr プロファイルの公開キーは、毎週のハッシュ (すべてのユーザーの投稿のマークル ルートおよびツリー ハッシュ全体) を含むビットコイン トランザクションの公開キーと一致する必要があります。 Schnorr 署名を使用する Nostr ユーザーとは異なり、署名にはビットコイン ウォレット (モバイル ウォレット/ライト ウォレットまたはフル ノード) を使用する必要があります。 **
この利点は、各 Nostr アカウントがビットコイン アドレス** で表されることです。つまり、ユーザーは 2 つの異なる公開キーを要求せずに、Nostr アカウントに直接支払いを送金できることになります。これにより、システム内の新規ユーザーの認知コストが削減されます。ユーザー名を使用する代わりに、ユーザーは Nostr 上でお互いを見つけるために公開キーまたは DNS を送信する必要があります。 **
他の Nostr アプリケーションが異なる公開キーを使用している場合でも、同じ分散 ID (DID) にアタッチできます。これにより、アカウントの識別方法がアプリケーション間で一貫したままになります。ただし、この Nostr コンセンサス ルールでは、各 Nostr アプリケーションのプロファイルごとに公開キーの使用が 1 つだけ制限されます。
DHT はピア発見のリーダーボードとして機能します。
Relay は、分散ハッシュ テーブル (DHT) を使用して他の Relay を検索できます。リレーは、データが保存されている公開キーをリストすることで、分散ハッシュ テーブル内のホワイトリストを共有できます。このようにして、特定の公開キーのデータのフォークが欠落しているリレーは DHT をスキャンし、それらの欠落しているフォークを保存していると主張する他のリレーの IP アドレスに直接接続できます。その後、リレーはこれらの Nostr リレーから不足しているブランチを直接ダウンロードできます。
リレーは、最近およびすべての時点で、それらのリレーがオンチェーンで解決した過去の ZKCSP トランザクションの数を確認することで、最もアクティブなリレーを見つけることもできます。このシステムでは、すべての Nostr リレーがフル ノードになるため、他のリレーの以前のトランザクションを簡単に監査できます。オンチェーン取引には常に取引手数料が必要となるため、これにより信頼の構築にコストがかかることになります。 Nostr リレーが他のリレーの信頼を得るために多くのチャネルを開き、自身との信頼を構築すると、偽の評判を維持するために毎週多額の取引手数料を支払わなければなりません。攻撃者が不足しているブランチの提供に失敗すると、タイムアウトによってリレーが切断されます。したがって、これは一時的でコストのかかる攻撃にすぎません (51% 攻撃が一時的でコストのかかる攻撃であるのと同様です)。
各 Nostr リレーの公開キーが DHT 内の IP アドレスの隣にリストされるため、DHT はマイニングほど匿名ではありませんが、十分な規模で、リレーがネットワーク全体にリクエストを盲目的に送信する必要がなくなります。ネットワークに過負荷がかかります。プライバシーをさらに強化したい Nostr 中継者は、VPN またはその他の IP 保護サービスを使用できます。
ユーザーは完全なノードではないため、この同じ信頼システムにアクセスできません。ただし、ユーザーはそれを信頼できます。
愛好家は何百もの Nostr リレーに間接的に接続されています
ユーザーはすべてのブロックヘッダーをライトウォレットに自動的に保存するため、ユーザーは最もアクティブなマイナーが誰であるかを確認できます。マイナーが資金提供者になることで、ユーザーは最も人気のあるマイナーをフィルタリングして除外できるため、ネットワークの存続可能性と相関関係のないランダムな資金提供者に盲目的に資金を結び付ける必要がなくなります。
**金融業者 (マイナー) は、ユーザーとリレーの間でデータ自体を渡すことなく、Nostr リレーで自分の衛星をロックするだけで済みます。 **金融業者 (マイナー) は、ユーザーが金融業者が接続されているすべての Nostr リレーと直接対話できるように、ユーザーのリクエストに署名するだけで済みます。ZKCSP + Lightning の場合は上記の 4 ステップです。
＃＃＃ 結論は
ユーザーにはオフチェーントランザクションのバンドルされた証明を保存する場所がないため、ライトニングネットワークはビットコインのナカモトコンセンサスブロックチェーンなしでは存在しませんでした。
ユーザーがこれらすべての Lightning Network トランザクションをまとめて小さなプルーフをブロックチェーンに入れるのと同じように、私たちはすべての Nostr データをバンドルして小さなプルーフをブロックチェーンに入れます。ライトニング ネットワークが第 2 層で即時決済を提供するのと同じように、Nostr は安全でないサイドチェーンのリスクを負うことなく、第 2 層でデータ ストレージを提供できる可能性があります。 **
**ライトニングネットワークと同じアプローチを使用しており、最初のレイヤーにビットコインのナカモトコンセンサスブロックチェーン、2番目のレイヤーにNostr+ZKCSPライトニングを使用します。 **