Safe Network Entwickler Update đŸ‡©đŸ‡Ș 20. Oktober 2022

Dies ist eine maschinelle Übersetzung. Das Original in Englisch ist hier: Update 20 October, 2022

efbc1925d4a69809fe6f384cfa4066da8cae1c5c

Diese Woche bringt @joshuef einige Neuigkeiten ĂŒber den Fortschritt bei der Kommunikation (Kommunikation zwischen Knoten). Wie geduldige Leser wissen werden, ist dies schon seit einiger Zeit ein Hindernis, aber wir sehen definitiv ein Licht am Ende dieses speziellen Tunnels.

Allgemeines Update

Eine kurze Zusammenfassung dessen, was das Team vorhat.

@anselme hat einen Rogue Key Attack untersucht, der einige andere Implementierungen von BLS betrifft und hat festgestellt, dass unsere auch verwundbar ist. Er hat einen Fix fĂŒr die blsttc-Kiste eingereicht. Er untersucht auch einen Fehler, der Clients daran hindert, dem Netzwerk in Tests beizutreten.

@chriso arbeitet an Chunk- und Registersignaturen, bei denen Daten (oder ihr Xorname im Fall von Chunk) von den Ältesten signiert werden, um sie im Netzwerk gĂŒltig zu machen.

In diesem Zusammenhang nimmt @bochaco Änderungen an der Client-API in Bezug auf Befehle und Chunks vor und debuggt damit verbundene Fehler in CI.

Mostafa ist mit TestfĂ€llen fĂŒr unseren Konsensmechanismus beschĂ€ftigt, und @bzee stochert weiterhin bei qp2p herum, wo wir glauben, dass es einen tiefsitzenden Fehler gibt, der die KonnektivitĂ€t beeintrĂ€chtigt.

Kommunikationsfortschritt

Eine Sache, an der wir arbeiten, ist also, unseren Code zur Reduzierung der Verbindung zu entfernen und uns nur auf den zugrunde liegenden „Quinn“-Code zu verlassen, um Verbindungen nach einem kleineren Timeout zu beenden. Auf diese Weise gehen wir weniger davon aus und ĂŒberlegen nicht mehr, was wann geöffnet ist.

In unseren Tests hat sich dies positiv auf die Client-Tests ausgewirkt und die Wahrscheinlichkeit beseitigt, dass unsere Verbindungen auf halbem Weg geschlossen werden.

Bi-Streams

Parallel dazu gehen wir auch dazu ĂŒber, die Kommunikation zwischen Clients und Knoten mithilfe von bidirektionalen Streams zu optimieren. Das bedeutet, dass wir die KomplexitĂ€t der Zustandsverwaltung beseitigen und nur auf eine Antwort von Ältesten warten. FrĂŒher (vor langer Zeit im Node-Land) hatten wir diese Art von Streams verwendet, um mit Kunden zu kommunizieren, aber die Verwaltung des Response-Streams war ein komplizierter Albtraum. Aber jetzt ist der Knoten viel einfacher (aufgrund der Arbeit, die in den letzten anderthalb Jahren oder so geleistet wurde), und dies ist viel einfacher zu handhaben.

Reduzierte Wiederholungen

Wir haben auch versucht, alles zu entfernen, was diese Probleme verschleiert hat (z. B. unsere oben erwĂ€hnten Kommunikationsabstraktionen) und auch Wiederholungsversuche auf Clientebene. Wir haben jetzt ACK (BestĂ€tigungs-) Nachrichten (sie wurden vor ein paar Monaten eingefĂŒhrt) an den Client. Diese helfen uns zu sagen, wann ein Befehl von Ältesten gesehen wurde. Aber wir haben immer noch nur abgefragt, bis ein Chunk zurĂŒckgegeben wurde. @bochaco hat versucht, hier strenger zu sein
 Wiederholungsversuche nicht zuzulassen und nur zu sagen: „Wir haben das ‚ACK‘ gesehen
 also warum sehen wir beim ersten Mal keinen Erfolg?“. Dies hat einige Fehler beim Lesen/Schreiben von Dateien aufgedeckt. (Es sieht so aus, als ob das Deserialisieren der Speicherbefehle lĂ€nger dauern kann als Abfragen 
 also verarbeiten wir sie zuerst, selbst wenn sie nachher gesendet werden).

Reduzierte Knotenverarbeitungslasten

Um die Handhabung von Node-Befehlen besser zu regulieren, haben wir zuvor Code hinzugefĂŒgt, der eingehende Nachrichten hĂ€tte organisieren und zur Verarbeitung anordnen sollen. Wir haben tatsĂ€chlich gesehen, dass dies ĂŒberhaupt nicht die Wirkung hatte, nach der wir gesucht hatten (tatsĂ€chlich löste es nur aus, dass alle Nachrichten unabhĂ€ngig von ihrer PrioritĂ€t nacheinander verarbeitet wurden).

Das Entfernen dieses Codes hat eine Menge Knotenvereinfachung ermöglicht. Am wichtigsten ist, dass wir in der Lage waren, die Verarbeitung von Node-Prozessen sperrungsfrei aus dem Thread zu verschieben (nachdem unser Single-Thread-Push die ĂŒberwiegende Mehrheit des Sperrcodes entfernt hatte).

Einfluss

FrĂŒher konnten wir den Eingang von Nachrichten verfolgen, die zur Verarbeitung in die Warteschlange gestellt, bearbeitet und dann zum Senden in die Warteschlange gestellt wurden. Dieser Vorgang unter Last könnte erhebliche Zeit in Anspruch nehmen. Manchmal war es relativ schnell, unter einer Sekunde. Manchmal kann es bei all der Befehlsverarbeitung und NachrichtenĂŒbermittlung 20 Sekunden dauern.

Jetzt sehen wir, dass Nachrichten routinemĂ€ĂŸig an Knoten eingehen, sofort verarbeitet werden und Nachrichten in weniger als einer Millisekunde ausgehen.

Das ist viel nĂ€her an dem, was wir vorher von unserer Kommunikation erwartet hĂ€tten, und fĂŒhlt sich sehr nach der richtigen Richtung an.

NĂ€chste Schritte

Wir möchten die bidirektionalen Streams vollstĂ€ndig in die Clients integrieren und dort einen Großteil der Zustandsverwaltung entfernen. Und wir werden auch darauf abzielen, denselben Fluss in der Kommunikation zwischen Älteren und Erwachsenen zu haben, wo Antworten erforderlich sind, was die Dinge auch dort weiter vereinfachen sollte. Es sollte tatsĂ€chlich ermöglichen, dass unsere „ACK“-Nachrichten auch die Speicherung von Erwachsenen widerspiegeln, anstatt nur Älteste zu sagen, dass sie eine Nachricht gesehen haben, was auch bei fehlgeschlagenen ÜberprĂŒfungen helfen sollte.


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!