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

Dies ist eine maschinelle Übersetzung. Das Original in Englisch ist hier: Safe Network Dev Update - February 25, 2021

Zusammenfassung

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

  • Am Freitag, den 26. Februar (morgen) um 21.00 Uhr (GMT) findet ein virtuelles Community Safe Chat-Meeting statt. AusfĂŒhrliche Informationen hier.
  • Die Identifizierung und Beseitigung von Fehlern wird fortgesetzt, zusammen mit mehreren Effizienzverbesserungen, da wir diese Woche auf dem Weg zu einem öffentlichen Testnetz erhebliche Fortschritte erzielen.
  • Diese Woche wurden einige bedeutende „sn_routing“ -PRs zusammengefĂŒhrt, insbesondere PR # 2323, PR # 2328 und PR # 2336. Alle Details unten.
  • Zwei weitere wichtige „sn_routing“ -PRs, # 2335 und # 2336, beide kritisch fĂŒr ein stabiles Testnetz, werden jetzt angehoben und sollten in den kommenden Tagen ĂŒberprĂŒft und zusammengefĂŒhrt werden.
  • @scorch hat eine PR eingereicht, um (endlich!) „dieses Problem“ zu lösen, bei dem die Versionen der CLI selbst und die externen BinĂ€rdateien wie sn_node oder sn_authd wurden verwirrt.
  • Schauen Sie sich @bzee exzellentes Graben und Analysieren hier an, wĂ€hrend er versucht, das zu verbessern und zu aktualisieren Bindungen an Node.js.

Community Safe Chat: Freitag, 26. Februar, 21 Uhr GMT

Community-gesteuerte MarketingbemĂŒhungen werden dank der Arbeit von @sotros25, @m3data, @piluso und anderen fortgesetzt. UnermĂŒdliche Anstrengungen mĂŒssen wir sagen!

Es gab Diskussionen und Strategien im Forum und in kleinen Zoom-Meetings vorbei in den letzten Wochen, einschließlich dieser, in der wir einige der Marktforschungen von @sotros25 zu benachbarten Projekten diskutieren.

Wir freuen uns, diesen Freitag einen weiteren virtuellen Treffpunkt mit einer offenen Einladung fĂŒr alle Community-Mitglieder zur Teilnahme zu haben.

In den ersten 45 Minuten des GesprĂ€chs geht es um die Community-Marketing-Strategie. Danach werden wir das Wort fĂŒr eine breitere Diskussion ĂŒber das sichere Netzwerk eröffnen. Ziel ist es, die Marketingstrategie zu definieren und Inhalte aus diesen Diskussionen als Video zu verwenden, um Bewusstsein und Engagement zu schaffen.

Bitte beachten Sie, dass dieser Anruf aufgezeichnet, gestreamt und erneut gesendet wird, damit diejenigen, deren ZeitplÀne oder Zeitzonen nicht ganz funktionieren, dies nicht verpassen.

Alle Details und der Link zum Beitritt werden hier zur VerfĂŒgung gestellt.

Safe Client, Nodes und qp2p

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

Bei der Arbeit in dieser Woche ging es ausschließlich um die Stabilisierung von Netzwerken. Wir haben die Woche damit begonnen, ein merkwĂŒrdiges Verhalten zu untersuchen, das nur bei bestimmten aktivierten Protokollen beobachtet wurde. Dies fĂŒhrte uns schließlich zu einem kleinen Ausschnitt im Routing, bei dem wir fĂŒr die Dauer eines langen asynchronen Anrufs (Senden einer Client-Nachricht) eine Sperre hielten verursachte einen Deadlock in den Antworten. Es war schwierig herauszufinden; Aber als wir merkten, dass das Schloss als Teil der „if“ -Anweisung aufgerufen wurde, mussten wir das nur herausziehen und sicherstellen, dass das Schloss fallen gelassen wurde, sobald wir das hatten, was dort gebraucht wurde. Dadurch kamen die Kundenantworten erneut durch.

