generated at
Nostr 2.0: Layer 2 Off-Chain Data Storage. Syncing Nostr Relays and Paying them to Become Full-Nodes.
ちょうどこの前Social Media is broken.を見て、仕組みについて調べたいと思ってたからタイミング神Yudai

Abstract
>Nostrは、同期データベースや台帳としてレイヤー1のブロックチェーンを置き換えることはできないだろう。しかし、Nostr 2.0のリレーを同期させるためにレイヤー1のビットコインブロックチェーンを使うことはできる。
> Nostr 2.0は、Lightningがビットコインのレイヤー2としてインスタントなオフチェーン決済を提供するのと同様に、ビットコインのレイヤー2として安全なオフチェーンデータストレージを提供できるかもしれない。
これまさしくMonasでやろうとしていることに近いのかも?

Consistency(一貫性)
Availability(可用性)
Partition tolence(分割耐性)
>Nostrリレーはプロファイルが不完全であることを知らない。リレーには一貫性(CAP定理のC)が欠けている。
> 一貫性とは、さまざまなコンピュータ間で同期されるデータベースが同一であることを意味する。
ちょうどこんな話してたからなんとなくイメージ付くYudai
>だからそこのリレーにないデータはないから色んなリレーと接続しなくちゃいけない
> リレーに接続できるようにして外部からそこにあるデータなら取得できるようにできるんやと思う
「特定のユーザーの署名によって署名されたすべての投稿をやみくもに要求する以外に、どのようなデータが欠けているかを発見する手段を持っていない。
Monasはこれを解決できる可能性があるかも
一貫性/同期の問題
>2人のユーザーがそれぞれの投稿を別々のNostrリレーにアップロードした場合、Nostrはブロックチェーンとは違うので、2人のユーザーはお互いの投稿を見ることができないかもしれない。ブロックチェーンでは、新しいエントリーがあるたびに、すべてのフルノードがブロックチェーンを同期させる。すべてのフルノードは、ブロックという形で、そのデータをブロックチェーンに一斉に追加する。ビットコインのブロックチェーン上のすべてのフルノードは、まったく同じブロックチェーンを持っています。
=> ユーザーが常に互いの投稿を見ることが出来るようにするには、どのようなデータが書けているのかを特定する方法が必要になる。


「Nostrリレーと週次オンチェーンMerkleルートと全ツリーハッシュを同期する。」
週に一度程度、自分の投稿を全てMerkle Treeにまとめられる
Merle treeの各Leafにはトランザクションのハッシュが含まれるように、投稿のハッシュが含まれる
通常のBitcoin取引の下にある OP_RETURN でMerkle Rootをオンチェーンに投稿する
ユーザーはツリー全体のハッシュを取り、Merkle Rootと共にオンチェーンにアップロードする
Tree全体のハッシュを得るには単純にMerkleのルートをテキストファイルの先頭に置く。次に枝をルートの下の行に置く。枝の下に葉を置く。全てをハッシュする。
読んでて思うのが全体の状態(動的)はどこかしらで管理する必要があり、ブロックチェーンは一番適しているYudai
それとハッシュってまじで凄い

Merkle RootとWhole tree hashは2つの機能を可能にする
Block全体をダウンロードせずにトランザクションをダウンロードできる
全ツリーハッシュは保存しているプロファイルが不完全であることをユーザーとリレーに知らせる。
(最新hash ) -(現在持っているhash) = 同じかどうかで分かるYudai
同じ = 完全
これってzkScoreの時も似た構図があった
個人スコアのRoot hashをオンチェーン上に書き込む
SBTにより瞬間的な状態(現在持っているhash)を保存していた。
膨らませると検証者は最新かどうかを検証することができるってこと
最新(Time stamp的に)かどうかを検証する

信頼最小化の3つのレイヤー
レイヤー1では検閲が非常に難しい、不変かつ高価なデーったストレージ
検閲が中程度に困難なレイヤー2上の不変で安価なデータストレージ
検閲が容易なローカルデバイス間んで同期されたローカルデータストレージ
Nakamoto Consensus blockchainとNostrのトレードオフ
>特定のアドレスのデータを保存するNostrリレーが多ければ多いほど、そのデータを検閲するのは難しくなる。つまり、多くのNostrリレーによってホストされている人気データは、めったにダウンロードされない不人気データよりも検閲が難しい可能性があるということだ。
> 一方、Nakamoto Consensusブロックチェーンは、データの年齢による検閲を防ぐことができる。データがブロックチェーンに存在する時間が長ければ長いほど、51%攻撃で削除するのが難しくなる。

Filecoinの文脈で出てきた言葉だYudai
>..信頼できるサードパーティを必要としない...我々はまた、クライアントのデータがサーバによって正しく保存されていることの証明を提供するためにクライアントがサーバに支払う、Proof of RetrievabilityのケースのためのZKCSPプロトコルを実装している"

Peer Discovery Landerboard as DHT
リレーは分散ハッシュテーブルを使用して他のリレーを見つけることができる
分散型ハッシュテーブル内でどの公開鍵のデータを保存しているかをリストアップする事でホワイトリストを共有できる。
こうすることである公開鍵のデータのブランチが見つからないリレーはDHTをスキャンし、見つからないブランチを保存していると主張する他のIPアドレスに直接接続できる
これ、めっちゃIPFSCID(Block)を探す構図に似ているYudai
なんかどこも重要な機能は同じなんだ

>ユーザーがLightningのトランザクションをすべて束ね、ブロックチェーンに小さな証明を置くのと同じように、私たちはNostrのデータをすべて束ね、ブロックチェーンに小さな証明を置くつもりです。Lightningがレイヤー2で行っているような即時決済を提供する代わりに、怪しいサイドチェーンのような恐ろしいセキュリティリスクなしに、レイヤー2でデータストレージを提供することができるかもしれない。
Intmaxもこの構図よねYudai
それを見た時にMonasも出来ると思った