Safe Network Entwickler Update đŸ‡©đŸ‡Ș 7. Januar 2021

Dies ist eine maschinelle Übersetzung. Das Original in Englisch ist hier: Safe Network Dev Update - January 7, 2021

Zusammenfassung

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

  • Frohes neues Jahr! :fireworks:
  • Wir freuen uns, Ihnen mitteilen zu können, dass die Arbeiten zur dynamischen Mitgliedschaft abgeschlossen wurden, und haben heute mehrere BRB-Kisten (Byzantine Reliable Broadcast) auf GitHub :tada: veröffentlicht. Alle sind von der zentralen brb-Kiste aus verknĂŒpft.
  • Wir haben auch in den Ferien hart daran gearbeitet, unsere Fehler- und Kommunikationsebene zu verbessern, einschließlich der Erstellung einer neuen sn_messaging Kiste.
  • Wir bereiten derzeit einige kleinere Korrekturen fĂŒr eine neue Patch-Version der CLI vor.
  • Wir stehen auch kurz davor, die CLI und „authd“ mit musl zu erstellen, was KompatibilitĂ€t mit einer grĂ¶ĂŸeren Anzahl von Plattformen bedeutet.
  • Wir haben ein neues Stresstest-Tool fĂŒr das Routing mit dem PR, das derzeit geprĂŒft wird. Dieses neue Tool wurde entwickelt, um die Grenzen des Routings im Hinblick auf den Umgang mit MitgliedschaftsĂ€nderungen (Abwanderung) zu ermitteln. Es hat uns bereits auf einige Probleme aufmerksam gemacht.

Testnet Update

Vielen Dank an alle, die sich die Zeit genommen haben, den vor Weihnachten veröffentlichten Code testnet auszuprobieren. Nachdem das gesamte MaidSafe-Team wieder an den Schreibtischen sitzt, arbeiten wir weiterhin an einigen Problemen, die wir vor der Veröffentlichung festgestellt haben, und an anderen, die Sie fĂŒr uns hervorgehoben haben. Sobald wir zufrieden sind, dass diese Probleme behoben wurden, werden wir eine weitere Iteration ankĂŒndigen, mit der Absicht, ein öffentliches Testnetz fĂŒr alle zu hosten, die eine Verbindung herstellen können.

Safe Client, Nodes und qp2p

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

Wir haben daran gearbeitet, unsere Fehlergeschichte in unseren Bibliotheken zu verbessern, und sind auf die Verwendung von thiserror in node / data_types / client / transfers umgestiegen um eine bessere Fehlerkette und eine grĂ¶ĂŸere Kapselung der FunktionalitĂ€t bereitzustellen. Zuvor verwendeten wir viele gemischte Fehler und zogen viel von sn_data_types in andere Bibliotheken. Jetzt haben wir spezifische Fehler in jeder Bibliothek fĂŒr diese Bibliothek und verbreiten nur Fehler aus niedrigeren Bibliotheken als eine andere Version der Fehler der aktuellen Bibliothek.

DarĂŒber hinaus haben wir sn_messaging aus sn_data_types in eine eigene Kiste extrahiert, um unsere Kommunikationsebene sowie die von uns verursachten Fehler zu trennen Ich werde an / von anderen Knoten und Clients senden. Dies ist ein kleiner Schritt zur klareren Definition einer Netzwerk-API fĂŒr Nachrichten und Fehler und bietet eine sauberere Trennung von Fehlern von internen Bibliotheken zum Client.

Im Rahmen dieser BemĂŒhungen untersuchen wir verschiedene Serialisierungstypen mit dem Endziel, einen programmiersprachenunabhĂ€ngigen zu haben. Wir konzentrieren uns derzeit auf eine einfache JSON-Serialisierung (im Gegensatz zum derzeit verwendeten Bincode), spielen aber auch mit Msgpack herum.

Die Auswirkung all dessen war ein sauberer Code, und in allen beteiligten Bibliotheken fließen viel klarere Fehler, was großartig ist.

Gleichzeitig haben wir Client- „Herausforderungen“ aus dem Knoten / Client-Bootstrap-Flow entfernt. Diese wurden zuvor verwendet, um zu ĂŒberprĂŒfen, ob ein Client SchlĂŒssel hielt, um Angriffe auf die Nachrichtenwiedergabe zu verhindern. Da idempotency von AT2- und CRDT-Datentypen stammt, wird dies dort behandelt. Dies vereinfacht sowohl den Client als auch den Knoten und verdeutlicht den Netzwerkbetrieb nur als signierte Nachrichten.

Zuvor haben wir alle SecretKey-Exposure-APIs aus „sn_routing“ entfernt und sie nur in ihrer Kiste enthalten, um Key-Selling-Angriffe auf das Netzwerk zu verhindern. Wir stellten jedoch fest, dass es durch diese Entfernung mehrere Komplikationen im AbhĂ€ngigkeitsbaum gab, und stimmten daher zu, diese APIs zurĂŒckzubringen, damit wir in den Ferien schnell mit dem Testnetz fortfahren können. Wir haben uns entschlossen, dieses Problem sofort zu lösen, und haben begonnen, die Kisten „sn_transfers“ und „sn_node“ zu ĂŒberarbeiten, in denen wir diese SecretKeys außerhalb von „sn_routing“ aufbewahren und verwenden.

Die von sn_node wĂ€hrend des Nachrichtenaustauschs zwischen KeySection und DataSection ausgefĂŒhrte Signaturaggregationsarbeit wird möglicherweise mit der Konsensakkumulationsarbeit des Routings dupliziert, da beide tatsĂ€chlich von Ă€lteren Knoten ausgefĂŒhrt werden. Wir untersuchen und fĂŒhren einige Refactoring-Arbeiten durch, um diesen Teil aus der „sn_node“ -Kiste zu entfernen und den Konsensnachrichten von „sn_routing“ zu vertrauen.

