Nostr2.0: ビットコインレイヤー2チェーンの下のデータストレージレイヤーとして

DAOrayaki

特邀专栏作者

2023-06-22 10:30

この記事は約4721文字で、全文を読むには約7分かかります

この記事では、Nostr リレーが軽量機能を維持しながらデータを同期し、ユーザーがレイヤー 1 ブロックチェーンでは利用できないデータを選択的に削除できるようにする方法について説明

原作者: コルビー・セルパ

オリジナルコンピレーション：DAOrayaki

画像の説明

この記事では、Nostr リレーがその軽量性を維持しながらデータを同期し、ユーザーがレイヤー 1 ブロックチェーンでは利用できないデータを選択的に削除できるようにする方法について説明します。同時に、ビットコインブロックの容量と速度には限界があるため、ビットコインブロックチェーンに大量のデータを保存する場合と比較して、Nostr リレーを使用してデータを保存する方がコストが安くなる可能性があります。

次の単純なコンピューターサイエンス設計により、標準化された CAP 定理基準の下で Nostr ネットワークの分散特性が向上します。 CAP は、一貫性、可用性、およびパーティション許容度の略です

Nostr リレーは設定ファイルが不完全であることを認識せず、リレーには一貫性がありません (CAP 定理の C)

一貫性とは、各コンピュータ上で同期されたデータベースが同じであることを意味します。 Nostr リレーは、ブロックチェーンがブロックごとにデータを同期する方法と同様の方法で、信頼を最小限に抑えた同期を実行できません。ビットコインのフルノードとは異なり、Nostr リレーによって保存されるデータベースは通常不完全です。特定のユーザーが署名したすべての投稿を盲目的に要求することを除けば、Nostr リレーは欠落しているデータを検出できません。

ビットコインの各リーフにトランザクションのハッシュが含まれるのと同様に、マークルツリーの各リーフには投稿のハッシュが含まれます。

2 人のユーザーがそれぞれの投稿を異なる Nostr リレーにアップロードした場合、Nostr はブロックチェーンのようなものではないため、これら 2 人のユーザーはお互いの投稿を見ることができない場合があります。ブロックチェーンでは、新しいレコードが存在するたびに、すべてのフルノードがブロックチェーンを同期します。すべてのフルノードは、このデータをブロックとしてブロックチェーンに同時に追加します。ビットコインブロックチェーン上のすべての完全なノードは、まったく同じブロックチェーンを所有します。

Nostr ユーザーが常にお互いの投稿を閲覧できるようにしたい場合は、すべての Nostr リレーがユーザープロファイル内の欠落データを特定して、他の Nostr リレーまたはユーザーに欠落部分をリクエストできるようにする方法が必要です。

Nostr リレーを毎週のオンチェーンマークルルートおよび完全なツリーハッシュと同期します

週に 1 回程度、ユーザーはすべての投稿をマークルツリーに整理できます。
ビットコインの各リーフにトランザクションのハッシュが含まれるのと同様に、マークルツリーの各リーフには投稿のハッシュが含まれます。
Nostr リレーがマークルルートのみに依存している場合、マークルルートに最も近いブランチのペアはすべて同じマークルルートにハッシュされるため、マークルツリーがいつ完成するかを知る方法がありません。
さらに、ユーザーはツリー全体をハッシュし、マークルルートとともにチェーン ( OP_RETURN 内) にアップロードします。マークルルートは、ツリー全体ではなく、最上位のブランチのハッシュにすぎません。ツリー全体のハッシュは、ユーザーと中継者がプロファイルデータが欠落しているかどうかを検出できるようにするために不可欠です。

ツリー全体のハッシュを取得するには、テキストファイルのルートにマークルルートを配置します。次に、マークルの枝をルートの下の線に配置します。次に、マークルの葉を枝の下の列に置きます。ツリーが説明どおりに配置されたら、すべてを一度にハッシュします。以下は、上に示したマークルツリーのツリー全体のハッシュがどのようになるかを示す、ツリー全体のハッシュの例です。ツリー全体のハッシュ (すべてのマークルツリーデータを一度にハッシュ)

