Safe Network Entwickler Update đŸ‡©đŸ‡Ș 15. Juni 2023

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 :heart:, und eine besondere ErwĂ€hnung an @shu fĂŒr seine fantastische Dashboard-Arbeit :trophy:.

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!