Safe Network Entwickler Update đŸ‡©đŸ‡Ș 26. November 2020

Dies ist eine maschinelle Übersetzung. Das Original in Englisch ist hier: Safe Network Dev Update - November 26, 2020

Zusammenfassung

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

Safe Client, Nodes und qp2p

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

Nachdem wir letzte Woche das Signieren von Sequenz-CRDT-VorgĂ€ngen hinzugefĂŒgt haben, haben wir dies diese Woche in den Stapel integriert, mit einigen Änderungen in sn_node hier und sn_client hier und hier, um alle VorgĂ€nge zu signieren, bevor sie an das Netzwerk weitergeleitet werden. Dies hob einige andere Probleme in Bezug auf das lokale Caching von Sequenzen hervor (wann lokal gegen Netzwerk verwendet werden soll usw.). Wir haben uns vorerst entschieden, diesen Cache ĂŒber diese PR zu entfernen. Dies hat dazu beigetragen, die Testsuite zu stĂŒtzen, sodass wir einige CRDT-Flows in Aktion deutlicher sehen können. Beispielsweise werden Push-Änderungen nicht sofort aus dem Netzwerk abgerufen, sodass wir dort auf erwartete Änderungen warten mĂŒssen.

Mit den oben genannten Änderungen haben wir auch einige neue Probleme beim Starten von Abschnitten behoben, die auf der RĂŒckseite dieser Probleme aufgetreten sind. Einige kleine Client-Optimierungen wurden hier hinzugefĂŒgt, um ein Versagen zu verhindern, wenn ein Ältester nicht verfĂŒgbar ist (aber noch genĂŒgend andere vorhanden sind). Mit diesem Eintrag können wir nun eine Teilmenge von sn_client-Tests sehen, die gegen einen Abschnitt mit elf Mitgliedern in CI bestanden werden.

Der Rest der Fehler, die wir sehen, ist hauptsĂ€chlich auf einige versteckte Fehler bei der Auswahl der Ziele und den Chunk-Abruf bei der Blob-Daten-Chunk-Replikation zurĂŒckzufĂŒhren, die wir letzte Woche aktiviert haben. Seien Sie versichert, wir sind mit den Korrekturen auf dem besten Weg und kreuzen die letzten fehlgeschlagenen Tests der Client e2e-Testsuite an. Bei der Suche nach diesen Fehlern wurde auch hervorgehoben, dass einige Elemente des Messaging noch fehlten und nun erforderlich waren, um den Kontrollfluss / die Fehlerbehandlung einen Schritt nĂ€her an das heranzufĂŒhren, was wir als „Lazy Messaging“ bezeichnen. Es wird daran gearbeitet, dies zu beheben.

Bei Lazy Messaging erhalten wir eine Nachricht, die wir aus irgendeinem Grund nicht verarbeiten können (nicht synchron, zukĂŒnftige Sequenznummer usw.), und wir senden diese Nachricht mit unserem letzten bekannten Verlauf an den Absender zurĂŒck. Der Absender weiß dann, dass er uns das fehlende Glied mitteilen muss (wir können auch die Umkehrung durchfĂŒhren (allerdings kein Fehler) und den Absender aktualisieren, wenn er dahinter steckt). Dies erspart uns das Speichern von Nachrichten bis zu deren Bestellung, die zum Angriff auf das Netzwerk ausgenutzt werden könnten, und es wĂ€re komplexerer Code. Lazy Messaging ist einem Modell fĂŒr die Weitergabe von Nachrichten viel nĂ€her, und wir haben es erweitert, um teilweise geordnete Ereignisse zu verarbeiten.

Mit einer Änderung der neuen Knotenverbindungsdynamik im Routing, siehe PR # 2234, haben wir auch begonnen, sn_node so zu aktualisieren, dass die Knoten die Verantwortung dafĂŒr ĂŒbernehmen Zulassen, dass neue Knoten dem Netzwerk beitreten. TatsĂ€chlich verfolgen die Ältesten des Netzwerks nun das Angebot / die Nachfrage nach Ressourcen in ihrem Abschnitt und fordern dementsprechend das Routing an, damit neue Knoten, die sich in der Warteschlange befinden, ihrem Abschnitt beitreten können.

