Safe Network Entwickler Update 🇩🇪 26. Mai 2022

Dies ist eine maschinelle Ăśbersetzung. Das Original in Englisch ist hier: 26 May 2022

Unser Hauptziel bei Safe Network ist die Datenpermanenz. Wir speichern Kopien von Daten auf Geräten, die sich statistisch gesehen wahrscheinlich nicht in derselben Region befinden, falls es beispielsweise zu einem massiven Stromausfall oder einer von der Regierung verordneten Internetsperrung kommt. Zu diesem Zweck gilt: Je mehr Kopien, desto besser, aber das stellt Anforderungen an den Speicherplatz und insbesondere an die Netzwerkbandbreite. Diese Woche betrachten wir einen Ansatz zur Lösung dieses Problems, der mehr Redundanz mit weniger Datenfluss ermöglichen sollte.

Allgemeiner Fortschritt

@Anselme hat einen Konsensfehler behoben, indem Anti-Entropie sowohl fĂĽr die Ăśbergabe als auch fĂĽr Generationen implementiert wurde. Umfassendere Join-Wiederholungen (bei denen wir sicherstellen, dass wir uns im aktuellen Abschnittsstatus befinden) wurden ebenfalls zusammengefĂĽhrt :muscle: .

@Chriso vertieft sich in die DBC-Implementierung und hat bereits alle CLI-Ă„nderungen abgeschlossen, um einen DBC an einen neuen EigentĂĽmer zu ĂĽbergeben. Er richtet seine Aufmerksamkeit nun auf die sn_api-Seite, um den Change-DBC-Besitzer zuzuweisen.

Wir können auch Fortschritte an der Beobachtbarkeitsfront melden, wobei @yogesh mit den Traceroute-Nachrichten gute Fortschritte macht und sicherstellt, dass alle Nachrichtenflüsse (Datei und Register) eine Traceroute-Antwort von den Erwachsenen an den Client zurückerhalten und in den Tests protokolliert werden.

Und @davidrusu hat das Wort verbreitet und an einem anderen CompSci-Treffen in Toronto teilgenommen, um über Tree CRDTs zu sprechen. „Rundum eine großartige Diskussion“, berichtet er, und ein großartiger Ort, um Interessenten für Safe Labs zu gewinnen.

In der weiteren sicheren Welt wird das laufende Gemeinschaftsprojekt zur Unterstützung von MaidSafeCoin im Rahmen des ERC20-Protokolls unvermindert fortgesetzt, und wir freuen uns, Ihnen mitteilen zu können, dass diese Bemühungen weiterhin Früchte tragen! Neben Uniswap ist eMAID nun also auch für den Handel auf P2PB2B offen!

Du kannst den engagierten Community-Mitgliedern wie @Sotros25 und @Mightyfool danken, die es sich zur Aufgabe gemacht haben, dieses Thema kontinuierlich voranzutreiben :clap:

DatenĂĽbertragung optimieren

Wenn jemand eine GET-Anfrage stellt, startet dieser Kick eine Reihe von Prozessen. Zuerst wird die Anfrage an die Ältesten weitergeleitet, in welcher Sektion der Chunk gespeichert ist. Die Ältesten berechnen dann, welche vier Erwachsenen den Chunk speichern – die vier XOR-am nächsten an der Adresse des Chunks – und jeder dieser Erwachsenen gibt seine Kopie des Chunks an die Ältesten zurück, die sie dann an den anfordernden Kunden zurücksenden.

Dies bietet Redundanz, es gibt immer vier Erwachsene mit einer Kopie des Chunks und gibt uns auch eine Möglichkeit, die Leistung zu überwachen. Wenn ein Erwachsener deutlich langsamer oder weniger zuverlässig ist, kann er herabgestuft werden. Aber es kommt mit einem Preisschild.

Wenn der Klient alle sieben Sektionsältesten kontaktiert und um einen 1-MB-Block „A“ bittet, und jeder Älteste seinerseits Block A von den vier Erwachsenen anfordert, die ihn besitzen, und ihn an den Klienten zurücksendet, dann sind das möglicherweise 28 MB (4x7), die über das Netzwerk übertragen werden eine einzelne 1 MB GET-Anfrage.

