Dies ist eine maschinelle Übersetzung. Das Original in Englisch ist hier: Update 13 October, 2022
Wir haben jetzt schon eine Weile über den überarbeiteten Prozess zur Wahl neuer Sektionsältester und zur Verwaltung von Splits gesprochen. Diese Woche befasst sich @anselme mit der Denkweise hinter dem Gürtel-und-Klammern-Ansatz.
Allgemeiner Fortschritt
@Chriso überarbeitet die Prozesse zum Signieren von Chunks und Registern und testet Speicher- und DBC-Doppelausgaben.
@roland arbeitet an Tests für die sn_sdkg-AE- und Mitgliedschaftsfunktionalität, die unten beschrieben werden.
Mostafa hat dezentrale Konsensmechanismen erforscht und überprüft unser aktuelles Setup.
@davidrusu überarbeitet den Beitrittsprozess, um vor dem Beitritt eine Aktualisierung des Netzwerkwissens einzuschließen.
Und @anselme und @dirvine überarbeiten den Autoritätsprozess wie letzte Woche beschrieben.
@bzee, @bochaco und @joshuef arbeiten am Debuggen der Stabilität auf niedriger Ebene. Wir haben festgestellt, dass eine Kombination aus langsamer Nachrichtenverarbeitung und Fehlern in der Verbindungsverwaltung gelegentlich Probleme verursacht. Also tauchen wir hier tief ein. Wir haben einige Fortschritte gemacht, indem wir die Handhabung von Nachrichten vereinfacht haben, und machen weiter an dieser Front, da es so aussieht, als würde es ein ziemlich vielversprechender Refactor sein, sowohl in Bezug auf die Einfachheit des Codes als auch auf die Stabilität.
Alles über sn_sdkg
DKG mit sn_sdkg
- Basierend auf der Schlüsselgenerierung von poanetwork in hbbft
- Entfernt Timer
- Stellt Klatsch vor
- Umarmt die gleichzeitige DKG
- Ein Rennen zwischen DKGs bis zur Übergabe
Wir haben gerade sn_sdkg (Safe Network Synchronous Distributed Key Generation) integriert und die vorherige Version ersetzt, in der wir bei langsamen Netzwerken Fehler und Zeitüberschreitungen sahen. Die Hauptursache ist wahrscheinlich, dass wir Timer verwenden. Dieser neue DKG-Prozess verwendet keine Timer, tatsächlich wollen wir überhaupt keine Timer auf Safe, nirgendwo.
DKG ist nicht aktiv, es ist nur etwas, was Knoten im Hintergrund tun, wenn sie Systemmeldungen erhalten, und sie können mehrere Sitzungen gleichzeitig ausführen.
Neben der Verwendung von Anti-Entropie (AE) führt sn_sdkg auch Klatsch ein, um sicherzustellen, dass Knoten alle Nachrichten erhalten, die ihnen möglicherweise fehlen, damit alle letztendlich konsistent sind.
Gehen wir es durch.
Älteste senden DkgStart
- Abschnitt aufgeteilt
- Abschnittsübergabe
Der erste Schritt in diesem Prozess besteht darin, dass die Ältesten eine „DkgStart“-Nachricht senden. Dies geschieht, wenn eine von zwei Situationen eintritt. Der erste ist, wenn ein Knoten in einem Abschnitt ankommt, der älter ist als einer oder mehrere der aktuellen Ältesten. In diesem Fall müssen wir übergeben - der neue Knoten wird gefördert und Abschnittswissen weitergegeben. Das zweite Szenario ist, wenn der Abschnitt zu groß wird und sich aufspaltet.
Rost
pub struct DkgSessionId {
/// Präfix der Sitzung, für die wir die älteren Kandidaten sind
Pub-Präfix: Präfix,
/// Andere Älteste in dieser dkg-Sitzung
Pub-Älteste: BTreeMap<XorName, SocketAddr>,
/// Die Länge des Hauptasts der Abschnittskette.
pub section_chain_len: u64,
/// Die Bootstrap-Member für die nächste Membership-Instanz.
pub bootstrap_members: BTreeSet<NodeState>,
/// Die Mitgliedschaftsgeneration, bei der dieser SAP instanziiert wurde
Pub-Mitgliedschaft_gen: Generation,
}
Wenn es ein DkgStart-Ereignis gibt, generieren die Ältesten Informationen in einer Struktur namens DkgSessionId (das Format wird in Rust als ‚struct‘ bezeichnet). Sie signieren diese Struktur mit ihrem BLS-Schlüsselanteil und tauschen sie mit den anderen Ältesten aus. Jede „DkgSessionId“ stellt Basisinformationen über den aktuellen Stand der Dinge bereit und ist für eine DKG-Runde eindeutig.
Das Präfix ist das aktuelle Abschnittspräfix. Bei einer Übergabe ändert sich daran nichts. Im Falle einer Teilung ist dies der Fall, und wir fügen unserem aktuellen Präfix eine Eins oder eine Null hinzu, je nachdem, ob wir uns auf der 0- oder 1-Seite der Teilung befinden.
Das Feld „Älteste“ enthält alle neuen Kandidaten für Älteste für diese DKG-Sitzung, Knoten mit einem Knotenalter, das gleich oder größer als das eines aktuellen Ältesten ist.
section_chain_length (umzubenennen) ist die Entfernung vom aktuellen Abschnittsschlüssel zurück zu Genesis. Wir können es uns als „Abschnittsgeneration“ vorstellen.
membership_gen zeigt auch die Mitgliedschaftsgeneration. Es unterscheidet sich von der Abschnittsgenerierung. Jeder Abschnitt hat viele Zugehörigkeitsgenerationen und die Kettenlänge ändert sich nicht.
bootstrap_members sind die aktuellen Ältesten in der Sektion.
Sobald Knoten DkgSessionIds von allen aktuellen Ältesten erhalten, können sie eine DKG-Sitzung starten.
Lass uns gehen!
Dkg-Schritte
„Meerjungfrau
Flussdiagramm LR;
A[DkgStart] --> B[Kurzlebiger Schlüssel]
Alle derzeitigen Ältesten und Ältestenkandidaten erhalten eine DkgStart-Nachricht, die an sie adressiert ist und in der sie als Älteste in der DkgSessionId-Struktur enthalten sind.
Jeder dieser Knoten generiert dann einen flüchtigen einmaligen BLS-Schlüssel, der nur für diese DKG-Runde verwendet wird. Dieser vergängliche Schlüssel ist mit seinem ed25519-Schlüssel signiert, der als Identität dient, sodass die anderen Knoten prüfen können, ob er gültig ist.
Dkg-Schritte
„Meerjungfrau
Flussdiagramm LR;
A[DkgStart] --> B[Kurzlebiger Schlüssel] --> C[Voting]
Als nächstes kommt die Abstimmungsphase, in der jeder Knoten seine eigenen Schlüssel für die Abstimmung generieren kann. Wir verwenden einen von Poanetwork Schlüsselgenerierung in hbbft, die sicherstellt, dass jeder Knoten nur seinen eigenen Schlüssel generieren kann und keine Informationen von anderen Knoten verwendet, um einen separaten Schlüssel für die DKG-Runde zu generieren.
Die Knoten stimmen darüber ab, welche der Kandidaten und Ältesten nun die Ältesten der Sektion sein sollen.
Dkg-Schritte
„Meerjungfrau
Flussdiagramm LR;
A[DkgStart] --> B[Ephemeral Key] --> C[Voting] --> D{Schlüsselgenerierung}
Sobald die Abstimmung beendet ist, generiert der Kandidat einen neuen Schlüssel, den er an die aktuellen Ältesten sendet, um zu beweisen, dass er berechtigt ist, ein Ältester zu werden (weil eine Supermehrheit von Knoten ihn mit dem neu geprägten Schlüssel signiert hat). DKG ist also eine Art Test für einen guten Kandidaten. Wenn sie DKG nicht beenden, sind sie nicht gut genug.
Parallelität
„Meerjungfrau
Flussdiagramm LR;
A[DkgStart1] --> B[Ephemeral Key] --> C[Voting] --> D{Key1 Generation}
„Meerjungfrau
Flussdiagramm LR;
A[DkgStart2] --> B[Ephemeral Key] --> C[Voting] --> D{Key2 Generation}
Es können mehrere DKG-Sitzungen gleichzeitig stattfinden. Jedes Mal, wenn es ein neues Mitglied in der Sektion gibt, könnten wir (wenn der neue Knoten älter als jeder der aktuellen Ältesten ist) eine neue DKG-Sitzung haben, wenn also während einer laufenden Sitzung ein neuer Knoten beitritt, kann eine andere DKG-Sitzung beginnen. Einige werden beendet, andere werden nur eine Zeitüberschreitung haben und fehlschlagen. Es ist ein Rennen, und wir wählen das erste aus, das ins Ziel kommt. Wenn sich später herausstellt, dass es einen älteren Knoten gibt, der kein Ältester ist, beginnt der Prozess erneut.
Durch Übergabe behoben
„Meerjungfrau
stateDiagram-v2
Dkg1 --> Übergabe
Übergabe --> Gewinner:Dkg1
Dkg2 --> Übergabe
Dkg3 --> Übergabe
Bei Gleichstand wollen wir nur einen Sieger, also einen neuen Ältesten. Die Übergabe ist ein Prozess, bei dem im Konsens entschieden wird, wer gewinnen soll.
Aktive AE
„Meerjungfrau
stateDiagram-v2
DkgStart --> EphemeralKey
EphemeralKey --> EphemeralKey: Beinhaltet DkgStart AE
EphemeralKey --> Abstimmung
Abstimmung --> Abstimmung: Enthält EphemeralKeys AE
Abstimmung --> Kündigung
In diesen oben erwähnten Phasen, dem Empfangen einer „DkgStart“-Nachricht, dem Erstellen eines vergänglichen Schlüssels und der Abstimmung, müssen wir Netzwerkprobleme und langsame Knoten ausgleichen. Zum Beispiel brauchen wir alle Schlüssel, um mit der Abstimmung zu beginnen, wenn nicht, bleiben wir hängen. Daher fügen wir AE in jede schlüsselbezogene Nachricht ein, um Informationen darüber bereitzustellen, dass ein Knoten möglicherweise fehlt. AE ist leichtgewichtig und eine effiziente Methode, um sicherzustellen, dass alle Knoten auf dem neuesten Stand sind.
Rost
enum SystemMsg {
DkgStart(DkgSessionId),
DkgEphemeralPubKey {
/// Die Kennung der DKG-Sitzung, für die diese Nachricht bestimmt ist.
session_id: DkgSessionId,
/// Section Authority für die DKG-Startmeldung
section_auth: AuthorityProof<SectionAuthProof>,
/// Der flüchtige bls-Schlüssel, der vom Kandidaten ausgewählt wurde
pub_key: BlsPublicKey,
/// Die ed25519-Signatur des Kandidaten
sig: Unterschrift,
},
DkgVotes {
/// Die Kennung der DKG-Sitzung, für die diese Nachricht bestimmt ist.
session_id: DkgSessionId,
/// Die kurzlebigen öffentlichen bls-Schlüssel, die für diese Dkg-Runde verwendet werden
pub_keys: BTreeMap<XorName, (BlsPublicKey, Signatur)>,
/// Die DKG-Nachricht.
Stimmen: Vec<DkgSignedVote>,
},
DkgAE(DkgSessionId),
...
}
Im Code sieht eine Systemnachricht, der Nachrichtentyp, der für Prozesse verwendet wird, die die Netzwerkstruktur ändern könnten, wie oben aus. Dies umfasst alle Prozesse, über die wir gesprochen haben.
Widerstandsfähigkeit
- Aktive AE
- Abstimmung AE
- Tratsch
- beim Warten auf Stimmen
- wenn veraltete Stimmen empfangen werden
Abschließend haben wir mehrere Mechanismen für Resilienz bei der Handhabung von Übergaben und Splits.
Aktive AE bedeutet, dass Knoten Informationen aus dem vorherigen Schritt gesendet werden, falls sie diese verpasst haben.
Wir haben auch Klatsch als Backup. Wenn Sie sich in einer DKG-Sitzung befinden, können Sie flüchtige Schlüssel oder Stimmen von jemandem empfangen. Wenn sie nicht auftauchen, schickst du dein aktuelles Wissen an die anderen in der Hoffnung, dass sie dich auf den neuesten Stand bringen. Auch wenn Sie veraltete AE von jemandem erhalten, können Sie diese aktualisieren.
Klatsch hat also zwei Zwecke. Um sicherzustellen, dass wir auf dem neuesten Stand sind, damit wir vorankommen können, und um andere auf den neuesten Stand zu bringen, damit wir zur Kündigung gelangen können.
Zusammen mit AE und dem Ermöglichen des Wettbewerbs zwischen DKG-Prozessen bietet dies einen viel robusteren Prozess für die Förderung neuer Ältester und den Umgang mit Splits. Während Splits haben wir zwei DKGs statt einem.
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!