Dieser Monat war sehr arbeitsreich für uns, da wir uns auf die Zielgerade auf dem Weg zur Auslieferung von Nectar begeben, der ersten vollständigen Implementierung unseres vollständig dezentralisierten, koordinatorenfreien Netzwerks, die in ein paar Wochen erwartet wird! Unsere Gruppen haben alle hervorragende Fortschritte bei der Umsetzung unserer Forschungsergebnisse in brauchbare Komponenten gemacht, ein Ziel, auf das wir stolz sind, unseren Teil dazu beizutragen.
Einige wichtige Errungenschaften in diesem Monat haben den Fortschritt in Richtung der Freigabe der Nectar-Stufe unseres koordinatorfreien Netzwerks vorangetrieben, darunter: die Implementierung von mana in das Pollen-Testnetz, was uns erlaubt, Angriffe unter realistischen Netzwerkbedingungen zu untersuchen; die fast vollständige Fertigstellung unserer formalen Spezifikationen, was uns erlaubt, das Protokoll besser an Partner und andere interessierte Parteien zu kommunizieren, sowie die Grundlage für die Standardisierung des IOTA-Protokolls zu schaffen; und die Fertigstellung unseres Autopeering-Papiers, welches eine Validierung einer unserer Netzwerkkomponenten darstellt. Im Folgenden finden Sie Updates aus unseren Forschungsgruppen, die diese und andere Fortschritte des letzten Monats detailliert beschreiben:
Pollen Testnet Implementierung
Das Team hat mehrere Iterationen des Pollen-Testnetzes ausgerollt, beginnend mit v0.5.0, das Mana (das Reputationssystem) sowie die Staukontrolle (die den Zugriff auf das Tangle regelt) einführte, um die erste Iteration zu testen und die Verteilung in einer solchen Umgebung zu untersuchen. Mit dieser Version fügten wir eine Reihe neuer APIs, einen neuen Mana-Abschnitt auf dem lokalen Dashboard, dem Pollen Analyzer Dashboard sowie auf dem Grafana Dashboard hinzu. Sowohl die GUI- als auch die CLI-Wallets wurden aktualisiert, um dem Benutzer die Möglichkeit zu geben, die Identität des Knotens als Empfänger des Zugriffs- und Konsens-Mana-Pfandes einer Transaktion zu definieren.
Wir haben auch die Consensus-Manager-Komponente refaktorisiert, um agnostisch in Bezug auf die tatsächlich implementierten Konsensmechanismen zu sein. Auf diese Weise kann GoShimmer nicht nur als IOTA 2.0-Prototyp, sondern auch als flexibles Framework für jede DAG-basierte DLT gesehen werden. Tatsächlich kann jeder Konsens-Mechanismus, wie z.B. On Tangle Voting, BFT, Leader-basiert und mehr, so einfach wie das Ändern von nur ein paar Zeilen in der Tangle-Initialisierung eingesteckt werden. Mit den nachfolgenden Versionen haben wir begonnen, die ersten Komponenten in mana zu integrieren, nämlich das Fast Probabilistic Consensus (FPC-Protokoll) und das Autopeering. Bislang hat unser Konsensmodul die Meinungen aller Knoten gleich behandelt. Dies bietet jedoch keinen Schutz gegen Sybil-Angriffe, bei denen Angreifer hunderte oder sogar tausende von Knoten betreiben, um den Konsens zu stören. Mit der Integration von Mana bilden die Knoten nun ihr Quorum, indem sie die abzufragenden Knoten proportional zu ihrem Mana auswählen.
Um Sybil-basierte Angriffe zu verhindern/einzuschränken, nutzt das Autopeering einen Screening-Prozess namens Mana-Rank, der eine Teilmenge aus allen bekannten Knoten basierend auf ihrer Mana-Ähnlichkeit auswählt. Das bedeutet, dass Knoten mit ähnlichem Mana mit größerer Wahrscheinlichkeit zu Nachbarn werden. Wir können die Auswirkungen bereits in der Topologie des Pollen-Netzwerks sehen:
Knoten im linken Teil des Netzwerkgraphen haben mehr Konsensmana, während im rechten Teil Knoten mit weniger oder null Mana zu sehen sind. Mit diesem Experiment versuchen wir, die richtigen Parameter zu finden, um ein gutes Gleichgewicht zwischen Sybillenschutz und Netzwerkkonnektivität zu finden. Derzeit haben wir ein Netzwerk mit mehr als 200 Knoten und einem Netzwerkdurchmesser von 5.
In den kommenden Wochen wird sich das Team auf die Integration von mana mit den restlichen Modulen konzentrieren: Congestion Control, Finality (Zulassungsgewicht), Reorg und dRNG. Als letzte Meilensteine vor Nectar werden wir Snapshots und Timestamp-Voting einführen. Sobald diese fertig sind, wird Nectar bereit sein, der Öffentlichkeit vorgestellt zu werden.
Spezifikationen
Die Fortschritte bei den Spezifikationen sind stetig, und wir arbeiten nun mit dem Ziel, die Hauptkomponenten etwa zum Zeitpunkt des Upgrades auf Nectar fertig zu haben. Der gesamte Prozess wird vollständig dokumentiert und standardisiert, so dass wir besser kontrollieren können, wie der Fortschritt verläuft und wissen, welche Module noch unterstützt werden müssen.
Lassen Sie uns ein wenig über die Struktur des Projekts sprechen. Im Moment sind die Dateien in 7 Abschnitte unterteilt, die sich auf ihre Rolle im Projekt oder im Netzwerk beziehen: Steuerdateien, Strukturdateien, Netzwerkschicht, Kommunikationsschicht, Wertübertragungsanwendung, Konsensanwendung und Verlaufsverwaltung.
In den Steuerdateien geht es um die Informationen, die sich auf jede Datei beziehen und die Standardisierungsrichtlinien und die Organisation definieren. Hier ist der Index der Parameter- und Terminologiedateien zu erwähnen, der diese Informationen über die Dateien an einem einzigen Referenzort erhält. Structure Files enthält wesentliche Informationen über die Datenelemente, die Teil des Tangle sind. Hier findet man das brandneue Message Layout, die wichtigsten Payload Layouts sowie den Datenfluss, den eine Nachricht durchläuft, um von einem Knoten verarbeitet zu werden.
Network Layer befasst sich mit der Kommunikation zwischen den Knoten, einschließlich der Bootstrapping-Methodik und aller Autopeering-Module. Communication Layer, wahrscheinlich unser umfangreichster Abschnitt, zeigt das Protokoll für einen Knoten, um sein Tangle zu pflegen. Dies beinhaltet einen Großteil der Module über das Tangle selbst, wie z. B. Zeitstempel, Spitzenauswahlalgorithmus, Verfestigung, Raten- und Staukontrolle und Marker. Werttransfer-Anwendung definiert die Richtlinien für alles, was mit dem Ledger zu tun hat, wie die UTXO-Systematik, Ledger-Zustandsberechnungen und alle Richtlinien über Mana.
Konsensanwendungen, wie der Name schon sagt, ist die Spezifikation über alles, was mit dem Konsens zu tun hat. Hier findet man alle Informationen über den schnellen probabilistischen Konsens (FPC), den dezentralen Zufallszahlengenerator (dRNG), die Reorganisation der Knotenwahrnehmung und die Finalität. Schließlich wird in der History-Verwaltung der Prozess des Snapshotings detailliert beschrieben.
Dies zeigt ein wenig die umfangreiche Natur des Projekts. Von unserem anfänglichen Stapel von 20 Dateien haben bereits 7 die Revision durchlaufen und viele andere stehen kurz vor der Fertigstellung. Wir erwarten im Laufe des Aprils einen großen Fortschritt und hoffen, diesen bald mit der Community teilen zu können.
Pollen Testnet Studiengruppe
Während des letzten Monats haben wir unser erstes Forschungspapier über unser salzbasiertes Autopeering fertiggestellt und eingereicht. Dieses Papier diskutiert mehrere unserer Designentscheidungen und präsentiert eine erste quantitative Behandlung einiger Anforderungen an die Netzwerktopologie. Nachdem wir das Mana in das Autopeering in Pollen integriert haben, setzen wir unsere Forschung an diesem Modul von Coordicide fort.
Wir analysierten auch die Verteilung und Dynamik von Zugriffsmana und Konsensmana im aktuellen Testnetz. Ein besonderes Ergebnis dieser ersten Analyse ist eine Anpassung des „Glättungsparameters“ des Zugriffsmanas; eine Änderung des Zugriffsmanas wird in viel kürzerer Zeit wirksam als in unserem ersten Vorschlag.
Vernetzung
Diesen Monat haben wir an einer Strategie gearbeitet, um Knoten zu synchronisieren, die vorübergehend offline sind oder Neulinge, die dem Netzwerk zum ersten Mal beitreten. Es ist sehr wahrscheinlich, dass diese Knoten viele Nachrichten verpasst haben, die bereits verarbeitet und an ihre lokale Version des Ledgers angehängt sein sollten. Bei Verwendung der festen Scheduling-Rate kann es zu langen Verzögerungen kommen, bis die Knoten synchronisiert sind. In unserem Vorschlag ermöglichen wir eine höhere Scheduling-Rate für den Fall, dass ein Knoten als „out-of-sync“ gekennzeichnet ist: in der aktuellen Version von GoShimmer werden Beacon-Nachrichten verwendet, um out-of-sync-Knoten zu erkennen, aber wir planen, einen Mechanismus ähnlich einem Leaky Bucket (der die Rate opportunistisch erhöht) zu bauen, der automatisch Netzwerkstörungen oder Paketverluste erkennt.
Das zweite Hauptthema des Monats war die Feinabstimmung des Algorithmus zur Staukontrolle. Insbesondere führten wir eine umfangreiche Angriffsanalyse durch und stellten fest, dass Angreifer benachbarte Knoten mit einer verfälschten Wahrnehmung der aktuellen Verkehrsüberlastung belegen können. Die Unterschätzung der Überlastung führt zu einer Erhöhung des vom Ratenregler erlaubten Durchsatzes. Wir arbeiten derzeit an Gegenmaßnahmen, um mit diesem Eckfall umzugehen. Wir möchten betonen, dass dieses Szenario nur bei voller Auslastung des Netzwerkdurchsatzes relevant ist. Daher wird unser Protokoll in unmittelbarer Zukunft nicht betroffen sein.
Sharding
Wir machen weiterhin Fortschritte bei unserem White Paper zum Thema Data Sharding. Im vergangenen Monat haben wir ein Brainstorming über zusätzliche Angriffsvektoren durchgeführt. Obwohl wir ein besseres Verständnis der bisherigen Angriffsvektoren gewonnen haben, haben wir keine neuen grundlegenden Schwachstellen gefunden. Somit scheint unser Vorschlag für die Datensplittung robust gegen eine Vielzahl von bösartigen Verhaltensweisen zu sein.
Wir diskutierten auch weitere Möglichkeiten zur Modellierung des Wachstums von Datenwirrwarr, um zu versuchen, den potenziellen Durchsatz des Systems besser abzuschätzen. Wir begannen mit der Arbeit an der Erstellung von Simulatoren, um die Erstellung von Child Tangles zu modellieren und auch um Interaktionen zwischen Parent und Child Tangles zu modellieren. Diese Simulationen werden verwendet, um unser Verständnis und unsere Annahmen über das Verhalten des Systems zu verifizieren.
Da viele der anfänglichen theoretischen Fragen geklärt sind, müssen wir jetzt nur noch das White Paper fertigstellen. Das größte Hindernis ist im Moment, die Arbeitsstunden zu finden, die wir für das Schreiben aufwenden können, da alle unsere Forscher auch an der Fertigstellung von Nectar beteiligt sind.
Original by William Sanders: https://blog.iota.org/iota-research-status-updateapril-2021/
Schreibe einen Kommentar