---
title: "P2Pネットワーク"
description: "P2Pネットワークでは、各ノードが探索、ゴシップ、要求・応答の交換に使う有限で変動する直接ピア集合を持ちます。単一のグローバルビューを作るものでも、メッセージ受理をコンセンサスに変えるものでもありません。"
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# P2Pネットワーク
> 教育目的の参考情報であり、投資助言ではありません。投資により損失が生じる可能性があります。
## 直接の回答
P2Pネットワークでは、各ノードが有限数の直接ピアを探索・維持し、認証されたプロトコルメッセージを交換して、すべてを単一の中央サーバー経由にせずローカルビューを構築します。完全グラフでも、グローバルなメンプールでも、それ自体が正しい情報源でもありません。あるピアがオブジェクトを受信、検証、転送しても、全ノードが確認したこと、ブロックに収録されたこと、コンセンサスでファイナライズされたことは証明されません。
マージ後のEthereumは二つの独立したP2Pネットワークを使用します。実行クライアントは探索機構、RLPx、バージョン付きの `eth` ケイパビリティを同期とトランザクション交換に使用します。コンセンサスクライアントはdiscv5でピアを探索し、libp2pゴシップと要求・応答プロトコルでビーコンブロック、アテステーションなどのコンセンサスオブジェクトを交換します。両クライアントはローカルの認証済みEngine APIを通じて連携します。ウォレットは一般にJSON-RPCで送信しますが、それだけでゴシップ参加ノードになるわけではありません。
## 仕組み
1. チェーン、ネットワーク、ジェネシス、フォーク設定、実行・コンセンサスクライアントのバージョン、ノード識別子、観測時刻を確定します。実行クライアント、コンセンサスクライアント、任意のバリデーター、ローカルEngine API、利用者向けRPCを別々の構成要素として図示します。
2. 組み込みブートノード、DNSリスト、静的・信頼済みピア、ENRまたはenode識別子、広告エンドポイントとシーケンス、ネットワーク互換性、NAT、着信到達性という各探索経路を確認します。署名済みENRはレコードを鍵に結び付けますが、誠実性、同期状態、現在の到達性は証明しません。
3. 接続とプロトコル交渉を分けて記録します。実行ピアはRLPxセッションを確立し、`eth` などのケイパビリティを交渉します。コンセンサスピアはdiscv5探索後にlibp2pのトランスポート、セキュリティ、プロトコルIDを交渉します。エンドポイントの発見はアプリケーション互換性を意味しません。
4. オブジェクトごとに実際の経路を追跡します。トランザクションはRPC送信からローカル検証、実行レイヤーのメンプールを経て、`eth` の通知と要求で伝播します。コンセンサスオブジェクトにはトピック固有のゴシップ検証を用い、不足ブロックは要求・応答で取得できます。
5. ローカル受理・転送前に、有界デコード、重複排除、レート制限、署名・構文・状態検査を適用します。無効、無視、取得不能、リソース制限の結果を記録します。ピアスコアと切断方針はローカル実装上の判断であり、コンセンサス上の評判ではありません。
6. 受信、検証、転送、トランザクション収録、実行結果、フォーク選択、正当化、ファイナリティを別々の状態と時計として扱います。ローカルプール、チェーンヘッド、履歴応答が不完全、矛盾、陳腐化しているときは、複数のピアまたはノードを比較します。
7. 着信・発信ピアの多様性、運用者、IPプレフィックスとASNの集中、入れ替わり、遅延、パケット損失、帯域、キュー、無効トラフィック、時計の健全性、RPC依存を監視します。ブートノード喪失、NAT障害、分断、エクリプス攻撃、過負荷、復旧を訓練しますが、絶対的耐性は主張しません。
ピア探索、トランスポートの安全性、アプリケーションの有効性は異なる問題を解きます。ブートノードは候補を紹介するだけで、通常トラフィックを中継せず、正規チェーンも選びません。暗号化はセッション内容と認証を保護しますが、ピアにはネットワークエンドポイントと時刻が分かります。リモートRPC事業者はさらに問い合わせ、アドレス、送信トランザクションを観測できます。
伝播は並行かつトポロジー依存です。ファンアウト、重複経路、帯域の直列化、検証CPU、待ち行列、パケット損失、再送、ピアスコアリング、オブジェクト固有規則が到着時間の分布と裾を決めます。`delay = hops * perHopTime` のような式は、直列処理を明示的に仮定した教材モデルにすぎず、ネットワーク保証ではありません。
## 計算例
- **直列経路とパイプライン。** 教材上の一経路が `4 hops` で、各ホップのネットワーク時間が `80 ms`、検証時間が `20 ms` なら、完全な直列処理は `4 * (80 + 20) = 400 ms` です。検証が次の送信と重なる場合、単純化した下限は `4 * 80 + 20 = 340 ms` です。どちらもネットワーク全体の伝播時間ではありません。
- **トランザクション通知と取得。** ノードが `20` 個のトランザクションハッシュを受信し、既に `6` 個を持つなら、不足する本体は `20 - 6 = 14` 個です。教材上、一要求が最大 `8` 個を運ぶなら `ceil(14 / 8) = 2 batches` が必要です。バッチ当たり往復 `120 ms`、検証 `30 ms` なら、直列完了は `2 * (120 + 30) = 300 ms`、理想的な並列完了は `150 ms` です。実際の制限は交渉済み `eth` バージョンとクライアントに依存します。
- **単純化したエクリプス確率。** `8` 個の発信ピアをそれぞれ独立抽出し、悪意ある候補が `25%` なら、全て悪意ある確率は `0.25^8 = 0.0000152587890625 = 0.00152587890625%` です。探索の偏り、シビル識別子、IP・ASN相関、ピア維持方針は独立性の仮定を崩すため、これは安全性の保証ではありません。
- **検証過負荷。** 着信ゴシップが `900 messages/s`、`4` 個のワーカーが各 `250 messages/s` を検証するなら、処理能力は `1,000 messages/s`、余力は `100 messages/s`、使用率は `90%` です。攻撃流量が `1,400 messages/s` なら、毎秒 `400 messages/s` のバックログが生じ、`6,000 messages` の累積には `15 seconds` かかります。処理時間の分散を無視すると、`5,000-message` のキューは破棄またはレート制限前の `5,000 / 400 = 12.5 seconds` で満杯になります。
## リスク
- チェーン、ジェネシス、フォーク設定の誤り
- 実行クライアント、コンセンサスクライアント、Engine APIの不整合
- 集中または乗っ取られたブートノードとDNS探索
- 古い、偽造された、または到達不能なエンドポイント情報
- NAT、ファイアウォール、ポート設定による想定到達性の阻害
- ローカルビューを選別するエクリプス攻撃
- シビル識別子とIP、ASN、運用者、クラウドの集中
- 静的・信頼済みピアへの過度な依存
- トランザクション検閲または選択的中継
- 公開・非公開オーダーフローの乖離
- ローカルメンプールの受理、置換、排除方針の乖離
- 無効なゴシップによる検証CPU枯渇
- 巨大要求、解凍、帯域、メモリ、ディスクの枯渇
- ピアスコアの操作または誤った罰則
- キューのバックプレッシャーによる時間依存メッセージの破棄
- 遅延、損失、時計ずれによる一時的なチェーンヘッドの乖離
- プロトコルバージョンまたはフォークダイジェストの非互換
- 削除済み履歴またはリソース取得不能応答を不存在と誤認
- IP、時刻、問い合わせ、トランザクション発信元のプライバシー漏えい
- 集中・露出したRPCによる追跡、古いビュー、検閲、侵害
## よくある誤解
- **各ノードは他の全ノードに直接接続する。** 各ノードのローカルピア集合は有限かつ変動し、異なるノードが一時的に異なるメッセージやチェーンヘッドを見ることがあります。
- **ブートノードは信頼できるブロック情報源またはコンセンサス参加者だ。** 通常の役割は初期ピアの紹介であり、チェーンの有効性やフォーク選択は別に検証されます。
- **一つのピアが受理したトランザクションは全世界に配信され、必ず収録される。** 受理と中継はローカルであり、ビルダーや提案者は収録しないことがあります。
- **ゴシップ検証はコンセンサスとファイナリティを意味する。** これは初期のローカルなネットワーク関門であり、フォーク選択、正当化、ファイナリティは別の状態機械です。
- **ピア数の増加や暗号化トランスポートが匿名性とエクリプス耐性を自動的に与える。** 多様性と選択方法が重要で、ピアとRPC事業者は依然としてエンドポイント、時刻、活動を関連付けられます。
## 関連トピック
- [フルノード](/ja/crypto/full-node/)
- [メンプール](/ja/crypto/mempool/)
- [検閲耐性](/ja/crypto/censorship-resistance/)
## 出典
- [Networking layer](https://ethereum.org/developers/docs/networking-layer) - Ethereum.org（参照日：2026-08-13）
- [Ethereum Wire Protocol (ETH)](https://github.com/ethereum/devp2p/blob/master/caps/eth.md) - Ethereum devp2p（参照日：2026-08-13）
- [The RLPx Transport Protocol](https://github.com/ethereum/devp2p/blob/master/rlpx.md) - Ethereum devp2p（参照日：2026-08-13）
- [Node Discovery Protocol v5 - Wire Protocol](https://github.com/ethereum/devp2p/blob/master/discv5/discv5-wire.md) - Ethereum devp2p（参照日：2026-08-13）
- [Phase 0 -- Networking](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/p2p-interface.md) - Ethereum Consensus Specs（参照日：2026-08-13）
- [gossipsub v1.1: Security extensions to improve on attack resilience and bootstrapping](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.1.md) - libp2p（参照日：2026-08-13）
- [Connecting To The Network](https://geth.ethereum.org/docs/fundamentals/peer-to-peer) - go-ethereum（参照日：2026-08-13）
- [Spin up your own Ethereum node](https://ethereum.org/developers/docs/nodes-and-clients/run-a-node/) - Ethereum.org（参照日：2026-08-13）
Source: https://wiki.fcontext.com/ja/crypto/peer-to-peer-network/index.mdx