Safe Network Entwickler Update ūüá©ūüá™ 19. Mai 2022

Dies ist eine maschinelle √úbersetzung. Das Original in Englisch ist hier: 19 May 2022

Ein gesundes Netzwerk besteht aus gesunden Knoten, Ger√§ten, die das tun, was von ihnen erwartet wird, innerhalb eines akzeptierten Leistungsbereichs. Es ist die Aufgabe der √Ąltesten, sicherzustellen, dass die Erwachsenen in ihrer Abteilung auf dem neuesten Stand sind, und durch Abstimmung Ma√ünahmen zu ergreifen, wenn sie etwas Ungew√∂hnliches entdecken. Die Verfolgung von Funktionsst√∂rungen ist ein gro√üer Teil dessen, woran das Team derzeit arbeitet.

Allgemeiner Fortschritt

Diese Woche stellten wir fest, dass wir bei hoher Abwanderung und Splits potenziell Knoten verlieren w√ľrden, wobei der Knoten denkt, dass er sich angeschlossen hatte, aber mit Abwanderung der g√ľltige Abschnittsschl√ľssel weitergegangen war. Der Knoten, der dachte, alles sei in Ordnung, versuchte nicht, sich wieder zu verbinden. @anselme hat also daran gearbeitet, unser Netzwerkwissen zu √ľberpr√ľfen und nach der Aktualisierung den Beitrittsprozess f√ľr diese verlorenen Knoten erneut zu versuchen.

Die DBC-Arbeit wird mit den ersten Schritten zum Speichern des SpentBook fortgesetzt.

Beim Ausf√ľhren von Testnetzen zum Debuggen von Dateninstabilit√§t haben wir ein Paar potenzieller Deadlocks aufgedeckt. In einem Fall sahen wir, dass DataStorage-Lesevorg√§nge w√§hrend der Replikation h√§ngen blieben. Also machten wir uns daran, einige Benchmarks zu erstellen, um ChunkStorage zu testen, und damit entdeckten wir einen Deadlock im zugrunde liegenden Speichercode.

Eine weitere (unbest√§tigte) Sperre trat w√§hrend des Bereinigungsprozesses von ‚ÄěPeerLink‚Äú auf. Es ist schwer zu sagen, ob dies definitiv der Fall war, aber wir hatten ins Stocken geratene Knoten gesehen und unser Bereinigungscode wurde h√§ufig um die Sperren herum aufgerufen. Es gab viel Potenzial zur Vereinfachung, also haben wir genau das getan.

Eine weitere potenzielle Sperre trat bei einer Fehlfunktion auf, wobei die verschachtelte Datenstruktur falsch gelesen wurde ohne ‚Äěmut‚Äú-Sperre. :open_mouth: :man_facepalming:

Es ist schwer zu sagen, ob all dies mit Sicherheit geschehen ist (und bestimmte Bedingungen erfordert), aber sicherlich sollten diese √Ąnderungen Schritte in die richtige Richtung sein!

Mit all dem haben wir endlich auch die DKG-√úbergabe mit Generationsarbeit integriert (die gegen√ľber anderen k√ľrzlichen √Ąnderungen viel stabiler war). Wir schrauben an der Stabilit√§t, da weitere Tests/Benchmarks f√ľr DataStorage kommen werden, und einige andere Optimierungen an Datenreplikationsfl√ľssen, die getestet werden (wir m√ľssen den Pool von Knoten erweitern, die wir nach Daten fragen, wie bei starker Abwanderung, die Chancen eine weitere frisch verbundene Node-Erh√∂hung zu treffen und es sieht so aus, als w√ľrden wir anfangen, die Datenspeicherung zu verlieren!).

Dysfunktionsverfolgung

Die Verfolgung von Funktionsstörungen ist ein fortlaufender Prozess. Es gibt immer neue Verhaltensweisen zu testen und zu modellieren, und daher ist es ein iterativer Prozess, der Verbesserungen in Leistung und Stabilität ermöglicht, während wir uns weiterentwickeln.