Nachdem die Änderungen an der Messaging-Infrastruktur letzte Woche abgeschlossen wurden, enthalten die Knoten keine Logik mehr fĂŒr die Aggregation von Signaturen. Dies hĂ€ngt vollstĂ€ndig von der FĂ€higkeit des Routings ab, dies zu tun. Bisher hatten wir nur eine Aggregation an der Quelle, bei der das Routing die Signaturen bei den Ältesten aggregierte, bevor sie an das Ziel gesendet wurden. Dies fĂŒhrte dazu, dass die Nachricht mit der aggregierten Signatur mehrmals an das Ziel gesendet wurde und Duplikate am Zielknoten herausgefiltert wurden. Durch Verschieben der Signaturaggregation an das Ziel können wir die Last der Ältesten verringern und die Anzahl der ausgetauschten Nachrichten erheblich reduzieren. Wir haben UnterstĂŒtzung fĂŒr Zielakkumulation im Routing hinzugefĂŒgt und in sn_node verwendet ) fĂŒr die Kommunikation zwischen einem Abschnitt und seinen Erwachsenen, die einen Block halten. Mit den beiden oben genannten Korrekturen haben wir jetzt alle Client-Tests, die fĂŒr einen einzelnen Abschnitt mit einem massiv vereinfachten Knotencode bestanden wurden. Es ist jedoch eine Folge-PR erforderlich, um einen zusĂ€tzlichen Anwendungsfall abzudecken, der zwischen Ältesten in einem Abschnitt und Ältesten in einem anderen Abschnitt, einem Teil des Belohnungsflusses, kommuniziert wird (da die Mittel des Abschnitts von einem Abschnitt verwaltet, aber gehalten / verifiziert werden in einem anderen Abschnitt). Dies wird behandelt, wĂ€hrend wir sprechen und sollte vor Ende der Woche zusammengefĂŒhrt werden.

In diesem Zusammenhang erhalten wir mit einem kleinen Update einiger Routing-Ereignisse jetzt unseren Abteilungsgeschwister „PublicKey“ aufgespalten, damit wir wissen, wohin Token gesendet werden mĂŒssen, um die resultierenden untergeordneten Abschnittsmappen zu fĂŒllen. Nach einigen weiteren Flow-Debugging-VorgĂ€ngen scheint dies zu laufen, und wir debuggen jetzt eine kleine Routing-Schleife beim Teilen, bei der Abschnittsinformationen nicht richtig erkannt werden und wir dieselben (falschen) Informationen wiederholt an eine neue weitergeben Knoten. Wir ĂŒberarbeiten auch das Kommunikationsmuster zwischen Clients, Knoten und ihren Abschnitten, bei denen zuvor veraltete AbschnittsschlĂŒssel Fehler in den Belohnungen und ÜbertragungsablĂ€ufen verursachten. Daher werden wir jetzt die ÜberprĂŒfung und Aktualisierung des PublicKey-Wissens mit jeder Nachricht erzwingen, die ĂŒber das Netzwerk gesendet wird, und folglich alle Peers mit den neuesten Kenntnissen des Netzwerks auf dem neuesten Stand halten.

ZunĂ€chst wird die Aufteilung der Abschnittsmittel eine Überweisung nach der anderen sein, da wir immer noch keine Eins-zu-Viele-Überweisungen haben und die Verkettung eine triviale Aufgabe war, die fĂŒr ein Testnetz gut genug funktionierte. Mit dem Refactor von „TransferAgreementProof“ vor einigen Monaten in eine signierte Lastschrift und eine signierte Gutschrift können wir jetzt relativ einfach „Eins-zu-Viele“ -Transfers implementieren, indem wir eine Reihe von Gutschriften hinzufĂŒgen. Ein Goodie fĂŒr spĂ€ter :).

Als Aufgabe mit niedrigerer PrioritÀt und parallel zu den oben genannten haben wir begonnen, das Upgrade auf eine neue Version von Quinn vorzubereiten ermöglicht uns endlich ein Upgrade auf stabiles Tokio v1. Wir haben es gerade ausprobiert und bereiten die PRs auf diese Migration vor, sobald Quinn Release v0.7.0 veröffentlicht wird.

