2.3 ネットワークとP2P

ブロックチェーンが「データをどう並べるか」「どうやって合意するか」は、これまで見てきました。でも、世界じゅうの何千台ものコンピュータは、そもそもどうやってお互いを見つけて、ずっと同じ状態を保ち続けるのでしょう？

このレッスンでは、ばらばらのコンピュータをひとつのブロックチェーンネットワークにまとめあげるしくみ（ネットワーキング）を見ていきます。

ノードの種類（Node Types）

「ノードを動かす」と言うとき、実は役割のちがう何種類かのノードがあって、必要なものも大きくちがう、ということは案外知られていません。

フルノード（Full Nodes）

フルノードは、いちばん最初から今までのすべての取引とブロックをダウンロードして、ひとつ残らず検証します。データ量は数百ギガバイト規模。Bitcoin なら 2009 年からの全取引、という世界です。

これを動かすというのは、まじめなリソースを差し出すということ。たとえば 500GB（半テラバイト）級のストレージ、それなりの回線、そして常に電源が入ったコンピュータ。これは「いままで作られた金融記録の完全なコピーをずっと保管し続けます」と名乗り出て、さらに新しい取引が来るたびにルールに合っているか全部チェックするようなものです。

では誰が実際にやるのか？ 最大限の安全がほしい愛好家、自分で全部を検証したい企業、まちがいが許されない取引所など。

フルノードを動かすとき、あなたは誰も信用しません。自分ですべてを検証します。

ライトノード / SPV（Light Nodes）

簡易支払い検証（Simplified Payment Verification, SPV）ノードは、ブロックヘッダ（各 80 バイトほど）だけをダウンロードし、マークル証明（Merkle proofs）を使って、自分に関係する取引だけを検証します。

スマホのウォレットが「半テラバイトも要らないのに動く」のは、まさにこのおかげです。あなたは「ネットワークの多数派は正直だ」という前提を信用しつつも、自分の取引は自分で検証できるわけです。前のレッスンで出てきたマークル木、覚えていますか？ ここで効いてきます。あなたのスマホは、500GB のブロックチェーンを丸ごと落とさなくても、自分の Bitcoin 取引を確認できるのです。

アーカイブノード（Archive Nodes）

これはフルノードをさらに強化したものです。アーカイブノードは、フルノードなら捨て（prune し）てしまうかもしれない過去の状態（historical states）まで含めて、すべてを保存します。たとえば「2019 年 1 月 3 日のあるアドレスの残高はいくらだったか」を知りたければ、アーカイブノードが必要です。そのぶん巨大なストレージ（複数 TB）と強力なハードウェアを要します。

数テラバイト規模の世界です。Etherscan のようなブロックエクスプローラはこれを動かしています。オンラインで古い取引を調べるとき、あなたは誰かのアーカイブノードに問い合わせているわけです。

マイニング / バリデータノード（Mining/Validator Nodes）

これは新しいブロックを作るという、追加の責任を持ったフルノードです。

• PoW では、パズルを解いています。
• PoS では、トークンをステーク（預け入れ）し、ブロックを提案しています。

うまくできているのは、この階層構造がしなやかで壊れにくいシステムを作る点です。全員がすべてを保存する必要はないけれど、十分な数のノードがそれをやるので、ネットワークは安全でアクセスしやすいまま保たれます。あなたのスマホは、データセンターにならなくても参加できるのです。

P2P ネットワークのトポロジ（P2P Network Topology）

ウェブサイトを見るときは Amazon のサーバへ接続しますが、ブロックチェーンのノードは中央の名簿（central directory）がいっさい無いまま、お互いを見つけなければなりません。最初はここでつまずきがちです。「参加すべきネットワーク」がまだ無いのに、どうやってネットワークに参加するの？

ノード発見（Node Discovery）

ノードを初めて起動したとき、それはほかのノードを見つける必要があります。これはブートストラップ問題（bootstrap problem）と呼ばれます。新しい街へ引っ越したとき、友だちは友だちづてに増えていくけれど、まず最初の 1 人を見つけないと始まらない、という感じです。

これを解くために、いくつかの方法があります。

いったん接続すると、ノードはふつう8〜125 個の接続をほかのノードと保ち、情報が複数の経路を流れるメッシュネットワークを作ります。いくつかの接続が切れても、ほかが引き継ぎます。単一障害点（single point of failure）が無いのです。

メッセージの伝播（Message Propagation）

東京で発行された取引が、なぜ数秒でアイスランドのマイナーに届くのか？ それはメッセージ伝播（message propagation）、ざっくり言えば組織化されたうわさ話の広がりによってです。

取引 / ブロックの伝播（Transaction/Block Propagation）

取引をブロードキャストすると、こう進みます。

1. 自分が接続しているすべてのノードに、その取引を送る。
2. 各ノードがそれを検証し、さらに自分のピアたちへ転送する。
3. これが続いて、最終的にネットワーク全体が知ることになる。

帯域を節約するため、ノードはまず「自分はこの取引を持っているよ」と告知（inv メッセージ）してから本体を送ります。受け取った側は、まだ持っていない場合だけ本体を要求します。

これは驚くほど効率的で、中央のとりまとめ役がいないのに、ひとつの取引はふつう10 秒以内にネットワークの 90% に届きます。「ちゃんと成立する伝言ゲーム」のようなものです。

API と RPC：アプリはどうやってブロックチェーンと話すか

