Oktober 26, 2019

Coordicide Update - Autopeering: Teil 2

Coordicide Update - Autopeering: Teil 2

Einführung

Im letzten Blogbeitrag haben wir dir den IOTA Research Team-Simulator des aktuellen Autopeering-Modells, sowie einige erste Ergebnisse vorgestellt. In diesem zweiten Teil der Serie möchten wir dir einen klaren Überblick über den Autopeering-Algorithmus und dessen Funktionsweise geben.

Zuallererst, warum ist es wichtig, Peering mit einem gewissen Grad an Zufälligkeit zu automatisieren? Grob gesagt, wenn ein neuer Node eine Verbindung zu anderen Nodes herstellt, die von einem Nachbarn vermittelt wurden, sind die vom ersteren Node empfangenen Informationen denen von den zuvor verfügbaren Informationen sehr ähnlich. Dadurch entsteht eine Art Echokammer. Darüber hinaus kann ein Angreifer mit dieser Art des Netzwerkwachstums eine ausgewählte Region eclipsen (in den Schatten stellen), indem er eine große Menge seiner eigenen Nodes an die Neulinge weitergibt.

Unser Ziel ist es daher, einen Algorithmus zu implementieren, der Folgendes beinhaltet:

1) Gute topologische Eigenschaften (also Eigenschaften, die sich auf die Anordnung der Nodes beziehen), um eine gute Konvergenz für den darauf aufbauenden Abstimmungsmechanismus zu ermöglichen

2) Die Wahrscheinlichkeit, dass ein Angriff eines böswilligen Akteurs erfolgreich ist, sollte vernachlässigbar klein sein

Zu diesem Zweck haben wir einen Algorithmus eingeführt, der drei verschiedene Variablen kombiniert. Eine, die überprüfbar ist, eine, die nicht vorhersehbar ist, und eine letzte Variable, die aus etwas Bregenztem errechnet wird.

Der Autopeering-Algorithmus

Hier wird beschrieben, wie der Autopeering-Prozess, wie er bereits im gemeinsam genutzten Simulator modelliert wird, nach Abschluss der Nodes Erkennung genau abläuft. Jeder der Nodes hat:

1) eine öffentliche "Node-ID" (eine 32-Byte-Zeichenfolge)

2) einen "öffentlichen Salt" (eine 20-Byte-Zeichenfolge)

3) einen "privaten Salt" (eine 20-Byte-Zeichenfolge)

Wir definieren den Anforderungsabstand zwischen Node A und B wie folgt:

d_req (A, B) = Hash (node_id (A)) XOR-Hash (node_id (B) + pub_salt (A))

Um eine neue Verbindung anzufordern, berechnet Node A d_req (A, B) für alle ihm bekannten Nodes und ordnet sie nach deren Entfernungen. Danach beginnt der Node, vom nächsten Node bis zum entferntesten anzufordern, bis k von den anderen Nodes akzeptieren und folglich Verbindungen hergestellt werden.

Weiterhin definieren wir den Akzeptanzabstand zwischen Node A und B wie folgt:

d_acc (A, B) = Hash (node_id (A)) XOR-Hash (node_id (B) + priv_salt (A))

Ein Node A akzeptiert eine Anfrage von einem Node B, jedesmal dann, wenn

1) weniger als k Anfragen angenommen wurden

oder

2) d_acc (A, B) kleiner ist, als die Akzeptanzdistanzen zu einem seiner akzeptierten Kollegen. In diesem Fall unterbricht Node A die Verbindung zu seinem am weitesten akzeptierten Node.

In regelmäßigen Abständen ändern die Nodes ihre Salt's und aktualisieren alle Entfernungen. Es ist zu beachten, dass jede Node 2k Verbindungen anstreben wird, wobei k (die Hälfte aller) Verbindungen durch Anfragen an andere Nodes hergestellt werden, während k Verbindungen (die andere Hälfte) durch Annehmen der Anfragen von anderen Nodes zustande kommen.

Wie verhindert dieser Algorithmus Angriffe?

Konzentrieren wir uns zunächst auf das "öffentlich-private Salt". Die anzufragenden Entfernungen hängen nur von öffentlichen Informationen ab. Auf diese Weise können die Nodes überprüfen, ob eine bestimmte Anforderung wahrscheinlich legitim ist oder nicht, indem sie auswerten, ob die Entfernung eine geeignete Größenordnung hat. Dies erschwert dem Angreifer bereits ein wenig die Arbeit, da er nun einen öffentliches Salt „minen“ muss, das ihn nahe genug an dem Node positioniert, den er eclipsen (in den Schatten stellen) möchte. Wenn die Salt's unter Verwendung von Hash-Ketten erzeugt werden, verpflichten sich die Nodes außerdem zu einer langen Sequenz von Salt's, was es praktisch unmöglich macht, einen erfolgreichen Angriff über einen großen Zeitraum aufrechtzuerhalten.

Da die Akzeptanz nun von einer Variablen (dem privaten Salt)  abhängt, die nur dem angegriffenen Node bekannt ist, ist es für den Angreifer völlig unvorhersehbar, ob ein Angreifer eine Verbindung zu einem Ziel herstellen wird oder nicht. Dies wird die möglichen Strategien des böswilligen Angreifers teils noch weiter eingrenzen und das Ausprobieren mit mehreren verschiedenen Nodes zur einzig möglichen Strategie in der Praxis machen. Dies führt uns zur letzten Komponente des Systems: Mana *. Wenn wir die oben definierten Entfernungen mit Manadifferenzen abwägen, stellt der Algorithmus Verbindungen zwischen Nodes mit ähnlichen Manabeträgen her. Auf diese Weise soll Mana knapp werden. Kein Angreifer wird genug davon haben, um diese Art von Versuch-und-Irrtum-Angriff auf teilnehmende (von null verschiedene) Mananodes durchzuführen. Dies macht unser Autopeering zum vielversprechendsten zufälligen, automatisierten, nicht leicht zu betrügenden Peering-Algorithmus unter den wichtigsten DLTs.

Wir hoffen, dir hat diese kleine Serie über das Autopilot-Modell gefallen! Wie immer sind alle Fragen und Kommentare willkommen, entweder hier oder auf unserem Discord-Server.

* noch nicht im Simulator implementiert


Quelle: https://blog.iota.org/coordicide-update-autopeering-part-2-4e462ba68bd