Dies ist eine maschinelle Übersetzung. Das Original in Englisch ist hier: Safe Network Dev Update - February 11, 2021
Zusammenfassung
Hier sind einige der wichtigsten Dinge, die seit dem letzten Entwickler-Update hervorgehoben werden sollten :
- Die Testnet-Version wird noch angehalten, während wir daran arbeiten, das Refactoring des Nachrichtenflusses abzuschließen, wodurch das Fortschreiten der Belohnungen blockiert wird.
- Die Umgestaltung des Nachrichtenflusses macht gute Fortschritte, da ein PR-Entwurf vorhanden ist. Dies führt zu einem saubereren, einfacheren und effizienteren Nachrichtenfluss.
- Wir haben unsere Testnet-Bereitstellungs- / Abschaltskripte auf terraform migriert, was zu einer drastischen Verkürzung der Zeit geführt hat, die zum Erstellen von Testnetzen beliebiger Größe für interne Tests / externe Tests benötigt wird Einsatz.
- Wenn wir einige Zeit mit der Einrichtung ohne Belohnungen verbracht haben, konnten wir einige Fehler erkennen und beseitigen, die sonst verborgen geblieben wären, bis die Belohnungen vollständig implementiert wurden.
- In der CLI wird ein neuer Unterbefehl „$ safe network set“ implementiert, mit dem Benutzer einfacher eine Verbindung zu Netzwerken herstellen können, indem sie einfach ihre Bootstrapping-IP: Port-Adresse mit dem entsprechenden PR wird jetzt überprüft.
- Wir glauben, wir haben eine Lösung für das Gabeln von Abschnittsketten in
sn_routing
gefunden. Diese Lösung wird derzeit implementiert und wir glauben, dass sie dazu beitragen wird, Testnetze stabil genug zu machen, um mit Community-Tests fertig zu werden. -
Community Code Beiträge kommen immer wieder!
Testnet-Status - in der Warteschleife
Auch in dieser Woche wollten wir Belohnungen in ein öffentliches Testnetz aufnehmen, aber einige verwandte Arbeiten zur Anpassung der Nachrichtenflüsse, nachdem wir den Wechsel vorgenommen haben, nur die Nachrichtenakkumulation in „sn_routing“ durchzuführen, die alle Teile von „sn_node“ betrifft, wurden geändert um zeitaufwändiger zu sein als wir erwartet hatten. Diese Arbeit blockiert derzeit den Fortschritt von Belohnungen.
Anfang der Woche haben wir uns entschlossen, etwas Energie auf die Alternative zu konzentrieren, ein Testnetz ohne Belohnungen zu haben, d. H. Einen Teil des Belohnungsflusses zu streichen, was wir letzte Woche begonnen haben. Wir haben hier einige gute Fortschritte gemacht, sind aber auf dem Weg auf mehrere Blockierungsprobleme gestoßen, bei denen wir mehrere „Hacks“ anwenden mussten, um sie vorübergehend zu lösen, bis Belohnungen und die damit verbundenen Funktionen vorhanden sind. Den resultierenden „No-Rewards“ -Netzwerken, die wir aufgebaut haben, mangelte es an Stabilität, Zuverlässigkeit und Konsistenz. Daher glauben wir derzeit nicht, dass es sinnvoll ist, ein Testnetz ohne Belohnungen aufzubauen. Dieser alternative Ansatz hatte diese Woche einige Vorteile, da wir einige Tests mit mehreren Abschnitten etwas vorantreiben konnten, was dazu führte, dass wir einige Probleme identifizierten und behebten, die wir sonst erst gesehen hätten, wenn Belohnungen und die damit verbundenen Funktionen vorhanden waren.
Wir gehen weiterhin davon aus, dass wir so schnell wie möglich ein Testnetz hosten werden, wobei der Fokus zurück verschoben wird, um die Belohnungen wieder voranzutreiben und ein zuverlässiges Testnetz mit diesem zu veröffentlichen. Möglicherweise werden wir ein wenig mehr Tests mit der Arbeit „Keine Belohnungen“ durchführen, um zu sehen, ob wir auf der ganzen Linie noch etwas entdecken können, das für uns lauert.
Testnet vorbereiten und testen
Gegen Ende der letzten Woche haben wir versucht, große Testnetze zu veröffentlichen, und es wurde schnell klar, dass unser Bash-Skript dafür nicht geeignet war - es dauerte 30 Minuten, um 20 Knoten oder so zu starten, und es dauerte verdammt viel länger 100 Knoten starten! Aus diesem Grund haben wir auf terraform migriert, um die Bereitstellung / Zerstörung von Tröpfchen und Knoten zu verwalten, und das ist viel besser. Wir können jetzt in wenigen Minuten 40 ungerade Knoten starten. Wir haben dies ziemlich häufig zum Iterieren verwendet und es jetzt so eingerichtet, dass wir auch benutzerdefinierte Knoten-Builds bereitstellen können. Was sich an der Iterationsfront als sehr praktisch erwiesen hat. Die PR für diesen Wechsel zu Terraform ist an Ort und Stelle und wird jetzt ziemlich gründlich getestet, wobei vor dem Zusammenführen einige Aufräumarbeiten vorgesehen sind.
Zu einem bestimmten Zeitpunkt in der Woche sahen wir ziemlich regelmäßig interne Testnetze, die sich teilen wollten, dies aber nicht taten. Wir haben versucht, mit kleineren Abschnitten (z. B. 3 Ältesten, einer Abschnittsgröße von 5 Knoten) zu debuggen, um mehr Teilungen auszulösen, aber das hat nicht geholfen. Es stellte sich heraus, dass wir keine Teilungen sahen, da unser Code von den beweglichen Abschnitten der Ältesten abhing, aber dies ist nicht erforderlich (aus heutiger Sicht). Wie bei allen Wahrscheinlichkeiten schienen auch diese unwahrscheinlichen Ereignisse ziemlich oft zu passieren … und so fielen alle unsere Ältesten in eine Hälfte des Abschnitts und bildeten so einen neuen Abschnitt für sich, ohne dass eine Schlüsseländerung erforderlich war und keiner unserer Codes wird getroffen.
Mit mehr Fehlerkorrekturen und dem Entfernen einiger Belohnungsfunktionen, die überarbeitet werden, haben wir ein Problem behoben, das beim Start des Netzwerks auftrat, bei dem der neu beförderte Älteste bei jeder Abwanderung im Abschnitt „Genesis“ eine Genesis erneut vorschlug Auszahlung noch einmal, so dass der Rest der Ältesten effektiv auf a wartetEine weitere Genesis-Auszahlung, die ursprünglich nur einmal erfolgen sollte. Damit haben wir auch einen weiteren verwandten Fehler behoben, bei dem keine Anhäufung des Genesis-Zahlungsnachweises stattgefunden hat (wir haben alle Zahlungsereignisse außer den Validierungsereignissen gespeichert). das half, die Dinge in Bewegung zu bringen.
Danach stießen wir auch auf eine Schleife in sn_routing
, die eine hohe Speichernutzung verursachte und möglicherweise zum Absterben von Knoten führte. Wir wissen, wo das Problem liegt, und wir haben eine vorübergehende Maßnahme ergriffen, um zu verhindern, dass es vorerst auftritt. Eine dauerhaftere Lösung wird zu gegebener Zeit erfolgen.
Nachdem alle oben genannten Punkte mit dem Zweig „Keine Belohnungen“ eingeführt wurden, erreichten wir endlich das Stadium, in dem die meisten Client-Tests bestanden wurden, wobei die Fehler einige andere Probleme hervorhoben, z. B. das gelegentliche Schlagen von Code, den wir nicht sollten in der Lage sein zu erreichen (dafür ist eine Fehlerbehandlung erforderlich), und jetzt haben wir derzeit auch ein Problem mit Client-Wallets. Die Client-Testsuite wird ein wenig umweltfreundlicher, um sich darauf vorzubereiten, dass der Belohnungsfluss wieder vollständig integriert ist.
Safe Client, Nodes und qp2p
Projektplan für sichere Netzwerkübertragungen
Safe Client-Projektplan
Projektplan für sichere Netzwerkknoten
QP2P
In der letzten Woche haben wir die neue qp2p
API mit all unseren Kisten getestet. Anfangs gab es einige Probleme, aber diese sind jetzt alle behoben und wir befinden uns in der endgültigen Überprüfungs- und Zusammenführungsphase auf ganzer Linie. Wir werden diese Änderungen in End-to-End-Tests einbeziehen und sie werden Teil der nächsten Testnet-Version sein.
Mitteilungen
Kürzlich sind wir umgezogen, um Nachrichten nur in „sn_routing“ zu sammeln, nachdem wir dies zuvor auch in „sn_node“ getan haben. Um diesen Refactor fertigzustellen, wurde viel Code berührt, aber auch ungefähr 1350 Zeilen entfernt.
Das Ergebnis ist ein einfacherer, sauberer und effizienterer Nachrichtenfluss.
Derzeit wird daran gearbeitet, und ein PR-Entwurf verfolgt den Fortschritt. Dies wird uns helfen, die Nachrichtenflüsse im Allgemeinen voranzutreiben, aber jetzt auch die Belohnungen, die durch diese Aktualisierungen etwas zurückgehalten wurden.
API und CLI
Eine technische Schuld, die wir in unserer „sn_api“ -Kiste hatten, bestand darin, dass unsere „Error“ -Typen „std :: error :: Error“ implementieren. Dies haben wir in der vergangenen Woche mit Hilfe des thiserror abgeschlossen und zusammengeführt. Kiste. Wir haben auch die CLI-Codebasis geändert, um anyhow zu verwenden, sodass alle Funktionen jetzt „anyhow :: Result“ zurückgeben und die Fehlerbehandlung wesentlich einfacher wird, ohne Informationen oder Kontext zu verlieren über die Grundursache für jeden der propagierten Fehler.
In der CLI wird ein neuer Unterbefehl „$ safe network set“ implementiert, mit dem Benutzer mithilfe ihrer Bootstrapping-IP: Port-Adresse einfacher eine Verbindung zu Netzwerken herstellen können. Die entsprechende PR enthält eine Aktualisierung des Benutzerhandbuchs. Wenn Sie also frühzeitig Feedback zu diesem Befehl geben möchten, schauen Sie sich diese an die Beschreibung hier.
In der vergangenen Woche kamen immer wieder Gemeinschaftsbeiträge. Es gibt eine in Arbeit befindliche Anstrengung von @bzee, um das nodejs
-Paket mit der neuesten Version von sn_api
kompatibel zu machen, sowie einen Fix in der CLI, um einen Flag-Namen zu entfernen, der einen Konflikt zwischen zwei verschiedenen Befehlen verursacht hat (https://github.com/maidsafe/sn_api/pull/708). Ein PR wurde ebenfalls ausgelöst und zusammengeführt, um die Protokollierungsimplementierung aus „sn_client“ zu entfernen, da dies den Anwendungen oder Binärdateien überlassen bleiben sollte, die die Bibliothek verwenden Stellen Sie sicher, dass Anwendungen auf stdout oder stderr keine unerwartete Ausgabe erhalten.
Da die meisten Abhängigkeiten unserer Kisten tiny-keccak
v2.0.2 verwenden, hat @mav PRs gesendet, um alle unsere Kisten so zu aktualisieren, dass sie von derselben Version abhängen. Wir alle schätzen die Bemühungen aller sehr, die sich auf jede erdenkliche Weise engagieren: klatschen:
BRB - Byzantinische zuverlässige Sendung
Wir haben einige zusätzliche Arbeiten an brb_node_qp2p
durchgeführt, damit es mit bidirektionalen Streams und der neuen (in Kürze) qp2p
API funktioniert. Auf diese Weise kann jeder Knoten von demselben Port senden und empfangen, anstatt neue Verbindungen über einen separaten zufälligen Port für ausgehende Pakete zu öffnen. Dabei haben wir ein paar kleine PRs zu „qp2p“ beigetragen. Eine macht es insbesondere einfacher, einen „qp2p“ -Endpunkt zwischen Threads zu teilen, was für jeden, der eine p2p-App mit der Bibliothek erstellt, ein Gewinn sein sollte.
sn_data_types
Wir haben ein Design, um die Richtlinie / Berechtigung zu vereinfachenDie Logik für den Zugriff auf Netzwerkdaten wird derzeit intern überprüft. Wir haben auch einen PoC für eine neue Ketten-CRDT, die sich als bessere zugrunde liegende CRDT für unseren Sequenzdatentyp herausstellen könnte aus dem Problem @mav ausgelöst bezüglich unseres Sequenzdatentyps.
Routing
Diese Woche haben wir einen vielversprechenden Ansatz für die Gabelauflösung untersucht. Um es zusammenzufassen: Wir haben eine sogenannte „Abschnittskette“, eine Liste von Abschnittsschlüsseln, die mit Signaturen verknüpft sind. Es kann verwendet werden, um zu beweisen, dass ein Datenelement von einer Gruppe von Knoten signiert wurde, die einst gültige Mitglieder eines Abschnitts waren, selbst nachdem diese Knoten längst verschwunden sind. Derzeit erfordert diese Kette, dass der Abschnitt vereinbart, welcher Schlüssel als nächstes an ihn angehängt werden soll. Wenn diesbezüglich eine Meinungsverschiedenheit besteht, kann sich die Kette in zwei (oder mehr) miteinander inkompatible Ketten teilen, die den Abschnitt derzeit brechen könnten. Dies kann beispielsweise in Zeiten intensiver Abwanderung geschehen. Wir hatten gehofft, wir könnten davonkommen, ohne dies etwas länger in Angriff zu nehmen, d. H. Bis das Testnetz aus war, aber es stellte sich heraus, dass wir manchmal Gabeln sogar in relativ kleinen Testnetzwerken sehen.
Wir waren also damit beschäftigt zu diskutieren, wie dieses Problem am besten angegangen werden kann, und kamen auf ein paar vielversprechende Ideen. Derzeit wird eine solche Idee umgesetzt, die hoffentlich dazu beitragen wird, Testnetze stabil genug zu machen, um mit Community-Tests fertig zu werden. Es gibt immer noch einige potenzielle Bedenken hinsichtlich der Sicherheit und möglicher Angriffsmethoden, auf die später eingegangen wird. Im Moment liegt der Fokus auf Stabilität. Kleine Schritte.
Nützliche Links
Fühlen Sie sich frei, unten mit Links zu Übersetzungen dieses Entwickler-Updates 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!