Dies ist eine maschinelle Übersetzung. Das Original in Englisch ist hier: Update 15 June, 2023
Als Erstes muss ich sagen, dass wir mit der Entwicklung von ReplicationNet sehr zufrieden sind. Es war ein bisschen ein Wagnis, so viele Knoten auf den Tisch zu werfen – unser bisher mit Abstand größtes Testnetz – und wir hatten mit einigen großen Schwankungen gerechnet, aber es hat alles, was wir ihm entgegensetzen konnten, problemlos und klaglos hinnehmen müssen, bis volle Knoten aufgehört haben zu spielen . Am ermutigendsten ist, dass diese Stabilität trotz einiger Messaging-Fehler bei der Datenreplikation erreicht wurde, von denen man hätte ausgehen können, dass sie zu einem Ausfall führen würden. Stattdessen schlug es sie weg wie eine Fliege. Herzlichen Dank noch einmal an alle, die teilgenommen haben 
, und eine besondere Erwähnung an @shu für seine fantastische Dashboard-Arbeit 
.
ReplicationNet – Erkenntnisse und Maßnahmen
Nachdem wir die Protokolle durchgesehen haben, sowohl die Protokolle, die uns freundlicherweise von der Community zur Verfügung gestellt wurden, als auch unsere eigenen, können wir Folgendes berichten.
-
Das langsam zunehmende Speicherproblem ist mit ziemlicher Sicherheit darauf zurückzuführen, dass die Knoten ihre Kapazitätsgrenze erreichen. Wir sehen dieses Verhalten erst, wenn eine Reihe von Knoten voll sind (in diesem Fall 1024 Blöcke). Sobald das Netzwerk betriebsbereit ist, sollten wir dies nicht mehr sehen, da neue Knoten einen Anreiz erhalten, sich anzuschließen.
-
Probleme wegen unzureichendem Arbeitsspeicher scheinen darauf zurückzuführen zu sein, dass zu viele Daten im Cache gespeichert werden, wenn der Knoten seine Kapazitätsgrenze erreicht. (Und in diesem Fall haben wir anscheinend zu viele Knoten auf einer zu kleinen Maschine). Das ist per se kein Fehler, libp2p sollte diesen Cache auflösen und Daten würden gespeichert, wenn mehr Knoten beitreten.
-
Wir haben einen Fehler identifiziert und beseitigt, durch den die Datenreplikation zu Verbindungsabbrüchen und folglich zu vielen verworfenen Nachrichten rund um die Replikation führte. Dies wird wahrscheinlich zum Untergang führen und ist ein Beweis für die grundlegende Stabilität des Netzwerks, dass es so geringe Auswirkungen hatte.
-
Eine weitere Fehlerbehebung betraf die Fehler „Outbound Failure“.
-
Die Datenverteilung über die Knoten ist ziemlich gleichmäßig. Auch das sind großartige Neuigkeiten, denn wir können den genutzten Prozentsatz wie geplant als Auslöser für die Prämienpreisgestaltung nutzen. Das Problem, dass einige Knoten nicht voll sind, ist ein Fehler, der wahrscheinlich damit zu tun hat, dass neue Knoten sich nicht stark genug in die Routing-Tabellen anderer hochstufen.
-
Es gibt einige Anomalien in den Protokollen, bei denen die gespeicherten Metriken für Put-Anfragen und Chunks nicht übereinstimmen. Wir müssen daran arbeiten, diese zu klären.
-
Um Benutzern mit geringerer Bandbreite mehr Kontrolle zu geben, haben wir dem Client die Möglichkeit hinzugefügt, die Zeitüberschreitungsdauer für Anfragen und Antworten festzulegen aus dem Netzwerk . Wir haben außerdem die Standard-Timeout-Dauer von 10 auf 30 Sekunden erhöht.
-
Wir denken jetzt über Zahlungsflüsse und Belohnungen für die verschiedenen Szenarien nach: neue Daten, Replikation von Daten und erneute Veröffentlichung von Daten (wobei gültige Daten aus irgendeinem Grund verloren gegangen sind).
Das nächste Testnetz wird uns dabei helfen, diese Annahmen und Korrekturen zu testen und einige Workarounds zur Benutzererfahrung zu validieren.
Allgemeiner Fortschritt
Alle Augen sind jetzt auf DBCs gerichtet, wobei @bochaco und @Anselme daran arbeiten, die Überprüfung des Zahlungsprozesses für die Speicherung von Chunks zu sichern, einschließlich der Überprüfung der Eltern der Die Zahlungs-DBC werden ausgegeben und es wird sichergestellt, dass ihre „Grund“-Hash-Übereinstimmungen mit den für jeden Block bereitgestellten Zahlungsnachweisinformationen übereinstimmen. Anselme hat einen Fehler behoben, durch den Faucet und Wallet DBCs nicht als verbraucht markierten. Es stellte sich heraus, dass dies mit der synchronen Aktivität der Prüfknoten zu tun hatte, die eine Lese-/Schreibsperre verursachte, wohingegen wir eine asynchrone Aktivität benötigen.
Ebenso beseitigt @roland einen Deadlock bei PUT- und GET-Vorgängen, um sicherzustellen, dass diese gleichzeitig ausgeführt und bezahlt werden können. Parallelisierung ist das A und O. Er stellt außerdem sicher, dass unsere Datenvalidierungen unabhängig davon erfolgen, wann die Daten in einen Knoten eingehen, und verhindert so ein „Sideloading“ von Daten über die Protokolle „libp2p“/„kad“ (was im Wesentlichen freie Daten ermöglicht hätte).
@bzee bastelt immer noch an den Innereien von „libp2p“ und optimiert derzeit die anfängliche Anwahl der Bootstrap-Peers.
@Joshuef und @qi_ma haben hauptsächlich die Ergebnisse des letzten Testnetzes durchgearbeitet und im Laufe der Zeit Korrekturen vorgenommen.
@chriso hat hart daran gearbeitet, „safeup“ zu aktualisieren, mehr dazu bald.
Und @aed900 hat ein Testnetz-Starttool entwickelt, um die Erstellung von Testnetzen auf AWS und Digital Ocean zu automatisieren.
Vorwärts!
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!