04. Jun’21
Übersetzung des Blogartikel von Autor William Sanders, Director of Research bei der IOTA Foundation.
Während IOTA 2.0 ein komplexes Protokoll mit verschiedenen Modulen ist, ist seine 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 Messages genannt werden. Jede Message muss zwei bis acht andere Messages referenzieren. Somit ist die Sammlung aller Nachrichten, Tangle genannt, ein ständig wachsender DAG, oder ein gerichteter azyklischer Graph.
Derzeit wird das Chrysalis-Netzwerk vom Koordinator gesteuert, einer zentralen Node, 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 Message eine konsistente Historie ohne jegliche Konflikte haben. Wenn also Konflikte auftreten, gabelt sich der Tangle in verschiedene Zweige. Das kommende 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 ermöglicht es 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 widersprüchliche Transaktionen, A und B, und der Tangle gabelt sich in drei Zweige: Zweig 1, der die Transaktion A an Navin enthält, Zweig 2, der die Transaktion B an Serguei enthält, und Zweig 3, der beide Transaktionen an Navin und Serguei ablehnt.
Das Protokoll muss sich zwischen den folgenden entscheiden:
- Zweig 1, einschließlich Transaktion A an Navin, wird abgelehnt, was Serguei die 5 IOTA nennt
- Zweig 2, einschließlich Transaktion B an Serguei, wird abgelehnt, wodurch Navin die 5 IOTA erhält.
- Beide Zweige 1 und 2 werden zusammen mit den beiden Transaktionen an Navin und Serguei 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 “Multiverse-Theorie” von Hans Moog (Senior Research Scientist bei IOTA) verfolgt das Branch-Manager-Modul effizient alle Verzweigungen in dem Gewirr. Unabhängig von der Komplexität der Verzweigungen wählt das IOTA-Protokoll immer einen einzigen Zweig 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. Messages erreichen das Netzwerk über den Congestion-Control-Algorithmus, der den Zugang verwaltet. Nodes stimmen über neue Konflikte durch unser Abstimmungsprotokoll, Fast Probabilistic Consensus (FPC), ab, das bestimmt, welche Zweige abgelehnt werden sollten. 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 Consensus-Mana an Nodes. Da diese Verpfändungen Token erfordern, können Angreifer nur so viel Mana haben. Siehe dazu auch “Mana, ein Schlüsselfeature in der post Koordinator Ära” für weitere Erklärungen.
FPC-Abstimmung: Wenn neue Messages im Netzwerk eingehen, lösen Konflikte das Abstimmungsprotokoll Fast Probabilistic Consensus, kurz FPC, aus. Zuerst entscheiden die Nodes, welche konfliktierenden 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 Consensus-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 Consensus-Mana hat.
Tip-Selektion: Nach der Beendigung von FPC hat das Protokoll effektiv ausgewählt, welche Zweige abzulehnen sind: Jeder Zweig, der eine von FPC missbilligte Transaktion enthält, wird abgelehnt. Beim Erstellen einer neuen Message 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 Consensus-Mana, die von Nodes gehalten wird, die eine Message auf diesem Zweig erstellt haben. Da alle ehrlichen Nodes ihre neuen Nachrichten 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 Nachricht nicht verwaist wird. In IOTA 2.0 wird die Nachricht final, wenn sie von genügend Nachrichten indirekt referenziert wird (gewichtet mit dem Consensus-Mana ihrer Emittenten), was garantiert, dass die Message tief im Tangle ist und nicht mehr verwaist werden wird. Im Nectar-Prototyp geschieht dies innerhalb von Sekunden.
Quellen
https://blog.iota.org/fully-decentralized-iota-explained-in-under-3-minutes/