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_nodeodersn_authdwurden 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
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!