Safe Network Entwickler Update ­čçę­čç¬ 2. Dezember 2021

Dies ist eine maschinelle ├ťbersetzung. Das Original in Englisch ist hier: Update 02 December, 2021

Wir stehen kurz davor, die neue integrierte CLI und API f├╝r Community-Tests einzuf├╝hren, aber es gibt immer noch einige Randf├Ąlle, die Probleme verursachen - und die Geschichte sagt uns, dass alles, was schief gehen kann, auch schief gehen wird. Wir arbeiten also daran, diese auszub├╝geln, bevor wir die CLI richtig integrieren.

Im letzten Update haben wir erw├Ąhnt, dass DKG (nicht verwandte) Probleme verursacht hat, wobei Knoten manchmal nicht zu ├ältesten bef├Ârdert werden und Aufteilungen gelegentlich nicht so stattfinden, wie sie sollten. Ein Teil der Schuld liegt darin, dass Nachrichten nicht ordnungsgem├Ą├č ankommen und w├Ąhrend der DKG-L├Ąufe nicht richtig verarbeitet werden. @lionel.faber erkl├Ąrt, wie wir das mit Anti-Entropy beheben.

Allgemeiner Fortschritt

Die meisten CLI-Befehle funktionieren jetzt gut, aber einige sind noch nicht konsistent. Wir m├╝ssen auch die CLI zum neuen automatisierten Freigabeprozess hinzuf├╝gen.

@Anselme hat sich weiter mit dem NRS befasst, einschlie├člich der Implementierung von Probelaufunterst├╝tzung f├╝r die Batchverarbeitung. Au├čerdem hat er @danda und David Rusu bei ihrer Arbeit an Zahlungsnachweisen und privaten Transaktionen unterst├╝tzt. Wenn Sie diese Aktualisierungen verfolgt haben, wissen Sie, dass sie die besten M├Âglichkeiten zur Implementierung von DBCs untersucht haben, damit Transaktionen schnell und nicht nachverfolgbar sind, w├Ąhrend sie gleichzeitig ├╝berpr├╝fbar sind und mehrere DBC-Ausgaben unterst├╝tzen. Die Jungs haben mehrere Wege beschritten, und der vielversprechendste Ansatz scheint bisher eine Version von Ring Confidential Transactions (RingCT) zu sein, wie sie von Monero verwendet wird und die als Zahlungsnachweis verwendet werden kann. David Rusu hat dem Team dazu einen Vortrag gehalten, den wir hier bald wiedergeben werden.

Beheben von DKG-Problemen mit Anti-Entropie

Die verteilte Schl├╝sselgenerierung (DKG) ist die Art und Weise, wie wir den Vereinbarungsprozess zwischen Knoten verwalten. Damit eine Aktion ausgef├╝hrt werden kann, ist ein Schl├╝ssel erforderlich. Dieser Schl├╝ssel wird in Schl├╝sselanteile aufgeteilt, wobei jeder Abstimmungsknoten einen einzigen eindeutigen Anteil hat. Erst wenn eine bestimmte Anzahl von Anteilen (zB 5 von 7) empfangen und aggregiert wurden, kann der Signaturschl├╝ssel generiert werden.

In den letzten Wochen haben wir uns mit einigen Problemen befasst, die w├Ąhrend der DKG bei der Bef├Ârderung der ├Ąltesten erwachsenen Knoten zu ├ältesten auftreten. Wenn eine Sektion entscheidet, dass ein Erwachsener bef├Ârdert werden muss, wird eine DKG-Runde durchgef├╝hrt und die ├Ąlteren Kandidaten generieren einen Sektionsschl├╝ssel und einen Schl├╝sselanteil.

Der DKG-Lauf ist ein schrittweiser Prozess mit sechs unterschiedlichen Phasen: Initialisierung, Beitrag, Beschwerde, Begr├╝ndung, Verpflichtung und Abschluss. Schl├╝ssel m├╝ssen generiert, ausgetauscht, aggregiert und vereinbart werden. Mit Nachrichten, die in jeder Phase hin und her gehen. W├Ąhrend f├╝r DKG im Allgemeinen keine Gesamtreihenfolge von Nachrichten erforderlich ist, kann ein Knoten nur Nachrichten verarbeiten, die f├╝r seine aktuelle DKG-Phase relevant sind.

Die asynchrone Natur des Netzwerks bedeutet jedoch, dass Nachrichten in beliebiger Reihenfolge ankommen k├Ânnen, und in einer verteilten Umgebung ist es normal, dass einige Nachrichten aufgrund von Netzwerkst├Ârungen viel sp├Ąter oder sogar gar nicht kommen.

