Safe Network Entwickler Update đŸ‡©đŸ‡Ș 19. November 2020

Dies ist eine maschinelle Übersetzung. Das Original in Englisch ist hier: Safe Network Dev Update - November 19, 2020

Zusammenfassung

Hier sind einige der wichtigsten Dinge, die seit dem letzten Entwickler-Update hervorgehoben werden sollten:

Safe Client, Nodes und qp2p

Projektplan fĂŒr sichere NetzwerkĂŒbertragungen
Safe Client-Projektplan
Projektplan fĂŒr sichere Netzwerkknoten

ZunĂ€chst einmal haben wir diese Woche in qp2p Verbindungspooling implementiert. Dies bedeutet, dass wenn ein Knoten eine Verbindung zu einem Peer herstellen möchte und die Verbindung zuvor geöffnet wurde (und noch offen ist), die vorhandene Verbindung wiederverwendet wird, anstatt eine neue herzustellen. Dies verbessert die Leistung, da das Herstellen einer Verbindung teuer ist (dies beinhaltet unter anderem einen TLS-Handshake). Dies verbessert auch die Ergonomie, da sich die Benutzer von qp2p nicht mehr um das Zwischenspeichern von Verbindungen kĂŒmmern mĂŒssen. Wir haben auch die Verbindungs-Deduplizierung implementiert. Dies bedeutet, dass mehrere gleichzeitige Verbindungsversuche mit demselben Peer zu derselben Verbindung aufgelöst werden, anstatt jeweils eine separate Verbindung zu öffnen. Dies verbessert erneut die Leistung.

