20. Sep’21
Übersetzung des IOTA Blogartikel.
TL;DR:
Wir geben einen detaillierten Überblick über den aktuellen Stand und die nächsten Schritte für IOTA 2.0. Die aktuellen Bemühungen konzentrieren sich hauptsächlich auf die Optimierung der Consensus- und Communication-Layer, um das Protokoll effizienter und weniger komplex zu machen. Die nächsten Schritte umfassen die Implementierung von aktiven Verteidigungsmaßnahmen und Benutzerfreundlichkeitsmerkmalen wie beispielsweise lokale Snapshots.
Einführung
Die Veröffentlichung des DevNet für IOTA 2.0 stellt einen der wichtigsten Meilensteine in der Geschichte der IOTA Foundation dar. Zum ersten Mal waren wir nicht nur in der Lage, die Ideen hinter IOTA 2.0 in einem echten, vollständig dezentralisierten und koordinatorenfreien Netzwerk zu demonstrieren, sondern wir konnten auch das Zusammenspiel der verschiedenen Komponenten untersuchen.
Die Möglichkeit, die Leistung jeder dieser Komponenten zu messen und zu bewerten, hat es uns ermöglicht, eine Reihe von Optimierungen zu diskutieren und zu beschließen, um das Protokoll robuster, effizienter und weniger komplex zu machen.
Bei den meisten Änderungen handelt es sich um kleine Optimierungen des Datenflusses und Codevereinfachungen. Aber wir haben auch Anpassungen an dem Communication-Layer und einige entscheidende Verbesserungen an dem Consensus-Layer vorgenommen.
Die Verbesserungen an dem Consensus-Layer vereinfachen das Protokoll erheblich, indem alle Informationen aus dem Tangle abgeleitet werden und eingehende Transaktionen optimistisch behandelt werden. Die erste Implementierung ist abgeschlossen, und wir arbeiten gleichzeitig an detaillierten Simulationen und Forschungspapieren. Es müssen nur noch einige wenige Änderungen vorgenommen werden, während wir einen klaren Weg einschlagen.
Was den Communication-Layer betrifft, so wird derzeit ein effizienter Scheduling-Algorithmus im IOTA 2.0 DevNet implementiert. Dieser arbeitet mit einem Rate Setter Modul, um Fairness und kurze Verzögerungen zu gewährleisten. In einem nächsten Schritt werden wir einen Mechanismus zur Bestrafung von Angreifern implementieren, der bereits spezifiziert ist. Außerdem arbeiten wir derzeit an einer verbesserten Benutzerfreundlichkeit, um die Nutzung des Netzwerks zu erleichtern.
Dieser eher technische Blog-Beitrag geht auf die Details der IOTA 2.0-Verbesserungen ein, beschreibt den aktuellen Stand und zeichnet ein allgemeines Bild des weiteren Weges.
Consensus-Layer
Die Vision
Wie in einem früheren Blogbeitrag beschrieben, müssen die Nodes nicht mehr andere Nodes nach ihrer Meinung fragen, um Konflikte zu lösen, sondern erhalten alle Informationen, die sie benötigen, einfach durch Beobachtung des Tangle. Das daraus resultierende Protokoll ist der ursprünglichen Vision von IOTA sehr ähnlich, die einen reinen Konsens im Nakamoto-Stil ohne zusätzlichen Abstimmungs-Overhead verwendete, bei dem die Nodes ihre Meinung durch das Erstellen von Messages im Tangle kundtun.
Bei FCOB+FPC wurde jede Transaktion mit einer Quarantänezeit bestraft, um eine anfängliche Meinung festzulegen und die Metastabilität im seltenen Fall von Konflikten, die nicht rechtzeitig gelöst werden können, von vornherein zu brechen. Im Gegensatz dazu erlauben die Änderungen am Konsens den Nodes, ihre Meinung zu äußern, ohne eine Quarantänezeit anzuwenden. Erst wenn ein Konflikt für einige Zeit ungelöst ist, wird ein Metastabilitätsmechanismus wie FPCS aktiviert, um den Konflikt zu entscheiden. Dieses optimistische Verfahren beschleunigt nicht nur die Bestätigungszeiten, sondern macht das Protokoll auch viel einfacher und schlanker.
Wo wir gerade stehen
Die Umsetzung der Verbesserungen des Konsensverfahrens schreitet zügig voran: Eine erste Implementierung des reinen On Tangle Voting (OTV) als modulare Konfliktauswahlfunktion und des Like-Switch ist abgeschlossen, und wir befinden uns derzeit in der Test-, Fehlerbehebungs- und Dokumentationsphase. Unmittelbare nächste Schritte sind die Vereinfachung der Marker für das Approval Weight (AW) und die Aktualisierung des Toolings, d.h. der GUI-Wallet, der Bibliothek und ihrer Dokumentation.
Die erste Version unseres auf FPC basierenden Metastabilitätsunterbrechers wurde von der Wissenschaft gründlich validiert (FPC-BI, Fast Probabilistic Consensus with Weighted Votes). Die gleichen Ergebnisse und Konzepte können auf unseren aktuellen optimierten Vorschlag ausgeweitet werden, der eine einfache Modifikation des ursprünglichen FPC ist und in Kürze in einer strengen wissenschaftlichen Abhandlung veröffentlicht werden wird. Wir werden unsere Validierung fortsetzen, indem wir ein wissenschaftliches Forschungspapier erstellen, das die Stärke unseres verbesserten Konsensmechanismus demonstriert.
Neben der Beschreibung des OTV-Mechanismus werden wir seine Leistung durch umfangreiche Simulationsstudien auf der Grundlage des Multiversum-Simulators analysieren, der derzeit erweitert wird, um als allgemeiner Simulationsrahmen für unseren Konsens zu dienen. Dazu gehören die Untersuchung der Bestätigungszeiten und der Widerstandsfähigkeit in verschiedenen Double-Spend-Szenarien sowie die Berücksichtigung eines ungünstigen Umfelds. Schließlich werden wir OTV zusammen mit FPC on a set (FPCS) einbeziehen und die Auswirkungen dieser Symbiosen im Detail untersuchen.
Der weitere Weg
Bei reinem OTV legen die Nodes ihre anfängliche Meinung zu Konflikten auf der Grundlage ihrer Wahrnehmung des heavier branch (dt,. schwersten Zweig) fest, wodurch sich das Protokoll ähnlich wie die Longest-Chain-Regel von Bitcoin verhält. Das bedeutet, dass der Konsens inhärent probabilistisch ist und der Kunde (z. B. eine Node, eine Wallet oder eine Börse) anhand seiner Sicherheitsschwelle entscheidet, wann er eine Transaktion als bestätigt ansieht (dies ist in Bitcoin als 6-Block-Regel bekannt). Dementsprechend werden wir mehrere Finalitätsgrade (Grades of Finality, GoF) einführen, die hauptsächlich auf dem Approval Weight (dt. Genehmigungsgewicht) basieren und ansteigende Sicherheitsschwellenwerte definieren. Je höher der Grad, desto höher die Sicherheit. In seltenen Fällen (z. B. wenn eine Node eclipsed oder teilweise offline ist) kann es jedoch vorkommen, dass eine Node zu einem späteren Zeitpunkt fehlende Informationen erhält, was dazu führen kann, dass er seine lokale Wahrnehmung reorganisieren muss, genau wie bei Bitcoin. Glücklicherweise macht eine hohe GoF-Einstellung solche Vorkommnisse praktisch unmöglich. Nichtsdestotrotz muss dieses Reorganisationsverfahren in die Node-Software implementiert werden, um Komponenten zurückzusetzen, die von der Bestätigung abhängen.
Sobald wir eine stabile Version von reinem OTV mit laufender Reorg haben, können wir uns auf die Implementierung eines Mechanismus zur Unterbrechung der Metastabilität konzentrieren, der mit reinem OTV Hand in Hand geht und einsetzt, wenn ein Konflikt zu lange ungelöst bleibt. Konkret werden wir zunächst Fast Probabilistic Consensus on a set (FPCS) als Metastabilitätsunterbrechung implementieren und dabei positive frühere Forschungsergebnisse nutzen. Die modulare Konfliktauswahlfunktion ermöglicht es uns, die Art und Weise, wie wir die anfängliche Meinung festlegen, einfach auszutauschen; daher erfordert auch das Experimentieren mit anderen Ansätzen zur Konsensfindung nur geringfügige Anpassungen des Codes.
Als Sybil-Schutz werden die Stimmabgaben nach cMana gewichtet. Die absoluten cMana-Werte liefern jedoch möglicherweise nicht genügend Informationen. Stattdessen verwenden wir aktives cMana, um das Gewicht einer Node im Verhältnis zu allen kürzlich aktiven Nodes auszudrücken. Daher ist aktives cMana eine entscheidende Komponente, die gründlich untersucht werden muss, um ihre Grenzen und Einschränkungen zu verstehen.
Communication-Layer
Die Vision
In traditionellen, auf Proof of Work basierenden Distributed Ledger Technologien (DLTs) wird das Recht, eine neue Message in das Ledger einzufügen, durch den Mining-Prozess garantiert, bei dem einer der Nodes gewählt wird, nachdem er eine rechenintensive Aufgabe erfüllt hat. Als Anreiz für die Durchführung einer solchen Aufgabe erhält die siegreiche Node Transaktionsgebühren und Blockbelohnungen. Bei solchen DLTs dienen die Gebühren als Filter, um auszuwählen, welche Messages zum Ledger hinzugefügt werden sollen: In Zeiten der Überlastung wird der Betrag der Gebühren folglich größer.
IOTA hingegen soll das Rückgrat der aufstrebenden digitalen Wirtschaft sein, insbesondere der Maschinenwirtschaft. Daher ist ein Protokoll, das Gebühren und High-End-Geräte erfordert, weder machbar noch nachhaltig. Die Abschaffung der Gebühren erfordert jedoch die Einführung eines expliziten Mechanismus zur Bewältigung großer Datenmengen.
In der IOTA Foundation verfolgen wir einen Ansatz, der vom “Standard-Internet” inspiriert ist, um den IOTA Congestion Control Algorithm (ICCA) zu definieren. Im Gegensatz zu DLTs, die auf Proof of Work basieren, ermöglicht unser Ansatz die optimale Nutzung der Netzwerkressourcen, die nur durch die physischen Beschränkungen des Netzwerks in Bezug auf Bandbreite und Transaktionsverarbeitungskapazität begrenzt sind. Darüber hinaus kann ICCA von Low-End-Nodes effizient genutzt werden, da es keine teuren Aufgaben oder Gebühren erfordert. Unsere Lösung bietet mehrere weitere grundlegende Funktionen:
- Konsistenz: Alle Nodes schreiben letztendlich die gleichen Messages in ihr lokales Ledger.
- Fairness: Der Netzzugang wird proportional zu einer “knappen Ressource” gewährt, nämlich dem Access-Mana (siehe unten).
- Effizienz: Wenn die Nachfrage besteht, wird das volle Potenzial des Netzes genutzt.
Wo wir gerade stehen
Dieser Unterabschnitt beschreibt die Aktionen, die eine Node ausführen muss, wenn eine neue Message erstellt wird und wenn eine Message von einem Nachbarn empfangen wird, und die derzeit im IOTA 2.0 DevNet implementiert sind.
Erzeugung von Messages
Eine Menge namens Access-Mana gibt den Nodes Schreibrechte. Aus Sicht des Benutzers bedeutet Access-Mana einen bestimmten Durchsatz für die Node. Interessanterweise passt sich dieser Durchsatz an die aktuellen Datenverkehrsbedingungen an: Die Nodes erhöhen schrittweise ihre Message-Generation-Rate (Durchsatz) bis zu dem Punkt, an dem eine Überlastung festgestellt wird; sobald dies der Fall ist, wird der Durchsatz reduziert. Die Nodes erkennen eine Überlastung, indem sie die Anzahl ihrer eigenen Messages in der Warteschleife in ihrem Ausgangspuffer betrachten.
Message Empfang
Nachdem eine neu empfangene solid Message (siehe nächster Abschnitt) bestimmte Validierungsfilter (z. B. Signaturprüfung und syntaktische Validierung) durchlaufen hat, wird sie dem lokalen Ledger hinzugefügt. Danach wird die Message an den Postausgangspuffer angehängt, der von einem Scheduler verwaltet wird, um zu entscheiden, welche Message zur Menge der Tips hinzugefügt und an die Nachbarn weitergegeben werden soll. Der Scheduler verwendet einen leichtgewichtigen Round-Robin-Algorithmus, um eine große Anzahl von Messages gleichzeitig effizient zu verarbeiten. Kürzlich haben wir den Scheduler nach der Message-Buchung verschoben, um das Resynchronisationsverfahren zu optimieren.
Solidification (dt. Verfestigung)
Solidification ist der Prozess der Abfrage von Messages, deren Past Cone einem Node noch nicht bekannt ist. Ähnlich verhält es sich bei Transaktionen: Die verbrauchten Outputs (Inputs) einer Transaktion müssen einer Node bekannt sein, um die Transaktion ordnungsgemäß validieren zu können. In der Vergangenheit verlangte das Protokoll, dass alle Eingaben einer Transaktion im Past Cone der sie enthaltenden Message liegen müssen. Um zu überprüfen, ob sich etwas im Past Cone befindet, muss man möglicherweise durch das Tangle laufen (von Tx zu Tx), was eine teure Operation ist und sich im DevNet als nicht praktikabel erwiesen hat. Aus diesem Grund wurde die erste Version eines anderen Ansatzes zur Verfestigung implementiert, der nicht nur das Erfordernis des “past cone” beseitigt, sondern auch den Datenfluss vereinfacht und eine stärkere Parallelisierung ermöglicht.
Der weitere Weg
Widerstand gegen Angriffe
Bei DLTs haben böswillige Nodes ein großes Interesse daran, das Funktionieren des Netzwerks zu beeinträchtigen. Aus diesem Grund muss jede Lösung gegen alle potenziellen Bedrohungen validiert werden. Wie wir experimentell bewiesen haben, ist ICCA resistent gegen Angriffe: Wenn Angreifer versuchen, einen schnelleren als den erlaubten Durchsatz zu erreichen, werden ihre Messages von ehrlichen Nodes verzögert, da sie nicht gemäß dem aktuellen Access-Mana Vektor eingeplant werden. Daher bleiben die vom Angreifer verschickten Messages lange Zeit im Postausgang der ehrlichen Nodes. Obwohl dies die Leistung ehrlicher Messages nicht beeinträchtigt, ist es aus zwei Gründen wichtig, solche bösartigen Verhaltensweisen zu erkennen: (i) der Angreifer kann die Anzahl der Messages in den Postausgängen seiner Nachbarn aufblähen, so dass ihnen die Ressourcen ausgehen; (ii) ehrliche Nodes können zusätzlich zu den böswilligen Messages noch weitere angehängt haben, was zu inkonsistenten Ledgern zwischen den Nodes führt. Um diese Probleme zu überwinden, werden wir böswillige Nodes auf eine schwarze Liste setzen, indem wir ihre Messages verwerfen. Bösartige Datenströme werden erkannt, wenn die Anzahl ihrer Messages im Postausgang einen bestimmten Schwellenwert überschreitet. Die Art und Weise, wie dieser Schwellenwert festgelegt wird (der für die schnelle Erkennung von bösartigem Verhalten entscheidend ist, ohne dass ehrliche Nodes auf die schwarze Liste gesetzt werden), wurde in einem kürzlich erschienenen Artikel beschrieben und wird bald in unserem DevNet implementiert.
Es ist auch wichtig, eine genaue Einschätzung der Gültigkeit der Timestamps in den Messages zu haben. So sollten beispielsweise alte Messages nicht in den Scheduler aufgenommen werden, da sie mit hoher Wahrscheinlichkeit bereits von Nachbarn empfangen wurden. Auch das Anhängen an alte Messages ist unerwünscht, da dies die Bestätigungszeit für neue Messages erhöhen würde (wir gehen davon aus, dass alte Messages bereits validiert wurden). Darüber hinaus werden genaue Timestamps benötigt, um eine schnelle Resynchronisation zu gewährleisten und Angreifer davon abzuhalten, die Leistung des Protokolls zu beeinträchtigen. Wir untersuchen derzeit eine Metrik, die so genannte Inklusionsbewertung, die die Wahrscheinlichkeit bewertet, dass eine Message als “neu” und bereit für die Planung angesehen wird: Diese Metrik berücksichtigt den Timestamp der Message und die Belegung des Schedulers der Message durch die ausstellenden Node.
Benutzererfahrung
Der Durchsatz einer Node wird durch den Rate Setter Algorithmus reguliert. Das bedeutet, dass die Nodes im Falle einer Überlastung nicht kontinuierlich Messages generieren können, da sie von ICCA bestraft werden würden. Wir arbeiten derzeit an der Bereitstellung von Schätzungen des Node-Durchsatzes, der als Funktion des Access-Mana-Vektors berechnet wird. Mit einer vernünftigen Schätzung wäre es möglich, die folgende Frage zu beantworten: Angenommen, ein Nutzer (eine Wallet oder eine Node) hat eine neue Message herauszugeben: Welche Node sollte gewählt werden, damit diese Message schnell zum IOTA Ledger hinzugefügt wird? Diese Forschungsrichtung versucht, neue Messages denjenigen Nodes zuzuweisen, die zu einem bestimmten Zeitpunkt weniger ausgelastet sind. Wir haben diese Herausforderung als Optimierungsproblem formuliert und testen einige vorgeschlagene Strategien, die auf der Belegung der Message-Ersteller oder der Verzögerung pro Node basieren.
Andererseits ist zu bedenken, dass die Zeit, die für die Zustellung einer Message an alle Nodes benötigt wird, (fast) unabhängig von der Access-Mana des ausstellenden Nodes ist. Dies bedeutet, dass der Access-Mana-Vektor nur die Rate regelt, mit der neue Messages erstellt werden, aber keinen Einfluss auf die Nutzbarkeit des Netzes hat. Im Durchschnitt dürften die Verzögerungen relativ gering sein: Wir schätzen, dass die Messages unter normalen Bedingungen nur Bruchteile von Sekunden im Scheduler verbleiben; bei hohem Datenaufkommen erhöht sich diese Verzögerung leicht. Im aktuellen Vorschlag gehen wir mit starkem Datenverkehr um, indem wir einen minimalen Mana-Schwellenwert festlegen, der von den Nodes benötigt wird, um Messages ausgeben zu können: Wenn ein solcher Schwellenwert niedriger ist, können trivialerweise mehr Nodes Messages ausgeben und potentiell Staus verursachen. Wir arbeiten derzeit daran, diesen Schwellenwert opportunistisch an das aktuelle Datenaufkommen anzupassen.
Snapshots
Das Tangle kann sehr groß werden, und nicht jeder Nutzer wird in der Lage sein, seine gesamte Historie bis zurück zur Entstehung zu verfolgen. Daher sollten lokale Snapshots es den Nodes ermöglichen, ihre Datenbank sicher zu bereinigen, d.h. ausreichend alte Daten können gelöscht werden, ohne die Sicherheit des Netzwerks zu beeinträchtigen. Snapshots hängen von vielen Teilen des Protokolls ab und haben direkte Auswirkungen auf die Partitionstoleranz, da Partitionen nicht über lokale Snapshots hinaus zusammengeführt werden können. Sie stehen auch in engem Zusammenhang mit der vertrauenslosen Synchronisierung, da Nodes ohne die gesamte Historie, die bis zur Entstehung zurückreicht, den Zustand des Ledgers ohne einen zusätzlichen Mechanismus, wie z. B. Merkle-Tree oder polynomiale Commitments, nicht einfach überprüfen können. Diese Themen werden derzeit erforscht.
Schlussfolgerung
Das IOTA 2.0 DevNet hat unserem Team wertvolle Einblicke in unser Bestreben gegeben, das IOTA Netzwerk mit einem Leaderless, Feeless und Permissionless Distributed Ledger Protokoll vollständig zu dezentralisieren.
Wir haben große Fortschritte in der GoShimmer-Implementierung gemacht, indem wir einige der jüngsten Verbesserungen (insbesondere beim Konsens) hinzugefügt und begonnen haben, die Codebasis zu überarbeiten. Wir freuen uns über diesen iterativen Fortschritt auf dem Weg zu einer stabilen Netzwerkimplementierung, aber es gibt noch einige wichtige Forschungsfragen, die unser Team evaluieren, validieren und dann in GoShimmer implementieren muss. Wir sind zuversichtlich, dass diese Änderungen das Protokoll insgesamt sicherer, einfacher zu implementieren und schneller einsetzbar machen werden.
Sobald wir alle erforderlichen Änderungen implementiert haben, werden wir das IOTA 2.0 DevNet aktualisieren und die IOTA Community zusammen mit unserem Team und unseren Forschungspartnern einladen, sich zu beteiligen und mit dem verbesserten Protokoll zu experimentieren. Auf der Grundlage der Ergebnisse und des Feedbacks aus diesem Netzwerk wird unser Team dann an der Fertigstellung der IOTA 2.0 Spezifikationen arbeiten und mit der Entwicklung einer stabilen Implementierung in Go und Rust beginnen. Dies wird dann zum Start eines incentivierten Testnetzes und schließlich zum “Coordicide” des IOTA Mainnet führen.
Quellen
https://blog.iota.org/iota-2-0-details-on-current-status-and-outlook/