Safe Network Entwickler Update đŸ‡©đŸ‡Ș 26. Januar 2023

Dies ist eine maschinelle Übersetzung. Das Original in Englisch ist hier: Update 26 January, 2023

Diese Woche gehen wir noch einmal auf das Node-Alter ein und sehen uns einige Optimierungen an, um es fĂŒr mehr Netzwerkoperationen zu nutzen. Machen Sie sich keine Sorgen, um jegliches Heulen und ZĂ€hneknirschen zu vermeiden, es ist nicht die Art von architektonischer Umgestaltung, die Monate dauern wird. Es baut auf dem auf, was bereits in Bezug auf neue Knoten vorhanden ist, die sich beweisen und im Netzwerk bewegen mĂŒssen, nimmt diesen jungen Knoten jedoch kritische Datenverarbeitungspflichten ab und beschrĂ€nkt sie auf diejenigen, die sich bereits bewĂ€hrt haben.

Allgemeiner Fortschritt

Nach langen und teils hitzigen Community-Diskussionen haben @JimCollinson und @andrew die Spreadsheets wieder rausgeholt und die verschiedenen Optionen zur Token-Verteilung durchgearbeitet. Wir hoffen aufrichtig, dass dies die Grundlage dafĂŒr bietet, jetzt weiterzumachen.

@joshuef hat mit Testnetzen mit noch kleineren virtuellen Maschinen und kleinen Knoten experimentiert. Es lief ziemlich gut, aber es gab ein paar Fehler, die den DKG-Prozess (Elders Voting) betreffen, bei dem manchmal keine Stimmen eingehen. In diesem Zusammenhang werfen @anselme, @maqi und @davidrusu einen genauen Blick auf DKG, was genau es auslöst, einschließlich eines Blicks auf die SAP-Generation ( ein neuer Datensatz von Ältesten, der bei jeder Abwanderung erstellt wird) und wo genau das eine DKG-Runde auslöst.

@oetyng hat den Beitrittsprozess vereinfacht, indem es in die regulĂ€ren NachrichtenflĂŒsse verschoben wurde. Danach wurde der Umzugsfluss vereinfacht, indem er auch zu einem Join gemacht wurde, aber zu einem anderen Abschnitt, und einen Umzugsnachweis enthielt. @davidrusu fand eine potenzielle Notwendigkeit, zu behaupten, dass ein gĂŒltiges Abwanderungsereignis verwendet wurde, diese Arbeit steht bevor.

@bochaco hat sn_comms, das Kommunikationsmodul, debuggt und finalisiert, das er weiterhin umgestaltet.

Und Mostafa hat das Testen des Konsensalgorithmus abgeschlossen und ihn zum Hauptrepo hinzugefĂŒgt.

Vielen Dank an @southside fĂŒr den Vorschlag der ChatGTP-Code-Kommentar-Initiative. Jeder, der dort helfen möchte (keine technischen FĂ€higkeiten erforderlich), sollte sich diesen Beitrag ansehen.

Alter und Daten des Knotens

Verantwortlichkeiten im Netzwerk basieren auf dem Begriff des Knotenalters.

Das Knotenalter steigt nicht linear, sondern exponentiell an, was bedeutet, dass jede Alterserhöhung auf dem 2-fachen dessen basiert, was der vorherigen Erhöhung zugrunde lag.
Die Zeit im Netzwerk wird in der Anzahl von Ereignissen gemessen, und die Messung ist ungefĂ€hr, da wir eine probabilistische Bewertung durchfĂŒhren.
Das Alter „A“ tritt also nach „~n“ Ereignissen auf, und das Alter „A+1“ tritt nach „~2n“ Ereignissen auf.

Der Grund, warum das Node-Alter auf diese Weise gemessen wird, ergibt sich aus der empirischen Beobachtung, dass Nodes, die x-mal online geblieben sind, wahrscheinlich noch mindestens x-mal online bleiben. Wenn Sie also Zeit „t“ im Netzwerk verbracht haben, ist es wahrscheinlich, dass Ihre Gesamtzeit im Netzwerk am Ende mindestens „2t“ betrĂ€gt.

Dies bedeutet einfach, dass je jĂŒnger der Knoten ist, desto wahrscheinlicher wird er offline gehen, und je Ă€lter, desto wahrscheinlicher, dass er online bleibt.

Sehr stabile und sehr instabile Knoten zu haben, die beide Live-Daten speichern, wie wir es jetzt tun, ist schwer zu verwalten, wenn es viele Abwanderungen gibt. Wenn ein Knoten offline geht, mĂŒssen seine Daten zum nĂ€chsten XOR-nĂ€chsten Kandidaten ĂŒbertragen werden, was einige Zeit in Anspruch nimmt. Neue Knoten sind nicht zuverlĂ€ssig und können schnell offline gehen, was viele Datenbewegungen und Kopfschmerzen fĂŒr die Ältesten bedeutet, die sie verwalten mĂŒssen.

PrimÀr- und SekundÀrspeicher

Wir betrachten Konzepte rund um einen „stabilen Satz“ von Knoten (dazu spĂ€ter mehr). Aber eine Idee, die uns dies gibt, ist die Aufteilung von Knoten in zwei Speicherebenen, basierend auf dem Alter und (daher) der Wahrscheinlichkeit einer Abwanderung, und ihnen somit unterschiedliche Aufgaben zuzuweisen.

Zum Beispiel möchten wir, dass die stabilsten Knoten (z. B. ab 10 Jahren) fĂŒr die primĂ€re Datenspeicherung verantwortlich sind. Diese Nodes kĂŒmmern sich um die Daten und geben sie auf Anfrage an einen Client weiter. Sie werden wahrscheinlich in absehbarer Zeit nicht abwandern.

Knoten außerhalb eines solchen stabilen Satzes, die noch daran arbeiten, ihr Knotenalter zu erhöhen, halten zusĂ€tzliche Kopien von Daten (SekundĂ€rspeicher). Dabei stellen sie Redundanz bereit, um den stabilen Satz zu unterstĂŒtzen.

Ihr Verhalten im Umgang mit diesen Daten wird auch in ĂŒblicher Weise zur Bewertung ihrer QualitĂ€t herangezogen. Aber da sie nur zusĂ€tzliche Kopien halten, mĂŒssen sie von den Ältesten nicht so genau verfolgt werden und können ausfallen, ohne ernsthafte Probleme im Netzwerk zu verursachen oder eine Massendatenmigration zu erfordern.

Dies wĂŒrde es uns ermöglichen, die Anzahl der Replikationen fĂŒr Daten zu erhöhen und gleichzeitig eingehende Knoten grĂŒndlicher zu testen, ohne dabei die DatenstabilitĂ€t zu opfern. Alles durch Nutzung unseres bestehenden Node-Age-Systems. :tada:


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!