Die Nachverfolgung von Funktionsst√∂rungen unterscheidet sich vom Umgang mit B√∂swilligkeit. Bosheit ist eine objektiv nachweisbare schlechte Handlung, wie das Signieren einer ung√ľltigen Netzwerknachricht, und es ist die Aufgabe aller Knoten, solche Knoten zu identifizieren und sie zu bestrafen. Dysfunktion hingegen bedeutet ‚Äěunterdurchschnittliches Verhalten‚Äú, und es ist die Pflicht der √Ąltesten, herauszufinden, was das bedeutet.

Ein Knoten kann aufgrund von Umgebungsfaktoren wie vor√ľbergehender lokaler Internet-Langsamkeit oder Bedingungen, die sich im Laufe der Zeit aufbauen, wie z. B. unzureichender Speicherplatz oder Arbeitsspeicher, unterdurchschnittliche Leistung erbringen. Oder eine pl√∂tzliche Funktionsst√∂rung, wie ein Stromausfall oder ein erzwungener Neustart.

Dysfunction deckt auch betriebliche Faktoren ab, darunter die Qualität und Anzahl der Nachrichten sowie das Speichern und Freigeben von Daten auf Anfrage.

Einige Arten von Funktionsstörungen (Datenverlust, längerer Verbindungsverlust) sind schwerwiegender als andere und sollten daher anders behandelt werden.

Wir können die Leistung eines Knotens im Vergleich zu anderen Knoten im Abschnitt testen, aber was ist, wenn der gesamte Abschnitt im Vergleich zu anderen Abschnitten minderwertig ist? Was dann?

Wie Sie sehen, ist die Nachverfolgung von Funktionsstörungen ein komplexes Thema mit vielen Variablen.

Ziele der Störungsverfolgung

Indem wir Nodes √ľberwachen, w√§hrend sie ihren Aufgaben nachgehen, wollen wir alle Probleme im Keim ersticken, bevor sie entstehen. Das Auswerfen eines Knotens sollte der letzte Ausweg sein, stattdessen m√∂chten wir Ma√ünahmen ergreifen ‚Äď oder den Eigent√ľmer des Knotens, den Farmer, Ma√ünahmen ergreifen lassen ‚Äď um das Problem zu beheben.

Dieser Prozess der schrittweisen Korrektur des Knotenverhaltens sollte automatisiert und flexibel sein und in der Lage sein, auf sich √§ndernde Bedingungen zu reagieren, anstatt auf willk√ľrlichen fest codierten Parametern zu basieren.

Bei der Nachverfolgung von Funktionsst√∂rungen geht es um Optimierung, aber nicht nur um die Leistung zu optimieren ‚Äď das w√ľrde zu einer Zentralisierung f√ľhren. Heimanwender k√∂nnten nicht mit Rechenzentrumsinstanzen konkurrieren ‚Äď sie w√§ren immer relativ dysfunktional.

Wo wir sind

Derzeit haben wir eine vereinfachte Version der Dysfunktion.

Liveness-Tests √ľberpr√ľft, ob Knoten online sind, sodass √Ąlteste Ma√ünahmen ergreifen k√∂nnen, wenn dies nicht der Fall ist. Dies wurde erweitert, um Knoten nicht nur f√ľr das Verwerfen von Chunks, sondern auch f√ľr das Verwerfen von Verbindungen und das Zur√ľckbleiben in Bezug auf Netzwerkwissen zu bestrafen.

Lebendigkeit Testen, einmal optimiert, um sicherzustellen, dass wir nicht zu hart (wie wir es bisher waren) oder zu weich mit fehlerhaften Knoten umgehen, ist ein guter erster Schritt, um ein stabiles Netzwerk zu gew√§hrleisten, aber mit der Verfolgung von Funktionsst√∂rungen m√∂chten wir noch weiter gehen und eine aufbauen Modell, das auch f√ľr andere Faktoren optimiert wird.

Nodes zu bestrafen bedeutet derzeit, sie fallen zu lassen, wird aber bald andere Ma√ünahmen wie die Halbierung des Node-Alters umfassen. Entscheidungen dar√ľber, welche Vorgehensweise zu ergreifen ist, werden von den √Ąltesten im Konsens getroffen.

