Safe Network Entwickler Update ­čçę­čç¬ 3. Dezember 2020

Dies ist eine maschinelle ├ťbersetzung. Das Original in Englisch ist hier: Safe Network Dev Update - December 3, 2020

Zusammenfassung

Hier sind einige der wichtigsten Dinge, die seit dem letzten Entwickler-Update hervorgehoben werden sollten :

Safe Client, Nodes und qp2p

Projektplan f├╝r sichere Netzwerk├╝bertragungen
Safe Client-Projektplan
Projektplan f├╝r sichere Netzwerkknoten

Diese Woche war ein Meilenstein f├╝r sn_node mit der ersten Ver├Âffentlichung und ver├Âffentlichen dieser Kiste unter ihrem neuen Namen und die erste seit Juli. In den Monaten seitdem hat sich dort viel ge├Ąndert, wie das Changelog deutlich hervorgehoben, und wie wir versucht haben, Sie in diesen Updates auf dem Laufenden zu halten. Diese Releases bedeuten nicht, dass die Entwicklung in ÔÇ×sn_nodeÔÇť abgeschlossen ist, sondern dass wir sie als stabil genug angesehen haben, um jetzt die zuvor erstellte Continuous Delivery Pipeline PR zusammenzuf├╝hren ). Die Entwicklung geht z├╝gig voran, und jetzt f├╝hrt jede zusammengef├╝hrte PR zu einer weiteren automatisch generierten neuen Version.

Wir haben die Arbeit mit verbesserte Fehlerbehandlung in sn_node zusammengef├╝hrt, wodurch der Pfad f├╝r den Fortschritt frei wird. Nachdem wir letzte Woche das Zwischenspeichern von Sequenzen entfernt entfernt hatten, haben wir den Client diese Woche einigen normaleren Netzwerkbedingungen ausgesetzt, was zu mehreren fehlgeschlagenen Tests f├╝hrte. Mit einigen ├änderungen an den Client-Tests, um dies zu ber├╝cksichtigen, sind sie jetzt wieder stabil. Dar├╝ber hinaus haben wir uns mit dem Start von Abschnitten befasst, die lokal einwandfrei gelaufen sind, aber CI hatte es ein bisschen schwer. Wir haben festgestellt, dass einige davon darauf zur├╝ckzuf├╝hren sind, dass die CI-Maschinen langsam sind, und dass zunehmende Zeit├╝berschreitungen zwischen den dort beginnenden Knoten zu zuverl├Ąssigeren Ergebnissen gef├╝hrt haben. Es gibt noch einige Fehler, die hier ausgeb├╝gelt werden m├╝ssen.

Wir haben bei einigen fehlgeschlagenen Tests w├Ąhrend der End-to-End-Tests des Netzwerks weitere Fortschritte erzielt, insbesondere in Bezug auf die Speicherung von Daten unter Verwendung des Blob-Datentyps. Wir haben einige Probleme identifiziert, die sich w├Ąhrend einiger Refaktoren eingeschlichen haben, und mit den behobenen sehen wir jetzt, dass die Tests konsistent bestanden werden. Wir werden nun das Chunk-Replikationssystem wieder aktivieren, wenn Knoten das Netzwerk verlassen. Sobald dies erledigt ist, werden alle Blob-Flows in der ├╝berarbeiteten Implementierung von sn_node wieder aktiviert.

Ein weiteres Feature, an dem wir diese Woche gearbeitet haben, ist die Regulierung des Speichers in einem Abschnitt und letztendlich im Netzwerk ├╝ber PR # 1153. Ab diesem PR ├╝berwachen die Datenspeicherknoten ihren Speicher bei jedem Schreibvorgang und warnen ihre Abschnitts├Ąltesten, wenn sie ihre maximale Kapazit├Ąt erreichen. Die ├ältesten f├╝hren dann ein Register dieser gef├╝llten Knoten und wenn sie einen Schwellenwert von gef├╝llten Knoten in demselben Abschnitt erreichen, w├╝rden sie daf├╝r stimmen, neue Knoten zu akzeptieren, um sich ihrem Abschnitt anzuschlie├čen, und die Tore schlie├čen, sobald Angebot / Nachfrage erf├╝llt sind, wodurch ein Gleichgewicht aufrechterhalten wird im Netzwerk. Wir werden in den kommenden Tagen verschiedene ├änderungen an den Metriken vornehmen.

Ein PR f├╝r Rust-CRDT wurde erstellt, um LSeq mit anderen CRDT-Typen in Einklang zu bringen, die zuvor einen Antrag stellen m├╝ssen ├ändern des Datentyps selbst. Wir verwenden dies in unserem Datentyp ÔÇ×SequenzÔÇť, um sicherzustellen, dass alle Vorg├Ąnge signiert sind.

Die ├änderungen an sn_api und CLI wurden in der vergangenen Woche fortgesetzt und an neue sn_client-APIs angepasst. Wie bereits letzte Woche erw├Ąhnt, wurde auch versucht, auf neue UX-Terminologien zu migrieren. Die meisten sn_api-Tests werden jetzt mithilfe eines lokalen Abschnitts bestanden, und wir versuchen nun, diese ├änderungen abzuschlie├čen und die fehlgeschlagenen Tests zu beheben. Dies sollte hoffentlich bedeuten, dass die CLI-Befehle und E2E-Tests wieder ausgef├╝hrt werden.

