Safe Network Entwickler Update 🇩🇪 11. März 2021

Dimitar · 12. März 2021 um 00:57

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

Zusammenfassung

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

Nachdem wir einige kleinere Refaktoren und Korrekturen durchgearbeitet haben, können wir jetzt alle unsere Rostkisten auf Tokio v1 aktualisieren.
Wir haben sn_routing diese Woche erneut besucht, um die Art und Weise zu ändern, in der eine Einigung erzielt wird, die jetzt eine Mehrheit (mehr als 2/3) anstelle einer einfachen Mehrheit (mehr als 1/2) erfordert. Wir glauben, dass dies notwendig war, um das Netzwerk gegen bestimmte Arten von Angriffen resistent zu machen.
Wir haben beschlossen, „Lazy Messaging“ in „sn_node“ zu implementieren, wobei die Arbeiten bereits im Gange sind. Dies war ursprünglich für Post-Testnet geplant, aber wir haben es als sinnvoll erachtet, dies vorzubringen.
@jimcollinson hat einen AMA on Reddit und rechts hier im Forum, letzte woche - es ist noch zeit, deine fragen zu stellen!
@jimcollinson hat die erste einer Reihe von YouTube-Videoantworten auf die größeren Fragen erstellt, die in der AMA eingegangen sind. Sie können sie hier ansehen.
@dimitar hat hinter den Kulissen gearbeitet, um mit einer Facebook- und Twitter-Werbekampagne das Bewusstsein für sichere Netzwerke in Indien zu stärken.
Behalten Sie regelmäßig den Thread Like This Tweet im Forum im Auge, um eine hervorragende Anleitung zur Förderung des sicheren Netzwerks zu erhalten umgebende Komponenten mit einem einfachen Knopfdruck!

Safe Client, Nodes, Routing und qp2p

Projektplan für sichere Netzwerkübertragungen
Safe Client-Projektplan
Projektplan für sichere Netzwerkknoten

Letzte Woche ist eine lang erwartete Veröffentlichung von Quinn mit einem wichtigen Upgrade eingetroffen: Tokio v1. Bisher hat uns die Verwendung einer älteren Version von Tokio in Quinn aufgrund inkompatibler Laufzeitversionen daran gehindert, alle unsere Kisten auf Tokio v1 zu aktualisieren. Daher sind wir dabei, alle unsere Kisten auf Tokio v1 zu aktualisieren. Mit einigen kleineren Refaktoren und Korrekturen konnten wir alle Tests mit der neuen Tokio-Version bestehen. Dieses Update hat uns auch dabei geholfen, ein zuvor unentdecktes Problem, bei dem Streams offen blieben zu identifizieren, das die Netzwerkkommunikation letztendlich blockiert, sobald die Obergrenze erreicht ist. Das Quinn-Team hat uns umgehend unterstützt und das Problem ist jetzt behoben in qp2p. Die Kommunikation von sn_routing funktioniert wieder einwandfrei! Wir erwarten, dass alle unsere Kisten in den nächsten Tagen aktualisiert werden.

Diese Woche haben wir auch weitere Beispiele zur qp2p-Kiste hinzugefügt, um die Verwendung der API besser zu demonstrieren und um qp2p sowohl lokal zu testen und auf Digital Ocean.

In sn_routing diese Woche haben wir beschlossen, die Art und Weise zu ändern, in der eine Einigung erzielt wird, um jetzt eine Mehrheit (mehr als 2/3) anstelle einer einfachen Mehrheit (mehr als 1/2) zu erfordern. Dies war notwendig, um das Netzwerk gegen bestimmte Arten von Angriffen resistent zu machen. Wir haben auch die Anzahl der Ältesten in einem Abschnitt von 5 auf 7 erhöht, was bedeutet, dass ein Abschnitt immer noch bis zu zwei Älteste verlieren und funktionsfähig bleiben kann. Diese Änderungen werden derzeit überprüft und getestet. Wir gehen davon aus, dass sie bald zusammengeführt werden.

Da Lazy Messaging aktiviert werden muss (siehe Unterabschnitt unten), haben wir uns überlegt, wie dies in sn_node am besten erreicht werden kann. Wir können vielleicht einige kleine Teile davon einarbeiten, aber wir sehen uns hier auch einen größeren Refaktor an, um die Dinge zu vereinfachen. Es sieht so aus, als ob ein Teil des „sn_node“ -Codes weg ist (im Wesentlichen „Duties“ entfernt) und Nachrichten direkt analysiert werden. Am Ende werden wir etwas finden, aus dem wir leicht Fehler machen können, während wir wahrscheinlich auch eine Menge „sn_node“ löschen Komplexität. Die ersten Bemühungen in diesem Bereich waren ziemlich positiv. Wir hoffen, dass dies keine so große Aufgabe ist, da die zugrunde liegende Logik gleich bleiben sollte, aber unabhängig davon nähern wir uns dem parallel zu leichteren Lösungen, sodass wir hoffentlich nichts blockieren.

`sn_node` Lazy Messaging

Lazy Messaging in sn_node würde funktionieren, indem die Größe der zwischen Knoten gesendeten Nachrichten geringfügig erhöht wird, sodass sie einige zusätzliche Informationen zum aktuellen Status des Netzwerks enthalten, die von verschiedenen Beobachtern in Raum und Zeit gesehen werden. Die Alternative zu diesem Ansatz wäre, ständig nach Veränderungen zu suchen - wir sind fest davon überzeugte dass die Kosten für zusätzliche Daten pro Nachricht mit der Verringerung des Gesamtverkehrs im Vergleich zu ständigen Abfragen mehr als ausgeglichen werden. Selbst wenn sich das Netzwerk in einer ruhigen Phase befindet, müsste die Abfrage im Hintergrund wütend im Hintergrund fortgesetzt werden. Andere Ansätze, um Teile des Netzwerks anzuhalten / anzuhalten, um eine Einigung zu erzielen, sind mit vielen Nebenwirkungen und komplexem Code behaftet, daher sind diese vom Tisch.