Wie bereits erw√§hnt, ist ein gewisses Ma√ü an ‚Äědysfunktionalem Verhalten‚Äú unvermeidlich, und im Moment experimentieren wir damit, Knoten als gut (95 %+ Erfolgsquote f√ľr eine bestimmte Operation), mittelm√§√üig (75 %) oder schlecht (30 %) zu klassifizieren kann jede Klasse entsprechend ihrer Ernsthaftigkeit unterschiedlich behandeln, ohne ‚Äěerwartete‚Äú Werte fest zu codieren (PR #1179). Wir wollen auch wissen, wie viele Knoten jeder Klasse in unserem Abschnitt sind.

Die sn_dysfunction Kiste ist hier.

Wo gehen wir hin

Wir m√∂chten die Anzahl der von uns durchgef√ľhrten Tests und Parameter, die wir √ľberpr√ľfen, erweitern, um sicherzustellen, dass wir das Netzwerk auf sinnvolle Weise modellieren.

Zu den Ideen geh√∂rt die regelm√§√üige Befragung von Erwachsenen, um ihnen einen kleinen Arbeitsnachweis zu geben, der auch √ľberpr√ľfen k√∂nnte, ob sie eine aktuelle Version einiger ver√§nderlicher Daten besitzen. Ver√§nderliche Daten sind ein CRDT und werden schlie√ülich konvergieren, aber eine zeitweilige Konnektivit√§t kann bedeuten, dass ein Replikat eine veraltete Version zur√ľckgibt. Wie veraltet es ist, w√ľrde sich auf seinen Dysfunktions-Score auswirken, eine kumulative Z√§hlung, die jedem Knoten zugeordnet wird. Wenn dies einen Schwellenwert √ľberschreitet, kann dieser Knoten als ‚Äěmittelm√§√üig‚Äú oder ‚Äěschlecht‚Äú neu klassifiziert und entsprechend behandelt werden. √úber welchen Zeitraum wir die Punktzahl weiter erh√∂hen, muss getestet werden.

Nicht alle Probleme können durch den Vergleich der Leistung zwischen Peers verfolgt werden (wenn alle Knoten schlecht sind, bedeutet dies einen schlechten Abschnitt; wenn zu viele Abschnitte schlecht sind, bedeutet dies ein schlechtes Netzwerk), daher werden wir uns geeignete globale Parameter ansehen.

Wir m√ľssen auch √ľberlegen, wie wir die Verfolgung von Funktionsst√∂rungen nutzen k√∂nnen, um die Knotenvielfalt zu f√∂rdern und zu vermeiden, dass es zu einer Zentralisierung kommt, sodass sowohl eine AWS-Instanz als auch ein Raspberry Pi eine Rolle spielen k√∂nnen.

Und wir wollen √ľberlegen, wie wir dem Endnutzer, dem Farmer, Informationen √ľber Funktionsst√∂rungen pr√§sentieren, m√∂glicherweise als eine Reihe von Standardparametern, die √ľber eine Konfigurationsdatei und sp√§ter √ľber eine GUI angepasst werden k√∂nnen.

Letztendlich ist Safe wie ein globaler Computer, wobei die √Ąlteren eine Multithread-CPU und die Erwachsenen eine riesige Festplatte sind. Wir wollen, dass diese Festplatte sich selbst heilt und dass sich die CPU an √Ąnderungen anpassen kann.

All dies f√ľhrt uns in den Bereich des Chaos Engineering, wie es von Unternehmen wie Netflix und Google auf ihren Cloud-Plattformen verwendet wird, um sicherzustellen, dass einzelne Serverausf√§lle verschwinden bringt nicht das ganze System zum Erliegen.

Wahrscheinlich können wir auch hier etwas lernen, wenn wir daran arbeiten, das Safe Network robust und zuverlässig zu machen.


N√ľtzliche Links

F√ľhlen Sie sich frei, unten mit Links zu √úbersetzungen dieses Entwicklungsupdates zu antworten, und die Moderatoren werden sie hier hinzuf√ľgen.

Als Open Source-Projekt sind wir immer auf der Suche nach Feedback, Kommentaren und Community-Beitr√§gen. Seien Sie also nicht sch√ľchtern, machen Sie mit und lassen Sie uns gemeinsam das sichere Netzwerk erstellen!