IOTA Forschungsstatus Update September 2021

IOTA Multiversum

Wir freuen uns, Ihnen die folgenden Neuigkeiten aus unseren Forschungsgruppen mitteilen zu können. Die Abteilung konzentriert sich weiterhin auf die Verbesserung der Implementierung des IOTA 2.0-Protokolls im DevNet.

In diesem Monat stellen wir zwei neue Gruppen vor: die Konsensgruppe und die Kommunikationsschichtgruppe. Die Konsensgruppe wurde gebildet, um das Problem der Verzögerung bei der Nachrichtenausbreitung anzugehen, das in unserem monatlichen Update vom Juli beschrieben wurde. Die Arbeit an der Simulation und dem Testen unseres verbesserten Konsensmechanismus hat bisher gute Ergebnisse erbracht. Die Kommunikationsschicht-Gruppe arbeitet, wie der Name schon sagt, an verschiedenen Aspekten der Kommunikation im IOTA 2.0-Protokoll. Dazu gehören Themen wie die Überprüfung der Netzwerkleistung, Optimierungen und Zeitstempel. Wie immer, lesen Sie bitte unten alle Details.

iota trading plattform

DevNet-Implementierung

Seit der letzten Aktualisierung hat das Team die Versionen 0.7.4 und 0.7.5 veröffentlicht, die die allgemeine Stabilität der Software verbessern, mehrere Fehler beheben und die Scheduler-Komponente an das Ende des Datenflusses verlagern. Dies ermöglicht einen besseren Synchronisationsprozess sowie eine Vereinfachung des gesamten Datenflusses. Es gibt immer noch einige Probleme im Zusammenhang mit der Marker-Zuweisung, die es für einige neue Teilnehmer schwierig machen, ihre Knoten erfolgreich zu synchronisieren. Aus diesem Grund arbeitet das Team an einer neuen Funktion, die es den Community-Knoten ermöglichen wird, eine aktuelle Datenbank herunterzuladen, um eine schnellere und zuverlässigere Synchronisierung zu ermöglichen.

Die Umsetzung der neuen Verbesserungen für den Konsens schreitet sehr schnell voran, da sich das Team bereits in der Testphase befindet. Konkret wurden eine modulare Konsens-Schnittstelle, der On Tangle Voting (OTV)-Mechanismus, ein neuer übergeordneter Typ (d.h. der Like-Schalter) und eine überarbeitete syntaktische Validierung von Nachrichten bereits zur Codebasis hinzugefügt, aber noch nicht zusammengeführt. Das Gewicht der Zustimmung, das jeder Nachricht zugewiesen wird, kann nun in Finalitätsgrade (GoF) übersetzt werden: niedrig, mittel und hoch. Die Sammlung neuer Metriken, die speziell für die Analyse von OTV entwickelt wurden, wurde ebenfalls hinzugefügt und eine neue Konfliktübersichtsseite wurde für das lokale Dashboard des Knotens entwickelt, so dass jeder Knotenbetreiber das Verhalten seines Knotens bei der Abstimmung über Konflikte in Echtzeit überprüfen kann.

IOTA Staking

IOTA Konses

Andere Komponenten des Protokolls, einschließlich des Rate Setters, der Kernkomponente der Staukontrolle, wurden in den Fluss integriert. Schließlich wurden erhebliche Anstrengungen zur Verbesserung der Codequalität unternommen. Die Verwendung von Dependency Injection bei der Initialisierung von Plugins, die Vereinheitlichung der Parameter, eine generischere Serialisierungs- und Deserialisierungsbibliothek sind nur einige Beispiele.

Die offizielle Dokumentation wurde zu docusaurus migriert und Sie können sie hier einsehen.

Vernetzung

