Safe Network Entwickler Update đŸ‡©đŸ‡Ș 11. Februar 2021

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! :heart:

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

Projektplan

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!