Safe Network Entwickler Update đŸ‡©đŸ‡Ș 27. Juli 2023

Dies ist eine maschinelle Übersetzung. Das Original in Englisch ist hier: Update 27 July, 2023

Wie Sie sicher bemerkt haben, ist ein neues Testnetz unter uns. Es ist Zeit, einzusteigen, falls Sie es noch nicht getan haben! Laden Sie den Safe herunter, laden Sie einige Dateien hoch und sehen Sie, wie die Zahlung fĂŒr jeden Upload automatisch von Ihrem Geldbeutel abgezogen wird. Im Moment ist das alles natĂŒrlich Monopoly-Geld, aber es ist toll, es in Aktion zu sehen. Teilen Sie uns alle Fehler mit, die Ihnen im Thread auffallen könnten.

Die Bezahlung von Daten ist ein großer Fortschritt, der durch die Tatsache ermöglicht wird, dass das Netzwerk mittlerweile ziemlich gut funktioniert und stabil ist (Touch Wood). Der Arbeitsspeicher pro Knoten bewegt sich im Bereich von 50 bis 60 MB, wĂ€hrend er zuvor bei Hunderten von MB lag. Aber es gibt noch einiges auszubĂŒgeln. Vielen Dank fĂŒr das bisherige Feedback und machen Sie weiter so. Der nĂ€chste Schritt besteht darin, den grundlegenden Zahlungsfluss zu Knoten und eine Art einfachen Preismechanismus zu testen.

Leider gibt es noch kein solides NAT-Traversal, aber diejenigen, die ĂŒber Cloud-Knoten verfĂŒgen oder mit der Portweiterleitung zufrieden sind, können versuchen, ein oder zwei Knoten zu betreiben. Lassen Sie uns wissen, wie es weitergeht.

Da wir uns nun in einer stabilen Lage befinden, werden wir auch damit beginnen, die Funktionsweise des Netzwerks auseinanderzunehmen. Diese Woche wird @roland erklÀren, was bei der Datenreplikation passiert.

Allgemeiner Fortschritt

@Chriso arbeitet an einer zentralen Protokollierung, um die aggregierte Analyse von Fehlern nach Testnetzen zu erleichtern. Letztendlich hoffen wir, den Community-Mitgliedern dies in Echtzeit zu ermöglichen, aber wir halten es vorerst einfach.

Thomas Eizinger und Max Inden vom rust-libp2p-Team haben einen Fix von @bzee zusammengefĂŒhrt, bei dem sich weiterhin neue Knoten einwĂ€hlten (Nachricht ) andere Knoten, auch nachdem diese mit dem Netzwerk verbunden sind. @bzee steht in regelmĂ€ĂŸigem Kontakt mit diesem Team, das sagt, dass AutoNAT und Hole Punching „bald“ funktionieren sollten. Einer der Betreuer hat eine vorlĂ€ufige Lösung, die das Problem der Port-Wiederverwendung beheben wĂŒrde: AutoNAT muss Ports bei ausgehenden Tests nicht wiederverwenden. Ich drĂŒcke die Daumen fĂŒr baldige Fortschritte.

@aed900 beschĂ€ftigt sich mit der Verbesserung von UX rund um nicht verbundene Knoten Umgang mit ZeitĂŒberschreitungen.

@bochaco entwickelt eine Funktion zum gleichzeitigen Abrufen aller Ausgaben fĂŒr einen Zahlungsnachweis weiter, um den DBC-Verifizierungsprozess zu beschleunigen, sowie einen Ansatz zur Erstellung von Registern inhaltsadressierbar.

@qi_ma hat einen subtilen Fehler mit DBCs behoben. Wenn ein Kunde einen DBC ausgeben möchte, um Daten hochzuladen, prĂŒfen die Knoten, ob an der entsprechenden Adresse ein Ausgabennachweis vorhanden ist (um doppelte Ausgaben zu verhindern). Der Knoten, der diese Adresse hĂ€lt, antwortet auch aktiv auf GET-Anfragen, was seine Antwort an die anfragenden Knoten verzögern kann, sodass diese denken, es gĂ€be dort keinen verbrauchten Beweis. Dies ist ein Ă€ußerst seltenes Ereignis, aber wir haben es in freier Wildbahn gesehen und es wĂŒrde doppelte Ausgaben ermöglichen. Wir patchen es, indem wir von 5 Knoten verlangen, dass sie ein GET sehen, bevor darauf reagiert wird.

Und @joshuef befasst sich mit dynamischen Zahlungen und Preisen, einschließlich der Frage des Kunden nach Knoten in der NĂ€he des Zahlungsstandorts wie hoch ihre Speicherkosten sind und der damit verbundenen Aktualisierung Bezahlung fĂŒr Uploads. Und auch eine grundlegende Ladenkostenberechnung basierend auf der KapazitĂ€t des Plattenladens.

