Wir freuen uns, die folgenden Aktualisierungen von mehreren unserer Gruppen weiterzugeben. Es war ein arbeitsreicher Monat für alle im Team. Zusätzlich zu der unten beschriebenen Arbeit waren wir auch mit der Planung unseres nächsten ReSum-Treffens beschäftigt, das Ende des Monats stattfinden wird.
Wir laden die gesamte Community ein, sich der AMA mit dem IF-Team anzuschließen, das am kommenden Mittwoch (14. Oktober) um 13.00 Uhr MESZ | 7.00 Uhr EST auf Reddit stattfindet. Wir werden Ihre Fragen zu Coordicide beantworten.
Hier die Updates!
Pollen-Testnet-Implementierung
Diesen Monat hat sich das Team darauf konzentriert, die gesamte GoShimmer-Codebasis zu bereinigen. Wir verfolgen einen ähnlichen Ansatz wie das Hornet-Team, indem wir die Paketstruktur verflachen. Dies wird sich positiv auf den Entwicklungsfortschritt auswirken und die Konsistenz zwischen den beiden Projekten erhöhen. Wir haben einen neuen Abschnitt in unserem Wiki hinzugefügt, um unseren Ansatz zur Fehlerbehandlung zu beschreiben.
Nachdem die Mana-Spezifikations-Implementierung fertig geschrieben war, begann das Team mit der Implementierung. Wir haben uns auf die grundlegenden Mana-Funktionen wie Manaberechnungen, Metrik-Sammlung und eine erste Integration mit dem neuen Transaktionslayout und der neuen Wallet konzentriert. Wir haben neue APIs hinzugefügt, um sowohl das Abrufen Mana-bezogener Informationen – wie Rohwerte für Zugriffs- und Konsensmana pro Node, Perzentil- und Höchstwerte – als auch die Angabe der ID des Knotens beim Verpfänden von Mana während der Ausgabe einer Werttransaktion zu ermöglichen.
Angesichts der Bedeutung von Mana in unserer Coordicide-Lösung haben wir damit begonnen, einige Visualisierungstools zu entwickeln, die in das lokale Dashboard der Nodes eingebettet sind, um seine Funktionsweise besser darzustellen, sowie eine Reihe von Überwachungsinstrumenten zur Untersuchung seiner Dynamik. Sie können einen Einblick in diese Arbeit in den Bildern unten sehen.
Darüber hinaus haben wir diesen Monat an zwei neuen RFCs gearbeitet, die sich noch im Entwurf befinden und die sich damit befassen, wie ein Konsens über Zeitstempel erreicht werden kann und wie die Konfliktlösung durch das Schreiben von FPC-Stellungnahmen in dem Tangle optimiert werden kann. Sie können diese hier und hier einsehen.
Unter dem Gesichtspunkt der kontinuierlichen Integration/des kontinuierlichen Einsatzes (Continuous Integration/Continuous Deployment, CI/CD) haben wir den Einsatz von Snyk in unsere Pipeline integriert. Seine Integration hat bereits dazu beigetragen, einige Sicherheitsprobleme innerhalb der JWT-Bibliothek aufzudecken, die wir derzeit zum Schutz des Zugangs zu den APIs verwenden. Dieses Tool wird uns dabei helfen, unseren Code während seiner gesamten Entwicklung sicherer zu machen.
Das dRNG-Experiment, das im vergangenen Monat mit dem von der Community gesteuerten GoShimmer X-Team begonnen hat, war voll und ganz erfolgreich! Die Community schaffte es, ein verteiltes Komitee von 7 Mitgliedern zu schaffen und gemeinsam alle 10 Sekunden ohne Unterbrechung neue Zufälligkeiten zu erzeugen, und das schon seit mehr als 2 Wochen. Unten sehen Sie einen Screenshot von einigen der Zufälligkeiten, die im lokalen Dashboard des GoShimmer angezeigt werden:
Wir überwachen ständig die Leistung unserer dRNG-Lösung auf der Grundlage des drand-Projekts. Innerhalb der letzten 2 Wochen konnte das verteilte Komitee ein schwellenwertbasiertes Unterschriftenschema (4 von 7) ausführen und die jeweiligen Beiträge austauschen, um eine neue Zufälligkeit unter 300 ms im Durchschnitt zu erzeugen, wie Sie aus dieser Darstellung ersehen können.
Was die nächsten Schritte betrifft, so werden wir sehr bald eine neue Pollen-Testnet-Version v0.3.0 mit dem Community-getriebenen dRNG als Standard veröffentlichen.
Pollen-Testnet-Studiengruppe
Da die Implementierung des Pollen-Testnetzes voranschreitet und immer mehr der Coordicide-Module integriert werden, ist es an der Zeit, das Testnetz richtig zu analysieren. Für uns Forscher sind dies aufregende Zeiten!
Coordicide umfasst viele Module, die wir auf Papier entwickelt und studiert und durch Simulationsstudien als eigenständige Module validiert haben. Es ist an der Zeit, all diese verschiedenen Module ineinandergreifen zu sehen und als Ganzes zum Leben zu erwecken.
Das Armaturenbrett in Pollen bietet bereits einen ausgezeichneten Überblick über die verschiedenen Komponenten und ihre Leistung in Pollen. Während diese Informationen viele gute Indikatoren für das ordnungsgemäße Funktionieren des Testnetzes liefern, besteht das Endziel dieser Gruppe darin, wissenschaftlich fundierte Beweise für die Behauptungen von Coordicide zu erhalten. Wir freuen uns darauf, demnächst weitere Ergebnisse zu diesem Unterfangen zu veröffentlichen!
Protokoll
In diesem Monat setzte die Protokollgruppe ihre Arbeit zur Klärung der wenigen letzten verbleibenden theoretischen Fragen zu IOTA 2.0 fort. Eines der Hauptthemen, das wir besprachen, war die Synchronisierung zwischen Knoten und Werkzeugen, mit denen der Knoten erkennen kann, ob er nicht synchron ist. Abgesehen davon entwickelten wir die Spezifikationen zum Bootstrapping weiter und vertieften unsere Diskussionen über das spieltheoretische Verhalten der Tip-Auswahl. Obwohl der URTSA (Uniform Random Tip Selection Algorithm) sehr gut funktioniert, ist er aufgrund der Freiheitsphilosophie der IOTA nicht durchsetzbar, so dass es letztlich dem Knotenoperator überlassen bleibt, welchen er verwendet. Die Forschung über TSAs muss sicherstellen, dass der TSA die beste Option ist, die ein Knoten unter Standardannahmen verwenden kann.
Nächsten Monat wollen wir die mathematische Untersuchung der TSA abschliessen und unsere Schlussfolgerungen in die entsprechenden Spezifikationen einfliessen lassen.
Vernetzung
Wir konzentrieren unsere Bemühungen auf eine umfassende Angriffsanalyse des Staukontrollalgorithmus. Insbesondere haben wir durch Simulationen nachgewiesen, dass Angreifer weder die Fairness (die Anforderung, dass ein Knoten Nachrichten proportional zu seinem Mana sendet) noch die effiziente Nutzung der verfügbaren Kommunikations- und Verarbeitungsressourcen der Knoten beeinträchtigen können. Wir untersuchen derzeit ausgefeiltere Angriffe, bei denen böswillige Knoten verschiedene Nachrichtenströme an verschiedene Nachbarn aussenden, um die Konsistenz zu beeinträchtigen. Vorläufige Ergebnisse zeigen, dass geeignete Richtlinien zur Nachrichtenabgabe und Schwarze Listen wirksame Gegenmaßnahmen sind.
Wir freuen uns, mitteilen zu können, dass unser Forschungspapier „Healthor: Protecting the Weak in Heterogeneous DLTs with Health-aware Flow Control“ (Schutz der Schwachen in heterogenen DLTs durch gesundheitsbewusste Flusskontrolle) zur Veröffentlichung auf dem 4. Workshop über skalierbare und belastbare Infrastrukturen für verteilte Ledger (SERIAL 2020) angenommen wurde. Die Arbeit zeigt, wie es möglich ist, unseren Staukontrollalgorithmus im Falle einer intermittierenden Konnektivität durch Rückkopplung von benachbarten Knotenpunkten anzupassen.
Zusätzlich entwerfen wir einen verteilten Zufallszahlengenerator (dRNG) auf der Basis verifizierbarer Verzögerungsfunktionen, der als zweite Zufallsquelle verwendet werden kann (die erste Zufallsquelle in Coordicide stammt von einem dRNG, der auf Schwellenwertkryptographie basiert).
Sharding
Wie vielen unserer Gemeindemitgliedern inzwischen bekannt ist, haben wir unseren Sharding-Ansatz, den wir Fluid Sharding nennen, genau unter die Lupe genommen. Unser Ziel beim Fluid Sharding ist es, das skalierbarste Basisschicht-DLT zu bauen, das man überhaupt bauen kann. Es genügt zu sagen, dass dies keine kleine Aufgabe ist, obwohl wir sehr zuversichtlich sind, dass unser Team dazu in der Lage ist! Es ist wahrscheinlich, dass wir beide Skalierbarkeitsschienen parallel verfolgen werden. Einen Überblick über diesen Ansatz auf hoher Ebene finden Sie hier.
Als wir begannen, uns formeller mit diesem Thema zu befassen, haben wir eine umfassende Literaturrecherche zu bestehenden Ansätzen und Lösungen durchgeführt, um sicherzustellen, dass unser Team auf dem neuesten Stand der Forschung über Sharding ist. Unser Ziel war es, die aktuelle Forschung zu untersuchen, um auch die Sicherheit unserer eigenen Lösung zu verbessern.
Unsere Leser sind wahrscheinlich mit dem Begriff der Skalierungslösungen der ersten und zweiten Schicht vertraut, und wir sind dabei, diese beiden Ansätze zur Skalierbarkeit in IOTA zu integrieren. Fluid Sharding bezieht sich auf unsere Skalierungslösung der ersten Schicht. Wir sehen uns auch das, was wir als „Datensharding“ bezeichnen, als eine Art Lösung der zweiten Schicht genau an.
Unsere Gespräche mit verschiedenen Interessenvertretern von IOTA waren fruchtbar, da wir verstanden haben, dass das Datensharding in der Tat vielen Bedürfnissen normaler Benutzer und Anwender in Unternehmen gleichermaßen dient. Wir glauben, dass letztendlich beide Lösungen entwickelt werden und zusammen werden sie das umfassen, was man als eine „vollständig gesharte“ IOTA 3.0 bezeichnen könnte.
Vielen Dank für die Lektüre, und wenn Sie Fragen haben oder einfach nur Hallo sagen möchten, finden Sie unsere Forschungsteammitglieder im Kanal #tanglemath auf unserer Seite Discord.
Sie sind auch willkommen, unsere technischen Diskussionen in unserem öffentlichen Forum zu verfolgen und daran teilzunehmen: IOTA.cafe.
Original Übersetzt von Serguei Popov: https://blog.iota.org/iota-research-status-update-october-2020-e8b279176f51
Schreibe einen Kommentar