Oktober 11, 2019

Coordicide-Update - Autopeering: Teil 1

Coordicide-Update - Autopeering: Teil 1

Das Autopeering-Modul

Vor einigen Monaten haben wir den Quellcode von GoShimmer, dem Prototyp und Forschungstool von IOTA, zum Experimentieren und Testen der Bausteine ​​von Coordicide geöffnet. Wir freuen uns sehr über dieses große und produktive Engagement der Community und möchten uns bei euch für Beiträge und Feedback bedanken! Die Community hat sich als sehr nützlich erwiesen, um GoShimmer zu verbessern und um herauszufinden, wie wir das Autopeering-Modul besser umgestalten können.

Wir freuen uns, dir den Quellcode der verbesserten Neugestaltung des Autopeering-Moduls mitzuteilen. Du kannst über das folgende Repository auf den Code zugreifen:

https://github.com/iotaledger/autopeering-sim

Kontext

Im IOTA-Protokoll ist ein Node (oder Peer) eine Maschine, die die Informationen über den Tangle, die zugrunde liegende Datenstruktur von IOTA, speichert. Nodes fungieren auch häufig als Einstiegspunkt für den Zugriff und die Verwendung des Tangle. Damit das Netzwerk effizient arbeitet, tauschen Nodes Informationen untereinander aus, um über den neuen Ledger-Status auf dem neuesten Stand zu bleiben. Gegenwärtig wird ein manueller Peering- oder Verbindungsprozess für Nodes verwendet, um sich gegenseitig als Nachbarn zu registrieren. Manuelles Peering kann jedoch Angriffen ausgesetzt sein (z. B. Social Engineering), um die Netzwerktopologie zu beeinflussen. Um diese Angriffe zu verhindern und den Einrichtungsprozess neuer Nodes zu vereinfachen, haben wir im Coordicide-Whitepaper eingeführt, ein Mechanismus, mit dem Nodes ihre Nachbarn automatisch auswählen können. Der Vorgang, bei dem Nodes ihre Nachbarn auswählen, ohne dass der Nodebetreiber manuell eingreift, wird als Autopeering bezeichnet.

Ziel des Redesigns des Autopeering-Moduls ist es, die Simulation zu vereinfachen und dabei die gleiche Codebasis beizubehalten, die auch in GoShimmer verwendet wird. Für IOTA ist es sehr wichtig, das Autopeering-Verhalten und die Leistung über Simulationen beurteilen zu können. Es ermöglicht die Beantwortung mehrerer Fragen, z. B. wie viele Peering-Anfragen ein Node durchschnittlich senden muss, bevor sie akzeptiert werden, wie lange eine Verbindung dauern wird, wie schnell das Protokoll konvergiert und so weiter. Darüber hinaus wird der Grundstein für die Untersuchung von Angriffsvektoren in einer kontrollierten Umgebung gelegt.

Design

Wir haben das Autopeering-Modul logisch in zwei Haupt-Submodule unterteilt: Peer Discovery und Neighbor Selection. Ersterer ist für Vorgänge wie das Erkennen neuer Peers und das Überprüfen ihres Onlinestatus verantwortlich. Letzterer ist für die Suche und Verwaltung der Nachbarn der IOTA-Nodes zuständig. Wir haben auch die Netzwerkschicht (P2P-Kommunikation) und die Speicherschicht (persistierende Peer-Informationen) mithilfe von Go-Schnittstellen gekapselt. In der folgenden Abbildung sehen Sie eine allgemeine Übersicht über das Design:

Mit diesem Design ist es einfach möglich, von einer Datenbank auf einen viel leichteren In-Memory-Speicher zu wechseln und von Verbindungen zwischen Servern auf prozessübergreifende Kommunikation umzuschalten. Für GoShimmer werden Server und eine Datenbank benötigt. Wenn Sie sie ersetzen, ist das Schreiben einer effizienten Simulation, die auf einem einzelnen Computer ausgeführt wird, so einfach wie das Schreiben von nur wenigen Codezeilen.

Simulation

Als Demonstrator haben wir eine Simulation geschrieben, die sich auf das Submodul für die Nachbarauswahl konzentriert. In der Simulation wird davon ausgegangen, dass die Peer-Erkennung alle Nodes im Netzwerk kennt, um nur die Auswirkung der Peer-Auswahl bewerten zu können. Szenarien mit Teilsicht auf das Netzwerk sowie die Performance der Peer Discovery werden Gegenstand weiterer Simulationen und Analysen sein.