Diese nat├╝rlichen Ereignisse sollten die DKG-F├Ąhigkeit von Knoten nicht beeintr├Ąchtigen, und ├Ąhnlich wie bei anderen Netzwerkvorg├Ąngen ist die L├Âsung f├╝r ungeordnete DKG-Nachrichten (falls Sie es noch nicht erraten haben) Anti-Entropie. AE versorgt die Akteure aktiv mit den ben├Âtigten Informationen und verhindert, dass Aktionen ausgef├╝hrt werden, bis die Teilnehmer bereit sind.

Es gibt zwei verschiedene Situationen, in denen AE f├╝r DKG-Nachrichten erforderlich ist.

DKG-Nachrichten kommen phasenverschoben an

Wenn ein Knoten eine DKG-Nachricht empf├Ąngt, die Teil einer noch nicht erreichten Phase ist, muss er diese Nachricht behalten und weiter anwenden, bis er schlie├člich (und hoffentlich) einen Punkt erreicht hat, an dem die Nachricht angewendet werden kann.

Anstatt dies dem Zufall zu ├╝berlassen, k├Ânnen wir den Absender der DKG-Nachricht bitten, uns die Liste der bereits verarbeiteten Nachrichten zuzusenden. Wir k├Ânnen diese Nachrichten mit der Signatur des Absenders ├╝berpr├╝fen und sie dann lokal anwenden, um uns in die gleiche Phase zu bringen, und dann die Nachricht anwenden, an der wir festgehalten haben. Dadurch k├Ânnen Knoten, die im DKG-Prozess zur├╝ckgefallen sind, zum Rest des Netzwerks aufschlie├čen.

Betrachten Sie Folgendes, um zu zeigen, warum dies effizienter ist.

Nehmen wir an, die erforderliche Reihenfolge der Nachrichten ist

1.1, 1.2, 1.3, 2.1, 2.2, 2.3...

wo jede Nachricht ist

<phase>.<message_no>

Zum Beispiel Initialisation.message1, Initialisation.message2, Contribution.message1 usw.

Angenommen, wir haben zwei Knoten A und B. Knoten A befindet sich in Phase 2 und Knoten B befindet sich in Phase 1.

Es gibt zwei M├Âglichkeiten:

Versuch und Irrtum

# Schritt 1
B(Phase 1) empf├Ąngt 2.1 -> Nicht bereit -> Speichern 2.1

# Schritt 2
B(Phase 1) empf├Ąngt 1,2 -> wende 1,2 . an
B(Phase 1) -> gilt 2.1 aus Speicher -> Nicht bereit

# Schritt 3
B(Phase 1) erh├Ąlt 1,3 -> gilt 1,3
B(Phase 2) -> wendet 2.1 vom Speicher an -> OK -> 2.1 aus dem Speicher entfernen

Je l├Ąnger 1.2 und 1.3 brauchen, um anzukommen, desto mehr Trial-and-Error tritt auf.

AE

# Schritt 1
B(Phase 1) empf├Ąngt 2.1 -> Nicht bereit ->Fragt A nach allen Nachrichten

B(Phase 1) empf├Ąngt 1.1, 1.2, 1.3, 2.1 -> Wendet sie alle an -> OK
B(Phase 2)

Daher ist AE viel effizienter und reduziert die Anzahl unerwarteter Nachrichtenfl├╝sse.

DKG-Nachrichten, die f├╝r eine Sitzung eintreffen, die noch nicht begonnen hat

Bevor eine DKG-Sitzung beginnt, m├╝ssen die teilnehmenden Knoten die Teilnehmerliste zusammen mit der Abschnittskette unterschreiben, um sicherzustellen, dass sie alle an derselben DKG-Sitzung teilnehmen. Der neue Schl├╝ssel wird der Abschnittskette hinzugef├╝gt, sodass sich alle teilnehmenden Knoten auf seine L├Ąnge einigen sollten.

Falls ein Knoten nicht gen├╝gend Signaturen zum Starten der DKG-Sitzung erhalten hat, aber die DKG-Nachrichten eingegangen sind (z. B. wenn w├Ąhrend dieser Anfangsphase Verbindungsprobleme aufgetreten sind), kann der Knoten die aggregierte Signatur der DkgStart-Nachricht, die mit dem Abschnittsschl├╝ssel verifiziert werden kann, wonach die DKG-Sitzung initialisiert und die Nachricht(en) wie oben beschrieben angewendet werden kann.


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!