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!