In diesem Monat gab es neue Veröffentlichungen unseres Pollen-Testnetzes sowie weitere Fortschritte bei der Verifizierung unseres Kernprotokolls, während wir uns auf die Veröffentlichung von Nectar vorbereiten.
Da die „Nectar“-Phase unserer Coordicide-Implementierung vor uns liegt, wickelt unser Team derzeit die letzten Forschungsarbeiten ab, die zum Erreichen dieses Meilensteins erforderlich sind. Zu diesem Zeitpunkt beziehen sich die verbleibenden Arbeiten hauptsächlich auf Optimierungen, und wir werden weiterhin die von Pollen gesammelten Daten nutzen, um alle erforderlichen Änderungen zu implementieren. Nectar wird unsere erste voll funktionsfähige Coordicide-Implementierung sein, daher wollen wir sie von Anfang an so robust wie möglich machen, mit dem Ziel, sie weiter zu optimieren, während wir das Netzwerk gemeinsam nutzen und daraus lernen.
Zusätzlich zu den Fortschritten in der Forschung und der Testnet-Implementierung freuen wir uns, dass Billy Sanders eine Führungsrolle als Director of Research übernommen hat. Serguei Popov wird weiterhin eine sehr aktive Rolle im Vorstand und im Forschungsalltag spielen. Da Billy bereits an vielen Entscheidungen beteiligt war und Serguei weiterhin in der Abteilung aktiv ist, hatte dieser Übergang nur geringe Auswirkungen auf den Abteilungsbetrieb. So hat unser Team in diesem Monat weiterhin Fortschritte an allen Fronten gemacht.
Nachfolgend finden Sie Updates aus unseren verschiedenen Forschungsgruppen:
Pollen-Testnet-Implementierung
Das Team hat zwei Releases ausgerollt, v0.3.6 und v0.4.0, und damit das Refactoring des Tangle mit der Zusammenführung des Value Tangle und der Einführung von verbesserten Komponenten wie dem Solidifier, Ledgerstate, Booker, Opinion Former sowie dem neuen Scheduler abgeschlossen, die alle Teil des neu gestalteten Ablaufs im Kern des Coordicide-Protokolls sind.
Wie in den Pollen-Testnet-Versionshinweisen dargestellt, kann jede Komponente als Blackbox betrachtet werden, und die Interaktion zwischen ihnen erfolgt über Ereignisse. Genauer gesagt, beginnt der Fluss entweder vom Gossip oder von der MessageFactory. Dann kümmert sich der Parser um die Validierung der Struktur der Nachrichten. Die Storage-Komponente speichert die Nachrichten sowie deren Metadaten in der DB und erstellt die Tangle-Struktur. Der Solidifier sorgt dafür, dass alle fehlenden Nachrichten angefordert werden, und stellt sicher, dass der Tangle monoton in Bezug auf die Zeitstempel der Nachrichten wächst.
Der Scheduler plant Nachrichten ein, die dann in den Booker gehen und gebucht werden. Wenn eine Nachricht eine Transaktion als Nutzlast enthält, führt der Booker eine Reihe von Prüfungen durch (z. B. Gültigkeit der Unterschrift, Gültigkeit des Saldos, Doppelausgaben) und bucht die Transaktion in die entsprechende Realität. Der OpinionFormer ermittelt die Message– und Payload-Meinung mit FCoB und führt ggf. die Abstimmung über FPC (Statements) durch. Abschließend werden je nach Ergebnis der Opinion der Nachrichten und deren vergangenheitsbezogenem Status gemochte Nachrichten dem Weak– bzw. Strong-Tip-Set hinzugefügt.
Diese Änderungen sowie neue Optimierungen wie die Integration von Markern und die effizienten Prüfungen auf vergangene/zukünftige Kegelzugehörigkeit ermöglichen es uns, mit der Mana-Integration in unserem Prototyp voranzukommen.
Genauer gesagt wird Mana in inkrementellen Schritten integriert werden. Die erste Version wird sowohl Zugriffs- als auch Konsens-Mana enthalten, aber keines der Module wird es verwenden. Visualisierungs- und Analysewerkzeuge werden es uns ermöglichen, zunächst seine Dynamik zu untersuchen und seine Verteilung im Testnetz kennenzulernen. Das ist ein wichtiger Schritt, um seine Parameter abzustimmen und damit zu beginnen, es in die verschiedenen Komponenten wie Staukontrolle, Konsens, Finalität und dRNG zu integrieren.
Protokoll
Die Protokoll-Gruppe nutzt nun ihre Ressourcen, um den Fortschritt des neuen Spezifikations-Projekts zu verwalten, das aus den Bemühungen um einen Entwurf, der letztes Jahr begann, zusammen mit der brandneuen Forschung, die seitdem entwickelt wurde, entstanden ist. Wir werden immer noch einige Forschungsarbeiten durchführen und weitergeben, aber in einer weniger häufigen Art und Weise, da die meisten unserer theoretischen Probleme gelöst wurden.
Im letzten Monat hat die Gruppe an dem Problem „Anzahl der Eltern“ gearbeitet. Seit einer Weile haben wir die Idee in Betracht gezogen, die Anzahl der Genehmigungen, die eine Nachricht durchläuft, von 2 auf einen größeren Wert k zu erhöhen. Wir überlegen, wie sich das auf die Verwaisungsrate, die Finalitätszeit und die Möglichkeit eines sehr starken Benutzers auswirkt, der viele Knoten nutzt (um die Ratenkontrollverteidigung zu umgehen) und versucht, einen Genehmigungsangriff durchzuführen, der die Verwaisung künstlich aufbläht. Wir suchen noch nach anderen Perspektiven, aber glücklicherweise ist die Erhöhung der Genehmigungen extrem effektiv gegen diese Art von Angriff. Wir erwarten, dass wir bis zum nächsten Update ein richtiges Dokument mit allen Studien und Simulationen, die wir zu diesem Thema durchführen, haben werden!
Spezifikationen
Es ist schon einige Zeit her, dass der erste Entwurf der Spezifikationen erstellt wurde, und die Forschung an Coordicide hat sich weiterentwickelt, um das System einfacher und robuster zu machen. Von den wichtigen Änderungen können wir die Verschmelzung des Message Tangle mit dem Value Tangle, die Schaffung des Approval Switch-Ansatzes, die Definition der Approval Weight-Metrik (ein neues Werkzeug, das die frühere Confirmation Confidence und Mana zur Bestimmung der Finalität verwendet), die Einführung von Markern und Epochen sowie die Verfeinerung vieler Komponenten nennen.
All dies gab uns ein Zeichen, dass es zusammen mit den Erfahrungen des ersten Entwurfs aus dem letzten Jahr an der Zeit war, zu den Spezifikationen zurückzukehren und etwas zu erstellen, das bereit ist, mit der Gemeinschaft geteilt zu werden, eine externe Validierung zu erhalten sowie eine Überprüfung nach anderen strengen Kriterien der Standardisierung.
Zu Beginn dieses Projekts haben wir die Komponenten, aus denen Coordicide bestehen wird, neu strukturiert und über Autoren, Termine und Methodik entschieden. Jeder gibt jetzt sein Bestes, um ein viel hochwertigeres Ergebnis zu erzielen. Wir erwarten, dass wir bei der nächsten Aktualisierung etwas mit allen teilen können!
Pollen Testnet Study Group
Der letzte Monat hat wieder einmal gezeigt, dass das Schreiben von akademischen Arbeiten nicht nur eine Übung im „Schreiben für eine Arbeit“ ist, sondern dass es hilfreich ist, um das eigene Denken und Verständnis eines Themas zu klären. In unserem Beispiel begannen wir mit dem Verfassen der wissenschaftlichen Arbeit zu unserem Autopeering-Vorschlag. Durch fruchtbare Diskussionen und Hinterfragen aller Elemente haben wir nicht nur ein viel besseres Verständnis erlangt, sondern auch Verbesserungsvorschläge gemacht. Neben dieser forschungsorientierten Aufgabe haben wir im vergangenen Monat die aktuelle Implementierung weiter analysiert und einige kleinere Probleme identifiziert, die nun angegangen werden.
Vernetzung
In diesem Monat haben wir die Auswirkung von Mana-Änderungen auf den Congestion-Control-Mechanismus untersucht. Simulationen zeigen, dass unser Algorithmus schnell auf solche Änderungen reagiert, wenn Mana nach einem gleitenden Durchschnitt berechnet wird. Wenn Mana jedoch plötzlich abnimmt, erhöht sich die Mana-skalierte Inbox-Länge des Knotens entsprechend. Da die Posteingangslänge die Schlüsselmetrik für das Blacklisting von bösartigem Verhalten ist, entwerfen wir derzeit einen Weg, der garantiert, dass falsch-positives Blacklisting für ehrliche Knoten nicht auftritt.
Darüber hinaus freuen wir uns, dass das Papier „Access Control in Adversarial Environments for IoT-oriented Distributed Ledgers“ zur Präsentation auf dem 7th IEEE/IFIP Workshop on Security for Emerging Distributed Network Technologies (IM 2021/DISSECT) angenommen worden ist. Das Paper beschreibt unseren Staukontrollalgorithmus, der in IOTA 2.0 zum Einsatz kommen wird („Coordicide“).
Sharding
Wie bereits im letzten Update erwähnt, arbeiten wir derzeit an einem Whitepaper zum Thema Data Sharding, bevor wir eine formellere Ankündigung zu diesem Thema machen. Durch das Schreiben dieses Papiers vervollständigen wir die Details der Lösung und verstehen die grundlegenden Herausforderungen besser. Zum Beispiel haben wir bereits eine viel bessere Vorstellung davon, wie wir den möglichen Durchsatz modellieren können, den die Data-Sharding-Lösung ermöglichen wird. Data Sharding scheint gegen alle Angriffsvektoren, die wir diskutiert haben, robust zu sein. Die Einfachheit der Lösung wird es ermöglichen, flexibel zu sein, und die Implementierung wird, relativ gesehen, viel einfacher sein als beispielsweise Coordicide.
Wir hoffen, das White Paper Ende April fertig zu haben, und wollen es irgendwann nach der Veröffentlichung von Nectar herausgeben. Dieser Plan wird uns genügend Zeit geben, ein klares und detailliertes Dokument zu erstellen, während wir uns gleichzeitig auf die Entwicklung von Nectar und die Spezifikationen konzentrieren können.
Original by William Sanders: https://blog.iota.org/iota-research-status-updatemarch-2021/
Schreibe einen Kommentar