Vaults Phase 2
In der vergangenen Woche haben wir die nächste Iteration der Vaults aus dem Heimtestnetz getestet und abgeschlossen. Nach einigen Runden des Testens und der Fehlerbehebung freuen wir uns, die nächste Iteration der Vaults aus dem Heim-Testnetz anzukündigen, die heute veröffentlicht wurde 
.
Geht hinüber zum release post , um sich einzubringen, jeder ist willkommen.
Parallel dazu haben wir an einigen der nächsten Schritte gearbeitet, die sich in erster Linie auf mehrere Abschnitte konzentrieren. Wir haben auch unsere Testsuite überarbeitet und zahlreiche Verbesserungen vorgenommen, darunter die Verwendung von echtem Routing für die Tests auf unseren Plattformen für eine kontinuierliche Integration.
SAFE API
Heute haben wir neue Versionen von safe-api, safe-cli, safe-authd, safe-ffi und jsonrpc-quic veröffentlicht, die alle die heutige neue Vaults von der Heimtestnet-Iteration unterstützen:
Im changelog findet Ihr die Highlights der neuen Funktionen und Fehlerbehebungen, die in den neuen Versionen enthalten sind, und natürlich findet Ihr in unserem detaillierten CLI-Benutzerhandbuch eine Schritt-für-Schritt-Anleitung zur Verwendung aller neuen und bestehenden Funktionen.
Wir haben damit begonnen, mögliche Designverbesserungen für die SAFE File API zu untersuchen.
Insbesondere hat ein kürzlich erschienenes Forschungspapier (und Video siehe 35:30) unsere Aufmerksamkeit erregt, das die Leistung dramatisch verbessern, zur Vereinfachung unserer API beitragen und die Herausforderungen der gemeinsamen Bearbeitung lösen könnte. Das Papier trägt den Titel A highly-available move operation for replicated trees and distributed filesystems (Ein hochverfügbarer Verschiebevorgang für replizierte Bäume und verteilte Dateisysteme) und beschreibt einen formal bewährten CRDT-Baum-Datentyp, der für die Verwendung im Dateisystem geeignet ist und, da er schließlich konsistent ist, ein langjähriges Problem des Verschiebevorgangs löst, das sogar Dropbox und Google Drive betrifft, wenn es um gleichzeitige Aktualisierungen geht. Er ist auch für die Offline-Arbeit geeignet.
Die Kernidee des Designs ist, Baum als SAFE-Datentyp hinzuzufügen und einen Dateibaum als Spezialisierung zu implementieren, so wie FileContainer eine Spezialisierung von Sequence war. Der wichtige Unterschied besteht darin, dass jedes Verzeichnis und jede Datei einzeln im Baum gespeichert wird, anstatt alle zusammen als flache JSON-Map in einem einzigen `Sequence’-Eintrag zu serialisieren. Dies macht Aktualisierungen und Abrufe für jede nicht-triviale Verzeichnisstruktur viel effizienter.
Darüber hinaus möchten wir Elemente von Safe.NetworkDrive für schnellen lokalen Zugriff und Offline-Nutzung sowie native Dateisystemintegration über FUSE einbauen.
Um es klar zu sagen, die Idee ist, dass SAFE-Anwendungen direkt auf die Datei-APIs zugreifen können, wenn sie es wünschen, aber nicht-SAFE-Anwendungen können trotzdem über ein lokales Mount mit SAFE-Dateien interagieren. Dies würde bedeuten, dass Tools wie rsync, Datei-Explorer usw. einfach verwendet werden könnten.
Im Moment bleibt dies noch Brainstorming und High-Level-Design. Es gibt eine Menge an Punkten zu lösen. Eine erste Herausforderung wäre die Implementierung des CRDT-Tree-Algorithmus in Rust. Er existiert zur Zeit nur in der Form der formalen Logik von Isabelle/HOL. Wenn irgendein Mitglied der Community mit Isabelle/HOL vertraut ist und helfen könnte, ihn nach Rust zu übersetzen, oder sogar Pseudocode bereit zu stellen, könnte das helfen, des Prozess zu beschleunigen.
Parallel dazu haben wir versucht, die Authenticator-FFI-APIs aus der Safe-ffi-Repository freizulegen. Dies wird unsere APIs auf allen Plattformen vereinheitlichen. In den letzten Wochen sahen wir uns mit einem Problem mit den FFI-APIs konfrontiert, als wir versuchten, eine Verbindung mit dem echten Netzwerk herzustellen, während die Schein-APIs gut funktionierten. Diese Woche haben wir dieses Problem behoben, und wir können nun mit der letzten Test- und Überprüfungsrunde fortfahren.
SAFE App C#
Wie wir im Abschnitt über die SAFE-API erwähnt haben, hat die Lösung der Verbindungsprobleme in safe-ffi es ermöglicht, die neuen Authentifizierer-APIs in den C#-APIs zu testen. Das bedeutet, dass wir in den kommenden Wochen eine neue Version des NuGet-Pakets veröffentlichen werden, die alle neuen APIs, einschließlich der Sequenzdaten-APIs und der Authenticator-APIs, enthalten wird. Sobald dieses Paket veröffentlicht ist, wird es einfach sein, die Authenticator- und SAFE Mobile Browser-Anwendungen zu aktualisieren, um die neueste Vault-Version zu unterstützen.
Diese jüngsten Änderungen haben sich bereits als sehr hilfreich erwiesen, und zum allerersten Mal können wir unsere CI problemlos so einrichten, dass die Tests gegen ein echtes Netzwerk durchgeführt werden können . Bisher mussten wir diese Tests vor einer neuen Paketveröffentlichung manuell durchführen, während auf CI nur Mock-Tests durchgeführt werden konnten.
SAFE Browser / SAFE Network App
Der Browser und die App des SAFE-Netzwerks wurden in letzter Zeit etwas vernachlässigt, wobei der Schwerpunkt auf den verschiedenen Testnetzen und den zugrunde liegenden AT2-Arbeiten lag. Aber mit den neuesten Vaults und den zugrundeliegenden Änderungen an der SAFE-API sind wir jetzt an einem guten Punkt angelangt, so dass wir an einer neuen Version arbeiten, die mit dem neuesten Vault und dem Testnetz kompatibel ist.
Das wird nicht heute ankommen, aber wir bauen und testen vor Ort, also sollten sie in nicht allzu ferner Zukunft bei uns sein.
CRDT
In der vergangenen Woche setzten wir unsere Forschungen über die Zugangskontrolle zu unseren CRDT-Datentypen fort. Zur Zeit betrachten wir hauptsächlich zwei verschiedene Ansätze, einen ersten, der es erlaubt, Operationen auch dann durchzuführen, wenn sie von einer älteren Version der Richtlinie abhängen, und einen zweiten Ansatz, bei dem solche Operationen nicht akzeptiert oder sogar rückgängig gemacht werden, wenn eine neue Richtlinie sie ungültig macht.
Beide Ansätze haben ihre eigene Komplexität und ihre eigenen Implikationen, die wir immer noch versuchen, vollständig zu verstehen, nicht nur aus der Sicht der Implementierung, sondern auch aus der Sicht der Benutzererfahrung.
In beiden Fällen müssen wir sicherstellen, dass wir diese Abhängigkeit (Kausalitäts-)Informationen zwischen Daten und Policy-Operationen im Auge behalten, und deshalb haben wir mit einem kleinen Refactoring unserer derzeitigen Sequenz-CRDT-Implementierung begonnen, um sicherzustellen, dass sie den bevorstehenden Änderungen Rechnung tragen kann, unabhängig davon, welcher Ansatz gewählt wird.
Transfers
SAFE-Transfer Projektplan
SAFE Client Libs-Projektplan
[SAFE Vault-Projektplan] (https://github.com/maidsafe/safe-vault/projects/6)
In dieser Woche hat sich unser Netzwerk-Messaging-Refaktor nach einer zusätzlichen Iteration etwas beruhigt. Mit den großen Änderungen, die jetzt in safe-nd und in Vault angewendet werden, haben wir die Safe-Client-Libs wieder inline gebracht und dort einige Verbesserungen in der Nachrichtenverarbeitung vorgenommen, nachdem wir die Spezifität des Netzwerk-Messaging erhöht haben. Darüber hinaus konnte dadurch ein mehr oder weniger vollständiger Fluss von Landwirtschaftsprämien in Vaults implementiert werden. Wir sind derzeit dabei, dort einige interne Nachrichtenmuster zu bereinigen.
In SCL haben wir Dinge eingerichtet, die eine ordnungsgemäße Behandlung von Netzwerkereignissen (wie die Validierung einer AT2-Zahlungsanforderung), den vollständigen „Abfrage“-Fluss (den alle unsere Nachrichten vorher durchliefen, auch wenn das nicht notwendig war) und schließlich die Grundlagen für den Empfang von Fehlern aus dem Netzwerk geschaffen. Tatsächlich wird die Behandlung solcher Fehler wahrscheinlich eher eine Entscheidung auf Anwendungsebene sein, die die Entwickler treffen müssen.
Nun wird der Schwerpunkt für SCL & Vaults auf dem Testen dieser Interaktionen liegen.
Routing
Im Rahmen der Arbeiten zur Verbesserung der Code-Qualität haben wir damit begonnen, einige Routing-Code-Blöcke in separate Repositories aufzuteilen. Das erste Repository, die wir diese Woche [ausgelagert] haben (https://github.com/maidsafe/routing/pull/2159), ist [safe-network-signature-accumulator] (https://github.com/maidsafe/safe-network-signature-aggregator), die für die generische BLS-Signaturaggregation für das SAFE-Netzwerk bestimmt ist. Sobald dies stabil ist, werden weitere Codeblöcke aufgeteilt, um die Komplexität der Routing-Logik zu reduzieren. Solche Aufräumarbeiten sind unserer Meinung nach für den Start unerlässlich, da jedes kleine Modul gründlich getestet und mit größerer Klarheit dokumentiert werden kann, als wenn es mit anderem Code gemischt wird.
Wie im Entwickler-Update der letzten Woche erwähnt, wurde die erste Aufgabe zur Beseitigung der Parsec-Verwendung, [sicherzustellen, dass Mutationen zu SharedState von der Sektion genehmigt werden] (https://github.com/maidsafe/routing/pull/2155), diese Woche zusammengelegt. Dies ermöglicht es uns, mit der Aufgabe der Überholung der Knotenbeförderung weiter zu gehen. Aufgrund des Elternurlaubs von Adam (herzlichen Glückwunsch an ihn ) wird die Arbeit jedoch durch PR 2160 ersetzt, die heute zusammengelegt wurden. Wir sind nun einen Schritt näher an der Umsetzung der nachrichtenbasierten Abstimmung, die die derzeitige Parsec-basierte Abstimmung ersetzt.