Als sehr kurze Übersicht: Wenn ein Knoten bei verzögertem Messaging eine Nachricht empfängt und feststellt, dass die * Netzwerkstatus * -Details in der eingehenden Nachricht von dem Status abweichen, von dem er glaubt, dass er der Status ist, kommuniziert er weiter mit dem sendenden Knoten, um sich selbst zu bringen. ** oder der Absender **, aktuell mit dem korrekten * Netzwerkstatus *, dann kann die ursprüngliche Nachricht entsprechend verarbeitet werden.

Lazy Messaging ist seit einiger Zeit in sn_routing implementiert und hat sich als effektiv und zuverlässig erwiesen. In sn_node standen wir in den letzten Wochen vor einigen Herausforderungen, um die Knoten mit den neuesten * Netzwerkstatus * -Änderungen (nach Abwanderung, Beförderung, Herabstufung usw.) auf den neuesten Stand zu bringen. Wenn sich beispielsweise ein Abschnitt teilt, standen wir vor der Herausforderung, die neuen Ältesten der jeweiligen neuen Geschwisterabschnitte mit den Ältesten des übergeordneten Abschnitts auf den neuesten Stand zu bringen und gleichzeitig die typischen erwarteten Verkehrs- und Netzwerkereignisse zu bewältigen.

Wir haben Lazy Messaging für eine Weile als Endziel markiert, aber bis jetzt als Post-Testnet-Optimierung betrachtet. Es ist jedoch ein harter Kampf mit den Herausforderungen, mit denen wir in den letzten Wochen konfrontiert waren, und dass wir Risse, von denen wir wissen, dass sie durch faules Messaging umfassend gelöst werden, mit einer scheinbar endlosen Menge temporären Putzes über Risse bringen. Wir haben uns daher entschlossen, hier keine Zeit mehr zu verschwenden und dieses Muster in sn_node zu verwenden, um den * Netzwerkstatus * auf jedem Knoten im Laufe der Zeit nach Bedarf zu aktualisieren.

Wie bereits erwähnt, ist dies zusätzliche Arbeit, von der wir nicht dachten, dass sie vor dem Testnetz erforderlich wäre, aber wir halten sie nicht für so groß, dass sie ein Testnetz zu stark verzögert. Und es ist ein weiterer Punkt, der auf dem Weg zu Beta & Launch von unserer * To-Do * -Liste gestrichen wurde.

CRDT

Die Arbeiten an einem begrenzten Zählertyp haben begonnen, mit dem Operationen auf einen Datentyp begrenzt werden können. Dies ist eine wertvolle Komponente, mit der veränderbare Daten kontinuierlich wachsen und Daten in Kompartimente eingeteilt werden können. Dies bedeutet, dass wir für das Hochladen des Datentyps zahlen und ihn dann bis zu einem begrenzten Punkt frei hinzufügen können. Zu diesem Zeitpunkt würde der Benutzer erneut zahlen und einen weiteren Satz von Operationsspeicherplatz freigeben. Durch die Aufteilung der wachsenden Daten auf diese Weise wird die Last auf das Netzwerk verteilt. Dies ist eine Optimierung, aber eine wichtige, die für den Start erforderlich ist, nicht jedoch für Fleming. Es ist schön, diese Nips und Tucks jetzt in der Pipeline zu sehen.

Wir haben seit der Migration auch Änderungen am Sequenzdatentyp vorgenommen, um das neue MerkleReg-CRDT zu verwenden, mit dem wir den gesamten Verlauf von Anhängen beibehalten und Datengabeln zulassen können, wenn der Endbenutzer oder die Anwendung sie generiert entweder absichtlich oder nicht. Dies wirkt sich darauf aus, wie unsere API dem Endbenutzer präsentiert werden soll, da es je nach Anwendungsfall Gabeln / Zweige von Anhängen geben kann, die der Benutzer möglicherweise nicht nur durchlaufen, sondern auch auflösen möchte. Daher arbeiten wir auch daran, unsere API auf der Clientseite anzupassen, um dem Benutzer alle Funktionen zu präsentieren, ohne sie komplizierter zu machen und ohne die Flexibilität und Leistung zu verlieren, die dieser neue CRDT-Datentyp für Anwendungen und Entwickler mit sich bringt.

Community & Marketing

@jimcollinson trat von einem AMA auf Reddit und rechts hier im Forum, letzte woche.

Das ursprüngliche Ziel war es, eine Reihe saftiger Fragen zusammenzufassen und sie in einer Frage-und-Antwort-Sitzung auf YouTube zu beantworten. Es gab eine großartige Antwort, und die Antworten auf viele Fragen erwiesen sich als weitaus detaillierter, als es eine einzelne Q & A-Sitzung möglicherweise könnte. Hier ist die erste Videoantwort in einer Serie, die wahrscheinlich zu einer Serie wird:

Bitte mögen, teilen, verteilen, verteilen, verbreiten, diskutieren und genießen Sie, wie Sie es für richtig halten. Und zögern Sie nicht, die Fragen zu beantworten.

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!