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 „Gefällt mir“