Dies ist eine maschinelle Übersetzung. Das Original in Englisch ist hier: Safe Network Dev Update - February 18, 2021
Zusammenfassung
Hier sind einige der wichtigsten Dinge, die seit dem letzten Entwickler-Update hervorgehoben werden sollten :
- Es wurde ein neuer Satz von Infrastrukturnachrichten hinzugefügt, mit denen „sn_routing“ Fehler während der Teilung und Abwanderung von Abschnitten besser behandeln und zurückgeben kann.
- Die Arbeit zur Behandlung ungültiger SignatureShares durch schlechte Akteure bei Übertragungen hat begonnen, und Strafen für diese schlechten Schauspieler werden jetzt ausgearbeitet und vereinbart.
- Die Messaging-Flow-Arbeit steht kurz vor dem Abschluss, was erheblich weniger Code und Komplexität für die Analyse eingehender Nachrichten in
sn_nodebedeutet und den Weg für die Integration von Belohnungen frei macht. - Neue Versionen der CLI (v0.19.0) und
authd(v0.1.1) wurden veröffentlicht, wodurch sie mit dem neuestensn_node(v0.26.16) kompatibel sind und einige andere Verbesserungen enthalten. - Die allererste Beispiel-App ist jetzt in der Kiste „sn_api“ verfügbar zeigt, wie eine Datei hochgeladen wird das Netzwerk und rufen Sie es dann mit seiner XOR-URL ab.
- Wir haben Schritte zur Integration von „sn_fs“ und „BRB“ unternommen, um einen P2P-Prototyp eines byzantinisch fehlertoleranten verteilten Dateisystems zu erstellen.
- Änderungen an der Abschnittskette
sn_routingzum Auflösen von Gabeln sind derzeit größtenteils vorhanden. Unsere Tests haben gezeigt, dass sich die Stabilität des Netzwerks erheblich verbessert, insbesondere bei Teilungen. -
Noch fantastischere Community-Beiträge zur Codebasis
Testnet-Status - in der Warteschleife
Wie bereits letzte Woche besprochen, haben wir beschlossen, unsere vollen Anstrengungen zu ändern, um Belohnungen in das nächste Testnetz aufzunehmen. Die Belohnungen selbst wurden durch verwandte Arbeiten blockiert, um die Nachrichtenflüsse anzupassen, nachdem wir den Wechsel vorgenommen haben, nur die Nachrichtenakkumulation in „sn_routing“ durchzuführen. Wir glauben, dass wir uns jetzt in der Endphase der Nachrichtenflussarbeit befinden. Wir glauben, dass einige letzte Probleme behoben werden (weitere Details siehe unten). Sobald dies erledigt ist, wird der Weg für die vollständige Integration der Belohnungen frei.
Wie bei allen bahnbrechenden Fortschritten erwarten wir, dass während der Integrations- und Testphase Probleme auftreten werden. Daher möchten wir keinen Zeitrahmen festlegen und das Team zusätzlich unter Druck setzen. Wie immer werden wir Sie über die genauen Fortschritte bei diesen wöchentlichen Updates auf dem Laufenden halten.
Vielen Dank für Ihre Geduld!
Safe Client, Nodes und qp2p
Projektplan für sichere Netzwerkübertragungen
Safe Client-Projektplan
Projektplan für sichere Netzwerkknoten
Lazy Messaging
Um Probleme beim Aufteilen von Abschnitten und während der Abwanderung besser zu behandeln, haben wir einen neuen Satz von Infrastrukturnachrichten hinzugefügt, mit denen „sn_routing“ Fehler wie „DKGINprocess“ zurückgeben kann, wenn wir versuchen, Älteste in solchen Zeiten zu benachrichtigen. Zu diesem Zweck stellen Clients / Knoten, soweit sie wissen, den aktuellen PublicKey für einen Abschnitt bereit, und wir können Maßnahmen ergreifen, wenn dies beispielsweise veraltet ist. Diese Änderungen wurden in „sn_messaging“, „sn_client“ und „sn_routing“ hinzugefügt, und wir betrachten einige kleine Refaktoren, um die Dinge mit Knoten zu vereinfachen.
Vor diesem Hintergrund haben wir die Client-Behandlung solcher Infrastrukturänderungen weiter gefestigt, sodass Clients durch eine Änderung in der Pipeline beliebig oft neu booten können. Daneben beseitigen wir auch Fehler, die mit dem in den letzten Wochen durchgeführten Refactor für die Nachrichtenakkumulation auftreten.
Schlechte Schauspieler bestrafen
Der Umgang mit ungültigen SignatureShares durch schlechte Akteure bei Übertragungen ist ebenfalls in Arbeit. Bis jetzt haben wir eine Übertragung genehmigt, wenn gültige „Schwellwert + 1“ -Freigaben erfolgreich aggregiert wurden, wobei fehlerhafte Freigaben ignoriert wurden, die für diese Aggregation nicht erforderlich sind. Wir werden jetzt Bestrafungsmechanismen im Netzwerk einführen, um Knoten nach der Überprüfung entsprechend zu bestrafen. Wir beginnen unseren Refactor mit „sn_transfers“, da dort Akkumulationen für Zahlungsüberweisungen stattfinden und wir uns dann durch die Ebenen nach oben arbeiten.
Nachrichtenfluss
Wenn wir nur in „sn_routing“ zur Akkumulation übergehen, müssen wir eindeutige Informationen in Nachrichten entfernen, damit die Ältesten dieselbe Nachricht signieren.
Damit mussten das Quell- und das Zielmuster geändert werden, und dabei haben wir es einfacher gemacht, indem wir die Messaging-Schnittstelle zwischen „sn_node“ und „sn_routing“ verkleinert und dieselben Grundelemente über der Grenze verwendet haben.
Da das Client-Bootstrapping jetzt in der Ebene „sn_routing“ stattfindet, mussten diese Standortprimitive um eine Client-Variante erweitert werden. Eine Registrierung verbundener Clients wurde in „sn_routing“ zusammen mit der Bereitstellung eines öffentlichen Schlüssels und einer Signatur über die Socket-Adresse beim Client-Bootstrapping implementiert. Es gibt jetzt deutlich weniger Code und Komplexität für die Analyse eingehender NachrichtenNachrichten in sn_node. Bisher wurden insgesamt ca. 1000 Zeilen entfernt.
API und CLI
Diese Woche wurden neue Versionen der CLI (v0.19.0) und authd (v0.1.1) veröffentlicht, die alle seit der vorherigen Version implementierten Korrekturen, Verbesserungen und neuen Funktionen enthalten. Wie üblich können sie mit „$ safe update“ bzw. „$ safe auth update“ aktualisiert werden. Diese Anwendungen sind mit der neuesten sn_node-Version v0.26.16 kompatibel. Stellen Sie daher für diese Aktualisierung auch sicher, dass Sie auch Ihre sn_node-Binärdatei aktualisieren ($ safe node install oder $ safe node update).
@scorch hat festgestellt, dass sich die neueste Version von clippy unter Windows für die CLI- und authd-Codebasis beschwert hat, und einen Fix dafür eingereicht. Dies führte dazu, dass wir die Clippy-Checks in unseren CI-Skripten verbesserten, um nicht nur unter Linux, sondern auch unter Windows ausgeführt zu werden, was verhindern sollte, dass dies erneut durchschlüpft.
Mit der Hinzufügung (von @mav) einer neuen API in unserem CRDT-Sequenzdatentyp zum Abrufen eines Eintrags, der einen einzelnen Index anstelle eines Bereichs angibt, hat @mav jetzt unser sn_api geändert, um diese neue API zum Abrufen einer bestimmten Version einer Sequenz zu verwenden.
An dieser neuen CLI (v0.19.0) wurden einige Verbesserungen vorgenommen, mit denen der Benutzer Bootstrapping-Informationen für ein Netzwerk mithilfe einer IP-Adresse (v4 oder v6) und einer Portnummer einrichten kann. Weitere Informationen zu diesem neuen Befehl finden Sie unter zum entsprechenden Abschnitt im CLI-Benutzerhandbuch.
Für diejenigen, die neugierig sind, wie sich die Rust-API entwickelt und wie es aussehen wird, eine Anwendung damit zu erstellen, gibt es eine allererste Beispiel-App ist jetzt in der sn_api-Kiste verfügbar, das zeigt, wie eine Datei in das Netzwerk hochgeladen und dann mithilfe ihrer XOR-URL abgerufen wird. Hoffentlich wird dies andere dazu inspirieren, andere einfache Beispielanwendungen für unsere Rust Safe-API zu erstellen, Verbesserungsmöglichkeiten zu ermitteln, sobald wir sie verwenden, und eine gute Ressource für neue Entwickler sein, die bereit sind, sichere Anwendungen zu schreiben.
CRDT
David Rusu, Autor von rust-crdt sowie unserer BRB-Implementierung, hat den LSeq-Code überprüft, nachdem @mav Probleme mit gemeldet hat es, wenn viele Einfügungen durchgeführt werden. Er ersetzte die ID-Implementierung, die auf dem ursprünglichen „LSeq“ -Papier basierte, durch eine rationale Nummer aus der „num“ -Kiste. Dies macht den LSeq-Code viel einfacher und führt auch zu einer besseren (gleichmäßigeren) Verteilung, wodurch das Problem gelöst und das Einfügen einer beliebigen Anzahl von Elementen ermöglicht wird. LSeq wurde ebenfalls in List umbenannt. Pull Request.
BRB - Byzantinische zuverlässige Sendung
Erinnern Sie sich an sn_fs, unseren Prototyp eines Dateisystems, das den Baum CRDT verwendet? Nun, diese Woche haben wir Schritte zur Integration von „sn_fs“ und „BRB“ unternommen, um einen P2P-Prototyp eines byzantinisch fehlertoleranten verteilten Dateisystems zu erstellen.
Zuerst haben wir „brb_node_qp2p“ gegabelt und „brb_node_tree“ erstellt, was das Senden von „crdt_tree“ -Operationen über brb demonstriert. Dann haben wir die sn_fs Kiste modifiziert und in eine Bibliothek verwandelt. Zuletzt haben wir eine brb_node_snfs Kiste erstellt, in der wir alles zusammenbringen. Bis heute konnten wir zwei (oder mehr) Knoten aufrufen und Verzeichnisoperationen wie „mkdir“, „rmdir“ ausführen. Die Operationen werden im bereitgestellten Dateisystem jedes Peers gespiegelt. Dateivorgänge funktionieren noch nicht, sollten aber bald sein.
Es sollte betont werden, dass dies eine reine Proof-of-Concept-Arbeit ist. Es müssen viele Details ausgearbeitet werden, bevor sie in die Praxis umgesetzt werden können.
Routing
Die im Update der letzten Woche beschriebenen Änderungen an der Abschnittskette zum Auflösen von Gabeln sind jetzt größtenteils vorhanden. Wir führen derzeit interne Tests mit dem Stresstest-Tool durch, um verbleibende Probleme zu identifizieren. Es scheint, dass sich die Stabilität des Netzwerks erheblich verbessert hat, insbesondere bei Splits. Einige Probleme bleiben jedoch weiterhin bestehen und wir sind mit dem Debuggen beschäftigt, aber insgesamt sind wir hinsichtlich dieses Ansatzes optimistisch.
Wir haben auch eine PR zusammengeführt, um eine Nachrichtenexplosion zu beheben. Dies geschah, als ein Ältester offline ging, aber die verbleibenden Ältesten immer noch versuchten, ihnen die Offline zu senden „Abstimmung“, die natürlich nicht abgegeben werden würde und dann weitere „Offline“ -Stimmen auslösen würde.
Wir haben einen weiteren PR zusammengeführt, um auf eine Kundenanfrage mit Fehler zu antworten, wenn eine DKG läuft. Eine fortlaufende DKG (Distributed Key Generation) bedeutet, dass der Abschnitt kurz vor dem Übergang zu einer neuen Gruppe von Ältesten steht. Daher sind die Dinge zu diesem Zeitpunkt möglicherweise nicht vollständig stabil oder konsistent. Daher ist es besser, den Kunden zu informieren, damit er sich zurückzieht und es versucht again kurze Zeit später.
[UPDATE 22. Februar] - Sicherer Browser
Etwas, das wir ursprünglich vergessen haben, zu diesem Update hinzuzufügen: man_facepalming:
@bzee hat eine PR erstellt, um sn_nodejs mit den neuesten API-Änderungen auf den neuesten Stand zu bringen, auf die der Safe Browser aktualisiert werden muss wieder mit dem Rest der sicheren Landschaft kompatibel sein. Er hat sich auch mit den Einschränkungen der aktuellen Bibliothek befasst und Möglichkeiten zur Verbesserung gesehen!.
Danke @bzee! 
und entschuldige mich dafür, dass du deine Beiträge im OP ursprünglich verpasst hast.
Nützliche Links
Fühlen Sie sich frei, unten mit Links zu Übersetzungen dieses Entwicklungsupdates 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!