Eine weitere Verbesserung, die es in dieser Woche geschafft hat, betraf die Löschung privater Daten. Vor den neu zusammengefĂŒhrten Änderungen in self_encryption und sn_client ) bedeutete das Löschen eines privaten Blobs das Löschen nur des Root-Blobs, der die Datenkarte der tatsĂ€chlichen Daten war, die selbst verschlĂŒsselt und im Netzwerk gespeichert sind. Unser jĂŒngster Neuzugang im Team, @kanav, hat einen rekursiven Löschansatz implementiert, bei dem die einzelnen Blöcke zusammen mit den Blöcken, in denen die Datenkarte (n) gespeichert sind, gelöscht werden, wodurch das Löschen im wahrsten Sinne des Wortes erreicht wird.

API und CLI

@scorch hat eine PR ĂŒbermittelt, um die Option „-V“ aus den CLI-Unterbefehlen zu entfernen, um Verwechslungen zwischen der Version der CLI selbst und der Version von zu vermeiden externe BinĂ€rdateien wie „sn_node“ oder „sn_authd“. Diese Änderung beinhaltete auch das HinzufĂŒgen eines Unterbefehls „bin-version“ zu den Unterbefehlen „$ safe node“ und „$ safe auth“, um die Version der externen BinĂ€rdateien abzurufen, damit die Semantik klar ist, sowie die Unterscheidung zwischen der CLI version und sn_node oder sn_authd version.

Derzeit ist die Bibliothek qjsonrpc implementiert, um den JSON-RPC 2.0-Standard zu unterstĂŒtzen. Es gibt jedoch bestimmte Fehlercodes, die in der Spezifikation definiert sind und von der Kiste nicht freigelegt wurden. Dies bedeutet, dass Verbraucher dieselben Konstanten selbst neu definieren mĂŒssen, was nicht erforderlich ist, da sie in gewissem Sinne Teil der Implementierung sind. Aus diesem Grund hat @scorch auch eine PR ĂŒbermittelt, um diese Fehlercodes als Konstanten von qjsonrpc verfĂŒgbar zu machen.

Wie im vorherigen Abschnitt erwÀhnt, haben wir auch versucht, uns auf ein Upgrade auf Tokio v1 vorzubereiten. Daher haben wir die CLI- und Authd-Kisten durch einige Vorversuche auf ein solches Upgrade vorbereitet.

CRDT

Wir haben die CRDT, die dem Sequenztyp in sn_data_types zugrunde liegt, wiederholt . Zuvor wurde Sequence mit LSeq implementiert. Wir haben eine einfachere Liste ausprobiert, um einige Paniken mit tiefen EinfĂŒgungen zu lösen, und sind dann zu GList ĂŒbergegangen. zur UnterstĂŒtzung des Nur-Wachstum-Anwendungsfalls. Bei der Analyse fĂŒhren alle diese CRDTs keine Modellversionierung durch, wie wir es gerne hĂ€tten. Sie versuchen, die Reihenfolge der Dokumente zu linearisieren, wenn in Wirklichkeit ein Dokumentverlauf eine DAG bildet. Wir haben ein Design fĂŒr ein Merkle-DAG-Register CRDT, mit dem wir die Dokumenthistorie originalgetreu modellieren und die aktuellsten Versionen lesen können.

Wir haben auch damit begonnen, die VerĂ€nderbarkeit der Richtlinien aus unseren verĂ€nderlichen Datentypen zu entfernen, d. H. Aus unseren CRDT-basierten Datentypen wie Sequence. In unserer aktuellen Implementierung haben wir versucht, alle Arten von Konflikten zu lösen, die durch gleichzeitige Richtlinienmutationen in CRDT-Daten entstehen können. Dies hat sich als ziemlich kompliziert erwiesen, ohne alle möglichen Szenarien fĂŒr die Konfliktlösung abzudecken. Aus diesem Grund haben wir uns entschlossen, einen anderen Ansatz zu wĂ€hlen, bei dem Richtlinien unverĂ€nderlich werden, sobald sie vorliegenSie wurden bei der Erstellung eines Inhalts definiert. Das Ändern einer Richtlinie bedeutet dann, dass der Inhalt mit der neuen Richtlinie auf eine neue Adresse geklont wird. Schließlich kann ein Mechanismus zum VerknĂŒpfen dieser verschiedenen Instanzen erstellt und von den Anwendungen nur von Fall zu Fall verwendet werden.