Wir haben auch damit begonnen, „authd“ und CLI an die neue UI / UX-Terminologie anzupassen, z. B. von „Accounts“ zu „Safes“ zu wechseln und die erforderlichen Änderungen vorzunehmen, damit „authd“ die Anwendungen speichert ‚SchlĂŒsselpaare im Netzwerk, die eine‘ Karte 'als Speicherdatentyp fĂŒr den „Safe“ verwenden. Wir werden mit dieser Aufgabe fortfahren, um alle CLI-Befehle und Authentifizierungsfunktionen auf diese neuen Terminologien sowie auf die neue sn_client-API abzustimmen.

Sobald wir mit den oben genannten Updates, Korrekturen und Fehlern fertig sind, können wir unsere internen Testnetze erneut mit Vollgas starten, die verschiedenen Module aufrĂ€umen, ihre StabilitĂ€t ĂŒberprĂŒfen und lose Enden zusammenbinden und hoffentlich ein frĂŒhes Weihnachtsgeschenk an euch Leute! :zwinkern:

BRB - Byzantinische Rehaftbar Broadcast

Diese Woche hat unser Berater die letzte Woche erwĂ€hnte Idee der Generationsuhr weiterentwickelt und dem Team einen Pseudocode-Algorithmus zur Kommentierung vorgelegt. Dieser hybride Ansatz legt eine Gesamtreihenfolge fĂŒr seltene Join- und Leave-Operationen fest, jedoch nur eine Teilreihenfolge fĂŒr viel hĂ€ufigere Datenoperationen. Im Klartext bedeutet dies, dass Join / Leave begrenzt sein muss (dh wir können nicht zulassen, dass nicht reagierende Knoten existieren) und eine Form der Gesamtreihenfolge verwenden, aber wir können viele BlĂ€tter gleichzeitig verarbeiten usw., wĂ€hrend regelmĂ€ĂŸige Datenoperationen auftreten können mit hoher ParallelitĂ€t, sofern jede aus einer anderen Quelle stammt (Akteur im CRDT-Sprachgebrauch). Bisher scheint der Vorschlag solide zu sein, und der nĂ€chste Schritt besteht darin, ihn in Code zu implementieren und einige Tests zu schreiben. Mehr dazu nĂ€chste Woche.

Routing

Projektplan

Wie in den vergangenen Wochen erlĂ€utert, wurde die Arbeit zur Verbesserung der Erkennung verlorener Peers diese Woche genehmigt und zusammengefĂŒhrt. Dies nutzt die Verbindungspooling-Funktion in qp2p. Diese Änderung bedeutet, dass die Routing-Code-Basis vereinfacht wurde und nun komplexere Integrationstests hinzugefĂŒgt werden können, um die Funktionen des Produktionscodes zu ĂŒberprĂŒfen.

Einige API-Funktionen funktionieren - Angabe fĂŒr Abschnittstart und Age Getter und
Benachrichtigen, wenn der SchlĂŒssel wĂ€hrend des Umzugs geĂ€ndert wurde - wurde ebenfalls diese Woche abgeschlossen. Wenn diese vorhanden sind, werden die Knoten jetzt beim Start besser ĂŒber den Routing-Status und das verwendete aktualisierte SchlĂŒsselpaar informiert.

Beim Testen haben wir ein Problem festgestellt, bei dem wĂ€hrend des Bootstraps, als auf die Nachricht „NodeApproval“ unmittelbar eine andere Nachricht folgte, z. B. „Verschieben“, der Bootstrap * nach * der Verarbeitung des „NodeApproval“ abgeschlossen wurde. Dies hinterließ eine folgende Nachricht, wie „Verschieben“, im Zwischenkanalpuffer, die niemals herausgenommen und verarbeitet werden konnte, d. H. Wir haben diese Nachricht verloren. Wir haben einen Fixing-PR Fehler beim Verlust von Nachrichten wĂ€hrend des Bootstraps beheben zusammengefĂŒhrt, um dieses Problem zu beheben. Der Zwischenkanal wird entfernt und durch einen einfachen Wrapper um den ConnectionEvent-EmpfĂ€nger ersetzt. Somit wird das „Push / Pull“ -Modell in ein einfaches „Pull“ -Modell geĂ€ndert. Auf diese Weise wird eine Nachricht niemals aus dem Kanal abgerufen, wenn sie nicht zur Verarbeitung bereit ist.

