Dies ist eine maschinelle Übersetzung. Das Original in Englisch ist hier: Safe Network Dev Update - November 19, 2020
Zusammenfassung
Hier sind einige der wichtigsten Dinge, die seit dem letzten Entwickler-Update hervorgehoben werden sollten:
- qp2p hatte diese Woche einige Schwerpunkte mit Leistungsverbesserungen, insbesondere im Bereich Verbindungspooling.
- Die Chunk-Replikation wird wieder in den Code eingeführt.
- Wir freuen uns, von einer kürzlich erschienenen wissenschaftlichen Arbeit der AT2-Autoren mit dem Titel Dynamic Byzantine Reliable Broadcast zu hören, die eine formal bewährte Lösung für unsere genauen Anforderungen zu bieten scheint Problem.
- In sn_routing sind wir dabei, ein join_flag hinzuzufügen, um umzuschalten, ob neue Knoten in das Netzwerk aufgenommen werden sollen oder nicht.
Safe Client, Nodes und qp2p
Projektplan für sichere Netzwerkübertragungen
Safe Client-Projektplan
Projektplan für sichere Netzwerkknoten
Zunächst einmal haben wir diese Woche in qp2p Verbindungspooling implementiert. Dies bedeutet, dass wenn ein Knoten eine Verbindung zu einem Peer herstellen möchte und die Verbindung zuvor geöffnet wurde (und noch offen ist), die vorhandene Verbindung wiederverwendet wird, anstatt eine neue herzustellen. Dies verbessert die Leistung, da das Herstellen einer Verbindung teuer ist (dies beinhaltet unter anderem einen TLS-Handshake). Dies verbessert auch die Ergonomie, da sich die Benutzer von qp2p nicht mehr um das Zwischenspeichern von Verbindungen kümmern müssen. Wir haben auch die Verbindungs-Deduplizierung implementiert. Dies bedeutet, dass mehrere gleichzeitige Verbindungsversuche mit demselben Peer zu derselben Verbindung aufgelöst werden, anstatt jeweils eine separate Verbindung zu öffnen. Dies verbessert erneut die Leistung.
Wir haben die Blockreplikation von Blob-Daten unter sn_node wieder aufgenommen. Ausgehend von einem 4-fachen Replikationsfaktor sind die Erwachsenen des Netzwerks in erster Linie für deren Speicherung verantwortlich. Wir portieren die ältere Implementierung von vorasynchronen Tresoren auf die neue Codebasis und passen sie an die neuesten Änderungen beim Speichern, Abfragen usw. an. Wir haben diese Woche auch auf der ganzen Linie ein bisschen Wartung durchgeführt, indem wir hinterhältige „Unwrap“ gesucht haben s, erwarten und paniken` von unserem Produktionscode und unseren Tests, stabilisieren im Wesentlichen unsere Codebasis und erfassen alle Ausnahmen. Dies ist eine bewährte Methode und etwas, das wir zu lange aufgeschoben haben. Achten Sie darauf, dass in den nächsten Tagen zusätzliche CI-Überprüfungen in unseren Kisten hinzugefügt werden, um sicherzustellen, dass diese nicht in unseren Code zurückschleichen.
Wir haben ein wenig Zeit in die Erforschung und Überlegung investiert, wie sich die APIs letztendlich weiterentwickeln müssen, um Signaturanforderungen vom Client mit mehreren Schlüsselpaaren anstatt nur einem zu unterstützen. Beispielsweise möchte ein Client möglicherweise eine Datei speichern, die einem öffentlichen Schlüssel gehört, während die Zahlung für einen solchen Vorgang unter Verwendung eines zweiten öffentlichen Schlüssels erfolgt, dem das Geld gehört, und möglicherweise kann der Client ein drittes Schlüsselpaar verwenden Verschlüsselung des Dateiinhalts. Dies ist derzeit keine hohe Priorität, sondern eher ein PoC, der uns hilft, die Herausforderungen zu identifizieren und zu erkennen, wie wir unsere Client-APIs letztendlich weiterentwickeln können.
CRDTs
Die Arbeit an der dynamischen Mitgliedschaft in DSB wird fortgesetzt. Diese Woche hat unser Berater einen Testfall geschrieben, der ein Parallelitätsproblem mit Datenoperationen zeigt, während ein Mitglied die Gruppe verlässt. Eine korrekte Implementierung einer dynamischen Mitgliedschaft sollte den Test immer bestehen, während unsere derzeitige naive Implementierung fehlschlägt. Daher müssen wir jetzt etwas Konkretes messen.
Zu diesem Zweck freuen wir uns über eine kürzlich erschienene wissenschaftliche Arbeit der AT2-Autoren mit dem Titel Dynamic Byzantine Reliable Broadcast. Es enthält ein Zitat: „die erste Spezifikation eines dynamischen byzantinischen zuverlässigen Broadcast-Grundelements (dbrb), das einer asynchronen Implementierung zugänglich ist“. Mit anderen Worten, dieses Papier bietet eine formal bewährte Lösung für genau unser Problem.
Unser Berater prüft derzeit dieses Dokument sowie eine andere mögliche Lösung mit einer sogenannten Generationsuhr, die möglicherweise nicht so viel erfordert Netzwerk-Kommunikation.
Routing
Wie im Update der letzten Woche erwähnt, wurde diese Woche die Arbeit genehmigt einem Knoten die Wiederverbindung mit demselben Namen ermöglichen und diese Woche zusammengeführt. Dies bedeutet, dass jeder wieder verbundene Knoten sofort mit der Hälfte seines Alters verschoben wird, solange das halbierte Alter größer als die „MIN_AGE“ (derzeit „4“) ist. Dies soll böswillige Neustarts verhindern.
Wir hatten während interner Tests beobachtet, dass der Genesis-Knoten manchmal zu schnell herabgestuft wurde. Dies war auf eine kürzliche Änderung zurückzuführen, bei der wir jetzt Knoten mit einem Zufall erstellen Altersbereich während der Startphase. Um dies zu beheben, haben wir beschlossen, den ersten Knoten mit einem höheren Alter zu starten, der derzeit auf 32 festgelegt ist. Dieser Knoten wurde nun zum Master zusammengeführt. Dies stellt sicher, dass der Genesis-Knoten als Ältester ausreichend lange stabil bleibt, was viele Dinge für das Testen und das Einrichten des Testnetzes erleichtert.
Die laufenden Arbeiten zur Verbesserung der Erkennung verlorener Peers kommen gut voran. Wir haben bereits die neue Verbindungspooling-Funktion in qp2p genutzt, mit der wir den Code vereinfachen konnten. Einige erste Integrationstests zeigen, dass das Refactoring gut funktioniert. Diese PR durchläuft derzeit einige abschließende Überprüfungen und Tests und wird daher hoffentlich bald zusammengeführt.
Um sicherzustellen, dass, wenn die Ressourcen eines Knotens fast aufgebraucht sind, neue Knoten einfließen, um die Arbeitslast zu teilen, werden wir den Knoten erlauben, das Routing anzuweisen, neue Knoten zu akzeptieren oder nicht. Diese Einschränkung, wann das Netzwerk neue Knoten akzeptiert, hilft auch dabei, Sybil-Angriffe zu verhindern, indem potenziellen Angreifern nicht erlaubt wird, nach Belieben unbegrenzt viele Knoten hinzuzufügen.
Darüber hinaus möchten wir einige Änderungen vornehmen, um uns über den genauen Status des Routings während des Netzwerkstarts und darüber hinaus zu informieren. Wir haben zwei laufende PRs Anzeige für das Starten und Auslösen des PromotedToAdult-Ereignisses und benachrichtigen, wenn der Schlüssel während des Umzugs geändert wird. Diese laufenden Änderungen helfen uns sicherzustellen, dass sich das Routing wie beabsichtigt verhält und bald abgeschlossen sein sollte, sobald die API-Designs zwischen Knoten und Routing vereinbart wurden.
Nützliche Links
Ihr könnt uns gerne Übersetzungen dieses Entwickler-Updates zusenden und wir werden sie hier auflisten:
Als Open-Source-Projekt sind wir immer auf der Suche nach Feedback, Kommentaren und Beiträgen der Gemeinschaft - seien Sie also nicht schüchtern, machen Sie mit und lassen Sie uns gemeinsam das SAFE-Netzwerk aufbauen!