Safe Network Entwickler Update đŸ‡©đŸ‡Ș 4. Februar 2021

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

Zusammenfassung

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

  • Die heutige erwartete Testnet-Version musste auf Eis gelegt werden, da wir nicht rechtzeitig Belohnungen erhalten konnten, und das Deaktivieren der bisherigen Version hat es immer noch nicht gekĂŒrzt.
  • Die Möglichkeit, in den letzten Tagen Netzwerk-Splits mit den neuesten Entwicklungen zu sehen, hat es uns ermöglicht, einige bisher unbekannte Probleme mit mehreren Abschnitten zu finden und zu beseitigen.
  • Die Vereinfachung der qp2p-Kisten-API zur internen Verwaltung der Verbindungen und Streams und zur Entlastung des API-Verbrauchers wird derzeit einer Peer-Review unterzogen.
  • Ein BRB PR zur Behebung eines zufĂ€lligen Paketverlusts, der die BRB-Operationen störte, wurde ausgelöst, getestet und wird voraussichtlich in KĂŒrze zusammengefĂŒhrt.
  • Besonderer Dank geht an die Community-Mitglieder @bzee, @mav und @scorch fĂŒr ihre BemĂŒhungen in der letzten Woche, bei denen mehrere Community-PRs zusammengefĂŒhrt wurden.

Testnet-Status - in der Warteschleife

Unser Ziel zu Beginn der Woche war es, Belohnungen in ein öffentliches Testnetz aufzunehmen und es heute fĂŒr die Community zu öffnen. Es waren jedoch noch einige Änderungen erforderlich, um es zum Laufen zu bringen, und wir konnten dies fĂŒr heute nicht beenden.

Aus diesem Grund haben wir den Belohnungsfluss gestrippt, um zu sehen, ob wir ein ausreichend stabiles Netzwerk erhalten können, und dabei einige Fortschritte erzielt, sind aber auf dem Weg auf Unebenheiten gestoßen, die uns verlangsamt haben.

Unser aktueller Status ist, dass wir jetzt eine neueste Version eines Testnetzes intern haben, aber keine Echtzeit hatten, um es zu testen. Wir gehen davon aus, dass es wahrscheinlich weitere kleinere Probleme geben wird. Wir möchten daher einige Zeit, um dies intern zu testen, bevor wir es mit Zuversicht veröffentlichen.

Wir mĂŒssen noch vollstĂ€ndig diskutieren und entscheiden, ob wir ein Testnetz mit ausgeschlossenen Belohnungen veröffentlichen oder ob die Probleme, auf die wir stoßen, dazu fĂŒhren, dass wir besser mit der vollstĂ€ndigen Implementierung von Belohnungen fortfahren, was wir voraussichtlich noch einige Tage dauern werden (plus Testen). Die StabilitĂ€t des Testnetzes, das wir jetzt haben, mit deaktivierten Belohnungen, sollte uns bei der Entscheidung helfen, aber so oder so, wir planen nicht, an einem Freitag ein Testnetz einzurichten, wĂŒrden wir es vorziehen, bis nĂ€chste Woche zu warten, damit wir es voll unterstĂŒtzen können es.

Die ĂŒberwiegende Mehrheit unserer Zeit in dieser Woche hat sich auf das Testnetz konzentriert, aber hier ist eine Zusammenfassung einiger allgemeiner Arbeiten, die wir durchgefĂŒhrt haben 


Safe Client, Nodes und qp2p

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

ZunĂ€chst einmal in dieser Woche wurde eine PR von @bzee, die die programmatische Konfiguration von Knoten ermöglicht, heute zum Master zusammengefĂŒhrt. Gute Arbeit! :raise_hands:

Wir haben in „sn_data_types“ ein neues „Signing“ -Eigenschaft erstellt, um das Vorzeichen und die ÜberprĂŒfung fĂŒr unsere verschiedenen Flows in Knoten / Übertragungen zu abstrahieren, und haben einige Flows getestet und behoben, die sich auf die Integration der neuen Infrastrukturabfragen des Routings konzentrieren. Dies hat die Bootstrapping-Operationen in das Routing selbst verschoben, im Gegensatz zu innerhalb von Knoten. Bisher waren wir darauf beschrĂ€nkt, nur Älteste (und Älteste unseres eigenen Abschnitts) nach Netzwerk-Bootstrap-Informationen zu befragen. Wenn Sie dies auf „sn_routing“ verschieben, können wir jeden Knoten abfragen und die richtigen Kontaktinformationen zurĂŒckerhalten. Dies ermöglicht Clients im Wesentlichen, gegen ein mehrteiliges Netzwerk zu arbeiten.

DarĂŒber hinaus haben wir verschiedene Probleme mit Abschnittsaufteilungen behoben, nachdem wir dies in Aktion sehen konnten (wenn auch aufgrund der oben genannten Probleme eingeschrĂ€nkt), und die Node-Logger-Web-App von @ mav hat sich als großartiges kleines Tool erwiesen um schnell knotenĂŒbergreifende FlĂŒsse zu sehen und die Protokollausgabe unseres mehrteiligen Netzwerks auf etwas zu beschrĂ€nken, das fĂŒr den Menschen etwas lesbarer ist.