マークルルートハッシュとツリー全体のハッシュは、次の 2 つの重要な機能を提供します。

Merkle ルートを使用すると、ユーザーと中継者は、ブロック全体をダウンロードしなくてもトランザクションをダウンロードできるなど、構成ファイルの一部を一度にダウンロードできます。
ツリー全体のハッシュにより、ユーザーと中継者は、保存されている設定ファイルが不完全かどうかを知ることができます。マークルルートとは異なり、マークルツリー内のすべてのビットがある場合にのみ、ツリー全体のハッシュが一致します。

この安価な方法を使用すると、構成ファイル全体を毎週またはユーザー定義の頻度で更新できます。 Nostr は現在と同様に機能しますが、ユーザーが自分の投稿をすべてのユーザーに見てもらいたい場合は、時折、料金を払って Nostr リレー間でデータを同期することができます。

ユーザーと中継者は、一度に 1 つのブランチの投稿をダウンロードできます。各ブランチの後、そのブランチをマークルルートに最も近い別のブランチでハッシュし、それがチェーン上のマークルルートと一致するかどうかを確認します (SPV と同様)。これらのブランチをハッシュしてマークルルートと一致させると、完全なユーザープロファイルをまだ持っていない場合でも、そのブランチがユーザープロファイルの一部であることがわかります。ユーザーは、各ブランチの有効性を検証し、ダウンロードされた設定ファイルが完全であることを確認しながら、多くの異なる Nostr トランクから同じ設定ファイルの異なるブランチをダウンロードできます。

フォークを 1 つずつダウンロードすることで、多くの分散ネットワークをダウンさせる可能性のある遅延攻撃を防ぐことができます。これが、SPV ライトウォレットを保護するためにビットコインホワイトペーパーでマークルルートとフォークが使用されている理由です。

なぜマークルルートはツリー全体のハッシュのように機能できないのでしょうか?

Nostr リレーがマークルルートのみに依存している場合、マークルルートに最も近いブランチのペアはすべて同じマークルルートにハッシュされるため、マークルツリーがいつ完成するかを知る方法がありません。

Nostr ストレージ制限: ユーザーの経験則

信頼の最小化の 3 つの層

ユーザーが所有する衛星よりも多くの衛星を送信するように指定した場合、または金融業者がその Nostr リレーで凍結した以上の衛星を送信するように指定した場合、Nostr リレーは支払いを受け取ることができないため、要求を拒否します。
レイヤー 2: 変更可能で安価なデータストレージ、中程度に困難な検閲。 (オフチェーンマークルツリーとオンチェーンハッシュ、同期 Nostr リレーオンデマンド)
ローカルデータストレージはすべてのローカルデバイスと同期され、簡単に監査できます。 (ローカル集中化)

ナカモトコンセンサスとNostrに基づくブロックチェーン間の基本的なトレードオフ

特定のアドレスのデータを保存する Nostr リレーが増えるほど、そのデータを検閲することが難しくなります。これは、多くの Nostr リレーがホストする人気のあるデータは、めったにダウンロードされない人気のないデータよりも検閲が難しい可能性があることを意味します。

一方、ナカモトコンセンサスブロックチェーンは、データの古さに基づく検閲を防ぎます。ブロックチェーン内に存在するデータが長くなるほど、51% 攻撃を使用してデータを削除することが難しくなります。

取得可能性の証明を使用した ZKCSP とライトニングネットワーク支払い Nostr リレー

