SAFE Network Entwickler Update - 18. Juni 2020

Zusammenfassung

Hier sind einige der wichtigsten Dinge, die seit dem letzten Entwickler-Update hervorzuheben sind: letztes Entwickler-Update(Englisch):

  • Vielen Dank an alle, die von zu Hause aus mit IGD testnet zu den Vaults der letzten Woche beigetragen haben!
  • Wir haben die Ergebnisse des Testnet untersucht und arbeiten nun an Bereichen, in denen Verbesserungsbedarf festgestellt wurde.
  • Es gibt ein von der Community betriebenes Testnet für diejenigen, die sich beteiligen möchten - siehe Forumsbeitrag hier.
  • Der safe-cli symlink PR wird jetzt getestet und überprüft.
  • Der Fortschritt des CRDT geht mit dem Tempo weiter, wobei die zugehörigen PRs in safe-nd und safe-vault zusammengeführt werden.
  • Es wurde eine GitHub issue erstellt, in der alle Schritte aufgelistet sind, die unserer Meinung nach erforderlich sind, um Parsec aus dem Routing zu entfernen.

Vaults Phase 2

Projektplan

Wir möchten allen für ihre Teilnahme am Testnet der vergangenen Woche danken. Obwohl das Testnetz auf Benutzer mit IGD-unterstützten Routern beschränkt war, hatten wir eine gute Resonanz mit Knoten, die 59 Mal der Sektion beigetreten sind. Mit 2214 unveränderlichen Datenblöcken, die in 107 Datei-Containern gespeichert waren, gab es auch eine gute Beteiligung von Kunden. Ein wichtiger Teil des Tests bestand darin, die Datenwiederherstellung zu demonstrieren, wenn Knoten das Netzwerk verlassen, und dies zeigte gute Ergebnisse. Das Netzwerk führte 4193 erfolgreiche Datenwiederherstellungsoperationen aus.

Das Testnet half uns, auch einige reale Netzwerkszenarien zu verstehen. Bei der Implementierung wurden einige dieser Szenarien bereits berücksichtigt, und das Testnetz half uns, einige Bereiche zu identifizieren, in denen wir bereits mit der Arbeit begonnen haben. Ein interessantes Beispiel sind die vorzeitigen Antworten. Das Netzwerk braucht nur eine beschlussfähige Anzahl von Ältesten, um einen Antrag zu genehmigen und zu bearbeiten. Nach der Bearbeitung wird die Antwort zur Bestätigung an alle Ältesten zurückgeschickt. Während einige dieser Ältesten über die Anfrage informiert sind, wissen andere vielleicht nichts davon. In solchen Fällen wird die Antwort zwischengespeichert, bis der Älteste schließlich die Anfrage erhält. Wir haben festgestellt, dass die Antwort manchmal zweimal zurückgeschickt wurde. Die erste wurde bearbeitet und die zweite wurde zwischengespeichert, um auf eine Anfrage zu warten, die nie wieder eintreffen würde.

Zwar ist hier die doppelte Antwort der Schuldige, aber wir haben auch festgestellt, dass die Zwischenspeicherung der Antworten für solche Szenarien möglicherweise nicht die beste Wahl ist. Der Älteste kann überprüfen, ob die Antwort eine Anfrage enthält, die von der Sektion validiert wurde, und sie entsprechend bearbeiten. Dies würde sowohl die Zeit- als auch die Speichereffizienz verbessern. Wir reduzieren auch die Verantwortung der Ältesten, sich um die Brockenverdoppelung zu kümmern. Stattdessen holt und speichert der neue Besitzer des Chunks eine neue Kopie des Chunks, was wiederum die Notwendigkeit der Signaturanhäufung für Nachrichten im Zusammenhang mit der Datenwiederherstellung überflüssig macht.

Wir werden diese Funktionen (und mehr) in die kommenden Testnetzen aufnehmen. In der Zwischenzeit seid ihr herzlich eingeladen, dem von der Communty betriebenen Testnetz beizutreten. Hut ab vor @tfa, @Traktion, @neo und allen anderen, die daran mitgewirkt haben. Besuche diesen Beitrag, um an der Aktion teilzunehmen.

SAFE API

Projektplan

Der Symlink-Support läuft diese Woche aus. Die Arbeit an den Testfällen, der Dokumentation und der Behebung einiger pfadbezogener Probleme unter Windows, die bei Tests aufgetreten sind, wurde fortgesetzt. Ein großer pull request wurde am Mittwoch angestoßen und wartet auf abschließende Tests und Überprüfung, bevor er zusammengeführt werden kann.

CRDT

In der vergangenen Woche wurden gute Fortschritte erzielt, um das Sequenz-CRDT für eine erste Testnet-Iteration bereit zu machen. Wir haben einen PR in der Safe-nd-Repository, in der dieser neue Datentyp definiert ist und in der sich die CRDT-Kernlogik befindet, fertiggestellt und bereits zusammengeführt. Die AppendOnlyData wurde ebenfalls aus ihr entfernt, da der Datentyp Sequence sie ersetzt.

