Nach der Aufregung um die DevNet-Veröffentlichung Anfang Juni ist unser Team ein wenig zu seiner normalen Kadenz zurückgekehrt. Wir arbeiten weiter an der Fertigstellung der Spezifikationen, optimieren bestimmte Aspekte des Protokolls, wie z. B. den Algorithmus zur Staukontrolle, und nehmen unsere Arbeit an Data Sharding wieder auf.
Ein Unterschied besteht jedoch darin, dass uns die im DevNet gesammelten Daten für unsere Arbeit zur Verfügung stehen. Wir hoffen, dass die folgenden Updates für Sie informativ sind, da wir genau erklären, wie diese Daten verwendet werden und was die nächsten Schritte für die IOTA-Forschungsabteilung sein werden.
DevNet-Implementierung
Wir sammeln wertvolle Daten von den meisten der Knoten im DevNet. Mit diesen Daten konnten wir einige Fehler in unserem Netzwerk-Stack entdecken, die dazu führen, dass einige Nachrichten mit größeren Verzögerungen als erwartet durch das Netzwerk propagiert werden.
Unabhängig davon, dass wir dieses Problem mit v0.7.3 behoben haben, hat dieses Problem einen Nachteil in Bezug auf FCoB aufgezeigt, dem Protokoll, mit dem die Knoten ihre anfängliche Meinung zu jeder Transaktion festlegen. Genauer gesagt kann es aufgrund der aktuellen Implementierung von FCoB und FPC passieren, dass zwei (oder mehr) Konflikte beide abgelehnt werden können. Ohne einen klaren Gewinner könnten neue Knoten, die dem Netzwerk beitreten, oder bestehende Knoten, die fehlende Nachrichten verfestigen, nur eine solche Nachricht erhalten und daher versuchen, ihre neuen Nachrichten an eine Seite des Tangles anzuhängen, die nicht genug Zustimmungsgewicht erhält, um jemals bestätigt zu werden.
Obwohl wir FCoB verbessern könnten, indem wir Kommunikationsredundanz für die abgelehnten Konflikte hinzufügen, möchten wir diese Gelegenheit nutzen, um eine Variante von FPC zu untersuchen, die wir „FPC on a set“ nennen und die immer einen Gewinner innerhalb einer Konfliktmenge auswählen würde. Dies würde uns auch erlauben, mit einem Mechanismus zu experimentieren, der dem On Tangle Voting (OTV) ähnlicher ist, kombiniert mit FPC on a set als Metastabilitätsbrecher.
Andere Aspekte der Implementierung werden ebenfalls verbessert. Zum Beispiel verschieben wir den Scheduler (den Kern der Staukontrolle) nach dem Booker. Dies führt zu einem natürlicheren Verhalten beim Synchronisieren, da der Knoten den Scheduler nicht explizit umgehen muss, um mit dem Netzwerk gleichzuziehen.
Darüber hinaus überarbeitet das Team den Solidification-Mechanismus so, dass eine Nachricht als solide gilt, wenn sowohl ihre Eltern als auch ihre Nutzlast (d. h. ihre Transaktion) solide sind. Dies wird es uns ermöglichen, die kostspielige Überprüfung der Vergangenheit zu entfernen.
[donation]
Protokoll-Aktualisierung
Mit der DevNet-Implementierung kam die erste Welle des Feedbacks bezüglich der vielen Komponenten, die unser IOTA 2.0-Netzwerk ausmachen werden. Während die meisten der Komponenten vielversprechende Ergebnisse zeigten, erkannten wir auch, dass einige von ihnen Änderungen benötigen würden, um den Standards zu entsprechen, die wir vom zukünftigen Netzwerk erwarten. Glücklicherweise macht es die modulare Natur von IOTA 2.0 möglich, dass wir Komponenten entwickeln, mit denen wir zufrieden sind, während wir gleichzeitig die erforschen und verbessern, die Aufmerksamkeit erfordern.
Die gesamte Forschungsabteilung hat sich zusammengesetzt, um zu bestimmen, welche Komponenten von weiterer Forschung profitieren könnten, und um zu entscheiden, wie wir dies in einer Weise organisieren, die die anderen laufenden Projekte nicht behindert. Die wichtigsten Verbesserungen, an denen wir arbeiten werden, sind:
- Erhöhung der Modularität des Konsens-Algorithmus durch Einführung der „Conflict Selection Function„, die alle Konsens-Mechanismen verallgemeinert, die in IOTA 2.0 implementiert werden können. Aktualisierung des FPC zum „On Tangle FPC on a set“ durch die
- Verwendung der Konfliktauswahlfunktionen.
- Entfernen der Notwendigkeit, über Zeitstempel abzustimmen und Nachrichten als geeignet für die Tipp-Auswahl zu klassifizieren, indem der Mechanismus „Inclusion Score“ eingeführt wird.
- Entfernen Sie die Notwendigkeit für schwache Freigaben und untersuchen Sie, wie sich das Protokoll unter Konflikt-Spamming verhält.
Nachdem wir diese Forschungsthemen definiert hatten, teilten wir uns in zwei Gruppen auf, um sie in Angriff zu nehmen. Das Hauptaugenmerk dieser Forschung liegt darauf, zu Ergebnissen zu kommen, die in die Spezifikationen aufgenommen werden können. Wir hoffen, bis zum nächsten Forschungsupdate einige Ergebnisse vorlegen zu können.
Spezifikationen
Nach umfangreicher Arbeit, um den ersten Stapel von Spezifikationen fertig zu stellen und mit der Gemeinschaft zu teilen, hat das Team eine Übersicht über unsere aktuelle Forschung erstellt, um die nächsten Ziele zu bestimmen. Um dies in angemessener Weise zu tun, war der kürzliche Start des DevNet entscheidend. Die neuen Aufgaben, die beschlossen wurden, waren: Aktualisierung der Spezifikationen gemäß den jüngsten Ergebnissen aus dem DevNet; Fortfahren mit dem Standardisierungsprozess für die Dateien, die nicht von den DevNet-Ergebnissen betroffen sind; und Arbeit an der zweiten Charge von Spezifikationen, um alle Dateien geschrieben zu haben.
Da der Schwerpunkt der Forschungsabteilung in den nächsten Monaten auf der Forschung liegen wird, wird die Arbeit an den Spezifikationen natürlich folgen. Sobald die Forschung abgeschlossen ist, werden wir die relevanten Ergebnisse in die Spezifikationen aufnehmen.
Vernetzung
Die Forschung im Netzwerkteam konzentriert sich derzeit auf die Implementierung des Staukontrollalgorithmus im DevNet und dessen Integration mit dem Rest des Protokolls.
Als Ergebnis untersuchen wir eine Reihe von Optimierungen, die es uns ermöglichen, den Code zu vereinfachen und gleichzeitig die Leistung zu verbessern. Die wichtigste Änderung gegenüber der ursprünglichen Idee ist die Tatsache, dass Nachrichten sofort nach ihrer Festigkeit gebucht werden können, sodass der Scheduler nur noch bestimmt, welche Nachrichten geklatscht und zur Tippliste hinzugefügt werden. Dies erlaubt eine viel schnellere Synchronisation für out-of-sync Knoten, die alte Nachrichten mit einer Rate wiederherstellen können, die schneller als die des Schedulers ist. Andererseits eröffnet die Verlagerung des Schedulers an das Ende des Datenflusses die Möglichkeit von Angriffen, die derzeit untersucht werden. Wir können potenzielle Angriffe durch die Einführung des Inklusions-Scores entschärfen, einer Metrik, die die Wahrscheinlichkeit misst, dass eine Nachricht in Zukunft ein permanenter Teil des Tangles wird.
Als zweites Forschungsthema untersuchen wir derzeit ein Modell zur Verbesserung der Erlebnisqualität für die Benutzer. Insbesondere bestimmt der Rate Setter den Durchsatz eines bestimmten Benutzers, abhängig vom Zugriffsmana. Fragen wie „wie viele Nachrichten kann ich – als Knoten – mit X Mana senden“ oder „wann darf ich die nächste Nachricht ausgeben“ werden durch dieses Modell beantwortet.
Schließlich sind wir stolz darauf, bekannt geben zu können, dass unser Paper, das wir in Zusammenarbeit mit Professor Bob Shorten und seinem Team am Imperial College London geschrieben haben, „Access Control for Distributed Ledgers in the Internet of Things: A Networking Approach„, zur Veröffentlichung im IEEE Internet of Things Journal (Impact Factor 9.936), einer hochrangigen Fachzeitschrift für Computerwissenschaften, angenommen worden ist.
Sharding
Während der letzten zwei Monate war die gesamte Forschungsabteilung auf zwei Dinge fokussiert: DevNet-Entwicklung und die Veröffentlichung der Spezifikationen. Daher ging die Sharding-Gruppe, zusammen mit einigen anderen Gruppen, in eine Pause, damit unsere Arbeitskräfte diesen Aufgaben richtig zugewiesen werden konnten. Mit der Freigabe des DevNet und der ersten Spezifikationsfreigabe arbeitet die Forschungsabteilung wieder an ihren Sharding-Lösungen. Der erste Vorschlag, ein Whitepaper über Data Sharding, befindet sich gerade in Produktion, und wir erwarten bald eine Veröffentlichung, um unsere Ideen mit der Community zu teilen.
Wir erwarten, dass die Entwicklung des Data Sharding den Durchsatz des Netzwerks für Datennachrichten deutlich verbessern wird, und seine Implementierung kann mit dem zukünftigen Fluid Sharding parallelisiert werden.
Original by William Sanders: https://blog.iota.org/iota-research-status-update-july-2021/
Schreibe einen Kommentar