29. Jul’21
Übersetzung des Blogartikel von Autor William Sanders, Direktor der Forschungsabteilung, IOTA-Foundation.
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.
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:
- Definieren Sie das Problem
- Brainstorming von Ideen zur Lösung des Problems
- Vielversprechende Ideen in Lösungen umwandeln
- Untersuchung der Lösungen mit einer Vielzahl von Methoden und aus verschiedenen Blickwinkeln: analytisch, durch Simulationen, durch Experimente
- Synthetisieren Sie die gesammelten Daten und sammeln Sie die Lehren aus Punkt 4, um sie zur Verbesserung der Lösung zu 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, so dass 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 erproben 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 Leader (dt. Anführer) funktioniert. In seinem Kern kombiniert er
- ein binäres Abstimmungsprotokoll (FPC) als Vor-Konsens und Metastabilitätsbrecher (d.h. er zwingt das System zu einer Entscheidung),
- und ein virtuelles Voting-Protokoll (dt. Abstimmungsprotokoll) oder Approval Weight (AW, dt. Zustimmungsgewicht), das eine Endgültigkeit ähnlich der Regel der längsten Kette im Nakamoto-Konsens (heaviest branch, dt. 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 Nodes aus der Synchronisation fallen. Daher ist das Zustimmungsgewicht notwendig, damit Nodes, 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 Zustimmungsgewichtung der einzelnen Konflikte verwenden. Bei FPC fragt eine Node einfach andere Nodes 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:
- Starke Vereinfachung unserer Codebasis
- Verringerung des Kommunikations-Overheads
- Beschleunigung der Bestätigungszeiten
FPC
Das Fast Probabilistic Consensus (FPC)-Protokoll ist ein binäres Abstimmungsprotokoll, bei dem jede Node mit einer anfänglichen Meinung zu einer von FCoB festgelegten Transaktion beginnt. Die Nodes tauschen dann in mehreren Runden Abfragen und Antworten über ihre Meinungen aus, bis jede Node mit einem endgültigen Wert abschließt: like oder dislike. 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 Tip-Pool aufgenommen und verwaisen eventuell (werden nicht mehr berücksichtigt).
Ohne einen eindeutigen Gewinner könnten neue Nodes, die dem Netzwerk beitreten, oder bestehende Nodes, die fehlende Message 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 “like” setzen und somit versuchen, ihre neuen Messages 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 jedoch mit zusätzlichen Informationen in den FPC-Anweisungen verbunden ist.
Approval Weight (AW)
Das Zustimmungsgewicht einer Message misst den prozentualen Anteil des aktiven Konsens-manas der Nodes, die eine Message in ihrem Future Cone ausgegeben haben (d.h. durch direkte oder indirekte Referenzierung). Darüber hinaus wird das Zustimmungsgewicht so berechnet, dass das Konsens-mana einer Node nicht auf das Zustimmungsgewicht von zwei konkurrierenden Transaktionen angerechnet werden kann. Nehmen wir zum Beispiel an, dass A und B kollidierende Transaktionen sind. Ich bin eine Node mit hohem Mana und gebe eine Message heraus, die sich auf A bezieht, dann trägt mein Konsens-mana zum Zustimmungsgewicht von A bei. Wenn ich aber später eine Message herausgebe, die B genehmigt, dann wird mein Konsens-mana vom Zustimmungsgewicht 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 Message (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 seinem On Tangle Voting Vorschlag. In seinem Vorschlag würden die Nodes immer Tips 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 festzuhalten, dass das aktuelle Protokoll nicht grundsätzlich 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 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 Nodes im Netzwerk nach ihrer Meinung zu einer Transaktion und entscheiden anhand des Prozentsatzes der positiven Antworten und eines zufälligen Schwellenwerts, ob unsere Meinung in der nächsten Runde “like” oder “dislike” sein soll.
In OTFPC verwenden wir anstelle von direkten Abfragen die Zustimmungsgewichtung. Da die Nodes ihr Konsens-mana nicht auf das Zustimmungsgewicht von zwei verschiedenen Konflikten setzen können, ist das Zustimmungsgewicht einer Abfrage sehr ähnlich, wobei die abgefragten Nodes im Wesentlichen diejenigen sind, die diese Message referenziert haben. OTFPC arbeitet nach wie vor in Runden, wobei eine Node in jeder Runde anhand der Zustimmungsgewichtung und eines zufälligen Schwellenwerts entscheidet, welche Transaktionen er favorisiert (liked). Die favorisierten Transaktionen bestimmen, welche Messages für die Tip-Auswahl in Frage kommen, und so erhalten nur favorisierte Transaktionen ein Zustimmungsgewicht.
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 Nodes erforderliche Bandbreite verringert.
Zweitens: Anstatt bei jeder Message eine binäre Entscheidung zwischen “Ja” und “Nein” zu treffen, wählen die Nodes mittels FPC einen Gewinner aus einer Liste konkurrierender Transaktionen. 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 favorisieren. Im Gegensatz zu FCoB verwendet OTFPC keine Quarantänezeiten, die zu längeren Bestätigungszeiten führen könnten. Eingehende Messages werden sofort zum Tip Set hinzugefügt, so dass jede Node seine Präferenz ausdrücken und eine Stimme für eine bestimmte Transaktion innerhalb eines Konfliktsets durch Tip Selection abgeben kann. Wie beim Mechanismus der Zustimmungsgewichtung wird die lokale Präferenz einer Node durch die Konsens-Mana-Gewichtung bestimmt, die mit einer bestimmten konfliktbehafteten Transaktion über direkte und indirekte Verweise auf diese verbunden ist. Somit wird OTFPC die lokale Meinung einer Node zu einer bestimmten Transaktion besser an dessen Zustimmungsgewicht anpassen, da es der gleichen “heaviest branch”-Regel 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 grundlegend von dem unterscheidet, was wir bisher getan haben. Obwohl FPC viel Aufmerksamkeit erhalten hat, war das Zustimmungsgewicht 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 Versuche, die mit FPC gemacht 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 Vor-Konsens. Das Zustandekommen dieser Runde ist jedoch zufällig, und zwar jedes Mal mit gleichmäßig positiver 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 congestion control (dt. Überlastungskontrolle), 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 Mainnet von IOTA 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 Community geweckt hat, denen gegenüber wir die Verantwortung haben, ein zuverlässiges und sicheres Netzwerk zu liefern, auf dem wir aufbauen können, mit minimalen Änderungen auf dem Weg.
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 Community 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, bauen und die 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 zusammen mit dem IOTA 2.0 DevNet noch eine Menge zu erreichen.
Wie immer heißen wir jeden willkommen, auf Discord vorbeizuschauen – unser Team wird mehr als glücklich sein, alle eure Fragen zu beantworten!
– – –
Anhang: FCoB
Obwohl es nicht unbedingt notwendig ist, um den obigen Beitrag zu verstehen, dachten wir, dass eine Erklärung der FCoB-Regel die Dinge klarer machen könnte. Die Fast-Consensus-of-Barcelona-Regel (FCoB) wurde entwickelt, um eine erste Meinung für jede Transaktion festzulegen und die Anzahl der erforderlichen Abstimmungen über FPC zu minimieren. Grob gesagt, verwendet FCoB zwei Quarantänezeitintervalle, nennen wir sie Q1 und Q2. Für jede empfangene Transaktion legt eine Node die Transaktion X für die Dauer von Q1 (z. B. 5 Sekunden) in einem Puffer ab. Während dieses ersten Zeitintervalls (Q1) können verschiedene Fälle eintreten:
- Wenn eine andere Transaktion Y eintrifft, die mit X kollidiert, erhalten beide Transaktionen eine anfängliche Meinungsabweichung und es wird aktiv über FPC abgestimmt;
- Wenn innerhalb von Q1 keine Konflikte mit X festgestellt wurden, legt die Node die Transaktion X für die Dauer von Q2 (z. B. 5 Sekunden) in einen zweiten Puffer und setzt seine anfängliche Meinung auf like.
Ähnlich wie beim ersten Zeitintervall können auch während der zweiten Quarantänezeit (Q2) verschiedene Fälle eintreten:
- Wenn eine andere Transaktion Y eintrifft, die mit X in Konflikt steht, erhält Y eine anfängliche Meinung von Abneigung, und sowohl X als auch Y werden über FPC abgestimmt;
- Wenn keine Konflikte mit X festgestellt wurden, fügt die Node schließlich die Message mit der Transaktion X zu ihrem Tip-Pool hinzu, so dass sie als Tipp ausgewählt werden kann.
Sobald eine Node seine lokale Meinung zu einer Transaktion X definiert hat, entweder über FCoB oder nach Abschluss der FPC, erhält jede nachfolgende neue Transaktion, die mit X in Konflikt steht, eine lokale Meinung der Ablehnung. Letztendlich ist die Kombination aus FCoB und FPC nur ein Vor-Konsens-Mechanismus. Das Zustimmungsgewicht, das auf dem Future Cone jeder Message aufbaut, diktiert den Finalitätsstatus einer Message sowie die darin eingebettete Transaktion. Wenn also eine Node die falsche Meinung für eine Transaktion festlegt, kann sie diese anhand ihres approval weight ( dt. Zustimmungsgewicht) korrigieren.
Es ist klar, dass die Festlegung der Dauer der beiden Quarantänezeitintervalle Q1 und Q2 entscheidend ist. Die korrekte Ausführung von FCoB beruht nicht nur auf der Annahme, dass der Großteil des Netzwerks jede Message innerhalb dieser Intervalle erhält, sondern die Intervalle wirken sich auch auf die Gesamtbestätigungszeit jeder Transaktion aus, selbst der ehrlichen.
Nehmen wir ein Beispiel und setzen Q1 = Q2 = 5 Sekunden. Jede neue Transaktion X, die von einer Node empfangen wird, muss Q1 + Q2 = 10 Sekunden warten, bevor sie in den Tip-Pool gelangt und als Tip verfügbar wird. Erst wenn die Mehrheit der aktiven Konsens-Mana-Nodes eine Message ausgibt, die X direkt oder indirekt billigt, gilt unsere Transaktion als bestätigt.
Eine Verringerung der Werte für Q1 und Q2 würde sicherlich zu kürzeren Bestätigungszeiten führen, allerdings mit der Einschränkung, dass ihre Werte nicht kleiner als die maximale Netzwerkverzögerung sein können.
Quellen
https://blog.iota.org/improvements-to-the-iota-2-0-consensus-mechanism/