Verbesserungen des IOTA 2.0 Konsens-Mechanismus

TL;DR

Wir beschreiben, was wir aus dem IOTA 2.0 DevNet gelernt haben und konzentrieren uns dabei auf den Konsensmechanismus. Wir erklären, wie wir das Protokoll verbessern können, indem wir den FPC-Abstimmungsprozess durch einen Mechanismus rationalisieren, den wir On Tangle FPC on a set (OTFPC) nennen.

[donation]

Bei der IOTA Foundation arbeiten Ingenieure und Forscher sehr eng zusammen, oft im selben Team und nach einer agilen Methodik. Der Ansatz ist pragmatisch und einfach:

1. Definieren Sie das Problem
2. Brainstorming von Ideen zur Lösung des Problems
3. Vielversprechende Ideen in Lösungen umwandeln
4. Untersuchung der Lösungen mit einer Vielzahl von Methoden und aus verschiedenen Blickwinkeln: analytisch, durch Simulationen, durch Experimente
5. Die gesammelten Daten synthetisieren und die Lehren aus Punkt 4 ziehen und zur Verbesserung der Lösung nutzen

Eines der besten Beispiele für diesen Ansatz ist GoShimmer, der Forschungsprototyp, der das IOTA 2.0 DevNet betreibt. Sein Hauptzweck ist es, Ideen aus der Forschung in eine funktionierende Implementierung zu verwandeln, damit wir wichtige Aspekte wie Machbarkeit, Schutz gegen verschiedene Angriffe, Leistung und die Behebung von Fehlern auf dem Weg bewerten können.

Die Veröffentlichung der ersten Iteration des IOTA 2.0 DevNet war ein sehr wichtiger Meilenstein für das Coordicide-Projekt, da wir nun die Möglichkeit haben, den Prototyp unserer vollständig dezentralisierten Lösung zu sehen, zu erleben und zu analysieren. Was wir dabei gelernt haben, hilft uns bereits dabei, das zu verbessern, was wir bisher gebaut haben. In diesem Blogbeitrag geht es um den Konsensmechanismus und wie wir das Protokoll durch die Einführung von On Tangle FPC (OTFPC) verbessern können.

Der Konsensmechanismus von IOTA 2.0 ist so konzipiert, dass er ohne Erlaubnis und ohne Anführer funktioniert. In seinem Kern kombiniert er

1. ein binäres Abstimmungsprotokoll (FPC) als Vorkonsens und Metastabilitätsbrecher (d.h. er zwingt das System zu einer Entscheidung),
2. und ein virtuelles Abstimmungsprotokoll oder Zustimmungsgewicht (AW), das eine Endgültigkeit ähnlich der Regel der längsten Kette beim Nakamoto-Konsens (d. h. schwerster Zweig) bietet.

Diese Kombination ist aus zwei Gründen notwendig. Erstens brauchen wir FPC, um eine gemeinsame Wahrnehmung dessen, was gut und schlecht ist, durchzusetzen. Zweitens legt FPC die anfängliche Meinung über Transaktionen auf der Grundlage ihrer Ankunftszeit fest (die FCoB-Regel): Ankunftszeiten sind jedoch unbeständig (denken Sie nur an Ihre Internetverbindung zu Hause), und jede Regel, die auf Ankunftszeiten basiert, wird dazu führen, dass einige Knoten aus der Synchronisation fallen. Daher ist die Genehmigungsgewichtung notwendig, damit Knoten, die aus dem Takt geraten sind, aufholen können.

Diese Kombination führt jedoch zu einem recht komplizierten Code. Wir haben festgestellt, dass wir das FPC-Verfahren tatsächlich nachahmen können, indem wir die Genehmigungsgewichtung jedes Konflikts verwenden. Bei FPC fragt ein Knoten einfach andere Knoten nach ihrer Meinung zu einer Transaktion. Jedes Mal, wenn sich jemand auf eine Transaktion bezieht, „stimmt“ er für sie, so dass die Zustimmungsgewichtung zeigt, wer für was gestimmt hat. Indem wir die direkten Abfragen gegen die AW austauschen, erhalten wir ein Verfahren, das wir On Tangle FPC (OTFPC) nennen. In diesem Beitrag werden wir erklären, wie unsere Verbesserungen drei Dinge erreichen:

1. Starke Vereinfachung unserer Codebasis
2. Verringerung des Kommunikations-Overheads
3. Beschleunigung der Bestätigungszeiten

FPC