Wir haben die Blockreplikation von Blob-Daten unter sn_node wieder aufgenommen. Ausgehend von einem 4-fachen Replikationsfaktor sind die Erwachsenen des Netzwerks in erster Linie fĂŒr deren Speicherung verantwortlich. Wir portieren die Ă€ltere Implementierung von vorasynchronen Tresoren auf die neue Codebasis und passen sie an die neuesten Änderungen beim Speichern, Abfragen usw. an. Wir haben diese Woche auch auf der ganzen Linie ein bisschen Wartung durchgefĂŒhrt, indem wir hinterhĂ€ltige „Unwrap“ gesucht haben s, erwarten und paniken` von unserem Produktionscode und unseren Tests, stabilisieren im Wesentlichen unsere Codebasis und erfassen alle Ausnahmen. Dies ist eine bewĂ€hrte Methode und etwas, das wir zu lange aufgeschoben haben. Achten Sie darauf, dass in den nĂ€chsten Tagen zusĂ€tzliche CI-ÜberprĂŒfungen in unseren Kisten hinzugefĂŒgt werden, um sicherzustellen, dass diese nicht in unseren Code zurĂŒckschleichen.

Wir haben ein wenig Zeit in die Erforschung und Überlegung investiert, wie sich die APIs letztendlich weiterentwickeln mĂŒssen, um Signaturanforderungen vom Client mit mehreren SchlĂŒsselpaaren anstatt nur einem zu unterstĂŒtzen. Beispielsweise möchte ein Client möglicherweise eine Datei speichern, die einem öffentlichen SchlĂŒssel gehört, wĂ€hrend die Zahlung fĂŒr einen solchen Vorgang unter Verwendung eines zweiten öffentlichen SchlĂŒssels erfolgt, dem das Geld gehört, und möglicherweise kann der Client ein drittes SchlĂŒsselpaar verwenden VerschlĂŒsselung des Dateiinhalts. Dies ist derzeit keine hohe PrioritĂ€t, sondern eher ein PoC, der uns hilft, die Herausforderungen zu identifizieren und zu erkennen, wie wir unsere Client-APIs letztendlich weiterentwickeln können.

CRDTs

Die Arbeit an der dynamischen Mitgliedschaft in DSB wird fortgesetzt. Diese Woche hat unser Berater einen Testfall geschrieben, der ein ParallelitĂ€tsproblem mit Datenoperationen zeigt, wĂ€hrend ein Mitglied die Gruppe verlĂ€sst. Eine korrekte Implementierung einer dynamischen Mitgliedschaft sollte den Test immer bestehen, wĂ€hrend unsere derzeitige naive Implementierung fehlschlĂ€gt. Daher mĂŒssen wir jetzt etwas Konkretes messen.

Zu diesem Zweck freuen wir uns ĂŒber eine kĂŒrzlich erschienene wissenschaftliche Arbeit der AT2-Autoren mit dem Titel Dynamic Byzantine Reliable Broadcast. Es enthĂ€lt ein Zitat: „die erste Spezifikation eines dynamischen byzantinischen zuverlĂ€ssigen Broadcast-Grundelements (dbrb), das einer asynchronen Implementierung zugĂ€nglich ist“. Mit anderen Worten, dieses Papier bietet eine formal bewĂ€hrte Lösung fĂŒr genau unser Problem.

Unser Berater prĂŒft derzeit dieses Dokument sowie eine andere mögliche Lösung mit einer sogenannten Generationsuhr, die möglicherweise nicht so viel erfordert Netzwerk-Kommunikation.

Routing

Projektplan

Wie im Update der letzten Woche erwĂ€hnt, wurde diese Woche die Arbeit genehmigt einem Knoten die Wiederverbindung mit demselben Namen ermöglichen und diese Woche zusammengefĂŒhrt. Dies bedeutet, dass jeder wieder verbundene Knoten sofort mit der HĂ€lfte seines Alters verschoben wird, solange das halbierte Alter grĂ¶ĂŸer als die „MIN_AGE“ (derzeit „4“) ist. Dies soll böswillige Neustarts verhindern.

Wir hatten wĂ€hrend interner Tests beobachtet, dass der Genesis-Knoten manchmal zu schnell herabgestuft wurde. Dies war auf eine kĂŒrzliche Änderung zurĂŒckzufĂŒhren, bei der wir jetzt Knoten mit einem Zufall erstellen Altersbereich wĂ€hrend der Startphase. Um dies zu beheben, haben wir beschlossen, den ersten Knoten mit einem höheren Alter zu starten, der derzeit auf 32 festgelegt ist. Dieser Knoten wurde nun zum Master zusammengefĂŒhrt. Dies stellt sicher, dass der Genesis-Knoten als Ältester ausreichend lange stabil bleibt, was viele Dinge fĂŒr das Testen und das Einrichten des Testnetzes erleichtert.

Die laufenden Arbeiten zur Verbesserung der Erkennung verlorener Peers kommen gut voran. Wir haben bereits die neue Verbindungspooling-Funktion in qp2p genutzt, mit der wir den Code vereinfachen konnten. Einige erste Integrationstests zeigen, dass das Refactoring gut funktioniert. Diese PR durchlĂ€uft derzeit einige abschließende ÜberprĂŒfungen und Tests und wird daher hoffentlich bald zusammengefĂŒhrt.

Um sicherzustellen, dass, wenn die Ressourcen eines Knotens fast aufgebraucht sind, neue Knoten einfließen, um die Arbeitslast zu teilen, werden wir den Knoten erlauben, das Routing anzuweisen, neue Knoten zu akzeptieren oder nicht. Diese EinschrĂ€nkung, wann das Netzwerk neue Knoten akzeptiert, hilft auch dabei, Sybil-Angriffe zu verhindern, indem potenziellen Angreifern nicht erlaubt wird, nach Belieben unbegrenzt viele Knoten hinzuzufĂŒgen.

DarĂŒber hinaus möchten wir einige Änderungen vornehmen, um uns ĂŒber den genauen Status des Routings wĂ€hrend des Netzwerkstarts und darĂŒber hinaus zu informieren. Wir haben zwei laufende PRs Anzeige fĂŒr das Starten und Auslösen des PromotedToAdult-Ereignisses und benachrichtigen, wenn der SchlĂŒssel wĂ€hrend des Umzugs geĂ€ndert wird. Diese laufenden Änderungen helfen uns sicherzustellen, dass sich das Routing wie beabsichtigt verhĂ€lt und bald abgeschlossen sein sollte, sobald die API-Designs zwischen Knoten und Routing vereinbart wurden.

NĂŒtzliche Links

Ihr könnt uns gerne Übersetzungen dieses Entwickler-Updates zusenden und wir werden sie hier auflisten:

Als Open-Source-Projekt sind wir immer auf der Suche nach Feedback, Kommentaren und BeitrĂ€gen der Gemeinschaft - seien Sie also nicht schĂŒchtern, machen Sie mit und lassen Sie uns gemeinsam das SAFE-Netzwerk aufbauen!

1 Like