Datenreplikation

Die Datenreplikation ist ein Mechanismus, der es Knoten ermöglicht, Daten an neue Peers zu verteilen, wenn sie beitreten, und Daten von einem „toten Peer“ an die anderen Knoten zu ĂŒbertragen. Dadurch wird sichergestellt, dass Daten im Netzwerk verfĂŒgbar bleiben, auch wenn Knoten hinzukommen oder gehen. Der von „Libp2p“ verwendete Ansatz beruhte jedoch darauf, dass ein Knoten das Netzwerk regelmĂ€ĂŸig mit all seinen Daten ĂŒberflutete. Dies brachte einige Nachteile mit sich, darunter starker Netzwerkverkehr und eine hohe Speichernutzung zwischen den Knoten. DarĂŒber hinaus erhielten neue Knoten nicht die Daten, fĂŒr die sie verantwortlich waren, und die Daten der toten Knoten wurden nicht rechtzeitig repliziert. Um diese Probleme zu beheben, haben wir einen benutzerdefinierten Replikationsprozess implementiert, der jedes Mal ausgelöst wird, wenn sich in der geschlossenen Gruppe eines Knotens etwas Ă€ndert.

Bevor wir uns mit dem Replikationsprozess befassen, wollen wir kurz besprechen, wie Daten im Netzwerk gespeichert werden. Das Netzwerk funktioniert wie eine Distributed Hash Table (DHT) und ermöglicht den Datenabruf mithilfe eindeutiger SchlĂŒssel. Wenn jemand eine Datei im Netzwerk speichern möchte, bezahlt er die Datei zunĂ€chst mit seinem DBC und lĂ€dt sie dann in das Netzwerk hoch. Diese Daten (DBC, Chunk oder Register) werden in eine Reihe von Nullen und Einsen umgewandelt und in etwas abgelegt, das als „Datensatz“ bezeichnet wird. Obwohl die DatensĂ€tze unendlich groß sein können, sind die Knoten auf die Verarbeitung von DatensĂ€tzen mit einer GrĂ¶ĂŸe von 1 MB beschrĂ€nkt. Jeder „Datensatz“ hat seinen eigenen „SchlĂŒssel“, der der „XorName“ der Daten ist, die er speichert.

Um den „Datensatz“, der sowohl die Daten als auch den SchlĂŒssel enthĂ€lt, im Netzwerk zu speichern, berechnet der Client die Xor-Distanz zwischen dem „DatensatzschlĂŒssel“ und seinen Knoten in seinem RT (Routi).

ng Table) und sortiert die Peers nach ihrer NĂ€he zum „SchlĂŒssel“. Anschließend fordert der Client diese Knoten auf, „die Peers zu berechnen und zu teilen, von denen sie glauben, dass sie dem „SchlĂŒssel“ am nĂ€chsten sind“. Anschließend sortiert der Client die Antworten und identifiziert Knoten, die noch nĂ€her am „SchlĂŒssel“ liegen. Dieser Vorgang wird fortgesetzt, bis die acht verantwortlichen Knoten fĂŒr den Datensatz gefunden wurden und der Datensatz bei ihnen gespeichert wird. „Libp2p“ abstrahiert diesen komplexen Prozess und ermöglicht es uns, unser Netzwerk darauf aufzubauen.

Sobald ein „Datensatz“ unter den nĂ€chstgelegenen Peers im Netzwerk gespeichert wurde, möchten wir mindestens acht Kopien des Datensatzes behalten, auch wenn die Knoten, auf denen sie gespeichert sind, offline gehen. Unser aktueller Replikationsprozess funktioniert wie folgt: Jeder Knoten verfolgt die Peers in seiner NĂ€he, d. h. seine enge Gruppe. Immer wenn ein Peer zum RT hinzugefĂŒgt oder daraus entfernt wird, prĂŒfen wir, ob dies Auswirkungen auf unsere enge Gruppe hat. Wenn es eine Änderung gibt, senden wir die „Record Keys“ an unsere engsten Gruppenkollegen, von denen wir glauben, dass sie diesen Rekord halten sollten. Wenn ein Peer beim Empfang der SchlĂŒsselliste nicht ĂŒber den entsprechenden Datensatz verfĂŒgt, fordert er ihn von dem Knoten an, der ursprĂŒnglich den „SchlĂŒssel“ gesendet hat. Falls es den Datensatz nicht von dem Knoten empfangen konnte, der ursprĂŒnglich den SchlĂŒssel gesendet hat, fragt es das Netzwerk nach den Daten.

Obwohl weitere Optimierungen möglich sind, ist der aktuelle Replikationsansatz deutlich weniger ressourcenintensiv als der „Libp2p“-Ansatz und verhindert effektiv Datenverluste.


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!