In den folgenden Kapiteln erklären wir in eher allgemeinen Worten, wie das neue, dezentrale IOTA-Protokoll funktioniert. Unser Ziel ist es hier nicht, den Detaillierungsgrad unserer Forschungsspezifikationen zu erreichen, sondern eine einigermaßen detaillierte Erklärung zu liefern, die den Benutzern eine gute Vorstellung über die allgemeinen Prozesse “unter der Haube” nennen sollte, die in IOTA am Werk sind. Vollständige Dezentralisierung zu erreichen und gebührenfrei zu sein, ist etwas komplizierter, als sich einfach darauf zu verlassen, dass Dritte einen Anreiz haben, ein Netzwerk zu sichern, indem sie monetäre Anreize bieten, wie in PoW- oder PoS-basierten Protokollen.
Im Vorgriff auf die bevorstehende Veröffentlichung von IOTA 2.0 DevNet (Nectar) wollten wir eine kurze Erklärung nennen, wie das IOTA 2.0-Protokoll (Coordicide) funktioniert. Während IOTA 2.0 ein komplexes Protokoll mit verschiedenen Modulen ist, ist die Kernidee eigentlich recht einfach. Dieser Beitrag fasst zusammen, wie IOTA 2.0 den Konsens erreicht und das Ledger verwaltet.
Daten und Transaktionen sind in Objekten enthalten, die Nachrichten genannt werden. Jede Message muss zwei bis acht andere Messages referenzieren. Somit ist die Sammlung aller Messages, Tangle genannt, ein ständig wachsender DAG, oder ein gerichteter azyklischer Graph.
Derzeit wird das Chrysalis-Netzwerk vom Koordinator gesteuert, einem zentralen Knoten, der von der IOTA Foundation betrieben wird. Der Koordinator gibt an, welche Transaktionen und Daten in das Ledger, d.h. die Liste der Token-Guthaben aller Benutzer, aufgenommen werden. Um vollständig dezentralisiert zu sein, werden wir den Koordinator in Version 2.0 des IOTA-Protokolls entfernen. Im Coordicide-Projekt haben wir ein neues Protokoll entworfen, das den Koordinator abschaffen wird.
Ohne den Koordinator, der entscheidet, welche Transaktionen aufgenommen werden sollen, muss eine gültige Nachricht eine konsistente Historie ohne Konflikte haben. Wenn also Konflikte auftreten, gabelt sich der Tangle in verschiedene Zweige. Das IOTA 2.0 Protokoll muss zwei Dinge tun:
- Entscheiden, welche Zweige überleben werden.
- Diese Entscheidung für neue Nodes, die dem Netzwerk später beitreten, aufzeichnen.
Dies erlaubt dem IOTA-Protokoll, ein konsistentes Ledger aufrechtzuerhalten, in dem der Kontostand von jedem immer verfügbar ist.
Betrachten Sie das folgende Beispiel: Dom hat 5 MIOTA. Zuerst sendet er über Transaktion A diese 5 MIOTA an Navin. Dann sendet Dom versehentlich (oder absichtlich) dieselben 5 MIOTA an Serguei in Transaktion B. Jetzt haben wir zwei sich widersprechende Transaktionen, A und B, und der Tangle gabelt sich in drei Zweige: Zweig 1, der A enthält, Zweig 2, der B enthält, und Zweig 3, der sowohl A als auch B ablehnt.
Das Protokoll muss zwischen den folgenden Möglichkeiten entscheiden:
- Zweig 1, der Transaktion A enthält, wird abgelehnt und nennt Sergej die 5 IOTA.
- Zweig 2, einschließlich Transaktion B, wird abgelehnt, wodurch Navin die 5 IOTA erhält.
- Beide Zweige 1 und 2 werden zusammen mit den Transaktionen A und B abgelehnt, so dass Dom seine 5 IOTA erhält.
Angenommen, das Protokoll lehnt Zweig 1 ab. Dann werden die Zweige 2 und 3 überleben, und schließlich wird Zweig 2 Zweig 3 “schlucken”, da Zweig 3 nicht mit Zweig 2 in Konflikt steht. Ein Angreifer kann jedoch Zweig 1 aufrechterhalten. Das Protokoll muss neuen Nodes, die dem Netzwerk beitreten, mitteilen, dass Zweig 1 abgelehnt wird.
Ein Angreifer kann viele Konflikte mit komplizierten Abhängigkeiten erzeugen und so ein kompliziertes Netz von Zweigen schaffen. Mit Hilfe der “Multiversum-Theorie” von Hans Moog (Senior Research Scientist bei IOTA) verfolgt das Zweigverwaltungsmodul effizient alle Zweige im Tangle. Unabhängig von der Komplexität der Verzweigungen wählt das IOTA-Protokoll immer eine einzige Verzweigung und dann einen einzigen gültigen Ledger-Zustand.
Um diese Entscheidungen zu treffen, arbeitet das IOTA 2.0-Protokoll in einem Zyklus:
Bevor wir die einzelnen Module erklären, fassen wir zusammen, wie sie zusammenwirken. Nachrichten gelangen über den Überlastungskontrollalgorithmus, der den Zugang verwaltet, in das Netzwerk. Nodes stimmen über neue Konflikte durch unser Abstimmungsprotokoll FPC ab, das bestimmt, welche Zweige abgelehnt werden sollen. Die FPC-Abstimmung ist vor Angreifern durch Mana geschützt, ein Reputationssystem, das fairerweise einschränkt, wer abstimmen darf. Nachdem FPC schlechte Zweige abgelehnt hat, werden aus den korrekten Zweigen Tips ausgewählt, auf die neue Messages verweisen sollen. Wenn diese korrekten Zweige mehr Messages erhalten, sagen wir, dass ihr Zustimmungsgewicht wächst. Sobald ein Zweig genug Zustimmungsgewicht erhält, werden seine Transaktionen abgeschlossen und im Ledger verbucht, und das Mana wird aktualisiert, wodurch die nächsten FPC-Wähler bestimmt werden.
Mana: In jeder Transaktion verpfänden Token-Inhaber Konsens-Mana an Nodes. Da diese Verpfändungen Token erfordern, können Angreifer nur so viel Mana haben. Siehe unsere Blog-Beiträge Erklärungen zu Mana in IOTA Teil 1 und Teil 2 für weitere Erklärungen.
FPC-Abstimmung: Wenn neue Messages im Netzwerk eintreffen, lösen Konflikte das Abstimmungsprotokoll Fast Probabilistic Consensus, kurz FPC, aus. Zunächst entscheiden die Nodes, welche konfligierenden Transaktionen sie mögen, basierend darauf, was zuerst eingetroffen ist. Dann stimmt jede Node ab, indem er ein paar andere Nodes direkt fragt, welche Transaktionen sie mögen. Wenn genügend dieser Nodes eine Transaktion mögen (wobei “genügend” ein zufälliger Schwellenwert ist), mag die Node sie auch. Dann fragt jede Node wieder ein paar andere Nodes nach ihrer Meinung und wiederholt den Prozess mehrere Runden, bis sich alle Meinungen stabilisieren.
Mana schützt die FPC-Abstimmung: Je mehr Consens-Mana eine Node hat, desto öfter fragen andere Nodes nach seiner Meinung. Mathematische Analysen und Simulationen zeigen, dass FPC fast immer korrekt mit allen ehrlichen Nodes in Übereinstimmung endet, wenn der Angreifer eine signifikante Menge an aktivem Consens-Mana hat.
Tip-Auswahl: Nach der Beendigung von FPC hat das Protokoll effektiv ausgewählt, welche Zweige abgelehnt werden sollen: Jeder Zweig, der eine von FPC missliebige Transaktion enthält, wird abgelehnt. Beim Erstellen einer neuen Nachricht wählen die Nodes zufällig Tips (nicht referenzierte Messages) aus den überlebenden Zweigen aus.
Approval Weight (Genehmigungsgewicht): Das Genehmigungsgewicht eines Zweigs ist im Wesentlichen die Menge an Consens-Mana, die von Nodes gehalten wird, die eine Message auf diesem Zweig erstellt haben. Da alle ehrlichen Nodes ihre neuen Messages an nicht abgelehnte Zweige anhängen, wird das Zustimmungsgewicht dieser Zweige schnell groß, während das Zustimmungsgewicht eines abgelehnten Zweigs klein bleibt.
Neue Nodes, die dem Netzwerk beitreten, können auf die Ergebnisse früherer FPC-Abstimmungen schließen, die sie verpasst haben, indem sie beobachten, welche Zweige schwer genug sind und welche nicht.
Finalität: Finalität misst die Wahrscheinlichkeit, dass eine Message nicht verwaist wird. In IOTA 2.0 wird die Message final, wenn sie von genügend Nachrichten indirekt referenziert wird (gewichtet mit dem Consens-Mana ihrer Aussteller), was garantiert, dass die Message tief im Tangle steckt und nicht verwaist wird. Im IOTA 2.0 DEVNET-Prototyp geschieht dies innerhalb von Sekunden.
Wir hoffen, dass dieser Überblick hilfreich ist, um die grundlegende Funktionsweise des Protokolls zu verstehen. Bitte lesen Sie weiter, um mehr zu erfahren!