Wir arbeiten auch an dem Datenaufholfluss, der fĂŒr neu beförderte Älteste in einem Abschnitt erforderlich ist, der sich mit allen Daten aktualisieren mĂŒsste, die der Rest der Ältesten verwaltet. Da diese Daten relativ groß wĂ€ren, möchten wir die Daten idealerweise streamen, damit der Knoten bei dieser Aufgabe nicht blockiert wird. Daher basteln wir auch ein wenig an „qp2p“, um das direkte Streaming von Daten zu ermöglichen auf Anfrage zu Knoten.

In der letzten Woche haben wir einige ErgĂ€nzungen an der „qp2p“ -Kiste vorgenommen, um die Verbindungen und Streams intern zu verwalten und den API-Konsumenten etwas zu entlasten. Diese Arbeit ist abgeschlossen und wird derzeit in dieser PR ĂŒberprĂŒft. Die neue API wurde ebenfalls in das Routing integriert mit allen bestandenen Tests. Wir haben uns zurĂŒckgehalten, damit eine öffentliche Testnetz-Iteration veröffentlicht wird, bevor diese zusammengefĂŒhrt werden, aber mit der Verzögerung können wir uns entscheiden, bef zusammenzufĂŒhrenoder. Tests haben gezeigt, dass diese Änderung die Dinge erheblich vereinfacht hat und das Debuggen weiterer p2p-Netzwerkprobleme viel einfacher wird.

API und CLI

In der vergangenen Woche wurden mehrere weitere Community-PRs eingereicht, die zusammengefĂŒhrt wurden und bereits Teil einer neuen Version von CLI sind, die gerade heute veröffentlicht wurde (v0.18.0).

Dank dieser von @mav eingereichten PR schließt die NRS-Validierung jetzt einen grĂ¶ĂŸeren Satz von Zeichen aus, die niemals einen vernĂŒnftigen Zweck hĂ€tten URL. Mit dieser anderen PR wird jetzt eine Begrenzung der gesamten NRS-URL-LĂ€nge von 255 Byte erzwungen, wobei jeder Untername nicht lĂ€nger als 63 Byte sein darf. .

Die CLI-Befehle „safe auth“ geben dem Argument „–config“ jetzt Vorrang vor der Verwendung von Umgebungsvariablen. Dies ist jetzt auch in der neuen Version dank PR # 700, ebenfalls von @mav.

Auf der qjsonrpc-Seite implementiert PR # 698, eingereicht von @Scorch eine grundlegende Client / Server-Beispielanwendung unter Verwendung der qjsonrpc-API. Ein qjsonrpc-Client sendet eine Ping-Nachricht an einen qjsonrpc-Server, und der Server antwortet mit einer BestĂ€tigungsnachricht. Diese Beispielanwendung zeigt einfach und ĂŒbersichtlich, wie mit qjsonrpc jede Anwendung mit JSON-RPC ĂŒber QUIC erstellt werden kann. @Scorch hat viel mehr AktivitĂ€ten und Erkundungen mit mehr Ideen rund um qjsonrpc durchgefĂŒhrt. Wenn Sie an weiteren Details interessiert sind und / oder an diesen BemĂŒhungen teilnehmen möchten, schauen Sie sich seinen eigenen Entwickler-Thread an, in dem er alles geteilt hat it. :klatschen:

BRB - Byzantinische zuverlÀssige Sendung

Wir haben in brb_node_qp2p eine PR ausgelöst, um einen zufĂ€lligen Paketverlust zu beheben, der BRB störte Operationen. Dies macht den Knoten stabil fĂŒr den Fall, dass Mitglieder der technischen Community in einer CLI-Umgebung „praktisch“ mit BRB interagieren möchten. Grundlegende Gebrauchsanweisungen hierfĂŒr sind hier (Beachten Sie, dass Sie den Code zumindest vorerst selbst erstellen mĂŒssen).

Die Entwurfsdiskussionen zur Integration von BRB in die BLS Distributed Key Generation (DKG) wurden mit mehreren Optionen fortgesetzt. Die Übereinstimmung scheint sich um eine der Optionen zu vereinen. Details zu diesen PlĂ€nen sollten in zukĂŒnftigen Aktualisierungen zu Beginn der Arbeiten bekannt gegeben werden.

Routing

Projektplan

Wir haben einen ersten Schritt unternommen, um alle Nachrichtendefinitionen aus „sn_routing“ in die „sn_messaging“ -Kiste zu verschieben, in der sich nicht nur die Nachrichtendefinitionen befinden, sondern auch jede Logik, die sich auf deren Serialisierung bezieht. Die erste Iteration davon, zusammen mit einem einheitlichen Nachrichtentyp fĂŒr Clients und Knoten, die eine Verbindung zu einem Abschnitt herstellen, ist jetzt in den neuesten Versionen von „sn_routing“ und „sn_client“ vorhanden. Unser nĂ€chster Schritt in dieser Hinsicht besteht darin, alle Definitionen der Nachrichtentypen endgĂŒltig in die Kiste „sn_messaging“ zu verschieben, damit wir die eigentliche „sn_routing“ -Logik von der API des Netzwerks entkoppeln können.

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!