Der derzeitige Schwerpunkt des Teams liegt auf der Analyse der Leistung des IOTA-Staukontrollalgorithmus (ICCA) und auf der Verbesserung der Benutzererfahrung. Genauer gesagt wurde ICCA mit dem Ziel entwickelt, die maximale Verzögerung zu minimieren, d.h. die Zeit, die benötigt wird, um eine Nachricht an alle Knotenpunkte zu übermitteln. Das bedeutet, dass die von ICCA verwendeten Schwellenwerte (Blacklisting, Self-Back-Off und Minimum Mana) als Regler für diese maximale Verzögerung fungieren. Um dies zu verstehen, stellen Sie sich einen Puffer mit unendlicher Größe vor, bei dem die Verzögerungen potenziell unendlich sein könnten. Wenn derselbe Puffer eine geringe Größe hat, muss eine neue Nachricht nur warten, bis alle vorhandenen (wenigen) Nachrichten eingeplant sind. Aus diesem Grund arbeiten wir an der Analyse der verschiedenen Parameter, um herauszufinden, wie sie die tatsächliche Leistung von ICCA beeinflussen und wie diese Parameter optimiert werden können. Als vorläufiges Ergebnis haben wir festgestellt, dass die Art und Weise, wie das Defizit zugewiesen und gekappt wird, einen starken Einfluss auf die Leistung hat.

Parallel dazu arbeiten wir an der Lastverteilung zwischen den Knoten und versuchen, die folgende Frage zu beantworten: Angenommen, ein Nutzer (Brieftasche oder Knoten) hat eine neue Nachricht zu versenden, welcher Knoten sollte gewählt werden, damit diese Nachricht in kurzer Zeit erstellt wird? Es sei daran erinnert, dass jeder Knoten über ein Modul zur Nachrichtenerstellung verfügt und die Rate der Hinzufügung neuer Nachrichten in den Scheduler durch den Rate Setter-Algorithmus reguliert wird; daher versucht dieses Projekt, neue Nachrichten den Knoten zuzuweisen, die zu einem bestimmten Zeitpunkt weniger ausgelastet sind. Wir haben dieses Problem als Optimierungsproblem formuliert und testen einige vorgeschlagene Strategien, die auf der Belegung des Nachrichtenerstellers oder der Verzögerung pro Knoten basieren.

Suche Gastautoren

Im Zusammenhang mit überprüfbaren Verzögerungsfunktionen (VDFs) optimieren wir die Berechnungs- und Auswertungszeit unseres vorgeschlagenen Algorithmus zur Spamvermeidung durch den Einsatz von Mehrfachpotenzierungstechniken, die wir zuvor untersucht haben. Wir haben festgestellt, dass einer der (zeitlich) teuersten Aspekte der Verifizierung der VDF darin besteht, die minimale Zahl zu finden, so dass der Hash dieser Zahl plus einer Eingabenachricht prim ist. Wir konzentrieren uns derzeit darauf, diese Funktion zu beschleunigen.

Sharding

In den vergangenen Wochen gab es verschiedene Schwerpunkte für die Data Sharding Gruppe: Hauptsächlich Diskussionen über ISCP Chains und Motivation zu Data Sharding, Simulationen zum Modell und Formalisierung unserer Ergebnisse, Definitionen und Diskussionen.

Zwei verschiedene Simulationen wurden von Mitgliedern der Data Sharding Group durchgeführt. Bei der ersten handelte es sich um ein benutzerbasiertes Modell, bei dem wir davon ausgingen, dass verschiedene Benutzer mit unterschiedlichen MPS-Anforderungen (Nachrichten pro Sekunde) dem Netzwerk beitreten und sich selbst optimal zuordnen. Anhand dieses Modells überprüften wir interessante Daten wie die Zuteilung von Mana pro Shard, erwartete MPS pro Mana-Anteil und MPS pro Schicht. Das zweite Modell ist ein Shard-basiertes Modell, bei dem wir uns hauptsächlich auf den durch die Kommunikation zwischen den Shards verursachten Overhead konzentrierten. Beide Simulationen lieferten uns Ergebnisse, die entweder erwartet oder positiv waren. Die Ergebnisse werden formalisiert und tragen zu unserer laufenden Arbeit bei.

