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!