Safe Network Entwickler Update 🇩🇪 28. Oktober 2021

Dies ist eine maschinelle Ăśbersetzung. Das Original in Englisch ist hier: Update 28 October, 2021

Fehler können schwer zu finden, schwerer zu beseitigen und manchmal noch schwerer zu erklären sein. In diesen Updates versuchen wir, die neuesten Nachrichten zu unseren Fortschritten und unseren Plänen für die nächsten Schritte darzustellen, aber in gewisser Weise ist das das Einfachste. Als ob wir sagen, dass wir stetig einen bestimmten Bach hinaufkommen, ohne zu sagen, wie weit unser Ziel entfernt ist, wie viele Paddel wir zur Verfügung haben, und die Krokodile, Stromschnellen und andere Unannehmlichkeiten ignorieren, die im Weg liegen. Das Schwierige ist, diese Fehler zu erklären, ohne sich im Unkraut zu verlieren. Es ist ein schmutziger Job, aber um den dringend benötigten Kontext bereitzustellen, muss jemand die Protokolle durchsuchen. @joshuef hat den Kürzeren gezogen.

Allgemeiner Fortschritt

Der API- und CLI-Code wurde jetzt mit dem Hauptrepo von Safe Network zusammengeführt, obwohl es noch keine neue Version gibt, da einige CLI-Tests fehlschlagen. Der Freigabeprozess muss ebenfalls angepasst werden, um die Ergänzungen zu diesem Repo zu berücksichtigen. @Chriso ist auf dem Fall.

Verlockend nah ist auch die Entfernung des Connection Pools von qp2p, wobei diese Funktionalität in Safe Network übernommen wurde, wo wir sie optimieren können. Der Verbindungspool hielt Clientverbindungen offen, aber auf eine Weise, die schwer zu verfeinern und zu konfigurieren war, wie wir es wollten. Das Entfernen vereinfacht qp2p und beseitigt viele Randfälle - und mit ziemlicher Sicherheit viele Fehler.

In der Zwischenzeit hat @Joshuef diese Woche einen riesigen Blocker weggespült, der es schaffte, die Nachrichtenlast unter bestimmten Umständen (zwischen guten Knoten) von ~65.000 auf ~500 zu reduzieren, alles gut.

@bochaco und @yogesh haben untersucht, wie sich Sektionen gegenseitig aufzeichnen, wie dieser Prozess effizienter gestaltet werden kann und wo und in welchem ​​Format diese Informationen gespeichert werden.

Und @Lionel.faber hat sich mit der Priorisierung von Nachrichtentypen befasst. Manche Nachrichten sind wichtiger als andere. BLS DKG-Nachrichten, die die Autorisierung behandeln, sollten höchste Priorität erhalten. Nichts Wichtiges sollte ohne Zustimmung der Ältesten passieren. Das Freigeben der Kanäle für diese Nachrichten wird alles beschleunigen. Am anderen Ende des Spektrums können Abfragen, Datenbefehle und Fehlermeldungen glücklich warten, ohne die Leistung zu beeinträchtigen.

Fehler

Ich glaube nicht, dass irgendjemand jemals behauptet hat, dass Safe simple ist. Es ist nicht. Aber es ist auch nicht nicht. Wir haben die Teile so ausgelegt, wie sie die Leute in verschiedenen Testnetzen gesehen haben. Und seit dem letzten (was sich wir wissen schon vor einiger Zeit anfĂĽhlt) haben wir versucht, alles stabiler zu machen.

Die Fehler hinter der Instabilität werden oft in Updates angesprochen, aber auf ziemlich technische Weise. Deshalb wollten wir hier einen etwas mehr allgemeinen Überblick geben. Etwas zugänglicher für Leute, die nicht gerne stundenlang in einem Texteditor herumstöbern.

Du hast deine klassischen Fehler

2+2=5

Oder verworfene Nachrichten zwischen Knoten (Ihr Beitrag kommt nicht an).

Oder ein Verbindungsproblem, bei dem das meiste von dem ankommt, was Sie wollen. Aber die Schraube, die Sie brauchen, ist nicht durchgekommen. (Und jetzt müssen Sie versuchen, dies erneut zu erreichen, damit Sie sehen können, warum diese Schraube nicht ankommt.)

Race-Bedingungen, bei denen ein Problem nur dann auftreten kann, wenn ein Code oder ein Programm schneller abgeschlossen wird als ein anderer Teil des Systems. (Sie sehen es also vielleicht nur, wenn Ihr Pferd LuckyProblems kurz vor OtherWeWork und kurz nach ThisAlreadyHappened eintrifft; aber jede andere Kombination geht gut).

Schleifen. Dinge passieren immer wieder, weil sie am Ende Dinge auslösen. Möglicherweise für immer. Sie führen oft dazu, dass alles hängt oder direkt abstürzt, weil sie ständig die Ressourcen des Programms beanspruchen.