Und schlie├člich, um eine erh├Âhte Testabdeckung von ├ťberweisungen, Zahlungen undd Belohnungsmodule, einige Umstrukturierungen dieses Codes und ├änderungen an der Zugriffsgranularit├Ąt wurden diese Woche eingeleitet.

BRB - Byzantinische zuverl├Ąssige Sendung

Die Arbeit am Generation Clock-Ansatz f├╝r eine dynamische Mitgliedschaft wird fortgesetzt. Der funktionierende Prototypcode wird bis Ende der Woche erwartet.

Auf einer parallelen Spur wird die bft-crdts-Kiste im Rahmen einer Modularisierung in separate Kisten aufgeteilt. Die Idee ist, drei Merkmale zu definieren: eines f├╝r die BRB-Implementierung, eines f├╝r zu ├╝bertragende und zu sichernde Datentypen und eines f├╝r die Netzwerkschicht.

Auf diese Weise k├Ânnen Implementierungen aller drei Merkmale gemischt und angepasst werden. Beispielsweise k├Ânnen wir ein In-Memory-Netzwerk f├╝r Testf├Ąlle verwenden, ein qp2p-Ger├Ąt f├╝r das Routing in Safe Network, und ein Drittanbieter verwendet m├Âglicherweise eine TCP / IP-Sockets-Implementierung f├╝r etwas anderes. Auf der Datenseite haben wir bereits eine AT2-Bank-Implementierung und eine CRDT-Orswot-Implementierung.

Routing

Projektplan

Wie oben erw├Ąhnt, wurde sn_node diese Woche zum ersten Mal in seiner aktuellen Form ver├Âffentlicht und ver├Âffentlicht. Um nicht ├╝bertroffen zu werden, hat das Routing-Team jetzt auch ver├Âffentlicht und ver├Âffentlicht sn_routing, die erste Ver├Âffentlichung seit fast 2,5 Jahren! Im ├änderungsprotokoll finden Sie eine ├ťbersicht ├╝ber die vorgenommenen ├änderungen. Wie bei sn_node bedeuten diese Releases nicht, dass die Entwicklung in sn_routing abgeschlossen ist, nur dass wir es als stabil genug angesehen haben, um jetzt die zuvor erstellte Continuous Delivery Pipeline PR. Die Entwicklung geht z├╝gig voran, und jetzt f├╝hrt jede zusammengef├╝hrte PR zu einer weiteren automatisch generierten neuen Version.

Diese Woche haben wir eine Ma├čnahme zum Schutz vor wichtigen Verkaufsangriffen implementiert. Ein Schl├╝sselverkaufsangriff liegt vor, wenn ein Knoten, der seinen Ruf aufgebaut hat, seinen geheimen Schl├╝ssel an eine potenziell b├Âswillige Entit├Ąt verkauft, die dann seine Rolle ├╝bernehmen und Schaden anrichten kann. Diese Art von Angriff ist sehr schwer vollst├Ąndig zu verhindern, aber wir haben es den Menschen zumindest schwer gemacht, auf den geheimen Schl├╝ssel zuzugreifen, indem wir sichergestellt haben, dass der Schl├╝ssel nicht offengelegt oder auf der Festplatte gespeichert ist.

Wir haben auch daran gearbeitet, den heute zusammengef├╝hrten Prozess Durchf├╝hren von Ressourcenpr├╝fungen w├Ąhrend des Bootstraps einzuf├╝hren. Dies fordert potenzielle neue Verbindungsknoten heraus, um sicherzustellen, dass sie ausreichend qualifiziert sind, um die Netzwerkarbeitslast zu teilen. Mit der ├ťberpr├╝fung der Ressourcenpr├╝fung werden alle neu verbundenen Knoten sofort als ÔÇ×ErwachseneÔÇť betrachtet - die Behandlung von ÔÇ×S├ĄuglingsÔÇť -Knoten ist jetzt nicht mehr erforderlich.

Wir haben auch an Aktualisierung des Refactoring-Abschnitts gearbeitet, um die Codebasis f├╝r die DKG-Behandlung zu vereinfachen. Die beiden vorgeschlagenen Haupt├Ąnderungen, um dies zu erreichen, sind:

  1. DKG-Fehler werden nicht mehr an die aktuellen Abteilungsleiter gemeldet, sondern starten sich selbst neu.
  2. Der separate DKG-Ergebnisakkumulator wird entfernt, stattdessen wird der regul├Ąre Stimmenakkumulator verwendet.

Nach den Diskussionen w├Ąhrend des ├ťberpr├╝fungsprozesses wurden jedoch weitere Probleme festgestellt, die wir l├Âsen m├Âchten. Daher wurde die PR in den Entwurfsstatus ge├Ąndert und wird voraussichtlich bald mit den Erg├Ąnzungen wieder zur ├ťberpr├╝fung bereit sein.

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 schaffen Sie gemeinsam das sichere Netzwerk!

1 Like