Das Fast Probabilistic Consensus (FPC)-Protokoll ist ein binäres Abstimmungsprotokoll, bei dem jeder Knoten mit einer anfänglichen Meinung zu einer von FCoB festgelegten Transaktion beginnt. Die Knoten tauschen dann in mehreren Runden Anfragen und Antworten zu ihren Meinungen aus, bis jeder Knoten mit einem endgültigen Wert abschließt: Gefallen oder Nichtgefallen. Das Ergebnis der Abstimmung wird jedoch stark durch den Anteil der ursprünglichen Meinung beeinflusst. Nehmen wir zum Beispiel zwei Transaktionen, die miteinander in Konflikt stehen und von der Mehrheit des Netzes innerhalb der ersten Quarantänezeit (Q1) gesehen werden. Dann werden beide mit hoher Wahrscheinlichkeit von FPC abgelehnt und somit nicht in den Tipp-Pool aufgenommen und schließlich verwaist.

Ohne einen eindeutigen Gewinner könnten neue Knoten, die dem Netzwerk beitreten, oder bestehende Knoten, die fehlende Nachrichten verfestigen, nur eine der beiden Transaktionen erhalten (z. B. aufgrund einer indirekten Verfestigung über schwache Referenzen oder eines Netzwerkausfalls), die anfängliche Meinung über FCoB auf „gefällt mir“ setzen und somit versuchen, ihre neuen Nachrichten an eine Seite des Tangles anzuhängen, die nicht genug Zustimmungsgewicht erhält, um jemals bestätigt zu werden. Dieses Verhalten könnte dadurch gemildert werden, dass nur die abgelehnten Konflikte mitgeteilt werden, was allerdings mit zusätzlichen Informationen in den FPC-Anweisungen verbunden ist.

Zustimmungsgewicht (AW)

Das Genehmigungsgewicht einer Nachricht misst den prozentualen Anteil des aktiven Konsensmanas der Knoten, die eine Nachricht in ihrem zukünftigen Kegel (d. h. durch direkte oder indirekte Referenzierung) ausgegeben haben. Darüber hinaus wird das Genehmigungsgewicht so berechnet, dass das Konsensmana eines Knotens nicht auf das Genehmigungsgewicht von zwei konkurrierenden Transaktionen angerechnet werden kann. Nehmen wir zum Beispiel an, dass A und B kollidierende Transaktionen sind. Ich bin ein Knoten mit hohem Mana und gebe eine Nachricht heraus, die sich auf A bezieht, dann trägt mein Konsensmana zum Genehmigungsgewicht von A bei. Wenn ich jedoch später eine Nachricht herausgebe, die B genehmigt, dann wird mein Konsensmana vom Genehmigungsgewicht von A abgezogen und zu B hinzugefügt.

Wenn also das Zustimmungsgewicht von A größer als 50 % ist, dann wissen wir, dass das Zustimmungsgewicht von B kleiner als 50 % ist. Wir können also sagen, dass eine Nachricht (oder eine Transaktion) abgeschlossen ist, wenn ihr Zustimmungsgewicht größer als 50 % plus die Stärke eines potenziellen Angreifers ist.

AW war ursprünglich ein Kernpunkt von Hans‘ On Tangle Voting Vorschlag. In seinem Vorschlag würden die Knoten immer Tipps auswählen, die sich auf die Transaktionen mit dem höchsten Zustimmungsgewicht beziehen. Es ist jedoch nicht klar, ob dieser Vorschlag gut funktionieren würde, wenn das Zustimmungsgewicht zweier konkurrierender Transaktionen gleich ist, weshalb ein Element wie FPC erforderlich ist, das die Gleichheit aufhebt. Die Zustimmungsgewichtung ähnelt dem Konzept der kumulativen Gewichtung im ursprünglichen White Paper, wurde aber an eine Umgebung angepasst, in der wir Mana als Sybil-Schutzmechanismus verwenden.

Verbesserungen

Es ist wichtig zu bemerken, dass das aktuelle Protokoll nicht grundlegend mangelhaft ist. Tatsächlich hat der aktuelle IOTA 2.0 DevNet Konsensmechanismus, der auf FCoB und FPC basiert, hunderte von Konflikten in unserem Prototyp erfolgreich gelöst. Da wir uns jedoch das Ziel gesetzt haben, das beste DLT zu entwickeln, möchten wir die Leistung des Protokolls optimieren, indem wir die Komplexität des Codes, die Bestätigungszeit und den Kommunikations-Overhead minimieren.