Die im Update der letzten Woche erwĂ€hnte Arbeit Knoten dĂŒrfen das Routing anweisen, neue Knoten zu akzeptieren oder nicht wurde ebenfalls abgeschlossen und diese Woche zusammengefĂŒhrt. Beim Routing wird davon ausgegangen, dass die Ă€lteren Knoten alle erwachsenen Knoten im Abschnitt verfolgen. Wenn sie feststellen, dass die durchschnittliche SpeicherkapazitĂ€t (oder eine andere Ressource) zu niedrig wird, wird das Flag umgedreht, sodass der Abschnitt neue Knoten akzeptiert. Alle Ă€lteren Knoten sollten dies mehr oder weniger gleichzeitig erkennen, damit ein Konsens erzielt werden kann. Wenn die Sektion bereits SĂ€uglinge hat, wird nicht nur die Flagge umgedreht, sondern auch einer von ihnen mit um eins erhöhtem Alter befördert, wodurch sie effektiv umziehen und sofort als Erwachsener zurĂŒckkehren können.

Safe Network App & UX

Feature Tracker / Screens & Flows / Onboarding Prototype

Vielen Dank fĂŒr Ihr Feedback zu den vorgeschlagenen Änderungen am Safe-Lexikon. Wir haben damit begonnen, diese Änderungen durch die UX-Flows und Safe Network App-Prototypen zu filtern. Sie sollten sie in den verschiedenen Figma-Dateien sehen, wĂ€hrend wir alles durcharbeiten.

Obwohl dies nicht direkt mit den SprachÀnderungen zusammenhÀngt, war ein interessantes kleines Nebenprojekt, das aus der Arbeit hervorging, ein erneuter Besuch einiger Onboarding-AblÀufe, beispielsweise wenn ein Benutzer bereit ist, seinen eigenen Safe zu erstellen.

Wenn Sie sich erinnern, wurden in der vorhandenen Version alle Optionen aufgefĂŒhrt, die ein Benutzer zum Erstellen eines Safes (oder eines Kontos wie zu diesem Zeitpunkt) hatte, und er konnte die entsprechende Route mit schrittweisen Anweisungen auswĂ€hlen.

Es sah so aus:

Aber könnten wir es glatter machen? Könnten wir es vielleicht weniger entmutigend machen und einem Benutzer helfen, seinen Safe ohne fremde Hilfe schnell zum Laufen zu bringen, und ihn dann dazu bringen, sichere Netzwerk-Token zum Booten zu verdienen?

Hier ist ein kleiner anklickbarer Prototyp des neuen Ansatzes - nur ein glĂŒcklicher Weg -, um Ihnen einen Vorgeschmack zu geben.

Dies ist nicht der einzige Weg, um einen Safe zu erhalten. Es wird andere alternative AblĂ€ufe mit etwas weniger Handhaltung geben, aber fĂŒr den erstmaligen Benutzer wird es interessant sein zu sehen, wie dies im Vergleich zum bestehenden Ansatz ist.

Es ist auch ein Muster, das auf andere Bereiche der App angewendet werden kann, z. B. das erstmalige Sammeln von Token, das Erstellen einer SafeID oder das AuswÀhlen starker Anmeldeinformationen.

Unter dem Gesichtspunkt des Designs und der Flusslogik ist es fĂŒr uns etwas mehr Arbeit, aber wenn es fĂŒr den Benutzer reibungsloser und weniger einschĂŒchternd ist und mehr Safes und Knoten im Netzwerk verfĂŒgbar sind, zahlt es sich aus.

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!

1 Like