Safe Network Entwickler Update 🇩🇪 10. Februar 2022

Dies ist eine maschinelle Ăśbersetzung. Das Original in Englisch ist hier: Update 10 February, 2022

Wie die meisten hier zweifellos wissen, sind Erwachsene Knotenpunkte, die Daten speichern und bei Bedarf weitergeben. Was aber, wenn sie anfangen, sich kindisch zu verhalten, sich weigern, Daten zu speichern oder preiszugeben, oder zumindest langsamer als erwartet? Zum Wohle des Netzwerks müssen wir solche eigensinnigen Knoten degradieren oder auswerfen, aber bevor wir dies tun, müssen wir die Daten, die sie halten, neu verteilen. Wir müssen auch aussagekräftige Fehlermeldungen für Clients und andere Knoten bereitstellen, die versuchen, Daten zu speichern, wenn dies fehlschlägt. Damit beschäftigen wir uns diese Woche.

Allgemeiner Fortschritt

@bochaco hat an der Safe Shell gearbeitet. Wenn Sie „safe“ in die Konsole eingeben (natürlich sobald „safe_network“ installiert ist), gelangen Sie in die Shell, was bedeutet, dass Sie danach nicht jedes Mal „safe“ eingeben müssen. Bei all den letzten CLI-Updates ist dieser Aspekt etwas zurückgeblieben, also hat er das richtig gestellt. Sowie einige Aufräumarbeiten und Überarbeitungen im Node-Code in Vorbereitung auf die bevorstehenden Mitgliedschaftsänderungen.

In den DBC-Labs arbeitet @danda an der Integration von Ring CT in das Netzwerk, einschließlich der benutzerfreundlicheren Gestaltung von DBCs für die Verwendung mit zwei Arten von Schlüsseln: einem langlebigen Basisbesitzerschlüssel für die Interaktion mit Dritten, z. B. für Spenden , und einen abgeleiteten Schlüssel zur einmaligen Verwendung für die Interaktion mit Mints und Spendedbook. Er arbeitet auch an Testfunktionen, die zum Debuggen und Optimieren ein- oder ausgeschaltet werden können, und hat die Anzahl der Aufrufe reduziert, die zum Durchlaufen des ausgegebenen Buchs erforderlich sind.

In Bezug auf Datenreplikationspflichten hat @yogesh Fortschritte bei einem Pull-Modell gemacht, bei dem Erwachsenen mitgeteilt wird, welche Daten sie speichern sollten, und automatisch Daten aus dem Netzwerk abrufen, um sicherzustellen, dass die richtige Anzahl von Kopien fĂĽr Redundanz gespeichert wird. Mehr dazu weiter unten.

Und @joshuef und @Qi_ma haben sich mit Client-Verbindungsproblemen befasst, die vom Playground und dem Komnet aufgeworfen wurden. Wir vielleicht haben einen CPU-intensiven Fehler behoben (zumindest können wir ihn im Moment nicht mehr reproduzieren), also werden wir versuchen, dies in einem bevorstehenden Playground zu überprüfen.

Präventive Datenreplikation und Fehler durch Erwachsene

Richtig funktionierende Erwachsene sind das Rückgrat des Netzwerks, und es ist zwingend erforderlich, dass es ersetzt wird und die Daten, die es enthält, reibungslos verschoben werden, wenn ein Erwachsener beginnt, sich schlecht zu benehmen. Dies wird als preemptive Datenreplikation bezeichnet und wird in PR #976 ausführlich beschrieben.

Lebendigkeitskontrollen

Älteste müssen sicherstellen, dass Erwachsene richtig auftreten. Sie führen regelmäßige Lebendigkeitsprüfungen durch, bei denen die Leistung eines Knotens mit seinen 3 nächsten Nachbarn verglichen wird. Wenn die Anzahl der anstehenden Operationen an einem Knoten fünfmal höher ist als an seinen Nachbarn, wird er herabgestuft und seine Daten neu verteilt. Um sich auf diese Eventualität vorzubereiten, beginnt die vorbeugende Replikation, sobald die Anzahl der ausstehenden Operationen eines Knotens 2,5-mal höher ist als die seiner Nachbarn (diese Parameter werden während des Tests optimiert), wobei die Ältesten diese Replikation derzeit initiieren.

Wenn es in einem Abschnitt Abwanderungen gibt (Knoten verlassen und beitreten), mĂĽssen wir sicherstellen, dass Daten repliziert und an die neu heraufgestuften Knoten verteilt werden. Wenn ein Erwachsener satt ist, muss er den Ă„ltesten auch sagen, dass er den Brocken bei einem anderen Erwachsenen aufbewahren soll.

All dies erfordert vom erwachsenen Knoten ein gewisses Selbstbewusstsein darüber, wie voll er ist. Die Überprüfung des Speicherplatzes ist ziemlich ressourcenintensiv, daher führen wir dies nur in Schritten von ungefähr 10 % des verfügbaren Speicherplatzes durch.

Fehler von Erwachsenen

Wir müssen Fehler generieren, um Kunden – und das System als Ganzes – darauf hinzuweisen, wenn Daten nicht so gespeichert werden, wie sie sollten. Dies kann aus verschiedenen Gründen geschehen. Diese Fehler werden Teil des Netzwerkprotokolls, das alle Knoten einhalten müssen, wenn sie im Netzwerk bleiben sollen.

Nachfolgend finden Sie eine Liste von Fehlern, die bei PUT/GET-Operationen an einem erwachsenen Knoten auftreten können (ohne AE- und DKG-Fehler), sowie die Antworten, an denen wir arbeiten.

„CouldNotStoreData“ – der Erwachsene hat während der Speicherung aufgrund des Speichermechanismus des Erwachsenen einen Fehler gemacht. Das ist die Schuld des Erwachsenen. Mögliche Ursachen sind ein Fehler beim Erstellen von Verzeichnissen, Probleme mit dem Dateisystem oder der zum Speichern von Registern verwendeten Datenbank, beschädigte Register oder falsche Dateipfade.

DataError - der Knoten hat aufgrund eines Datenfehlers nicht gespeichert. Dies ist die Schuld des Clients oder möglicherweise, weil die Nachricht beschädigt wurde. In jedem Fall (wir können es nicht wissen) sollte dies an den Client zurückgegeben werden.

NodeFull - der Knoten ist voll! Eine Fehlermeldung wird an den Ältesten zurückgesendet, der die Speicherung anfordert. Wir könnten möglicherweise Erwachsene bestrafen, die uns nicht vorher darüber informiert haben, dass ihre Speicherkapazitäten zur Neige gehen.

Fehler Spam

Neben der Information der Kunden können wir diese Fehler auch nutzen, um zu signalisieren, dass etwas schief gelaufen ist. Gleichzeitig müssen wir vermeiden, die Ältesten mit zu vielen Nachrichten hin und her zu überfordern.

Beim Umgang mit diesen Fehlern müssen wir sicherstellen, dass wir keine neuen Angriffsvektoren eröffnen, die es böswilligen Benutzern ermöglichen, davon Kenntnis zu nehmenFühren Sie illegale Operationen durch, um DDoS im Netzwerk durchzuführen, indem Sie Massen von Fehlermeldungen generieren. Als zukünftige Maßnahme ist es möglich, dass wir Kunden, bei denen ein solches Verhalten beobachtet wurde, auf eine schwarze Liste setzen.


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!