---
title: "Peer-to-Peer-Netzwerk"
description: "Ein Peer-to-Peer-Netzwerk gibt jedem Knoten eine begrenzte, wechselnde Menge direkter Peers für Erkennung, Gossip und Request-Response-Austausch; es schafft keine globale Sicht und macht aus Nachrichtenannahme keinen Konsens."
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.
# Peer-to-Peer-Netzwerk
> Nur zu Bildungszwecken; keine Anlageberatung oder Anlageempfehlung. Anlagen können zu Verlusten führen.
## Direkte Antwort
Ein Peer-to-Peer-Netzwerk lässt jeden Knoten eine begrenzte Menge direkter Peers erkennen und halten, authentifizierte Protokollnachrichten austauschen und eine eigene lokale Sicht aufbauen, ohne alles über einen zentralen Server zu leiten. Es ist weder ein vollständiger Graph noch ein globaler Mempool oder eigenständige Wahrheitsquelle. Dass ein Peer ein Objekt empfängt, validiert oder weiterleitet, beweist weder dessen Empfang durch alle Knoten noch Blockaufnahme oder Konsensfinalisierung.
Ethereum nach The Merge nutzt zwei getrennte P2P-Netzwerke. Ausführungsclients verwenden Erkennung, RLPx und die versionierte `eth`-Capability für Synchronisierung und Transaktionsaustausch. Konsensclients verwenden discv5 zur Erkennung sowie libp2p-Gossip und Request-Response-Protokolle für Beacon-Blöcke, Attestations und andere Konsensobjekte. Beide Clients koordinieren sich lokal über die authentifizierte Engine API; eine Wallet übermittelt gewöhnlich per JSON-RPC und wird dadurch nicht zum Gossip-Knoten.
## Funktionsweise
1. Blockchain, Netzwerk, Genesis- und Fork-Konfiguration, Versionen von Ausführungs- und Konsensclient, Knotenidentitäten und Beobachtungszeit festlegen. Ausführungsclient, Konsensclient, optionalen Validator, lokale Engine API und nutzerseitigen RPC getrennt abbilden.
2. Jeden Erkennungspfad prüfen: integrierte Bootnodes, DNS-Listen, statische oder vertrauenswürdige Peers, ENR- oder enode-Identität, angekündigten Endpunkt und Sequenz, Netzwerkkompatibilität, NAT und eingehende Erreichbarkeit. Ein signierter ENR bindet einen Eintrag an einen Schlüssel; er beweist weder Ehrlichkeit noch Synchronisierung oder aktuelle Erreichbarkeit.
3. Verbindung und Protokollaushandlung getrennt erfassen. Ausführungs-Peers bauen RLPx-Sitzungen auf und handeln Capabilities wie `eth` aus; Konsens-Peers handeln nach discv5-Erkennung libp2p-Transport, Sicherheit und Protokoll-IDs aus. Einen Endpunkt zu finden bedeutet keine Anwendungskompatibilität.
4. Jedes Objekt entlang seines tatsächlichen Pfades verfolgen. Eine Transaktion kann von der RPC-Einreichung über lokale Validierung und Ausführungs-Mempool zu `eth`-Ankündigungen und -Anfragen gehen. Konsensobjekte nutzen topic-spezifische Gossip-Validierung; fehlende Blöcke können per Request-Response abgerufen werden.
5. Vor lokaler Aufnahme oder Weiterleitung begrenzte Decodierung, Deduplizierung, Ratenlimits sowie Signatur-, Syntax- und Zustandsprüfungen anwenden. Ungültige, ignorierte, nicht verfügbare und ressourcenbegrenzte Ergebnisse erfassen; Peer-Score und Trennungsregeln sind lokale Implementierungsentscheidungen, kein Konsensruf.
6. Empfang, Validierung, Weiterleitung, Transaktionsaufnahme, Ausführungsergebnis, Fork Choice, Rechtfertigung und Finalität als getrennte Zustände und Uhren behandeln. Mehrere Peers oder Knoten vergleichen, wenn lokaler Pool, Head oder Verlaufsantwort unvollständig, widersprüchlich oder veraltet ist.
7. Vielfalt ein- und ausgehender Peers, Betreiber, IP-Präfix- und ASN-Konzentration, Wechsel, Latenz, Verlust, Bandbreite, Warteschlangen, ungültigen Verkehr, Uhrzustand und RPC-Abhängigkeiten überwachen. Verlust von Bootnodes, NAT-Ausfall, Partition, Eclipse, Überlastung und Wiederherstellung testen, ohne absolute Widerstandsfähigkeit zu behaupten.
Peer-Erkennung, Transportsicherheit und Anwendungsgültigkeit lösen verschiedene Probleme. Bootnodes stellen Kandidaten vor, leiten aber keinen gewöhnlichen Verkehr weiter und wählen nicht die kanonische Chain. Verschlüsselung schützt Sitzungsinhalt und Authentifizierung; Peers erfahren dennoch Endpunkte und Zeitpunkte. Ein entfernter RPC-Anbieter kann zusätzlich Anfragen, Adressen und übermittelte Transaktionen beobachten.
Verbreitung erfolgt parallel und topologieabhängig. Fanout, doppelte Pfade, Bandbreitenserialisierung, Validierungs-CPU, Warteschlangen, Paketverlust, Neuübertragung, Peer-Score und objektspezifische Regeln bestimmen Verteilung und Rand der Ankunftszeiten. Eine Formel wie `delay = hops * perHopTime` ist nur ein erklärtes serielles Lehrmodell, keine Netzwerkgarantie.
## Beispiele
- **Serieller Pfad gegenüber Pipeline.** Auf einem Lehrpfad mit `4 hops` hat jeder Hop `80 ms` Netzwerk- und `20 ms` Validierungszeit. Vollständig serielle Verarbeitung ergibt `4 * (80 + 20) = 400 ms`. Überlappt die Validierung die nächste Übertragung, lautet eine vereinfachte Untergrenze `4 * 80 + 20 = 340 ms`. Keiner der Werte ist die netzwerkweite Verbreitungszeit.
- **Transaktionsankündigung und Abruf.** Ein Knoten erhält `20` Transaktionshashes und besitzt bereits `6`; es fehlen `20 - 6 = 14` Bodies. Fasst eine Lehranfrage höchstens `8`, braucht sie `ceil(14 / 8) = 2 batches`. Bei `120 ms` Roundtrip plus `30 ms` Validierung je Batch beträgt der serielle Abschluss `2 * (120 + 30) = 300 ms`, der ideale parallele `150 ms`. Tatsächliche Grenzen hängen von ausgehandelter `eth`-Version und Client ab.
- **Vereinfachte Eclipse-Wahrscheinlichkeit.** Würden `8` ausgehende Peers jeweils unabhängig gezogen und wären `25%` der Kandidaten bösartig, wäre die Wahrscheinlichkeit ausschließlich bösartiger Peers `0.25^8 = 0.0000152587890625 = 0.00152587890625%`. Erkennungsverzerrung, Sybil-Identitäten, IP-/ASN-Korrelation und Peer-Bindung verletzen die Unabhängigkeit; dies ist keine Sicherheitsgarantie.
- **Validierungsüberlastung.** Eingehender Gossip beträgt `900 messages/s`; `4` Worker validieren je `250 messages/s`, also Kapazität `1,000 messages/s`, Reserve `100 messages/s` und Auslastung `90%`. Ein Angriff mit `1,400 messages/s` erzeugt `400 messages/s` Rückstau und `6,000 messages` in `15 seconds`. Eine `5,000-message`-Warteschlange füllt sich in `5,000 / 400 = 12.5 seconds` bis zum Verwerfen oder Begrenzen, ohne Streuung der Bearbeitungszeit.
## Risiken
- Falsche Blockchain-, Genesis- oder Fork-Konfiguration.
- Nicht übereinstimmender Ausführungsclient, Konsensclient oder Engine API.
- Konzentrierte oder entführte Bootnode- und DNS-Erkennung.
- Veraltete, gefälschte oder unerreichbare Endpunktmetadaten.
- NAT, Firewall oder Ports blockieren erwartete Erreichbarkeit.
- Eclipse-Angriff filtert die lokale Sicht eines Knotens.
- Sybil-Identitäten und IP-, ASN-, Betreiber- oder Cloud-Konzentration.
- Übermäßige Abhängigkeit von statischen oder vertrauenswürdigen Peers.
- Transaktionszensur oder selektive Weiterleitung.
- Abweichung zwischen öffentlichem und privatem Orderflow.
- Lokale Unterschiede bei Aufnahme, Ersetzung und Entfernung im Mempool.
- Ungültiger Gossip erschöpft Validierungs-CPU.
- Überdimensionierte Anfragen, Dekompression oder Erschöpfung von Bandbreite, Speicher oder Festplatte.
- Manipulation von Peer-Scores oder falsche Sanktionen.
- Warteschlangen-Gegendruck verwirft zeitkritische Nachrichten.
- Latenz, Verlust oder Uhrabweichung verursachen vorübergehende Head-Divergenz.
- Inkompatible Protokollversion oder Fork Digest.
- Bereinigter Verlauf oder ressourcenbedingt fehlende Antwort wird als Nichtexistenz missverstanden.
- Verlust der Privatsphäre bei IP, Zeitpunkten, Anfragen und Transaktionsursprung.
- Zentralisierter oder offener RPC ermöglicht Tracking, veraltete Sicht, Zensur oder Kompromittierung.
## Häufige Irrtümer
- **Jeder Knoten verbindet sich direkt mit jedem anderen.** Jeder hat eine endliche, wechselnde lokale Peer-Menge; Knoten können zeitweise verschiedene Nachrichten und Heads sehen.
- **Ein Bootnode ist vertrauenswürdige Blockquelle oder Konsensteilnehmer.** Seine normale Rolle ist die anfängliche Peer-Vorstellung; Chain-Gültigkeit und Fork Choice werden anderswo geprüft.
- **Eine von einem Peer angenommene Transaktion wird global verbreitet und garantiert aufgenommen.** Aufnahme und Weiterleitung sind lokal; Builder oder Proposer können sie auslassen.
- **Gossip-Validierung bedeutet Konsens und Finalität.** Sie ist eine frühe lokale Netzwerkschranke; Fork Choice, Rechtfertigung und Finalität sind getrennte Zustandsmaschinen.
- **Mehr Peers oder verschlüsselter Transport schaffen automatisch Anonymität und Eclipse-Schutz.** Vielfalt und Auswahl zählen; Peers und RPC-Anbieter können Endpunkte, Zeitpunkte und Aktivität weiter korrelieren.
## Verwandte Themen
- [Full Node](/de/crypto/full-node/)
- [Mempool](/de/crypto/mempool/)
- [Zensurresistenz](/de/crypto/censorship-resistance/)
## Quellen
- [Networking layer](https://ethereum.org/developers/docs/networking-layer) - Ethereum.org (abgerufen am 2026-08-13)
- [Ethereum Wire Protocol (ETH)](https://github.com/ethereum/devp2p/blob/master/caps/eth.md) - Ethereum devp2p (abgerufen am 2026-08-13)
- [The RLPx Transport Protocol](https://github.com/ethereum/devp2p/blob/master/rlpx.md) - Ethereum devp2p (abgerufen am 2026-08-13)
- [Node Discovery Protocol v5 - Wire Protocol](https://github.com/ethereum/devp2p/blob/master/discv5/discv5-wire.md) - Ethereum devp2p (abgerufen am 2026-08-13)
- [Phase 0 -- Networking](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/p2p-interface.md) - Ethereum Consensus Specs (abgerufen am 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 (abgerufen am 2026-08-13)
- [Connecting To The Network](https://geth.ethereum.org/docs/fundamentals/peer-to-peer) - go-ethereum (abgerufen am 2026-08-13)
- [Spin up your own Ethereum node](https://ethereum.org/developers/docs/nodes-and-clients/run-a-node/) - Ethereum.org (abgerufen am 2026-08-13)
Source: https://wiki.fcontext.com/de/crypto/peer-to-peer-network/index.mdx