Konsens

Die Consensus Group ist eine neu gegründete Gruppe, die sich mit allen Fragen im Zusammenhang mit Consensus Changes befasst. Als solche ist sie eine interdisziplinäre Gruppe, die sich derzeit hauptsächlich mit der Implementierung und dem Testen der modularen Konsensänderungen und des Like-Switch, der Simulation von OTV, dem Verfassen eines Artikels über OTV und der Diskussion weiterer Ideen zur Vereinfachung und Verbesserung des Protokolls beschäftigt.

Auf der Grundlage des Multiversum-Simulators baut das Team einen allgemeinen Simulationsrahmen auf, der uns dabei helfen wird, den Konsensmechanismus, seine Vorteile und seine Grenzen genau zu verstehen. Es wird auch als Schlachtfeld für verschiedene Angriffe auf reines OTV und OTV mit FPCS als Mechanismus zum Aufbrechen der Metastabilität und potenziell andere dienen. Derzeit befindet sich der Simulationsrahmen noch in einem sehr frühen Stadium und es können noch keine aussagekräftigen Ergebnisse erzielt werden. In naher Zukunft wird uns das Framework dabei helfen, fundierte Entscheidungen über Parametereinstellungen zu treffen (z. B. wann sollte FPCS eingeschaltet werden?), ein Gefühl für Bestätigungszeiten bei verschiedenen Manaverteilungen und Anweisungsraten zu bekommen und Inhalte für unsere Veröffentlichungen über OTV zu liefern.

Das Team diskutiert auch über weitere Vereinfachungen des Protokolls. Zum Beispiel haben wir mit dem „Like“-Schalter jetzt eine klare Trennung zwischen Genehmigungsgewicht (AW) für Zweige und Marker. Durch die Verwendung einer einzigen Marker-Sequenz zur Annäherung an AW können wir diese Komponenten trennen, die AW-Berechnung beschleunigen und die Dinge leichter verständlich machen. Darüber hinaus diskutieren wir den Begriff des aktiven cMana (cMana, das bei aktuellen Konflikten/Nachrichten berücksichtigt wird) und die Beendigung des Konsenses, da die Verfolgung des schwersten Zweigs ein nie endendes Abstimmungsschema ist, genau wie die Regel der längsten Kette in Blockchains.

Kommunikationsschicht

Die Communication Layer Group ist ein weiteres neu gegründetes Team. Ihr Schwerpunkt liegt auf Kommunikations- und Synchronisationsthemen, die während der Forschung in der Networking- und der GoShimmer-Gruppe aufkamen.

In diesem Monat führte das Team Tests und Benchmarks für die kürzlich zum DevNet hinzugefügten Komponenten Scheduler und Rate Setter durch. Dabei wurden verschiedene virtuelle Netzwerkkonfigurationen eingerichtet, um zu überprüfen, ob die bestehende Implementierung den erwarteten Ergebnissen aus der Netzwerkforschung entspricht. Ein weiterer Aspekt dieser Tests war die Ermittlung potenzieller Leistungsengpässe in bestimmten Grenzszenarien.

Auf einer eher theoretischen Ebene haben wir verschiedene Zeitstempel-Methoden evaluiert. Zeitstempel ermöglichen den direkten Vergleich und die Ordnung von Nachrichten, was für eine Vielzahl von Komponenten hilfreich ist. Diese verschiedenen Methoden müssen im Hinblick auf ihre Präzision, Zuverlässigkeit und Rechenkomplexität bewertet werden.

Original by William Sanders: https://blog.iota.org/iota-research-status-update-september-2021/

Folge und teile diese Seite:
error20
fb-share-icon0
Tweet 402
0 0 Stimmen
Artikel Bewertung
Abonnieren
Benachrichtige mich bei
guest
0 Kommentare
Inline-Rückmeldungen
Alle Kommentare anzeigen