Wir konnten auch den PR für das safe-vault Repository abschließen, die heute genehmigt und zusammengeführt wurde. Das bedeutet, dass wir jetzt den Code im Vault bereit haben, um Anfragen zur Speicherung und Mutation von Sequenz-CRDT-Inhalten anzunehmen. Einige der letzten Dinge, an denen wir gearbeitet haben, war unter anderem die Genehmigung und der Eigentümer der Sequenz CRDTs sowie die Erstellung einiger grundlegender Integrationstests für eine erste Iteration und/oder ein Testnetz. Die Änderungen, die erforderlich sind, um die Unterstützung von AppendOnlyData in safe-vault zu entfernen, stehen jetzt in einem separaten PR zur Prüfung bereit.

Wir versuchen nun, die PRs fertigzustellen, die zur Unterstützung dieses neuen Sequenzdatentyps auf der Client-Seite erforderlich sind, was bedeutet, dass die Safe-Client-Libs und Safe-APi-Repository APIs offenlegen, um Anfragen zum Speichern und Mutieren von Sequenzinhalten senden zu können. Die PRs sind bereits funktionsfähig, es sind nur noch einige abschließende Bereinigungen und das Hinzufügen einiger automatisierter Tests erforderlich, bevor ein erstes Testnetz mit diesem CRDT-Datentyp bereit ist.

Transfers

SAFE Transfers Projektplan
SAFE Client Libs Projektplan
SAFE Vault Projektplan

Wir haben hart an der Integration der Transferakteure in die SAFE Client Libs and Vaults gearbeitet. Ersterer hat jetzt unsere Tests mit einigen Platzhalter-APIs bestanden, und wir arbeiten jetzt an der Integration mit unserem aktualisierten Tresorcode. Dazu mussten einige neue Datenflüsse und Nachrichten erstellt werden. Wir haben jetzt einige SimulatedPayout-Anforderungstypen für das Mock-up, um Konten mit Test-Safecoins aufzuladen, als ob sie eine landwirtschaftliche Auszahlung erhalten hätten. Dies ist eine kleine, aber hilfreiche Änderung, die uns näher bringt, wie das Netzwerk letztendlich funktionieren wird.

Die AT2-Implementierung selbst macht einige Anpassungen unseres Ablaufs für verschiedene andere Operationen erforderlich. Vor allem müssen CreateLoginPacketFor-Anfragen (die es einem Konto erlauben, Login-Daten für eine andere Person hochzuladen und mit etwas Geld vorzuladen) zwei vorvalidierte Transaktionen effektiv abwickeln: eine für die Kosten eines Put und eine weitere für die Überweisung von Geld auf das neue Konto. Glücklicherweise haben wir die Grundlage für die Transaktionsvalidierung geschaffen, so dass es keine großen Erschütterungen geben dürfte, diese in den Kundenfluss zu integrieren. (Und das Schöne daran ist, dass wir die Überweisungsbündelung - wenn auch in geringem Umfang - effektiv einrichten, während die Verantwortung für die Koordinierung dieser Arbeit weiterhin beim Kunden liegt.)

Routing

Projektplan

Die gemeinsame staatliche Unterschriften-PR wurde schließlich angesprochen und wird derzeit überprüft. Die DKG-Ersatz-PR 1 ist ebenfalls fast fertig, abgesehen von einigen Mängeln, die erst noch bereinigt werden müssen. Wir haben einen GitHub issue erstellt, in dem alle Schritte aufgeführt sind, die unserer Meinung nach erforderlich sind, um Parsec aus dem Routing zu entfernen. Es scheint eine Menge Arbeit zu sein, aber wir glauben, dass das meiste davon recht unkompliziert ist. Der gesamte Aufwand lässt sich grob so zusammenfassen:

Wir werden die parsec-lose Abstimmung auf der Grundlage von Nachrichten und BLS-Signaturen einführen. Das wird uns Konsens / Autorität geben, aber keine totale Ordnung. Wir glauben, dass dies für unsere Bedürfnisse ausreichend ist. Der daraus resultierende Mechanismus wird viel einfacher und leistungsfähiger sein als Parsec.
Wir konvertieren alle Datenstrukturen, die zur Speicherung von abschnittsgenehmigten Informationen verwendet werden, in CRDTs (Conflict-free Replicated DataTypes), was bedeutet, dass alle Mutationen in diesen Strukturen kommutativ, assoziativ und idempotent sein werden. Vereinfacht ausgedrückt bedeutet das, dass sie widerstandsfähig gegen Nachrichtenneuordnung und -duplikation sind. Dies wird uns letztendlich Konsistenz zu sehr geringen Kosten im Vergleich zu Parsec ermöglichen.
Außerdem wenden wir eine Mutation nur dann an, wenn sie durch das oben erwähnte Abstimmungsverfahren genehmigt wurde. Das macht uns widerstandsfähig gegen verschiedene Arten von Fehlschlägen und Angriffen, denn jede Mutation muss vom Quorum der Sektionsältesten genehmigt werden.

Nützliche Links

2 Like