11. Okt’19
Übersetzung des Blogartikel vom Autor Angelo Capossele, IOTA Foundation.
Vor einigen Monaten haben wir den Quellcode von GoShimmer, dem Prototyp und Recherchetool von IOTA, geöffnet, um mit den Bausteinen von Coordicide zu experimentieren und zu testen. Wir freuen uns über ein so großes und produktives Engagement der Community und danken Ihnen allen für Ihre Beiträge und Ihr Feedback! Sie waren sehr nützlich, um GoShimmer zu verbessern und uns zu helfen, herauszufinden, wie wir das Autopeering-Modul besser neu gestalten können. Wir freuen uns, Ihnen den Quellcode des verbesserten Redesigns des Autopeering-Moduls zur Verfügung zu stellen.
Sie können auf den Code aus dem folgenden Repository zugreifen: https://github.com/iotaledger/autopeering-sim
Kontext
Im IOTA-Protokoll ist ein Node (“Knoten” oder Peer) eine Maschine, die die Informationen über das Tangle, die zugrunde liegende Datenstruktur von IOTA, speichert. Nodes fungieren auch häufig als der Einstiegspunkt für den Zugriff und die Nutzung des Tangle. Damit das Netzwerk effizient funktioniert, tauschen die Nodes untereinander Informationen aus, um über den aktuellen Zustand des neuen Ledgers informiert zu sein. Derzeit wird ein manueller Peering- oder Verbindungs-Prozess verwendet, bei dem sich Nodes gegenseitig als Nachbarn registrieren. Manuelles Peering kann jedoch Angriffen (z.B. Social Engineering) zum Opfer fallen, um die Netzwerktopologie zu beeinflussen. Um diese Angriffe zu verhindern und den Einrichtungsprozess neuer Nodes zu vereinfachen, haben wir im Coordicide-Whitepaper einen Mechanismus eingeführt, der es Nodes ermöglicht, ihre Nachbarn automatisch auszuwählen. Der Prozess, bei dem die Nodes ihre Nachbarn ohne manuelles Eingreifen des Node Operators auswählen, wird als Autopeering bezeichnet.
Das Ziel des Redesigns des Autopeering-Moduls ist es, die Simulationen zu vereinfachen und gleichzeitig die gleiche Codebasis zu erhalten, die auch in GoShimmer verwendet wird. Die Fähigkeit, das Verhalten und die Leistung von Autopeering mittels Simulationen beurteilen zu können, ist für IOTA sehr wichtig. Es ermöglicht die Beantwortung mehrerer Fragen, wie z.B. wie viele Peering-Anfragen jeder Node durchschnittlich senden muss, bevor er akzeptiert wird, wie lange eine Verbindung dauern wird, wie schnell das Protokoll konvergiert und so weiter. Darüber hinaus schafft es die Voraussetzungen für die Untersuchung von Angriffsvektoren in einer kontrollierten Umgebung.
Design
Wir haben das Autopeering-Modul in zwei wesentliche Submodule unterteilt: Peer Discovery und Nachbar-Auswahl. Ersterer ist für die operativen Tätigkeiten verantwortlich, wie z.B. die Entdeckung neuer Gleichgesinnter und die Überprüfung ihres Online-Status. Letzterer ist verantwortlich für das Auffinden und Verwalten von Nachbarn für die Nodes von IOTA. Wir haben auch die Netzwerkschicht (P2P-Kommunikation) und die Speicherschicht (persistierende Peer-Informationen) durch den Einsatz von Go-Schnittstellen eingekapselt. Einen Überblick über die Konstruktion erhalten Sie in der folgenden Abbildung:
Das Design des Autopeering-Moduls
Mit diesem Design ist es problemlos möglich, von einer Datenbank auf einen wesentlich leichteren In-Memory-Speicher zu wechseln und von Verbindungen zwischen Servern auf prozessübergreifende Kommunikation umzustellen. Für GoShimmer werden Server und eine Datenbank benötigt. Das Ersetzen dieser, macht das Schreiben einer effizienten Simulation, die auf einem einzelnen Computer läuft, so einfach wie das Schreiben von nur wenigen Zeilen Code.
Simulation
Als Demonstrator haben wir eine Simulation geschrieben, die sich auf das Submodul Nachbar-Auswahl konzentriert. In der Simulation gehen wir davon aus, dass die Peer-Erkennung alle Nodes im Netzwerk kennt, um nur die Wirkung der Peer-Auswahl bewerten zu können. Szenarien mit einer partiellen Sicht auf das Netzwerk sowie die Performance der Peer-Erkennung werden Gegenstand weiterer Simulationen und Analysen sein.
Die Auswahl der Nachbarn und insbesondere die Entscheidung, welche potenziellen Nachbarn bevorzugt werden, erfolgt auf der Grundlage ihrer Distanz. Diese Distanzfunktion basiert auf den privaten und öffentlichen Salt, wie sie im Coordicide Whitepaper definiert sind. Als nächster Schritt werden wir Mana abhängige Distanzen hinzufügen.
Derzeit kann die Simulation mit folgenden Parametern konfiguriert werden:
- N: die Gesamtzahl der Peers
- T: die Salt Lebensdauer in Sekunden
- SimDuration : Die Dauer der Simulation in Sekunden
- VisualEnabled : Der Schalter zum Aktivieren / Deaktivieren des Simulationsvisualisierers, zugänglich nach dem Start der Simulation unter http://localhost:8844.
- dropAll : Der Schalter zum Aktivieren / Deaktivieren der Abstossung aller Nachbarn bei jeder Salt-Aktualisierung.
Die folgende Animation wurde aufgezeichnet, während die Simulation mit aktiviertem Visualizer ausgeführt wurde. Es bietet uns eine schöne visuelle Darstellung des Peering-Prozesses:
Neu eingerichtete Verbindungen zwischen Peers werden blau hervorgehoben, wobei der anfordernde und der akzeptierende Peer blau bzw. grün dargestellt werden. Abgelegte Links werden rot hervorgehoben.
Metriken und Auswertung
Derzeit unterstützt der Simulator die folgenden Metriken, für die wir Auswertungsskripte zur Verfügung stellen:
- Konvergenz: der Anteil der Peers, die die maximale Anzahl von Nachbarn haben.
- Verbindungsüberlebenszeit: die Wahrscheinlichkeit, dass eine Verbindung nach einer bestimmten Zeitspanne noch aktiv ist.
- Nachrichtenanalyse: Statistik über die Anzahl der gesendeten und empfangenen Nachrichten (Peering-Anfragen, Peering-Antworten und Verbindungsabbrüche).
Wir integrieren auch ein Evaluierungsskript, plot.py, das in Python mit Matplotlib geschrieben wurde. Dieses Skript extrahiert die Daten aus CSV-Ausgabedateien, die durch den Simulationscode erzeugt werden und erzeugt Diagramme sowohl für die Konvergenz als auch für die Verbindungsüberlebenszeit.
Aus den folgenden Abbildungen können Sie beispielsweise erkennen:
a) den Prozentsatz der Nodes mit 8 Nachbarn (in dieser Konfiguration ist 8 die maximale Anzahl der Nachbarn), die durchschnittliche Anzahl der Nachbarn im Zeitverlauf und
b) die Wahrscheinlichkeit, dass eine bestimmte Verbindung eine bestimmte Zeitspanne dauern wird.
Darüber hinaus erzeugt die Ausführung der Simulation eine CSV-Datei (innerhalb des Datenordners) mit den Daten der Nachrichtenanalyse.
Ein Beispiel dafür finden Sie in der folgenden Tabelle:
Hier entspricht die durchschnittliche Anzahl der gesendeten Peering-Anfragen (OUTgoing) der durchschnittlichen Anzahl der empfangenen Peering-Anfragen (INcoming). Es ist einfach, die durchschnittliche Anzahl der gesendeten Peering-Anfragen zu berechnen, bevor man akzeptiert (ACC) wird: Indem man einfach die ausgehenden Anfragen (Out) durch die akzeptierten Anfragen (ACC) dividier. Das ist in diesem Beispiel 9,17 / 7,03 = 1,3.
Wir können auch Informationen auslesen, mit welcher Geschwindigkeit Verbindungen getrennt (DROP) werden: In diesem Beispiel wird durchschnittlich pro 9.17 (In/Out) / 3.03 (DROP) = 3.02 eingehende Nachrichten ein Peer ersetzt.
Wir werden weiterhin weitere Simulationen für die Peer-Erkennung und die Nachbar-Auswahl entwickeln und diese dem Repository hinzufügen! Wir haben auch das Ziel, den Code aus den Simulationen schließlich in GoShimmer zu portieren. Dank der Flexibilität und Modularität von Autopeering und GoShimmer ist dies mit wenigen Anpassungen möglich. Wenn diese Herausforderung interessant klingt, sind Sie herzlich eingeladen, IOTA bei der Integration zu unterstützen! Darüber hinaus prüfen wir die Möglichkeit einer Integration des Autopeering in das aktuelle IOTA-Protokoll (mit dem Koordinator) im Rahmen einer Reihe von Verbesserungen für das offizielle Mainnet.
Im nächsten Teil der Autopeering Blog Post Serie werden wir tiefer in das Innenleben dieses Moduls eintauchen. In der Zwischenzeit hoffen wir, dass dieser Code für alle, die an der Analyse des Autopeering-Moduls interessiert sind, nützlich sein kann. Du bist eingeladen, den Code mit neuen Funktionen zu bereichern! Alternativ können Sie die Simulation ausführen und Feedback geben oder sich über unsere offene Ausschreibung für das Coordicide Grant-Programm informieren, um weitere Kooperationsmöglichkeiten zu erfahren.
Wie immer freuen wir uns über Ihre Kommentare und Fragen entweder hier oder auf dem offiziellen Discord-Server von IOTA, im Kanal #tanglemath oder #goshimmer-discussion.
Quellen
https://blog.iota.org/coordicide-update-autopeering-part-1-fc72e21c7e11