Warum ist die Komplexität des Codes wichtig? Erstens: Je komplexer der Code ist, desto schwieriger ist es, ihn auf Fehler zu überprüfen, was zu Sicherheitsproblemen führen kann. Zweitens wollen die Entwickler auf etwas aufbauen, das sie verstehen können. Wenn die Node-Software einfacher gehalten wird, fördert dies die Akzeptanz.

Aus diesem Grund nehmen wir zwei Änderungen am Protokoll vor. Erstens wechseln wir von FPC zu dem, was wir On Tangle FPC (OTFPC) nennen. Wie bereits erwähnt, fragen wir bei FPC in jeder Runde Knoten im Netzwerk nach ihrer Meinung zu einer Transaktion ab und entscheiden anhand des Prozentsatzes der positiven Antworten und eines zufälligen Schwellenwerts, ob unsere Meinung in der nächsten Runde „gefällt mir“ oder „gefällt mir nicht“ lauten soll.

In OTFPC verwenden wir anstelle von direkten Abfragen die Zustimmungsgewichtung. Da die Knoten ihr Konsensmana nicht auf das Zustimmungsgewicht von zwei verschiedenen Konflikten setzen können, ist das Zustimmungsgewicht einer Abfrage sehr ähnlich, wobei die abgefragten Knoten im Wesentlichen diejenigen sind, die diese Nachricht referenziert haben. OTFPC arbeitet nach wie vor in Runden, wobei ein Knoten in jeder Runde anhand der Zustimmungsgewichtung und eines zufälligen Schwellenwerts entscheidet, welche Transaktionen er mag. Die gemochten Transaktionen bestimmen, welche Nachrichten für die Tipp-Auswahl in Frage kommen, und so erhalten nur gemochte Transaktionen ein Genehmigungsgewicht.

Mit OTFPC benötigen wir keinen Mechanismus für direkte Abfragen, sondern nutzen das Netzwerk selbst als einziges Kommunikationsmedium. Dadurch wird der Kommunikations-Overhead reduziert und die für den Betrieb eines Knotens erforderliche Bandbreite verringert.

Zweitens: Anstatt bei jeder Nachricht eine binäre Entscheidung zwischen „Ja“ und „Nein“ zu treffen, wählen die Knoten mittels FPC aus einer Liste konkurrierender Transaktionen einen Gewinner aus. Wir verwenden also ein Verfahren, das wir FPC on a set (FPCOS) nennen. Da OTFPCOS jedoch als Akronym nicht genießbar ist, lassen wir das OS weg.

Indem wir einen Gewinner wählen, befreien wir uns von der FCoB-Regel, der Regel, die anhand der Ankunftszeiten bestimmt, wen wir mögen. Im Gegensatz zu FCoB verwendet OTFPC keine Quarantänezeiten, die zu längeren Bestätigungszeiten führen könnten. Eingehende Nachrichten werden sofort zum Tipp-Set hinzugefügt, so dass jeder Knoten seine Präferenz ausdrücken und über die Tipp-Auswahl eine Stimme für eine bestimmte Transaktion innerhalb eines Konflikt-Sets abgeben kann. Wie beim Mechanismus der Genehmigungsgewichtung wird die lokale Präferenz eines Knotens durch die Konsens-Mana-Gewichtung bestimmt, die mit einer bestimmten konfliktbehafteten Transaktion über direkte und indirekte Verweise auf sie verbunden ist. Somit wird OTFPC die lokale Meinung eines Knotens zu einer bestimmten Transaktion besser an deren Genehmigungsgewicht anpassen, da es der gleichen Regel des schwersten Zweigs folgt. OTFPC sollte auch schneller handeln als FCoB. Außerdem sollte die Zufälligkeit von OTFPC das Auftreten von metastabilen Zuständen verhindern.

Wenn Sie mehr über OTFPC erfahren möchten, können Sie unseren iota.cafe-Beitrag lesen.

Es ist sehr wichtig zu betonen, dass sich dieser Ansatz nicht radikal von dem unterscheidet, was wir bisher gemacht haben. Obwohl FPC viel Aufmerksamkeit erhalten hat, war das Genehmigungsgewicht immer der Eckpfeiler des Protokolls. Außerdem wurde FPC (und sein Cousin FPC on a set) immer als mathematisches Modell ohne explizite Implementierung untersucht. Unsere Entwicklung ist einfach eine neue Implementierung dieses mathematischen Modells.

