Zusammenfassung
Hier sind einige der wichtigsten Dinge, die seit dem letzten Entwickler-Update hervorzuheben sind:
- Wir haben die Arbeit an den vaults von Home Improvements abgeschlossen und haben interne Testnetze laufen lassen - die Ergebnisse sehen bisher gut aus!
- Wir arbeiten weiterhin auf breiter Front daran, von Mocks auf den Produktivcode umzustellen.
- Wir sind dabei, einen weiteren Refactor für Netzwerkanfragen zu integrieren, der die Tür für das Farming im Netzwerk öffnen wird.
- Das Routing DKG-Ersatz PR (Pull Request) wurde zusammengelegt.
Vaults Phase 2
In dieser Woche haben wir die Implementierung von Verbesserungen auf der Grundlage der Rückmeldungen aus dem früheren Testnet abgeschlossen. Wir haben diese Änderungen in internen Testnetzen getestet, und wir sehen sehr gute Ergebnisse. Nach nur wenigen weiteren Tests werden wir bereit sein, eine weitere Iteration der Vaults aus dem Heimtestnet anzukündigen, in der alle Verbesserungen, an denen wir gearbeitet haben, vorgestellt werden 
Wir haben auch daran gearbeitet, unsere Testsuite gegen echtes Routing laufen zu lassen. Die Tests dauern viel länger, aber das liegt daran, dass wir derzeit für jeden Test ein eigenes Netzwerk aufbauen. Wir arbeiten an einigen weiteren Refactors, die für alle Tests dasselbe Netzwerk verwenden werden, und das wird die Dinge erheblich beschleunigen.
SAFE API
Diese Woche wurde ein PR auf Unterstützung für glob() gestellt, doch Bedenken hinsichtlich der Effizienz und die Notwendigkeit weiterer Änderungen an den Unterbefehlen für files ls könnten verhindern, dass diese zusammengeführt werden, bis weitere Arbeiten erledigt sind. Diese PR wird den üblichen Test- und Überprüfungsprozess durchlaufen, und wir werden die beste Vorgehensweise dafür erwägen.
SAFE App C#
Diese Woche haben wir eine etwas ältere PR wiederbelebt, der sich auf das Refactoring und die Verbesserungen der Authenticator API konzentriert. In diesem PR entfernen wir uns von den safe-client-libs/safe-authenticator-ffi" und stellen die Authenticator-APIs aus dem safe-api"-Repository vor. Dies wird die Anwendungs- und Authentifizierungs-APIs weiter vereinfachen und es einfacher machen, die APIs mit safe-cli , safe-api , & safe-nodejs synchron zu halten.
CRDT
In dieser Woche begannen wir mit der Untersuchung, wie Berechtigungen in unseren CRDT-Datentypen, wie dem neuen Datentyp „Sequenz“, richtig verwaltet werden können. Berechtigungen für CRDT-Daten zu haben, bringt einige Herausforderungen mit sich, da jede Änderung der Zugriffsregeln auf alle Replikate (d.h. Elders) in der gleichen Weise angewendet werden muss, damit wir die Datenkonvergenz beibehalten. Beispielsweise kann der Entzug der Erlaubnis eines Benutzers, Elemente an eine „Sequenz“ anzuhängen, dazu führen, dass einige Replikate dem Benutzer erlauben, weiterhin Elemente anzuhängen, wenn solche Operationen vor der Entzugsoperation gesehen werden, so dass die Replikate nicht zum gleichen Datenzustand konvergieren.
Wir sehen uns einige verfügbare Papers an, in denen einige Lösungen vorgeschlagen werden, um nicht nur die Lösungen, sondern auch das Problem selbst besser zu verstehen. Für diejenigen, die daran interessiert sind, mehr über das Problem zu lesen, könnte dieses Paper eine Hilfe sein, zumindest um die Herausforderung zu verstehen.
Transfers
SAFE-Transfers Projektplan
SAFE Client Libs-Projektplan
SAFE Vault-Projektplan
Nach dem Abschluss der Safe_core-Tests gegen das AT2-System haben wir an der Integration eines weiteren Refactors für Netzwerkanfragen gearbeitet, um die Tür für Farming im Netzwerk zu öffnen. Auf dem Weg zu einem Pseudo-Multisektionsaufbau mit AT2 und Farming müssen Vaults und Sections im Netzwerk Nachrichten untereinander austauschen, um einen Daten-/Zahlungsfluss zu vervollständigen. Daraus ergibt sich für uns die Notwendigkeit, zwischen Client-Nachrichten und netzwerkinternen Nachrichten zu unterscheiden. Daher wurde mit einer Überarbeitung der Nachrichtenstruktur begonnen, die das Netzwerk verwenden wird. Im Wesentlichen wird dies die Nachrichtenübermittlung mit den CRDT-Prinzipien und ereignisgesteuerten Systemen in Einklang bringen.
Dies hat wiederum zu weiteren Arbeiten an der Integration mit den SAFE Client Libs geführt, aber die Arbeiten kommen hier gut voran, da wir Fehler und Leistungsprobleme aufdecken und den Nachrichtenfluss dort verfeinern. Eine weitere bedeutende Änderung der SAFE Client Libs war die Entfernung von Antworten vom Typ „ack“ (die uns im Grunde genommen nichts sagen) und die Überlassung an den Client, optional zu bestätigen, ob ihre Operation abgeschlossen ist. (Dies selbst sollte uns schließlich zu einigen Try/Check/Retry-Flows für bestimmte Operationen führen, aber es wird nicht notwendig sein, dies zu tun. Das sollte den Anwendungsentwicklern mehr Flexibilität bei ihrem Vorgehen geben und im Gegenzug hoffentlich den Kunden selbst reaktionsfähiger machen).
Transfers
Diese Woche haben wir endlich die DKG-Ersatz PR zusammengeführt. Dies ermöglicht es uns, Abschnittsschlüssel ohne Parsec zu aktualisieren.
Um die Code-Qualität zu verbessern, haben wir auch Code-Abdeckungsstatistiken in das Repository aufgenommen und die Regel durchgesetzt, dass weitere PR die Abdeckungsrate nicht verringern dürfen. Wie bereits erwähnt, gehen wir schrittweise vor Mocks aus unseren Repositories zu entwernen. Das bedeutet unweigerlich, dass die Code-Abdeckungsstatistik gegenüber dem Produktivcode anfangs niedrig ausfallen wird, da dies noch nie zuvor unser Schwerpunkt war, aber wir werden dies im Laufe der Zeit schrittweise erhöhen.
Unser derzeitiger Hauptschwerpunkt liegt auf den Aufgaben zur Beseitigung der Parsec-Verwendung. Eine solche Aufgabe, die derzeit den PR-Überprüfungsprozess durchläuft, ist [sicherzustellen, dass Mutationen zu SharedState von der Sektion genehmigt werden] (https://github.com/maidsafe/routing/pull/2155). Wir haben auch mit der Arbeit an der Überarbeitung des Prozesses zur Förderung des Knotenpunkts begonnen, so dass er weniger Parsec enthält. Das ist eine Voraussetzung für eine weitere wichtige Aufgabe, nämlich die nachrichtenbasierte Abstimmung - damit werden wir die derzeitige Parsec-basierte Abstimmung, die uns natürlich einen Konsens und eine starke Ordnung gegeben hat, durch einen viel einfacheren Mechanismus ersetzen, der uns einen Konsens ohne Ordnung gibt, was unserer Meinung nach ausreicht.
xor-name
Nachdem wir letzte Woche die erste stabile Version unserer Xor-Name-Repository’s veröffentlicht hatten, haben wir diese Woche darauf aufbauend mehrere Repositories umgestaltet, um das neue Xor-Name-Repository zu verwenden.
So wie es jetzt aussieht, haben wir den jetzt redundanten XorName-Typ und die damit verbundenen Funktionalitäten aus safe-nd , safe-client-libs und safe-api offengelegt. Um den Code in diesen Repositories zu rationalisieren, sind wir dabei, XorName aus jedem dieser Repositories zu entfernen und stattdessen das neue dedizierte XorName-Repository’s zu verwenden. PR-Entwürfe, die diesen Wechsel in jedem dieser Repositories vornehmen, können hier , hier und hier eingesehen werden.
Wir warten nun auf die Veröffentlichung einer externen Repository-Version, die uns die weitere Bearbeitung freigibt. Sobald diese verfügbar ist, werden wir die Refactoring-Arbeiten mit safe-vault und anderen Repositorien fortsetzen.