Hängt. Auch als Deadlocks bekannt. Diese Bugs sind der Catch 22 der Bug-Welt. Sie können nur fortfahren, wenn Sie number=5 haben, aber Sie können number nur setzen, wenn Sie number=5 haben. Dies ist offensichtlich ein Symptom eines klassischen Fehlers, geht aber auch oft Hand in Hand mit etwas Rennen, sodass Sie dies erst bemerken, wenn es zu spät ist (und jetzt sind Sie sich nicht sicher, warum dies passieren sollte … : Denken:.)

Dann hast du noch ein paar sichere Details

Was oft nur Symptome der oben genannten sind…

Nachrichtenverstärkung. Dies ist der Zeitpunkt, an dem wir erwarten könnten, dass wir 5 Nachrichten an unsere Speicherknoten senden, aber stattdessen 500. Was wiederum dazu führt, dass weitere 15000 zurückkommen. Normalerweise ist da ein Fehler (2+2=5), wenn wir das sehen, oder es kann sein, dass das System nicht das tut, was wir dachten, also müssen wir das Design überdenken. (Wir hatten vor kurzem AE-Wiederholungen naiv an alle Ältesten geschickt. Um dies noch zu verschärfen, würden die nächsten Wiederholungen daher von allen Ältesten … an alle Ältesten gesendet. :chart_with_upwards_trend:)

Manchmal bekommen wir einen mangelnden Durchsatz. Nachrichten werden nicht gelöscht. Aber die Dinge sind langsam. Wieso den!? Manchmal eine Kombination aus allem oben genannten.

Im Moment haben wir nach einigem Refactoring zu viel Durchsatz. Dies ist kein Problem an sich, aber es kann oft verschiedene andere Probleme aufdecken … (wählen Sie einen der in diesem Beitrag erwähnten Fehlertypen aus!)

Gabeln! Gabeln im Weg unseres Sektionswissens (wer kam vor uns … wer zeugt wen) … wenn Knoten nichtaus irgendeinem Grund (ein fehlerhafter Grund) nicht zustimmen, nun, dann können wir vielleicht zwei Gruppen gültigen Wissens haben, wissen aber nicht, welches für unsere aktuelle Situation tatsächlich relevant ist.

Daten nicht gefunden. Ist offensichtlich… aber warum? Nun, jeder der oben genannten Punkte könnte dazu führen, dass die Daten nicht wirklich PUT sind. Also viel Glück bei der Suche nach dem, was es nicht gibt!

Nicht teilen! Wir brauchen Splits, um das Netzwerk gesund zu halten (zum Beispiel um die Arbeitslast leichter aufzuteilen und die Widerstandsfähigkeit gegen Hacks aufrechtzuerhalten). Nicht aufteilen könnte ein Fehler im DKG-Algorithmus (Distributed Key Generation…) sein oder wie wir unseren Ältesten ihre Autorität geben.

Wahl des falschen Ziels. Manchmal scheint das Nachrichtensystem zu funktionieren und das Paket wird zugestellt. Aber wir haben es tatsächlich an die falsche Person gesendet (oder an eine ganze Nachbarschaft / einen ganzen Abschnitt!?).

Zu aufgeregt sein! Manchmal tun wir etwas so schnell wie möglich. Aber das Netzwerk ist auf seinem notwendigen Weg zur letztendlichen Konsistenz noch nicht wirklich fertig. (Stellen Sie sich vor, Sie haben einen Brocken PUT, aber noch nicht alles gespeichert, aber Sie versuchen bereits zu GET.) Es kann scheinen, als ob es einen Fehler gäbe. Aber wenn Sie es in ein paar Sekunden noch einmal versuchen, ist vielleicht alles da und in Ordnung. Du dachtest, du hättest einen Fehler, aber du warst einfach zu scharf.

SooOOooo

So. Das ist ein kleiner grober Überblick über verschiedene Dinge, die wir im System sehen und finden können. Das kann pro Knoten, pro Client oder pro Abschnitt sein… Und nur manchmal oder nur an einem Dienstag auf einem obskuren Linux-Build. Und wenn Sie das Problem sehen, kann es sich hinter 3 oder 4 verschiedenen Fehlertypen verbergen, bevor Sie an der Wurzel des Problems ankommen.

All das betrachten wir in einem System von 45 Nodes und mehreren Clients (im Moment im Durchschnitt während interner Tests).

Safe ist nicht so komplex, wenn man darĂĽber nachdenkt, zumindest konzeptionell (Daten zwischen Computern teilen). Aber es ist auch noch nicht so einfach, wie es sein kann, weshalb wir immer noch an Problemen herumhacken, Dinge umgestalten (sie vereinfachen) und neue Funktionen implementieren (und manchmal zielen sie direkt darauf ab, dabei zu helfen) debuggen).

Das Entfernen von unnötigem Code und Komplexität hilft uns zu etwas Einfacherem zu kommen, das neben der Behebung Ihrer klassischen Fehler im System oft eine der wichtigsten Möglichkeiten zur Behebung von Fehlern ist. Weniger Code, weniger Probleme. :bulb:

Wir kommen dahin! Es fühlt sich nicht immer schnell an, aber es fühlt sich immer so an, als würden wir vorwärts drängen (auch wenn wir manchmal ein bisschen rückwärts gehen müssen).


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!