Derzeit verwenden wir ein Halfway-House-System, bei dem der Client zufällig drei Älteste kontaktiert und diese Ältesten die vier Erwachsenen kontaktieren, die Chunk A halten - also haben wir möglicherweise 12 MB (3x4) Daten, die für eine 1 MB-Anfrage über das Netzwerk fließen - besser, aber immer noch nicht toll. Und die Reduzierung der Kontakte auf drei Älteste hat ihren Preis: Wenn wir nur drei Älteste haben, die mit den Erwachsenen interagieren, haben wir keine Supermajorität mehr, um zu entscheiden, ob einer der Erwachsenen dysfunktional ist, was die Verfolgung von Dysfunktionen komplexer macht.

Eine Lösung, die wir uns derzeit ansehen, sind Informationsverteilungsalgorithmen (IDA, auch bekannt als Erasure Coding). Dies könnte uns helfen, das Volumen der Datenübertragung pro GET erheblich zu reduzieren, indem Erwachsene einen Anteil der Daten an die Ältesten weitergeben, anstatt das Ganze. Die Ältesten geben diese Datenanteile dann an den Kunden zurück, der sie wieder zusammensetzt und, voila, Chunk A wird neu erstellt. Potenziell könnte dies die Flüsse auf einem GET auf nur 1,4 MB für einen 1-MB-Chunk reduzieren.

Wie funktioniert es? Das Wichtigste zuerst: Wir schlagen nicht vor, die Replikation durch eine IDA zu ersetzen. Einige Projekte tun dies (z. B. Solana), aber für uns gibt es zu viele Kompromisse. Wenn also ein Erwachsener offline geht, werden seine Daten genau wie jetzt vollständig auf einen anderen Erwachsenen repliziert. Die Änderung besteht darin, dass Erwachsene mit einem IDA Block A in sieben Teile aufteilen und auf Anfrage nur einen Teil an die Ältesten zurückgeben können, anstatt den ganzen Block, was bedeutet, dass viel weniger Daten ausgetauscht werden.

Sobald er fĂĽnf der sieben Teile gesammelt hat, kann der Kunde Chunk A wieder zusammensetzen.

Diese Fünf-von-Sieben-Zahl hat zweifellos ein paar mentale Glühbirnen eingeschaltet :bulb:, weil es derselbe Schwellenwert ist, den wir für den BLS-Konsens verwenden, aber IDA ist ein anderes Biest als die Schwellenwertkryptographie, die eher zur Optimierung der Datenspeicherung und -übertragung entwickelt wurde als geheimes Teilen. Falls Sie sich fragen, woher die zusätzlichen 0,4 kommen (das Übertragen eines 1-MB-Blöckes mit IDA erfordert 1,4 MB Datenfluss), ist dies ein unvermeidbarer Overhead aufgrund der Funktionsweise des Algorithmus.

Also weniger Stress für das Netzwerk und auch für den Klienten, und natürlich sind jetzt alle sieben Ältesten in Kontakt mit den Erwachsenen, was den Konsens über Funktionsstörungen viel einfacher macht.

Auch mit dieser Architektur sollen weitere Optimierungen möglich sein. Aufgrund der jüngsten Mitgliedschaftsänderungen wissen wir jetzt, welcher Erwachsene der drei, der Chunk A hält, tatsächlich am nächsten ist. Anstatt nach Stück A zu fragen, kann der Klient direkt nach dem ersten Stück A [0] fragen, und die Ältesten gehen direkt zum nächsten Erwachsenen; beim zweiten Stück A[1] fragen die Ältesten den nächsten Erwachsenen und so weiter. Alle Fehler werden einfach bei einem anderen Erwachsenen wiederholt. Dies ist effizienter und bedeutet, dass wir möglicherweise die Anzahl der Replikate – Erwachsene, die Chunk A halten – ohne signifikante zusätzliche Belastung des Netzwerks erhöhen können, mit offensichtlichen Gewinnen für die Datenredundanz.


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!