Zum Inhalt springen
Financial Context Wiki

Peer-to-Peer-Netzwerk

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.

Aktualisiert

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

Quellen

Navigation

Wiki durchsuchen...