📘 Academy原文準拠 ｜ Phase 1 · Unit 2 · Lesson 2.3 Network Architecture & P2P Systems 内容に忠実な日本語版です。原文（英語）・図・動画は公式 Academy（外部リンク・別タブで開きます）を正本に。
ブロックチェーンが「データをどう並べるか」「どうやって合意するか」は、これまで見てきました。でも、世界じゅうの何千台ものコンピュータは、そもそもどうやってお互いを見つけて、ずっと同じ状態を保ち続けるのでしょう？
このレッスンでは、ばらばらのコンピュータをひとつのブロックチェーンネットワークにまとめあげるしくみ（ネットワーキング）を見ていきます。
ノードの種類（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）
取引をブロードキャストすると、こう進みます。
- 自分が接続しているすべてのノードに、その取引を送る。
- 各ノードがそれを検証し、さらに自分のピアたちへ転送する。
- これが続いて、最終的にネットワーク全体が知ることになる。
帯域を節約するため、ノードはまず「自分はこの取引を持っているよ」と告知（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（外部リンク・別タブで開きます）
つぎに読むページ
➡️ 原文準拠コースの入口へ戻る。このコースについて（次のレッスンは順次追加します）