BRB - Byzantinische zuverlÀssige Sendung

Unser Versuch, den Prototyp des Dateisystems sn_fs in BRB zu integrieren, hat einige Ecken und Kanten aufgedeckt. Der Grund dafĂŒr ist, dass sn_fs Operationen vom Betriebssystemkern schneller empfĂ€ngt, als sie von BRB angewendet werden können. Zu diesem Zweck haben wir einige verwandte Lösungen entwickelt: 1) Umgehen der Netzwerkschicht beim Senden einer Operation an sich selbst und 2) Verfolgen, wann Peers ProofOfAgreement erhalten haben, damit wir das Senden der nĂ€chsten Operation bis 2 vermeiden können / 3 von Peers haben die aktuelle Operation angewendet. Dies ist erforderlich, um die Anforderungen an die Quellenbestellung von BRB zu erfĂŒllen. Quellenreihenfolge bedeutet, dass Operationen, die von derselben Quelle (Akteur) stammen, nacheinander geordnet werden mĂŒssen. Operationen von vielen verschiedenen Akteuren können jedoch gleichzeitig verarbeitet werden.

Ebenfalls im Rahmen der sn_fs-Integration haben wir die brb_dt_tree-Kiste geĂ€ndert, um das Senden mehrerer Baumoperationen innerhalb eines einzelnen BRB-Ops zu unterstĂŒtzen. Dies gibt uns effektiv eine atomare Transaktionseigenschaft fĂŒr die Anwendung logisch verwandter CRDT-Operationen auf Alles-oder-Nichts-Weise. Wir beabsichtigen, dasselbe Muster in anderen BRB-Datentypen zu verwenden.

Routing

Projektplan

Diese Woche haben wir eine PR zusammengefĂŒhrt Änderung der Art und Weise, wie Client-Nachrichten behandelt werden, sodass sie jetzt wie Knotennachrichten ĂŒber das Netzwerk geleitet werden können. Dies bedeutet, dass ein Client eine Anfrage außerhalb seines Abschnitts senden und eine Antwort zurĂŒckerhalten kann, auch wenn der Client aufgrund restriktiver NAT- oder Ă€hnlicher Probleme von den EmpfĂ€ngern der Anfrage nicht direkt verbunden werden kann.

Wie im obigen Abschnitt „Knoten“ beschrieben, haben wir auch Ansammlung von Nachrichtensignaturen am Zielort implementiert, sodass die Benutzer des Routings diesen Fluss nicht mehr manuell implementieren mĂŒssen , was zu einfacherem Code fĂŒhrt.

Schließlich wird die Gabelauflösungs-PR jetzt ĂŒberprĂŒft. WĂ€hrend der Arbeit an dieser PR haben wir einige zusĂ€tzliche Fehler entdeckt, die nicht mit der Gabelhandhabung zusammenhĂ€ngen. WĂ€hrend der ganzen Woche waren wir damit beschĂ€ftigt, sie zu debuggen, und bis heute haben wir sie anscheinend grĂ¶ĂŸtenteils alle behoben. Die Ergebnisse der internen Stresstests sehen sehr vielversprechend aus. Außerdem haben wir es geschafft, ein Localhost-Netzwerk mit ** 111 (!) Knoten ** auf einem einzelnen Computer zu betreiben, und alles verlief reibungslos. Eine PR mit diesen Korrekturen befindet sich derzeit im Status * Entwurf * und sollte bald zur ÜberprĂŒfung bereit sein.

NĂŒtzliche Links


FĂŒhlen Sie sich frei, unten mit Links zu Übersetzungen dieses Entwicklungsupdates 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!