Safe Network Entwickler Update 🇩🇪 5. Januar 2023

Dimitar · 7. Januar 2023 um 08:54

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

Allen ein frohes neues Jahr Es ist großartig, zurück zu sein – wir sind fest entschlossen, dass dieses Jahr wirklich zählt Das Team hat es alle geschafft, sich ein bisschen Freizeit zu gönnen, und ist bereit zu gehen. In der Pause haben wir auch einige Dinge behoben und über mögliche Verbesserungen nachgedacht, einschließlich der optimalen Größe von Knoten und Abschnitten und Änderungen am Knotenalter und Umzug. Für das erste davon haben wir interne Testnetze mit kleineren Knoten und größeren Abschnitten ausgeführt. Diese liefen ziemlich gut und haben ein oder zwei andere Probleme im Zusammenhang mit Kommunikation und Übergabe aufgedeckt, die wir bearbeitet haben. Die zweite ist eine Designoptimierung, die jüngere Knoten anders behandelt als ältere. Näheres dazu in den nächsten Wochen.

Allgemeiner Fortschritt

Eine Pause in der Routine kann eine gute Gelegenheit sein, darüber nachzudenken, was besser gemacht werden kann, und lose Enden zu binden. Hier ist eine Zusammenfassung dessen, was das Team seit dem letzten Update gemacht hat.

Aufteilung des Catch-All-Messaging „NodeMsg::Propose“ in vier verschiedene Varianten zur Verdeutlichung.

RequestHandover: Wenn Nodes DKG beenden und eine Übergabe an die aktuellen Ältesten anfordern (node->elder)
SectionHandoverPromotion: Wenn Älteste diesen Knoten mitteilen, dass sie als Älteste befördert werden (Ältere->Knoten)
SectionSplitPromotion: wenn Älteste diesen Knoten mitteilen, dass sie auf beiden Seiten eines Splits als Älteste befördert werden (Ältere->Knoten)
ProposeSectionState: Wenn sich Älteste entscheiden, Knoten zu kicken oder neue Knoten innerhalb eines Abschnitts zu akzeptieren (Ältere->Ältere)

Diese Unterscheidung macht deutlich, wer signiert und wer die Signaturen empfängt/zusammenfasst.

Unnötige Nachrichten hacken
Wir behoben ein kostspieliges Problem, bei dem AE-Nachrichten wiederholt den SectionTree für jede Nachricht überprüften, selbst wenn er bereits überprüft worden war.

Optimierung von AE
Wir haben mit der Verlangsamung der AE-Untersuchung um Splits herum experimentiert, um die Anzahl der herumfliegenden Nachrichten zu reduzieren, und auch das Wissen der globalen Netzwerkabschnitte umgestaltet, um auf eine zufällige abzuzielen Elder in drei zufälligen Abschnitten alle fünf Minuten. Zuvor war die Standardeinstellung alle Ältesten in drei Abschnitten alle 30 Sekunden. Dies führte zu einer stark reduzierten CPU- und Speichernutzung um Splits herum, und die längere Zeit sollte für unsere Anforderungen ausreichen: Splits treten schließlich nicht etwa alle 30 Sekunden auf.

Hohe Speichernutzung beim Warten auf den Beitritt
Wir haben uns mit einem Fehler befasst, der eine hohe Speichernutzung verursacht in Knoten, während sie auf den Beitritt warten, wie in den letzten Testnetzen zu sehen war. Wir sind bereit, dies in Kürze in einem Community-Testnet auf Herz und Nieren zu testen. Wir haben auch das Caching von Verbindungssitzungen für nicht verbundene Knoten verhindert.

Comms-Refaktorierung
Eine hässliche Sperre im Code für „send-streams“ in „sn_node“ wurde entfernt. Darüber hinaus testen wir „Happy Path“-Kommunikation, bei der Kunden eine Nachricht nur an einen Ältesten und nicht an alle senden können.

Wir haben auch Knotenverfolgungscode und zugehörige Sperren entfernt, die potenzielle Fehlerquellen waren. Wir sahen viele Nachrichten als Folge einer fehlgeschlagenen Änderung der Sende-/Speicherebene, die Knoten blockierten.

Änderungen der Speicherparameter
Der Speicherkapazität wurde eine Marge hinzugefügt, wobei wir eine Mindestspeichermenge erwarten, Knoten jedoch mehr speichern können. Dies sollte dazu beitragen, die Fehler „Konnte nicht speichern“ vor der Aufteilung zu verringern. Wir haben auch Älteste eingerichtet, um Daten zu speichern (das waren sie vorher nicht) und verwenden ihre lokale Mindestspeicherkapazität als Indikator dafür, wann sie aufgeteilt werden sollten, wie im Forum besprochen.

Damit haben wir nun folgenden Ablauf:

Knoten empfangen Daten.
Jedes Mal, wenn wir (zum ersten Mal) eine bestimmte Menge an verwendetem Speicher passieren, lassen wir neue Knoten beitreten.
2.1 Wenn ein Knoten um Beitritt bittet, sehen wir, dass Beitritte erlaubt sind, und Älteste starten eine Abstimmung, um den Knoten hinzuzufügen.
Wenn ein neuer Knoten hinzukommt, werden Joins deaktiviert, wir prüfen, ob wir min_capacity erreicht haben
3.1. Wir haben min_capacity nicht erreicht, fahren Sie wie gewohnt fort.
3.2. Wir haben min_capacity erreicht, bereinigen Sie überschüssigen Speicher.
3.3 Wenn wir immer noch bei oder über min_capacity sind, lösen Sie das ausfallsichere allow_joins_until_split aus.
3.4. Wenn ein Knoten um Beitritt bittet, sehen wir, dass Beitritte erlaubt sind, und Älteste starten eine Abstimmung, um den Knoten hinzuzufügen.
Der beitretende Knoten entlastet die Speicherlast.

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!