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
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!