Safe Network Entwickler Update 🇩🇪 20. Januar 2022

Dies ist eine maschinelle Ăśbersetzung. Das Original in Englisch ist hier: Update 20 January, 2022

Ein Schlüsselbereich ist im Moment die Mitgliedschaft, wie Älteste die Erwachsenen und andere Älteste in ihrer Sektion im Auge behalten, damit sie neue Beitritte, Trennungen, Abwanderungen und Beförderungen handhaben können. Diese Funktionalität wird von der Kiste sn_membership übernommen. Die Algorithmen in dieser Kiste werden derzeit strengen Tests unterzogen, bevor sie in das Netzwerk integriert werden. Dies ist an sich kein neues Feature, sondern eher eine forensische Verschärfung des bisherigen Übergangs und eine Formalisierung der Algorithmen. Der größte Teil des Teams arbeitet derzeit an einigen Aspekten der Mitgliedschaft.

Allgemeiner Fortschritt

Die Kiste sn_membership wird von @davidrusu verwaltet. Fast alle Tests sind jetzt bestanden, also heißt es vor allem aufräumen.

@bochaco betrachtet Ströme innerhalb der Mitgliedschaft: Wie ist die Reihenfolge der Ereignisse, wenn ein neuer Knoten beitritt oder der älteste Erwachsene befördert wird?

Ein Aspekt, der von der Mitgliedschaftsverwaltung abgedeckt wird, sind Ältestenübergaben, um sicherzustellen, dass neu beförderte Älteste alle richtigen Informationen, Schlüssel und so weiter haben. @anselme hat das jetzt gut hinbekommen und es ist so gut wie fertig.

Außerhalb der Mitgliedschaft hat @chriso Probleme mit nächtlichen Tests durchgearbeitet und schreibt jetzt, nachdem er die CLI-Dokumentation fertiggestellt hat, NRS.

An der Datenfront konzentriert sich @yogesh auf das Testen der Datenreplikation, und @joshuef hat qp2p auf die neueste Version von quinn aktualisiert.

In der Zwischenzeit steckt @danda bei DBCs ein. Die Integration von Ring CT ist so gut wie abgeschlossen, und Mints sind der nächste Schritt, obwohl noch mehr Arbeit erforderlich ist, damit Mints mit Ring CTs ordnungsgemäß funktionieren.

@happybeing hat eine schöne kleine PR erstellt Aktualisierung der Node-Protokollierung. Dies sollte dazu beitragen, Platz auf allen gestarteten Knoten zu sparen und Protokolle mit Befehlen wie „tail -f“ leichter zu verfolgen.

Mitgliedschaft

Die Mitgliedschaftsoperationen umfassen neue Knoten, die der Sektion beitreten, die Kapazität verwalten, sich schlecht benehmende Knoten auswerfen oder ihr Knotenalter reduzieren, Erwachsene zu Ältesten befördern und sicherstellen, dass neue Älteste richtig ausgestattet sind.

Zur Erinnerung: Die Sektionen haben sieben Älteste und (sofern zukünftige Tests nichts anderes ergeben) 60 bis 100 Erwachsene. Erwachsene wechseln häufig, mit Aussteigern, Neuzugängen und älteren Knoten, wenn sie aus anderen Abteilungen umgezogen werden. Die Ältesten müssen die Sektionsmitgliedschaft im Auge behalten, damit sie wissen, wann sie neuen Erwachsenen den Beitritt erlauben müssen, und auch, wenn Älteste abwandern und ein Erwachsener befördert wird. Sie führen eine Liste aller aktuellen Erwachsenen und Ältesten in ihrer Abteilung.

Die Abschnittsmitgliedschaft wird durch die maximale Abschnittsgröße eingeschränkt. Wenn wir solche Einschränkungen in einem verteilten System haben, müssen wir oft auf einen Konsens zurückgreifen, um zwischen konkurrierenden Optionen zu entscheiden. In unserem Fall der Mitgliedschaft müssen die Ältesten entscheiden, welcher der (vielen) Knoten, die darauf warten, einer Sektion beizutreten, zugelassen werden soll.

Wir haben bis zu diesem Zeitpunkt keinen Konsensalgorithmus verwendet, die aktuellen Prozesse zur Verwaltung der Mitgliedschaft geraten manchmal ins Stocken, wenn unerwartete Ereignisse eintreten.

Die neue Kiste sn_membership bietet einen fĂĽhrerlosen BFT-Konsensalgorithmus, der eine gute Leistung in einem eventuell synchronen Netzwerkmodell bietet. Nach einem gnadenlosen Testregime ist es nun bereit, in das Netzwerk integriert zu werden.

sn_membership arbeitet mit Anti-Entropie (AE) und verteilter Schlüsselgenerierung (DKG) zusammen, um die Abschnittsmitgliedschaft zu verwalten. Hier sind einige Strömungen.

Knotenbeitritt

Ein beitretender Knoten interagiert mit einem Ältesten, tauscht „JoinRequests“-Nachrichten aus, bis er vorläufig akzeptiert wird, und empfängt die Ressourcennachweis-Herausforderung und sendet sie an den Ältesten zurück.