Alle Forschungen und Experimente, die mit FPC durchgeführt wurden, sind immer noch relevant, da FPC auf einer Menge nur eine Variante davon ist, mit dem Hauptunterschied, dass es bei einer Konfliktmenge immer einen Gewinner auswählt. Beide konvergieren in nur einer „glücklichen“ Runde zum Vorkonsens. Das Auftreten dieser Runde ist jedoch zufällig und erfolgt jedes Mal mit einer gleichmäßig positiven Wahrscheinlichkeit. Deshalb sind wir zuversichtlich, dass das FPCS mathematisch ebenso solide ist wie das FPC. Wir räumen jedoch ein, dass diese neuen Konzepte zwar recht einfach zu verstehen sind und in vielerlei Hinsicht dem, was wir bereits untersucht haben, grundlegend ähneln, dass sie aber noch nicht umfassend analysiert worden sind. Da der Teufel immer im Detail steckt, arbeiten wir weiter an der Verbesserung unserer Studien über ihr Verhalten bei verschiedenen Randfällen und Angriffen. Wie immer werden wir unsere Ergebnisse über unsere Medien, einschließlich akademischer Veröffentlichungen, verbreiten.

Wir freuen uns auf diese bevorstehenden Verbesserungen sowie auf weitere Upgrades für andere Komponenten, wie z. B. die Staukontrolle, an der wir derzeit arbeiten, und wir werden sie mit den nächsten Versionen schrittweise in das IOTA 2.0 DevNet integrieren.

Der weitere Weg

Leider werden die oben genannten Änderungen es unmöglich machen, den Coordicide im Jahr 2021 im IOTA-Mainnet bereitzustellen. Jede neue Idee, jeder neue Aspekt, jede neue Einsicht oder jede neue Gelegenheit durchläuft die zu Beginn dieses Artikels erwähnte Methodik. Das braucht Zeit: Exzellenz ist nicht schnell.

Diese Richtung einzuschlagen war eine schwere Entscheidung für uns und ist wahrscheinlich für einige eine Enttäuschung, und wir sind uns auch bewusst, dass unsere früheren Schätzungen zu ehrgeizig waren. Aber das ändert nichts an unserer Methodik, unserem Kurs und unserem Ziel: Die beste DLT aller Zeiten zu entwickeln. Letztendlich wären wir nachlässig, wenn wir das Protokoll nicht verbessern würden.

Die Lösungen, die wir entwickeln, sind zwar noch nicht fertig, werden aber bereits von einzelnen Entwicklern, Projekten und Industriepartnern eingesetzt. Wir haben das wunderbare Privileg, ein DLT geschaffen zu haben, das das Interesse eines riesigen Ökosystems von globalen, führenden Industrieakteuren, Regierungen, einzelnen Entwicklern und einer Gemeinschaft geweckt hat, denen gegenüber wir die Verantwortung haben, ein zuverlässiges und sicheres Netzwerk zu liefern, auf dem wir mit minimalen Änderungen auf dem Weg aufbauen können.

Das bedeutet auch, dass wir keine Abkürzungen nehmen werden, um den Zeitplan einzuhalten, indem wir eine technische Lösung durchsetzen, die wir ohnehin irgendwann ändern wollen. Unsere Loyalität gilt denjenigen, die uns dabei helfen, die Vision von IOTA Wirklichkeit werden zu lassen: unserer Gemeinschaft von Erbauern und Machern, öffentlichen und Unternehmenspartnern, die sich auf unsere Software verlassen und uns helfen, damit Branchenlösungen zu entwickeln. Sie sind eher an der bestmöglichen Lösung interessiert, als an der schnellsten, aber mittelmäßigen Lösung, die möglicherweise später Änderungen nach sich zieht. Deshalb konzentrieren wir uns auf diejenigen, die mitmachen, beitragen und bauen und die uns helfen, das Potenzial von IOTA auszuschöpfen. Sie sind es, die den Erfolg von IOTA bestimmen werden, von dem letztendlich alle profitieren werden.

Wenn Sie ein Entwickler sind, dann schauen Sie nur auf unsere Repos und den Entwicklungsfortschritt, und Sie werden im Voraus wissen, wann der Coordicide stattfinden wird. Bis dahin haben wir gemeinsam mit dem IOTA 2.0 DevNet noch eine Menge zu erreichen.

Original by William Sanders: https://blog.iota.org/improvements-to-the-iota-2-0-consensus-mechanism/