あなたのウォレットアプリは、Bitcoin のプロトコル全体を自前で実装しているわけではありません（さっき見たフルノードのように）。代わりに、API を通じてノードと話します。

JSON-RPC

ほとんどのブロックチェーンは JSON-RPC というインターフェースを公開していて、アプリは次のようなことができます。

• 残高を問い合わせる（Query balances）
• 取引を送信する（Submit transactions）
• ブロック情報を取得する（Get block information）
• イベントを監視する（Monitor events）

Web3 プロバイダ（Web3 Providers）

Infura・Alchemy・QuickNode のようなサービスは、あなたの代わりにノードを動かして API を公開してくれます。だから DApp は自分専用のノードを持たなくてもよくなります。便利ですが、いくらか中央集権を持ち込みます —— たとえば Infura が落ちると、多くの DApp が止まってしまいます。

トレードオフはこうです。自分でノードを動かすとリソースは要りますが、最大限の安全と分散性が得られます。プロバイダを使うと楽ですが、その相手を信用していることになります。

ネットワークへの攻撃と防御（Network Attacks and Defenses）

P2P ネットワークには、独特のむずかしさがあります。

エクリプス攻撃（Eclipse Attack）

攻撃者が、あなたのノードのまわりを悪意あるノードで取り囲み、あなたが受け取る情報を全部コントロールします。あなたは「ネットワークにつながっている」つもりでも、実は攻撃者が作った泡（バブル）の中にいる、という状態です。

• 防御：多様なピアに接続する。ノード発見の方法を複数組み合わせて使う。

シビル攻撃（Sybil Attack）

たくさんの偽ノードを作り出して、不釣り合いに大きな影響力を得ようとする攻撃です。

• 防御：Proof of Work / Proof of Stake を使う。これにより有効なブロックを作るのは高コストになるので、ノードの個数がいくら多くても影響力は買えません。

ネットワーク分断（Network Partition）

ネットワークをお互いに通信できない孤立したグループに分割する攻撃です。

• 防御：地理的な分散、複数の接続経路、そして衛星 / 無線のバックアップ回線。そう、人々は Bitcoin を衛星経由でブロードキャストしているのです（インターネットだけでは SF として足りなかったのか、暗号界隈はここまでやります）。

この P2P アーキテクチャこそが、ブロックチェーンを検閲耐性（censorship-resistant）のあるものにしています。

止めるべきサーバも、召喚状を突きつける会社も、単一障害点もありません。ノードたちがインターネット・メッシュネットワーク・電波など、なんらかの手段でお互いを見つけられるかぎり、ネットワークは生き延びます。

そして、これはブロックチェーンが遅くなりうる理由でもあります。すべてのデータは何千ものノードへ伝播し、それぞれ独立に検証され、合意に達しなければなりません。速さがほしいなら Venmo を。止められない存在でいたいならブロックチェーンを、というわけです。

このアーキテクチャは、効率よりも、しなやかさ（resilience）を優先しています。だからこうなります。

• 取引の確定には時間がかかる（伝播 ＋ 合意のぶん）。
• ノードを動かすことはネットワークを助ける（冗長性と検証が増える）。
• 「中央集権ノードを使う”ブロックチェーン”」は、本当はブロックチェーンとは言えないことがある。
• ネットワークのアップグレードは難しい（何千もの独立した運用者を足並みそろえる必要がある）。

これは速さや効率の話ではありません。誰にも止められず・支配されず・壊されないシステムを作るための話です —— たとえ相手が本気でそれを望んでいたとしても。

開発者として押さえる点

• ノードは役割で分かれる：フル（全検証・全保存）／ライト・SPV（ヘッダ＋マークル証明で自分の取引だけ検証）／アーカイブ（過去の状態まで保存）／マイニング・バリデータ（ブロック生成）。アプリの要件で「自前で持つか／問い合わせるか」を選ぶ。
• 中央名簿は無い。起動時のブートストラップ問題は、シードノード・DNS シード・ピア交換で解き、つねに 8〜125 接続のメッシュを保って単一障害点を作らない。
• 伝播は inv 告知 → 必要なら本体要求の二段階で帯域を節約。中央調整なしでも約 10 秒で 90% 到達。
• アプリはプロトコルを丸ごと実装せず、JSON-RPC でノードと話す（残高照会・取引送信・ブロック取得・イベント監視）。Web3 プロバイダ（Infura / Alchemy / QuickNode）は楽だが中央集権と信用前提を持ち込むトレードオフ。
• 攻撃と防御をセットで覚える：エクリプス→多様なピア・複数の発見手段、シビル→PoW/PoS で「有効ブロック作成を高コスト化」、分断→地理分散・複数経路・衛星/無線。
• 設計思想は効率より耐性。確定に時間がかかるのは仕様であり、検閲耐性と引き換え。

やさしい版・公式へ

• 公式：Academy Courses↗（外部リンク・別タブで開きます）（Phase 1 / Unit 2 / 2.3 Network Architecture & P2P Systems）
• ノード運用やネットワーク接続の実務は公式ドキュメントを：docs.midnight.network↗（外部リンク・別タブで開きます）

✍️ 白紙練習

答えを見る前に、いったん自分の頭と手から出してみよう。手で書くと「わかったつもり」がはがれます。

つぎに読むページ

➡️ 原文準拠コースの入口へ戻る。このコースについて（次のレッスンは順次追加します）