Unter dem alten System war der Knoten nach bestandenem Test drin, aber das war ein Sicherheitsrisiko und konnte zu Blockaden führen (siehe unten). Nun sendet der Älteste einen Vorschlag zum Hinzufügen des Knotens unter Verwendung des sn_membership-Protokolls an andere Älteste der Sektion. „sn_membership“ ist abgeschlossen, sobald wir „Super-Majority over Super-Majority“ haben, das heißt, eine Super-Mehrheit von Ältesten sieht, dass eine Super-Mehrheit von Ältesten diesen Vorschlag angenommen hat. Sobald sn_membership gestartet wurde, wird es garantiert abgeschlossen (solange unsere Annahme eines eventuell synchronen Netzwerks nicht verletzt wird).

Sobald der Vorschlag einen Konsens unter den Ă„ltesten erreicht, sendet der Ă„lteste die Genehmigung an den beitretenden Knoten zurĂĽck.

Erwachsenenförderung und Ältestenübergabe

Wenn ein Ältester bemerkt, dass die aktuellen Ältesten nicht die sieben ältesten Knoten sind, löst dies eine Abstimmung über die Beförderung der ältesten Erwachsenen und die Herabstufung der jüngsten Ältesten aus, um Platz zu machen.

Der Elder-Handover-Algorithmus, der diesen Prozess steuert und nun bereit ist, in die sn_membership-Kiste integriert zu werden, geht wie folgt.

Ein Ältester erhält eine Mehrheit der abgeschlossenen DKG-Anteile, um zu überprüfen, ob die aktuellen Ältesten die ältesten sieben Mitglieder sind.

Der Älteste schlägt einen neuen Satz vorÄlteste.

Die Ältesten folgen einem Konsens im Stil von sn_membership, um über eine einzige NewElders-Nachricht zu entscheiden. Dieser Schritt ist erforderlich, wenn wir eine komplizierte Kette von Ereignissen haben, die dazu führen, dass mehrere Gruppen von Knoten um die Vervollständigung von DKG rennen und die nächsten Ältesten werden.

Eine Liste der aktuellen Sektionsmitglieder wird an den neuen Ältesten weitergegeben, der Sektionsautoritätsanbieter (SAP) wird aktualisiert und ein neuer Block zur Sektionskette hinzugefügt.

Die Rolle des Konsenses

Warum also ist Konsens fĂĽr die Mitgliedschaft notwendig, wenn andere Teile des Netzwerks auf AE angewiesen sind, um auf dem Laufenden zu bleiben?

Hier ist ein Beispiel. Angenommen, ein Abschnitt ist fast voll. Die Abschnittsgrößenbeschränkung beträgt 50 Knoten (nur als Beispiel) und es gibt derzeit 49 Mitglieder. Ein neuer Knoten sendet eine „JoinRequest“ an einen Ältesten. In einem System ohne Konsens überprüft der Älteste die Kapazität und sieht, dass Kapazität vorhanden ist, tauscht AE-Nachrichten aus und vorausgesetzt, der neue Knoten besteht den Ressourcennachweistest, ist er dabei.

Aber in diesem Stadium ist der Abschnitt bereit, sich aufzuteilen, was zu widersprüchlichen Prioritäten führen kann, wenn mehrere Knoten versuchen, sich zu verbinden:

Nehmen wir an, im Extremfall erhalten alle sieben Ältesten gleichzeitig „JoinRequests“ von sieben verschiedenen Knoten. Alle sieben Ältesten sehen, dass wir Platz für einen weiteren Knoten haben, und da jeder der sieben Knoten seine Ressourcen-Beweistests bestanden hat, wird jeder Älteste seinem Knoten erlauben, der Sektion beizutreten.

Aber nach Anti-Entropie-Klatsch zwischen Ältesten stellen sie fest, dass ihre Mitältesten die neuen Knoten des anderen nicht akzeptieren werden, da dies die Kapazität der Sektion über die Grenze bringen würde. Die Ältesten finden sich in einer Situation mit zweigeteiltem Gehirn wieder, in der jeder Älteste eine andere Ansicht über die Sektionsmitgliedschaft hat.

Um dieses Problem zu verhindern, einigen sich die Ältesten darauf, welche Knoten zugelassen werden. Mit `sn_consensus’ kann jeder der sieben Ältesten bis zu eine Änderung vorschlagen. So können in einer Runde bis zu sieben Wechsel (Beitritt/Austritt) entschieden werden.

Im obigen Fall bedeutet sn_membership etwas zusätzliche Arbeit im Vergleich zu den Ältesten, die alleine handeln, aber dieser Overhead wird nur sichtbar, wenn wir viele konkurrierende Optionen haben. sn_membership wird elegant auf Byzantine Reliable Broadcast (BRB) herunterskaliert, wenn sich die Ältesten im Allgemeinen über die zu ergreifenden Maßnahmen einig sind, wir zahlen nur den Konsens-Overhead, wenn die Ältesten beginnen, Meinungsverschiedenheiten zu haben. sn_membership ist eine friedliche Methode, um Meinungsverschiedenheiten zu lösen :slight_smile:


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!