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 Konsens- und Kommunikationsschicht, um das Protokoll effizienter und weniger komplex zu machen. Die nächsten Schritte umfassen die Implementierung von aktiven Verteidigungsmaßnahmen und Benutzerfreundlichkeitsmerkmalen wie lokalen 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 der Kommunikationsschicht und einige entscheidende Änderungen an der Konsensschicht vorgenommen.
Die Verbesserungen an der Konsensschicht vereinfachen das Protokoll erheblich, indem sie alle Informationen aus dem Tangle ableiten und eingehende Transaktionen auf optimistische Weise behandeln. 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 die Kommunikationsschicht 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 Status und zeichnet ein allgemeines Bild des weiteren Weges.
Konsens-Ebene
Die Vision
Wie in einem früheren Blogbeitrag beschrieben, müssen die Knoten nicht mehr andere Knoten um ihre Meinung bitten, um Konflikte zu lösen, sondern erhalten alle Informationen, die sie benötigen, einfach durch Beobachtung des Tangles. 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 Knoten ihre Meinung durch das Erstellen von Nachrichten 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 Knoten, 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 ähnlicher Schalter 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 Weg nach vorn
Bei reinem OTV legen die Knoten ihre anfängliche Meinung zu Konflikten auf der Grundlage ihrer Wahrnehmung des schwereren Zweigs fest, wodurch sich das Protokoll ähnlich wie die Bitcoin-Regel der längsten Kette verhält. Das bedeutet, dass der Konsens inhärent probabilistisch ist und der Kunde (z. B. ein Knoten, eine Geldbörse oder eine Börse) anhand seiner Sicherheitsschwelle entscheidet, wann er eine Transaktion als bestätigt ansieht (in Bitcoin ist dies als 6-Block-Regel bekannt). Dementsprechend werden wir mehrere Finalitätsgrade (Grades of Finality, GoF) einführen, die hauptsächlich auf dem Genehmigungsgewicht basieren und ansteigende Sicherheitsschwellenwerte definieren. Je höher der Grad, desto höher die Sicherheit. In seltenen Fällen (z. B. wenn ein Knoten verfinstert oder teilweise offline ist) könnte ein Knoten jedoch zu einem späteren Zeitpunkt fehlende Informationen erhalten, was dazu führen könnte, 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 Knotensoftware implementiert werden, um Komponenten, die von der Bestätigung abhängen, zurückzusetzen.
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 Stimmen nach cMana gewichtet. Die absoluten cMana-Werte liefern jedoch möglicherweise nicht genügend Informationen. Stattdessen verwenden wir aktives cMana, um das Gewicht eines Knotens im Verhältnis zu allen kürzlich aktiven Knoten auszudrücken. Daher ist aktives cMana eine entscheidende Komponente, die gründlich untersucht werden muss, um ihre Grenzen und Einschränkungen zu verstehen.
Kommunikationsebene
Die Vision
Bei herkömmlichen, auf Proof of Work basierenden Distributed-Ledger-Technologien (DLTs) wird das Recht, eine neue Nachricht in das Hauptbuch aufzunehmen, durch den Mining-Prozess garantiert, bei dem einer der Knoten nach Abschluss einer rechenintensiven Aufgabe gewählt wird. Als Anreiz für die Durchführung einer solchen Aufgabe erhält der siegreiche Knoten Transaktionsgebühren und Blockbelohnungen. Bei solchen DLTs dienen die Gebühren als Filter, um auszuwählen, welche Nachrichten dem Hauptbuch 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 Verkehrsausbrüche.
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 Transaktionsverarbeitungsmöglichkeiten begrenzt sind. Darüber hinaus kann ICCA von Low-End-Knoten effizient genutzt werden, da es keine teuren Aufgaben oder Gebühren erfordert. Unsere Lösung bietet mehrere weitere grundlegende Funktionen:
- Konsistenz: Alle Knoten schreiben letztendlich die gleichen Nachrichten in ihr lokales Hauptbuch.
- Fairness: Der Netzzugang wird proportional zu einer „knappen Ressource“ gewährt, nämlich dem Zugangsmana (siehe unten).
- Effizienz: Wenn die Nachfrage besteht, wird das volle Potenzial des Netzes genutzt.
Wo wir im Moment sind
Dieser Unterabschnitt beschreibt die Aktionen, die ein Knoten ausführen muss, wenn eine neue Nachricht erstellt wird und wenn eine Nachricht von einem Nachbarn empfangen wird, und die derzeit im IOTA 2.0 DevNet implementiert sind.
Erzeugung von Nachrichten
Eine Menge namens access Mana gibt den Knoten Schreibrechte. Aus Sicht des Benutzers bedeutet Access Mana einen bestimmten Durchsatz für den Knoten. Interessanterweise passt sich dieser Durchsatz an die aktuellen Verkehrsbedingungen an: Die Knoten erhöhen schrittweise ihre Nachrichtengenerierungsrate (Durchsatz) bis zu dem Punkt, an dem eine Überlastung festgestellt wird; sobald dies der Fall ist, wird der Durchsatz reduziert. Die Knoten erkennen eine Überlastung, indem sie die Anzahl ihrer eigenen Nachrichten in der Warteschleife in ihrem Ausgangspuffer betrachten.
Nachrichtenempfang
Nachdem eine neu empfangene solide Nachricht (siehe nächster Abschnitt) bestimmte Validierungsfilter (z. B. Signaturprüfung und syntaktische Validierung) durchlaufen hat, wird sie dem lokalen Hauptbuch hinzugefügt. Danach wird die Nachricht an den Postausgangspuffer angehängt, der von einem Scheduler verwaltet wird, um zu entscheiden, welche Nachricht zu den Tipps hinzugefügt und an die Nachbarn weitergegeben werden soll. Der Scheduler verwendet einen leichtgewichtigen Round-Robin-Algorithmus, um eine große Anzahl von Nachrichten gleichzeitig effizient zu verarbeiten. Kürzlich haben wir den Scheduler nach der Nachrichtenbuchung verschoben, um das Resynchronisationsverfahren zu optimieren.
Verfestigung
Vertiefung/Solidification ist der Prozess der Anforderung von Nachrichten, deren vergangener Konus einem Knoten noch nicht bekannt ist. Ähnlich verhält es sich bei Transaktionen: Die verbrauchten Outputs (Inputs) einer Transaktion müssen einem Knoten bekannt sein, damit die Transaktion ordnungsgemäß validiert werden kann. In der Vergangenheit verlangte das Protokoll, dass alle Eingaben einer Transaktion im Vergangenheitskegel der enthaltenen Nachricht liegen. Um zu überprüfen, ob sich etwas im Vergangenheitskegel befindet, muss man möglicherweise durch das Tangle laufen, 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 bessere Parallelisierung ermöglicht.
Der Weg nach vorn
Widerstand gegen Angriffe
Bei DLTs haben böswillige Knoten ein großes Interesse daran, das Funktionieren des Netzes 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 Nachrichten von ehrlichen Knoten verzögert, da sie nicht gemäß dem aktuellen Zugriffs-Mana-Vektor eingeplant werden. Daher bleiben die vom Angreifer verschickten Nachrichten lange Zeit im Postausgang der ehrlichen Knoten. Obwohl dies die Leistung ehrlicher Nachrichten nicht beeinträchtigt, ist es aus zwei Gründen wichtig, solche bösartigen Verhaltensweisen zu erkennen: (i) der Angreifer kann die Anzahl der Nachrichten in den Postausgängen seiner Nachbarn aufblähen, so dass ihnen die Ressourcen ausgehen; (ii) ehrliche Knoten können zusätzlich zu den böswilligen Nachrichten noch weitere angehängt haben, was zu inkonsistenten Ledgern auf allen Knoten führt. Um diese Probleme zu überwinden, werden wir böswillige Knoten auf eine schwarze Liste setzen, indem wir ihre Nachrichten verwerfen. Bösartige Ströme werden erkannt, wenn die Anzahl ihrer Nachrichten 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 Knoten 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 Zeitstempel in den Nachrichten zu haben. So sollten beispielsweise alte Nachrichten nicht in den Scheduler aufgenommen werden, da sie mit hoher Wahrscheinlichkeit bereits von den Nachbarn empfangen worden sind. Auch das Anhängen an alte Nachrichten ist unerwünscht, da dies die Bestätigungszeit für neue Nachrichten erhöhen würde (wir gehen davon aus, dass alte Nachrichten bereits validiert wurden). Darüber hinaus werden genaue Zeitstempel benötigt, um eine schnelle Resynchronisierung 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 Nachricht als „neu“ und bereit zur Einplanung angesehen wird: Diese Metrik berücksichtigt den Zeitstempel der Nachricht und die Belegung der Nachrichten durch den Scheduler des ausstellenden Knotens.
Benutzererfahrung
Der Durchsatz eines Knotens wird durch den Rate Setter Algorithmus reguliert. Das bedeutet, dass die Knoten im Falle einer Überlastung nicht kontinuierlich Nachrichten generieren können, da sie von ICCA bestraft werden würden. Wir arbeiten derzeit an der Bereitstellung von Schätzungen des Knotendurchsatzes, der als Funktion des Zugriffs-Mana-Vektors berechnet wird. Mit einer vernünftigen Schätzung wäre es möglich, die folgende Frage zu beantworten: Angenommen, ein Benutzer (eine Wallet oder ein Knoten) hat eine neue Nachricht zu veröffentlichen: Welcher Knoten sollte gewählt werden, damit diese Nachricht schnell zum IOTA-Ledger hinzugefügt wird? Diese Forschungsrichtung versucht, neue Nachrichten den Knoten 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 Nachrichtenersteller oder der Verzögerung pro Knoten basieren.
Andererseits ist zu bedenken, dass die Zeit, die für die Zustellung einer Nachricht an alle Knoten benötigt wird, (fast) unabhängig von der Zugriffs-Mana des ausstellenden Knotens ist. Dies bedeutet, dass der Zugriffs-Mana-Vektor nur die Rate regelt, mit der neue Nachrichten 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 Nachrichten unter normalen Bedingungen nur Bruchteile von Sekunden im Scheduler verbleiben; bei hohem Verkehrsaufkommen 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 Knoten benötigt wird, um Nachrichten ausgeben zu können: Wenn dieser Schwellenwert niedriger ist, können trivialerweise mehr Knoten Nachrichten ausgeben und potenziell Staus verursachen. Wir arbeiten derzeit daran, diesen Schwellenwert opportunistisch an das aktuelle Verkehrsaufkommen anzupassen.
Schnappschüsse
Das Tangle kann sehr groß werden, und nicht jeder Nutzer wird in der Lage sein, seine gesamte Geschichte bis zurück zur Entstehung zu verfolgen. Daher sollten lokale Schnappschüsse es den Knoten ermöglichen, ihre Datenbank sicher zu bereinigen, d. h. ausreichend alte Daten können gelöscht werden, ohne die Sicherheit des Netzes zu beeinträchtigen. Schnappschüsse hängen von vielen Teilen des Protokolls ab und haben direkte Auswirkungen auf die Partitionstoleranz, da Partitionen nicht über lokale Schnappschüsse hinaus zusammengeführt werden können. Sie stehen auch in engem Zusammenhang mit der vertrauenslosen Synchronisierung, da Knoten ohne die gesamte Historie, die bis zur Entstehung zurückreicht, den Zustand des Ledgers nicht ohne einen zusätzlichen Mechanismus, wie z. B. Merkle-Baum oder polynomielle Zusagen, ü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 führerlosen, gebührenfreien und erlaubnisfreien 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 zu nutzen machen werden.
Sobald wir alle erforderlichen Änderungen implementiert haben, werden wir das IOTA 2.0 DevNet aktualisieren und die IOTA-Gemeinschaft 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.
Original by IOTA Foundation: https://blog.iota.org/iota-2-0-details-on-current-status-and-outlook/
Schreibe einen Kommentar