Safe Network Entwickler Update đŸ‡©đŸ‡Ș 11. MĂ€rz 2021

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. :movie_camera:
  • @dimitar hat hinter den Kulissen gearbeitet, um mit einer Facebook- und Twitter-Werbekampagne das Bewusstsein fĂŒr sichere Netzwerke in Indien zu stĂ€rken. :heart:
  • 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! :bird:

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!