特定のフォークが特定のユーザーに属していることを確認できるため、Nostr リレーはユーザーに小さなデータを渡すたびに料金を支払うことができます。これを実現するには、ユーザーはブロックチェーンのヘッド (SPV など) をダウンロードして、ライトウォレットの典型的な機能を実行できるようにする必要があります。ユーザーは、ライトウォレットの SPV 機能を利用して、チェーンから特定のトランザクションをフェッチします。これには、ユーザープロファイルのマークルルートとツリーハッシュ全体が OP_RETURN に含まれます。ユーザーはリレーに料金を支払い、そのユーザーのプロファイルをブランチごとにダウンロードし、オンチェーンのマークルルートと一致するようにハッシュすることで各ブランチを検証できるようになりました。

データを提供する代わりに、sat (ビットコインの最小単位) を Nostr リレーに送信するために、Gregory Maxwell (有名なビットコインコア開発者) の ZKCP 設計 (ゼロ知識条件付き支払い) [1] の進化版を使用します。 ZKCSP : ライトニングネットワークと組み合わせた取得可能性の証明 [2]。

ZKCSP ホワイトペーパーの説明によれば、次のようになります。

「…信頼できるサードパーティは必要ありません…また、クライアントのデータがサーバーに正しく保存されていることを証明するために、クライアントがサーバーに料金を支払う、取得可能性の証明の場合に ZKCSP プロトコルを実装しました。」 [2]

ユーザーが複数の金融業者と Lightning スマートコントラクトを開始します。
ユーザーは周囲の金融業者にリクエストを送信します。金融業者はリクエストに署名します。
ユーザーは、金融業者が署名したリクエストを、それらの金融業者に接続されている Nostr リレーに直接送信します。
ユーザーは ZKCSP 構造を開始して、正しく要求されたデータが配信された後にのみ Nostr リレーが金融業者から支払いを受けるようにするようになりました。

ステップ 3 が発生すると、ユーザーはステップ 4 で ZKCSP の構築を開始する前に、金融業者が署名した元のリクエストに加えて修正を加えます。ユーザーは元のリクエストに追加額を追加し、ユーザーと金融業者の両方の残高から差し引く金額を指定します (これらの金額は同じ金額に金融業者の手数料を加えたものである必要があります)。その後、ユーザーはその金額を元のメッセージに追加します。署名する内容。

ユーザーが所有する衛星よりも多くの衛星を送信するように指定した場合、または金融業者がその Nostr リレーで凍結した以上の衛星を送信するように指定した場合、Nostr リレーは支払いを受け取ることができないため、要求を拒否します。

DHT は、ピア発見のリーダーボードとして機能します。

ホワイトリストによる有料 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リレーに間接的に接続されています

ユーザーは完全なノードではないため、この同じ信頼システムにアクセスできません。ただし、ユーザーはそれを信頼できます。

金融業者は何百ものNostrリレーに間接的に接続されています

ユーザーはすべてのブロックヘッダーをライトウォレットに自動的に保存するため、ユーザーは最もアクティブなマイナーが誰であるかを確認できます。マイナーが資金提供者になることで、ユーザーは最も人気のあるマイナーをフィルタリングして除外できるため、ネットワークの存続可能性と相関関係のないランダムな資金提供者に盲目的に資金を結び付ける必要がなくなります。

結論は

ユーザーはオフチェーントランザクションのバンドルされた証明を保存する場所がないため、ライトニングネットワークはビットコインのナカモトコンセンサスブロックチェーンなしでは存在しませんでした。

ユーザーがこれらすべての Lightning Network トランザクションをまとめて小さなプルーフをブロックチェーンに入れるのと同じように、私たちはすべての Nostr データをバンドルして小さなプルーフをブロックチェーンに入れます。ライトニングネットワークが第 2 層で即時決済を提供するのと同じように、Nostr は安全でないサイドチェーンのリスクを負うことなく、第 2 層でデータストレージを提供できる可能性があります。

ライトニングネットワークと同じアプローチを使用しており、最初のレイヤーにはビットコインのナカモトコンセンサスブロックチェーン、2番目のレイヤーにはNostr+ZKCSPライトニングが使用されます。