Safe Network Entwickler Update đŸ‡©đŸ‡Ș 10. Dezember 2020

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

Zusammenfassung

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

  • sn_client v0.44.0 wurde diese Woche veröffentlicht, die erste Veröffentlichung des Kunden seit Juli.
  • Wir haben die Implementierung der VervielfĂ€ltigung von Blob-Chunks abgeschlossen und zusammengefĂŒhrt, wenn ein Erwachsener das Netzwerk verlĂ€sst - jetzt in sn_node v0.25.9 veröffentlicht.
  • Unser Berater hat einen codierten, getesteten und funktionierenden Algorithmus fĂŒr die dynamische Mitgliedschaft entwickelt.

Allgemeines Update

Ein kurzes allgemeines Update unserer Fortschritte auf dem Weg zum bevorstehenden Testnetz.

Wir sind alle sehr bemĂŒht, alle Teile fĂŒr das kommende Testnetz zusammenzureißen. Wie erwartet gibt es einige Fehlerjagden und einige Last-Minute-ErgĂ€nzungen. Eine Sache, fĂŒr die wir keine Zeit haben, in dieses Testnetz aufzunehmen, ist die neue BRB-Mitgliedschaft (Byzantine Reliable Broadcast). Die BRB-Mitgliedschaft ist ein wirklich wichtiger Schritt, aber im Moment möchten wir so viele andere bewegliche Teile testen, dass wir uns darauf geeinigt haben, dass der Fokus darauf liegen sollte, diese Phase I so schnell wie möglich zu starten, damit wir uns voll und ganz auf BRB konzentrieren können.

Safe Client, Nodes und qp2p

Projektplan fĂŒr sichere NetzwerkĂŒbertragungen
Safe Client-Projektplan
Projektplan fĂŒr sichere Netzwerkknoten

Diese Woche gab es die erste Veröffentlichung und Veröffentlichung von sn_client seit Juli. Dieses Repository bestand frĂŒher aus verschiedenen Kisten zusammen unter dem Banner „Safe Client Libs“, aber wie regelmĂ€ĂŸige Leser hier zweifellos wissen werden, haben wir es stark ĂŒberarbeitet, was dazu fĂŒhrte, dass wir viele tausend Codezeilen entfernt haben, die wir als ineffizient und fehlerhaft empfanden oder unnötig. Dies ist jetzt eine einzelne „sn_client“ -Kiste, die zum ersten Mal unter diesem Namen veröffentlicht wurde. Dies verbindet sn_node und sn_routing in den letzten 2 Wochen in neuen bedeutenden Kistenversionen, und wir hoffen, dass dies die Fortschritte zeigt, die wir machen, wenn die HauptstĂŒcke anfangen, sich zusammenzufĂŒgen. Diese Version bedeutet nicht, dass wir mit sn_client fertig sind, sondern nur, dass wir es fĂŒr stabil genug halten, um eine Continuous Delivery-Pipeline einzufĂŒhren. 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 versucht, die Ursache eines StapelĂŒberlaufproblems aufzuspĂŒren, das insn_node aufgetreten ist. Es scheint zunĂ€chst keine spezifische Quelle zu geben, aber die Stapelverwendung ist im Laufe der Zeit einfach gewachsen. Dies geschah ursprĂŒnglich nur unter Windows, wo wir festgestellt haben, dass die StandardstapelgrĂ¶ĂŸe 1 Megabyte betrĂ€gt, was im Vergleich zu Ubuntu mit 8 MB niedrig ist. Durch Verringern der StapelgrĂ¶ĂŸe unter Ubuntu können wir dies replizieren, was gut ist. Daher haben wir dies weiter untersucht und Optionen, um dies zu verhindern.

Wir haben die Implementierung der Duplizierung von Blob-Chunks abgeschlossen, wenn ein Erwachsener das Netzwerk verlĂ€sst. Diese Funktion, die wĂ€hrend einiger Refaktoren im Repo „sn_node“ vorĂŒbergehend deaktiviert wurde, um Landwirtschaft und Belohnungen zu erzielen, ist jetzt mit der neuen Struktur des Codes kompatibel, der getestet und zusammengefĂŒhrt wurde. Diese Implementierung bildet auch die Grundlage fĂŒr die nĂ€chsten Aufgaben auf unseren Karten - die Verteilung von Daten zu Elder Churn, Werbeveranstaltungen und Netzwerkaufteilungen. Wir haben bereits einige Ideen und werden bald mit der Implementierung beginnen.

BRB - Byzantinische zuverlÀssige Sendung

Gute Nachrichten! Unser Berater hat einen funktionierenden Algorithmus fĂŒr die dynamische Mitgliedschaft entwickelt. Dies ist eine Originalarbeit, die eine Generationsuhr verwendet, bei der pro Akteur und Generation eine Join- oder Leave-Operation zulĂ€ssig ist. Dieser Algorithmus wurde bereits zusammen mit einer Testsuite codiert, und alle Tests bestehen.

Der nĂ€chste Schritt wird darin bestehen, es in die bestehende DSB-Implementierung zu integrieren. Am Ende werden wir also ein Protokoll fĂŒr die Aushandlung einer dynamischen Mitgliedschaft haben, das sich vom DSB-Protokoll fĂŒr die BFT-Übertragung regulĂ€rer Operationen / Daten unterscheidet, aber dieses ergĂ€nzt.

Routing

Projektplan

Diese Woche haben wir uns entschlossen, das Routing auf tracing anstelle der log-Kiste umzustellen, um unsere Protokollierung zu verbessern und das Debuggen zu erleichtern . Dies ermöglicht es uns, strukturierte Protokollierung und Bereiche zu verwenden. Die PR fĂŒr diesen Switch wurde jetzt zusammengefĂŒhrt. Wir beabsichtigen, in den kommenden Wochen auf die Verwendung von „Tracing“ in anderen Kisten umzusteigen.

Nach weiteren Diskussionen darĂŒber, wie und wann der Ressourcen-Proofing verwendet wird, haben wir entschieden, dass umgesiedelten Knoten vertraut werden sollte, sodass sie nicht dem Resou unterzogen werden mĂŒssenerneut prĂŒfen. Die PR Keine RessourcenprĂŒfung von verschobenen Knoten erforderlich wurde jetzt zusammengefĂŒhrt, um ein solches Verhalten zu ĂŒberarbeiten. In derselben PR haben wir auch einige Fehler und Testfehler behoben, die wir dank der verbesserten Protokollierung durch die oben erwĂ€hnte „RĂŒckverfolgungs“ -Kiste aufgespĂŒrt haben.

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!

1 Like