Und eine letzte kleine Arbeit ist im Gange, um das Stream-Management von den Knoten zu entfernen. Dies wurde eingegebenOrt, um die Kommunikation mit Clients aufrechtzuerhalten, aber mit den jĂŒngsten „qp2p“ -Änderungen können wir uns darauf verlassen, dass dort Verbindungspools erstellt werden, um dies fĂŒr uns zu erledigen, und so die Client-Behandlung des Knotens erheblich komplexer gestalten. Wir sind auch dabei, die „qp2p“ -Beispiele in separate Teile umzugestalten, um die echo_service- und Messaging-Systeme klar und deutlich zu demonstrieren. Mit diesen Beispielen fĂŒhren wir TestlĂ€ufe mit manueller Portweiterleitung durch, um potenziell Router zu unterstĂŒtzen, die in weiteren Testnetzen nicht mit IGD kompatibel sind.

API und CLI

Wir haben uns auf Änderungen und Verbesserungen auf der Netzwerkseite konzentriert, aber wir haben immer noch daran gearbeitet, einige kleinere Fehler zu beheben, die von der Community bei der Verwendung des testnet und bereiten derzeit einige kleinere Korrekturen fĂŒr eine neue Patch-Version der CLI vor.

Außerdem versuchen wir, unsere nĂ€chste Version von CLI und authd mit musl zu erstellen, damit wir diese Anwendungen bekanntlich ausfĂŒhren können auf vielen weiteren Plattformen mit denselben freigegebenen Artefakten. Wir konnten sie bereits manuell erstellen (vielen Dank an @mav und @tfa fĂŒr ihre BeitrĂ€ge und BeitrĂ€ge dazu), daher versuchen wir nun, dies in den kommenden Tagen in unser CI aufzunehmen.

BRB - Byzantinische zuverlÀssige Sendung

Wir freuen uns, Ihnen mitteilen zu können, dass die Arbeiten zur dynamischen Mitgliedschaft abgeschlossen wurden, und haben heute mehrere BRB-Kisten (Byzantine Reliable Broadcast) auf GitHub: tada: veröffentlicht. Alle sind von der zentralen brb-Kiste aus verlinkt.

Das BRB-System besteht aus:
1. Das Kern-BRB-Broadcast-Protokoll fĂŒr Mitglieder eines Quorums zum Replizieren von Daten auf BFT-Weise.
2. Das dynamische Mitgliedschaftsprotokoll, mit dem Knoten dynamisch beitreten und ein aktives Quorum verlassen können.
3. Datentyp-Wrapper, die kompatible Datentypen (z. B. CRDTs) fĂŒr die Übertragung ĂŒber BRB kapseln.
4. Umfassende Tests zur ÜberprĂŒfung der Richtigkeit.
5. brb_node_qp2p: Eine beispielhafte CLI-App / ein CLI-Knoten zum manuellen Aufrufen der BRB-FunktionalitÀt.

FĂŒr diejenigen, die sich mit den Details befassen möchten, stehen Folien zur VerfĂŒgung und bieten weitere Einblicke in das System und die Protokolle.

Routing

Projektplan

Wie wir alle wissen, ist die Verlagerung gut fĂŒr das Netzwerk und erleichtert unter anderem die Alterung der Knoten. Wir haben jedoch festgestellt, dass wir in einigen Situationen zu viel umgezogen sind. Zum Beispiel haben wir umgezogen, selbst wenn wir aufgrund der Abwanderung nicht genĂŒgend Älteste hatten, und auch Knoten umgezogen, als sie neu beigetreten waren. Um dies zu beheben, haben wir einige Kriterien festgelegt, um ĂŒbermĂ€ĂŸige Verlagerung zu vermeiden, um das Netzwerk in bestimmten Szenarien stabil zu halten.

Eine API-Änderung wurde auch an Informationen zum Abschnittsabschnitt fĂŒr den angegebenen Zielnamen zurĂŒckgeben vorgenommen. Dies ist hauptsĂ€chlich fĂŒr die Verwendung von „sn_node“ fĂŒr anstehende Refactoring-Arbeiten vorgesehen.

Wir haben einen Stresstest fĂŒr das Routing zusammengestellt (PR wird ĂŒberprĂŒft). Es ist ein kleines Tool, mit dem Sie die Grenzen des Routings im Hinblick auf den Umgang mit Änderungen der Mitgliedschaft (Abwanderung) ermitteln können. Es generiert eine zufĂ€llige Abwanderung nach einem konfigurierbaren Zeitplan. Anschließend werden regelmĂ€ĂŸig verschiedene nĂŒtzliche Informationen zum Netzwerk ausgegeben und der Netzwerkzustand gemessen. Dieses Tool wird fĂŒr die bevorstehende Arbeit zur Integration der neuen dynamischen Mitgliedschaftslösung sehr nĂŒtzlich sein. Bei der AusfĂŒhrung auf der aktuellen Routing-Version wurden bereits einige Probleme im Zusammenhang mit UmzĂŒgen und Teilungen festgestellt, die wir in KĂŒrze untersuchen werden. Dies ist eigentlich gut, da der erste Schritt zur Behebung eines Problems darin besteht, das Problem zu kennen: smile: Hier ist ein kleiner Screenshot der Ausgabe des Tools:

NĂŒtzliche Links


FĂŒhlen Sie sich frei, unten mit Links zu Übersetzungen dieses Entwickler-Updates 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!