
2025/12/11 8:54
Nature's many attempts to evolve a Nostr
RSS: https://news.ycombinator.com/rss
要約▶
Japanese Translation:
要約
人気のあるアプリケーションの普遍的な設計は、ユーザーのデータと暗号鍵を所有する単一クラウドサーバーに集中しています(「あなたの鍵がないなら、あなたのデータではない」)。この中央集権化は封建制や寡占構造を生み出します。サーバーは橋を上げてユーザーを切り離す城のような存在です。フェデレーション(例:Mastodon、Matrix)はサーバー間で通信できるようにしますが、鍵とデータは依然としてサーバーの管理下にあり、ネットワーク理論はそのようなフェデレートシステムがスケールフリー分布へ収束し、支配的なハブを生み出すと予測しています。これはGmail/ProtonMail のメール寡占や Facebook Threads の ActivityPub ノードが Fediverse を支配する現象として観察されています。
セルフホスティングは居住IPの禁止やインフラコストにより多くのユーザーが個人サーバーから離れるため、非実用的になります。ピアツーピアネットワークはユーザー所有鍵を提供しますが、拡張性、信頼できないノード、スーパーpeer の中央集権化、複雑な最終的一致メカニズム、および長い多ホップルーティング遅延に悩まされます。
Nostr プロトコルは「リレーモデル」を提案します。単純で信頼できないリレーは署名されたメッセージを転送するだけで、相互通信しません。これにより (N^2) スケーリング問題を回避します。ユーザーは数個(通常 2–10)のリレーユーザーに購読し、自分のデータと鍵を完全に制御でき、リレーが失敗または停止した場合でも信頼性高く離脱できます。広く採用されれば、これはユーザーに真の所有権と単一点障害への耐久性を与え、中央集権サーバーに依存する企業に対し、よりユーザー中心で分散型アーキテクチャとの競争を強いるでしょう。これにより、ソーシャルメディアやメッセージングは真の分散モデルへと再構築される可能性があります。
本文
以下は、典型的なアプリケーションの構成図です。
クラウド上に大規模で集中化されたサーバーがあり、多数のクライアントを支援しています。
ウェブもこのように動作し、アプリも同様です。
この構造はサーバーにユーザーを完全にコントロールさせます。
サーバーはあなたのデータ、アカウント、そしてそれを保護する暗号鍵まで所有します。
後者はあまり見落とされがちですが重要です――暗号鍵こそがソフトウェアにおけるセキュリティ・プライバシー・所有権・制御を実現するものです。「自分の鍵ではない、データも同様」
アプリの構造は根本的に封建制です。
- アプリが暗号鍵を所有し、その鍵で私たちが生成したデータの山を囲む暗号壁を作ります。
- 「ログイン」をすると引き橋を渡ることができますが、城側がいつでも引き橋を上げてあなたを追い出すことができるのです。
「集中化」とは、一つまたは少数の主体がインターネット機能を独占的に観測・取得・制御・収益化できる状態(RFC 9518)を指します。
強力なネットワーク効果はその壁内で発展し、さらに集中化やレンタル抽出、競争の排除に利用されます。
今日もアプリストアなどのプラットフォームが成熟段階に入り、成長が鈍ると大きな城の王たちは悪い皇帝へと転身します。
インターネットは一つの支配主体を避けたことで成功しました(RFC 9518)。
したがってアプリは集中化しています――どうすれば修正できるでしょうか?
最初に必要なのはアプリ間のギャップを埋める「フェデレーション」です。
- ユーザーはサーバーと通信し、サーバー同士がメッセージを交換して他サーバー上のユーザーともコミュニケーションできるようにします。
- あなたは選択肢を得ます:どの城に住みたいか?
メールはこの仕組みで動作し、MastodonやMatrixも同様です。私のアドレスは
@gmail.com、あなたのは @protonmail.com です。異なるドメインに存在し、別会社が運営するアプリを使っていても自由にメールを送受信できます。
フェデレーションは実装が簡単で、クライアント―サーバー構成にプロトコルを付加すれば十分です。たとえばMastodonは普通の Ruby on Rails アプリなのです。
1. なぜ集中化が起こるか
ネットワークは時間とともに中心集約し、規模・力・富の指数分布へ収束します。この集中化は避けられないものです:
- 優先的付加:接続数が多いほどネットワーク効果が大きく、さらに接続が増える。
- N² スケーリング:すべてのフェデが互いに通信すると、接続数は (n \times (n-1)) になる。
- フィットネス圧力:小規模ノードはトラフィックスパイクで落ちやすく、大規模ノードだけが生き残る。
- 効率性:指数分布のネットワークは「超小世界」で、任意二点間のホップ数が少ない。
- レジリエンス:そのようなネットワークはランダム障害に耐えます。
このスケールフリー特性は、フェデレーションを含むすべての進化するネットワークで現れます。メールはもはや分散的ではなく、数社が支配し、ネット中立性原則を守っていない寡占状態にあります。
私は1999年から自前でメールサーバーを運用していましたが、住宅IPブロックやその他制限のため失敗しました。23年後に諦めました(Carlos Fenollosa, 2022)。
フェデリバースでも同様の統合が進行中です。2023年にFacebook Threads が ActivityPub を実装し、瞬時に最大ノードとなり、残りのフェデ全体より10倍以上大きくなりました。非フェデレーションはほぼ効果的ではなく、ネットワークは統合しています。
規模が大きいと、フェデレートされたシステムも集中化したアプリと同様に問題を抱えます:依然として封建制であり、あなたのデータ・アカウント・鍵を所有します。大きなフェデはネットワークトポロジー上の中心位置を占め、非フェデレーション機能を導入したり他フェデとの接続を切断することで引き橋を上げることができます。
2. ピアツーピア(P2P)ネットワーク
サーバーを完全に排除し、直接接続する場合は ピアツーピア が考えられます。
P2P ネットワークでは各参加者がピアを動かし、他のピアを見つけてメッセージを送信します。ユーザーは自分の鍵を所有し、それで署名・検証・暗号化を行うため、エグジット戦略と最小限のユーザー agency が実現できます。
しかし P2P には以下のような工学的課題があります:
- 真偽の中心源がない → 最終的整合性と衝突解決が必要。
- 実際のネットワーク:多くのリクエストが複数ピアを経由し、ピアは不安定(帯域制限・オン/オフ頻繁)。
- ピア発見がコスト高になり遅延増大、ネットワークの一部が到達不能になる可能性。
進化圧もここに働きます。スーパーpeer――高帯域幅と高可用性を持つノードは他者へサービスを提供し、スケーラビリティを解決します。これにより再び集中化が起こり、スーパーpeer はトポロジー上の戦略的立場を占有しネットワーク全体に影響を与えます。P2P ネットワークは指数分布へ傾き、フェデレートシステムと同様です。
3. より単純なアーキテクチャへの転換
規模が大きくなるとすべてのネットワークは大型サーバーを必要とします。
ユーザー所有権を保ちつつ、オフ・ザ・シェルフ(既製)サーバーを 信頼できないパイプ として利用する分散アーキテクチャを設計できるはずです。
そこで登場するのが Nostr プロトコルです:
- リレー は単純:情報を転送するだけの古典的サーバー。
- 経済規模の恩恵を受け、高可用性・高稼働率、コンビニエンスインフラで構築されます。
- N² スケーリング問題はありません。リレー同士が通信しないため、ユーザーは数個(最低2つ、ほとんどの場合12未満)に接続します。
- ユーザーは自分のデータ・アカウント・鍵を所有します。リレーがダウンしても、他所へミラーされているのでアカウントはそのまま残ります ― 信頼できる退場手段。
リレ―は最終的に得られるものです:同じ結果を得るためのステップ数を減らす。Nostr はフェデレーションでもなく純粋な P2P でもありませんが、リレー を使って分散化を実現しつつユーザー制御をコアに置いています。