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!