Safe Network Entwickler Update 🇩🇪 4. März 2021

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

Zusammenfassung

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

  • Safe Chat, die Open House Community am vergangenen Freitag, war ein großer Erfolg! Vielen Dank an alle Beteiligten, insbesondere an @sotros25 und @m3data für ihre hervorragenden Präsentationen. :clap:
  • @jimcollinson führt eine AMA über Reddit durch - bitte machen Sie mit!
  • Das Hauptthema dieser Woche war das tiefe Eintauchen in und Debuggen von Netzwerken mit mehreren Abschnitten. Mehrere neue Fehlerbehandlungsprobleme wurden eingeführt, um Probleme zu beseitigen, die zum Ausfall von Netzwerken führen können.
  • Neue Versionen von sn_api (v0.20.0), sn_authd (v0.2.0) und der CLI (v0.20.0) wurden [gerade veröffentlicht]((https://github.com/maidsafe/sn_api/ Releases/latest/)), wodurch es mit dem neuesten sn_node kompatibel ist.
  • Wir haben jetzt die Entwicklung des MerkleReg abgeschlossen, das letzte Woche erwähnt wurde, und daher wurde begonnen, es in sn_data_types zu integrieren.
  • Diese Woche wurden die ersten Dateien von einem SNFS-Knoten über BRB zu einem anderen übertragen. :tada:
  • Beim Routing haben wir schließlich die Gabelauflösungs-PR zusammengeführt.
  • Auch beim Routing haben wir drei separate PRs zusammengeführt (# 2349, # 2351 und # 2336), die Korrekturen für verschiedene Probleme implementieren, die beim Stresstest aufgetreten sind. Das Routing gilt jetzt als bereit für ein stabiles Testnetz.

Safe Client, Nodes und qp2p

Projektplan für sichere Netzwerkübertragungen
Safe Client-Projektplan
Projektplan für sichere Netzwerkknoten

Näher und näher…

Wir haben in der letzten Woche das Testen und Debuggen von Netzwerken mit mehreren Abschnitten fortgesetzt. Wir sind näher als je zuvor, verlockend, aber auch noch nicht da (es ist auch für uns frustrierend!). Es ist ein interessanter Ort zum Debuggen, es gibt viele Protokolle und Nachrichten, und sie kommen in allen möglichen Reihenfolgen, also testen wir hier wirklich die Kanten.

Weitere Korrekturen

Einige kleinere Ecken und Kanten wurden abgelegt. Wir behandeln jetzt einige Fehlersituationen, die sich aus abschnittsübergreifenden Übertragungen oder sogar aus Übertragungen ergeben können, die eingehen und Fehler auslösen, da sie nicht mehr gültig sind, wie wir sie bereits gesehen und angewendet haben. Wir behandeln jetzt auch einige „sn_transfers“ -Fehler, die auftreten können, wenn es keine Historie gibt - dies kann von neuen Ältesten herrühren, die noch keine Historie haben. Zuvor verursachte dies einen Fehler und unterbrach den Fluss.

Das Grundproblem angehen

Das größere Problem bei der Weiterentwicklung von Abschnittsaufteilungen auf der Ebene „sn_node“ besteht jedoch darin, die neuen Ältesten der jeweiligen Geschwisterabschnitte mit den Ältesten der übergeordneten Sektion auf den neuesten Stand zu bringen und sie Anfragen so behandeln zu lassen, als wären sie bereits Älteste. Ohne das wäre der Übergang im Grunde genommen zum Stillstand gekommen. Solange sie nicht alles haben, was benötigt wird, um ein Ältester zu sein, geben einige dieser Anfragen einen Fehler zurück - aber das ist im Grunde in Ordnung.

Wir kommen hier parallel zu zwei Aufgaben voran. Zum einen nehmen wir einige schnelle Anpassungen vor, die es uns ermöglichen, das oben beschriebene Testnetz in Gang zu bringen, und zum anderen nehmen wir einige Anpassungen auch auf der Ebene „sn_routing“ vor, um die Übergänge besser zu koordinieren. Damit treiben wir auch das Bestreben voran, alle beteiligten Ingenieure in irgendeiner Weise durchgängig einzubeziehen, was wir für ein gut funktionierendes System dieser Art für notwendig halten.

Sicherer Browser

Auch diese Woche haben wir im Safe Browser ein bisschen Zeit damit verbracht, das Repo abzuwischen (es ist eine Weile her!), Abhängigkeiten zu aktualisieren, damit wir nicht viele Sicherheitsprobleme haben, wenn wir bereit sind, dorthin zu gehen. (@bzee scheint mit seiner „Napi“ -Konvertierung von „sn_nodejs“ gute Fortschritte gemacht zu haben, was großartig zu sehen ist!). Dies sind keine aufregenden Schlagzeilen, aber es ist eine Sache weniger, die angegangen werden muss, wenn wir mit der Stabilität des Testnetzes zufrieden sind.

API und CLI

Eine neue Version von sn_api (v0.20.0), sn_authd (v0.2.0) und der CLI (v0.20.0) wurde gerade veröffentlicht, mit einigen Verbesserungen bei der Speicherung von Dateien und NRS-Containern im Netzwerk Wie bei den neuen Unterbefehlen „bin-version“, mit denen auth & node ihre Binärversion abfragen kann. Wie üblich können Sie die CLI zum Aktualisieren verwenden ("$ safe update" und „$ safe auth update“) oder die neueste CLI installieren, wie im Benutzerhandbuch. Diese neuen Versionen sind mit der neuesten Version von sn_node v0.28.1 kompatibel.

Wie bereits letzte Woche erwähnt, haben wir unseren Sequenzdatentyp so migriert, dass er jetzt eine unveränderliche Richtlinie enthält, die alle Komplexitäten beseitigt, die unser CRDT-Ansatz mit sich bringt. Mit thaIn der vergangenen Woche konnten wir alle unsere APIs und Messaging-Typen auf breiter Front anpassen, um die Möglichkeit der Mutation von Richtlinien zu beseitigen.

Aufgrund von Refactoring und anderen Änderungen in den letzten Monaten an der Art und Weise, wie Nachrichten vom Client an das Netzwerk gesendet werden, mussten wir unsere sn_api E2E-Tests in CI vorübergehend deaktivieren, da sie an die neue, asynchrone Art des Messaging angepasst werden müssen . Wir haben jetzt begonnen, sie langsam anzupassen, um sie wieder in unser CI-System aufzunehmen.

CRDT - Konfliktfreie replizierte Datentypen

Wir haben jetzt die Entwicklung des MerkleReg abgeschlossen, die letzte Woche erwähnt wurde: rust-crdt # 111, und daher wurde mit der Integration begonnen in sn_data_types. Zur Erinnerung, das MerkleReg wird das neue Hintergrund-CRDT für den Sequenztyp sein. Es unterstützt einen Verzweigungsverlauf, der durchlaufen werden kann (ähnlich einem Git-Verzweigungsverlauf).

Auch in dieser Woche wurde bei GList / List-CRDTs ein Problem beim Einfügen zwischen Indizes festgestellt, die denselben Bezeichner verwendeten. Daher wurde dies in rust-crdt # 112.

BRB - Byzantinische zuverlässige Sendung

Die Integration von Safe Network File System (SNFS) in BRB hat sich als sehr fruchtbar erwiesen, als einige fehlende Funktionen in BRB entdeckt wurden:

  1. Der Kunde wurde nicht benachrichtigt, als ein Op angewendet wurde. Clients benötigen diese Informationen, um potenziell verworfene Pakete erneut zu senden. Dies wurde mit „Delivered“ -Paketen behoben: brb # 27.
  2. Wenn eine Operation von BRB auf einem Client ausgeführt wurde, stützte sie sich auf den Netzwerkstapel, um Pakete an sich selbst zu senden. Dies würde zu Rennbedingungen für sehr gleichzeitige Clients führen, wenn Op’s schnell hintereinander ausgeführt werden. Wir schließen diese Pakete jetzt an uns selbst kurz und verarbeiten sie, bevor wir zum Client zurückkehren: brb # 29.
  3. Um mit verworfenen Paketen umzugehen, haben wir eine API zum erneuten Senden von Paketen hinzugefügt, für die wir noch keine Antwort erhalten haben: brb # 29.

SNFS - Sicheres Netzwerkdateisystem

Gute Nachrichten! Diese Woche wurden die ersten Dateien von einem SNFS-Knoten über BRB zu einem anderen übertragen. :tada:

Wir haben die BRB-Übertragung zunächst synchron mit der FUSE-Operation durchgeführt, dies erwies sich jedoch als zu langsam. Es wurde eine Verbesserung vorgenommen, um Vorgänge in die Warteschlange zu stellen und sofort zu FUSE zurückzukehren. Ein separater Thread sendet dann träge Vorgänge in der Quellreihenfolge an Peers und stellt sicher, dass jeder angewendet wird. Dies ist ein notwendiger Schritt in Richtung eines Dateisystems, das offline verwendet und dann bei Wiederherstellung der Konnektivität mit Peers synchronisiert werden kann. Mit dieser Änderung fühlt sich das Dateisystem in Bezug auf die Geschwindigkeit wie die Verwendung eines normalen Betriebssystem-Dateisystems wie ext4 unter Linux mit einer SSD an. Vielleicht noch nicht ganz so schnell, aber in der gleichen Größenordnung.

Beim gestrigen Testen haben wir festgestellt, dass zwei Threads mehr CPU verbrauchen, als sie sollten, nachdem starke Kommunikation stattgefunden und abgeschlossen wurde, und jetzt ist der Prozess inaktiv. Beide Threads sind aus unbekannten Gründen damit beschäftigt, Quinn-Code (Netzwerkcode) auszuführen. Diese Woche wurde eine neue Version von Quinn veröffentlicht, die das Problem möglicherweise beheben wird. Wir werden dies daher so bald wie möglich testen.

Routing

Projektplan

Diese Woche haben wir endlich die Fork Resolution PR zusammengeführt. Der Kern der PR ist eine neue Implementierung der „SectionChain“ -Datenstruktur, die jetzt eine ordnungsgemäße CRDT ist. Dies bedeutet, dass es (eventuelle) Konsistenz garantiert, unabhängig davon, in welcher Reihenfolge die Vorgänge angewendet werden, wie sie gruppiert oder sogar dupliziert werden. Selbst wenn mehrere unterschiedliche Schlüssel eingefügt werden, wird sich irgendwann jeder darüber einig sein, welcher der aktuellste ist und somit wer die aktuellen Ältesten sind (da jeder Abschnittsschlüssel eindeutig einer einzelnen Gruppe von Ältesten zugeordnet ist). Und all dies wird erreicht, ohne dass ein komplizierter Konsensmechanismus erforderlich ist. Genau das wollten wir, als wir Parsec entfernt haben und jetzt ist es endlich da.

Es folgten drei separate PRs (# 2349, # 2351 und # 2336), die Korrekturen für verschiedene Probleme implementieren, die beim Stresstest aufgetreten sind. Hier sind einige der bemerkenswertesten:

  • Vermeiden Sie eine unendliche Anforderungs-Antwort-Schleife während des Bootstrapings, indem Sie doppelte Umleitungsantworten ignorieren - was zu massiven Speicherlecks führte.
  • Das versehentliche Ablehnen gültiger Bootstrap-Antworten beim Verschieben wurde behoben. - Ein Knoten, der in einen anderen Abschnitt verschoben wurde, blieb hängen.
  • Das versehentliche Ungültigmachen der Signatur von erneut gesendeten „Sync“ -Nachrichten wurde behoben. Dies führte dazu, dass Knoten manchmal nicht ordnungsgemäß über den Status ihres Abschnitts aktualisiert wurden.
  • Benachrichtigen Sie umgesiedelte Älteste darüber, dass sie aus ihrem ursprünglichen Bereich gewählt wurden - wenn sie dies nicht tun, werden sie niemals gewähltihre Umsiedlung vorantreiben.
  • Stellen Sie sicher, dass die Informationen zum Geschwisterabschnitt nach dem Teilen vertrauenswürdig sind. Andernfalls haben die Knoten vergessen, wer die Knoten in ihrem Geschwisterabschnitt direkt nach dem Teilen waren, und konnten sie daher nicht kontaktieren. Dies führte ferner dazu, dass einige Knoten während des Bootstrapings stecken blieben.
  • Mehrere ausstehende DKG-Ergebnisse zulassen - Wenn dies nicht der Fall ist, vergessen Knoten manchmal ihre geheimen Schlüsselfreigaben und können daher keine Abschnittsnachrichten mehr signieren.
  • Verwenden Sie einen eindeutigen Schlüssel für DKG-Sitzungen mit denselben Teilnehmern. Andernfalls wurde das DKG-Ergebnis manchmal beschädigt, sodass die Knoten keine Abschnittsnachrichten signieren konnten.

Nach diesen Korrekturen sehen die internen Netzwerke, die wir ausführen, viel stabiler aus. Damit betrachten wir das Routing nun als bereit für ein Testnetz!

Community & Marketing

Sicherer Chat

Der erste unserer Open House Community Safe Chats war am Freitag und was für ein Vergnügen! Während sich die Agenda auf das Thema Community-Marketing des Netzwerks konzentrierte, mit einigen hervorragenden Präsentationen von @sotros25 und @m3data, waren die Diskussionen breiter, als Sie sich vorstellen können.

Es war nicht nur großartig, einige Gesichter zu sehen - obwohl Kameras optional waren! -, es scheint sich auch zu einem wichtigen Umfeld für die Zusammenarbeit und die Ausarbeitung großer Pläne zu entwickeln!

Wenn Sie es noch nicht getan haben, können Sie das Gespräch hier nachholen:

Wir werden zweifellos mehr davon ausführen, also bleiben Sie dran und wir werden Sie wissen lassen, wann Sie Ihre Tagebücher frei halten müssen.

Ich bin ein UX-Designer, der beim Aufbau des neuen Internets hilft: Frag mich alles!

@jimcollinson führt eine AMA über Reddit und wirklich alle sozialen Kanäle durch.

Er wird so viele Fragen wie möglich beantworten und einige der am häufigsten gestellten und saftigsten für YouTube-Fragen und Antworten speichern, um sie zugänglich zu machen, einfach zu teilen und hoffentlich noch ein bisschen länger zu bleiben.

Bitte machen Sie mit!

Safe Network App UX

Da wir zum ersten Mal den Onboarding-Prozess für Benutzer verbessert haben, die einen Safe im Netzwerk erstellen, haben wir Ihnen einen kleinen Einblick gegeben Vor einigen Monaten haben wir in mehr Bereichen der App daran gearbeitet, mehr von diesem eher gesprächigen Ansatz für Anfänger zu verwenden. Nicht ausgiebig, aber wo es helfen könnte, Menschen aus „No Content States“ in die richtige Richtung zu bringen.

Ein solcher Ort ist das Dienstprogramm zum Erstellen von Einladungen, mit dem vorhandene Benutzer einen Freund in das sichere Netzwerk aufnehmen können.

Die Arbeit zur Vereinfachung dieses Ablaufs hat uns auch dazu veranlasst, den Einladungsprozess insgesamt zu betrachten und ihn etwas zu gestalten.

Wenn Sie sich erinnern, hatten wir zuvor geplant, Kunden das automatische Aufladen zu ermöglichen oder Einladungen zu belasten, um die Inflation / Deflation der Token zu berücksichtigen. Dies hatte einige Nachteile, zum einen, dass es zunächst nur funktionierte, wenn der Client geöffnet war, und zum anderen, dass die Abläufe unter Umständen, in denen die automatische Aufladung aktiviert war, etwas komplexer wurden, aber die Brieftasche keine Mittel mehr hatte unterstütze es.

Kurz gesagt, was das Leben einfacher machen sollte, könnte auf dem glücklichen Weg gut funktionieren, aber etwas umständlich sein.

Gleichzeitig haben wir eine weitere nützliche Einladungsfunktion bis nach MVE verschoben: die Möglichkeit, einer Einladung zusätzliches Geld hinzuzufügen, wenn Sie sie einem Freund schenken.

Aber nicht mehr! Wir können die Inflationskompensation verständlicher und robuster machen, aber ein bisschen manueller, wenn wir einfach weitermachen und manuelle Aufladungen aufbauen.

Es ist also ein bisschen zwei für einen. Sie erhalten eine verständlichere Einladungsverwaltung, und Sie können einem beliebig viele Token hinzufügen.

Helfen Sie einem Freund, in das Netzwerk einzusteigen, und zahlen Sie ihn für das Mittagessen auf einmal zurück.

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!