Die Auswahl der Nachbarn und insbesondere die Entscheidung, welche potenziellen Nachbarn vorzuziehen sind, wird anhand ihrer Entfernung getroffen. Diese Distanzfunktion basiert auf den privaten und öffentlichen Salzen, wie im Coordicide White Paper definiert. Als Nächstes werden wir Mana abhängige Entfernungen hinzufügen.

Derzeit kann die Simulation mit folgenden Parametern konfiguriert werden:

  • N: die Gesamtzahl der Peers
  • T: die Salzlebensdauer in Sekunden
  • SimDuration : Die Dauer der Simulation in Sekunden
  • VisualEnabled : Der Schalter zum Aktivieren / Deaktivieren des Simulationsvisualisierers, der nach dem Starten der Simulation unter http: // localhost: 8844 aufgerufen werden kann
  • dropAll : Der Schalter zum Aktivieren / Deaktivieren des Fallen lassen aller Nachbarn bei jedem Salt-Update

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 bereitstellen:

  • Konvergenz: Der Anteil der Peers mit der maximalen Anzahl von Nachbarn
  • Link Survival Time: Die Wahrscheinlichkeit, dass ein Link nach einer bestimmten Zeit noch aktiv ist
  • Nachrichtenanalyse: Statistik über die Anzahl der gesendeten und empfangenen Nachrichten (Peering-Anfragen, Peering-Antworten und Verbindungsabbrüche)

Wir enthalten auch ein Evaluierungsskript, plot.py, das in Python mit Matplotlib geschrieben wurde. Dieses Skript extrahiert die Daten aus CSV-Ausgabedateien, die vom Simulationscode erzeugt werden, und generiert Diagramme sowohl für die Konvergenz- als auch für die Verbindungsüberlebenszeit.

Aus den folgenden Abbildungen können Sie beispielsweise Folgendes ersehen: a) den Prozentsatz der Nodes mit 8 Nachbarn (in dieser Konfiguration ist 8 die maximale Anzahl von Nachbarn) und die durchschnittliche Anzahl von Nachbarn über die Zeit und b) die Wahrscheinlichkeit, dass eine bestimmte Verbindung besteht, würde eine gewisse Zeit dauern.

Darüber hinaus produziert (in den CSV - Datei die Simulation laufen Datenordner) mit den Daten der Nachrichtenanalyse. Ein Beispiel dafür finden Sie in der folgenden Tabelle:

Hier entspricht die durchschnittliche Anzahl der gesendeten Peering-Anforderungen (OUT going) der durchschnittlichen Anzahl der empfangenen Peering-Anforderungen (IN coming). Es ist einfach, die durchschnittliche Anzahl von Peering-Anforderungen zu berechnen, die vor dem Empfang von ACC gesendet wurden: Teilen Sie einfach die ausgehenden Anforderungen auf die akzeptierten Anforderungen auf. Das heißt, in diesem Beispiel ist 9.17 / 7.03 = 1.3. Wir können auch Informationen über die Rate extrahieren, mit der Verbindungen DROP ped erhalten: In diesem Beispiel wird durchschnittlich ein Peer pro 9.17 / 3.03 = 3.02 eingehender Nachrichten ersetzt.

Wir werden weitere Simulationen für die Peer-Erkennung und die Nachbarauswahl entwickeln und diese dem Repository hinzufügen! Wir haben auch das Ziel, den Code aus den Simulationen nach GoShimmer zu portieren. Dank der Flexibilität und Modularität von Autopeering und GoShimmer ist dies mit nur wenigen Anpassungen möglich. Wenn diese Herausforderung interessant klingt, können Sie gerne IOTA bei der Integration unterstützen! Darüber hinaus prüfen wir die Möglichkeit einer Integration des Autopeerings 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-Blogpost-Reihe werden wir uns eingehender mit der Funktionsweise dieses Moduls befassen. Wir hoffen, dass dieser Code in der Zwischenzeit für alle nützlich sein kann, die das Autopeering-Modul analysieren möchten. Sie sind eingeladen, mit neuen Funktionen zum Code beizutragen! Alternativ können Sie die Simulation ausführen und Feedback geben oder sich in unserer offenen Aufforderung für das Coordicide Grant-Programm über weitere Möglichkeiten der Zusammenarbeit informieren.

Wie immer freuen wir uns über deine Kommentare und Fragen, entweder hier oder auf dem offiziellen Discord-Server von IOTA, im #tanglemath- oder #goshimmer-Diskussionskanal.


Quelle: https://blog.iota.org/coordicide-update-autopeering-part-1-fc72e21c7e11