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

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

Zusammenfassung

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

  • Der Aufruf fĂŒr freiwillige Komiteemitglieder fĂŒr den BambooGarden Fund ist jetzt geschlossen! Wir haben 8 angesehene und erfahrene Komiteemitglieder aus der Community.
  • Nachdem das BambooGarden Fund Committee nun bestĂ€tigt wurde, werden wir KommunikationskanĂ€le einrichten und die ersten FondsantrĂ€ge einladen können.
  • Wir haben in der letzten Woche mehrere relativ kleine Änderungen an der Client-Codebasis vorgenommen, was dazu gefĂŒhrt hat, dass wir jetzt feststellen, dass die meisten Client-Tests in einem mehrteiligen Netzwerk konsistent bestanden werden.
  • Mit der Stabilisierung des Kunden konnten wir die Auszahlungen von PrĂ€mien wieder aktivieren und arbeiten jetzt an Problemen und Optimierungen.
  • Die Implementierung von Lazy Messaging wird auf breiter Front fortgesetzt.
  • Weitere Fragen gehen an die AMA und Eine weitere Antwort finden Sie im neuesten Video von @jimcollinson hier
  • Wir haben Anfang der Woche eine FunktionsĂŒbersicht fĂŒr das kommende Testnetz veröffentlicht.
  • 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:

BambooGarden Fund Update

Ein großes Dankeschön an alle Freiwilligen fĂŒr das BambooGarden Fund Committee. Wir hatten 8 Freiwillige, die ihre Zeit anboten, und daher halten wir dies fĂŒr einen guten Punkt, um das Komitee vorerst zu schließen und es auf einer ĂŒberschaubaren Anzahl zu halten.

Wir hatten ursprĂŒnglich vor, 3 Mitglieder des Community-Komitees gleichzeitig zu haben, beschlossen jedoch, dies zu Ă€ndern, um alle 8 dieser Freiwilligen im Komitee zu haben. Diese Änderung hat mehrere Vorteile, z. B. die Möglichkeit, die vielfĂ€ltigen Erfahrungen und Fachkenntnisse, die sie bieten, optimal zu nutzen. Es ist auch unvermeidlich, dass es Zeiten geben wird, in denen einige Ausschussmitglieder andere Verpflichtungen haben. Diese grĂ¶ĂŸere Anzahl bedeutet, dass wir unabhĂ€ngig davon nahtlos weitermachen können. Mitglieder können sich enthalten, wenn sie es nicht schaffen oder wenn sie nicht der Meinung sind, dass sie fĂŒr die Beurteilung eines Antrags qualifiziert sind, ohne befĂŒrchten zu mĂŒssen, dass sie den Ausschuss kurz verlassen.

Die Mitarbeiter von MaidSafe werden weiterhin rund 3 Mitglieder des Ausschusses bilden. Wir haben auch eine Bedingung hinzugefĂŒgt, dass MaidSafe das Recht auf ein „Veto“ bei FinanzierungsantrĂ€gen hat, dh das Recht, VorschlĂ€ge abzulehnen, von denen wir glauben, dass sie nicht den Zielen, Grundlagen und Werten von MaidSafe entsprechen oder die nicht t den ursprĂŒnglichen Zweck und die Ziele zu erreichen, fĂŒr die dieser Fonds geschaffen wurde und fĂŒr die MaidSafe als Garanten fungieren soll. Beachten Sie, dass ein Veto nur dazu dient, AntrĂ€ge abzulehnen, nicht um sie durchzusetzen, wenn der breitere Ausschuss sie abgelehnt hat.

All dies wurde den Freiwilligen des Komitees in den letzten Tagen zusammen mit einigen anderen wichtigen Entscheidungen mitgeteilt. Zum Beispiel wird das Komitee alle Mitglieder eines separaten Diskursforums sein, in dem wir ĂŒber AntrĂ€ge diskutieren und abstimmen können. MaidSafe hat auch einige unmittelbare Bereiche vorgeschlagen, die wir als dringend identifiziert haben, um Schritte zu unternehmen, um den Hauptzweck dieses Fonds zu erreichen, nĂ€mlich „das Tempo der Bereitstellung des sicheren Netzwerks zu beschleunigen“. Diese Bereiche sind:

  • Formale Dokumentation - Wir glauben, dass das Projekt von einer formalen Dokumentation unserer Algorithmen enorm profitieren wĂŒrde. Vielleicht könnte ein technischer Redakteur oder dergleichen, der Erfahrung im Schreiben formaler Algorithmen und Papiere hat, hier einen Wert bieten. Das Vorhandensein dieser formellen Dokumente hilft Entwicklern an Bord, sich zu engagieren, und hilft externen PrĂŒfern, die wir irgendwann bitten wĂŒrden, unseren Code auf SicherheitslĂŒcken, Fehler usw. zu ĂŒberprĂŒfen.
  • ZusĂ€tzliches CRDT-Fachwissen, um dies auf die nĂ€chste Stufe zu bringen.
  • ZusĂ€tzliche Konsenskompetenz.
  • ZusĂ€tzliche Netzwerkkenntnisse.

Wenn Sie Ideen fĂŒr FondsantrĂ€ge in diesen Bereichen haben, senden Sie sie noch nicht ein, aber Sie können anfangen, sie ein wenig genauer zu ĂŒberdenken, um den Antragsprozess zu eröffnen.

Wir schlagen außerdem vor, dass wir, sobald das Testnetz aktiv ist, nach Anwendungen fragen, um unser Engineering-Team generell zu vergrĂ¶ĂŸern, damit wir schneller vorankommen können. Der Grund, warum wir nach testnet hier sagen, ist, dass das Einsteigen neuer Ingenieure im Voraus eine Ablenkung von der Testnet-Arbeit wĂ€re.

In den nĂ€chsten Tagen werden alle Freiwilligen des Komitees zu einem separaten Diskursforum eingeladen, in dem wir einige der Richtlinien des Komitees gemeinsam formalisieren werden. Wir werden dann bekannt geben, dass wir bereit sind, unsere ersten FinanzierungsantrĂ€ge mit vollstĂ€ndigen Details zu den spezifischen Anfangsbereichen, wie z. B. den Outli-AntrĂ€gen, anzunehmenoben erwĂ€hnt, dass wir möchten, dass der erste Stapel von Anwendungen auf beschrĂ€nkt wird. Wir werden Ihnen auch ausfĂŒhrliche Informationen darĂŒber geben, wie Sie AntrĂ€ge einreichen und woraus wir erwarten, dass AntrĂ€ge bestehen.

Safe Client, Nodes, Routing und qp2p

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

Verbesserungen des Client-Codes

Nachdem die neuen Änderungen an der Aufteilung der Abschnittsmappe zu Beginn der Woche ĂŒber die Repos hinweg zusammengefĂŒhrt wurden, haben wir verschiedene Verbesserungen am Client-Code vorgenommen. Es gab einige kleine Refaktoren, um die Dinge zu vereinfachen, sowie Aktualisierungen, um mehr FlexibilitĂ€t bei Elder-Zahlen zu ermöglichen (da sie mit Änderungen der SupermajoritĂ€t zunehmen), aber auch, um dieselbe SupermajoritĂ€tsberechnung fĂŒr die Antwortbehandlung zu verwenden (dh erhalten wir die gleiche Antwort auf eine Anfrage von X Elders und kann daher darauf vertrauen). Wir haben auch einige Korrekturen fĂŒr Probleme hinzugefĂŒgt, die den Client daran gehindert haben, in einem Netzwerk mit mehreren Abschnitten auf den richtigen Abschnitt zu booten. Damit konnten wir feststellen, dass die meisten Client-Tests in einem mehrteiligen Netzwerk konsistent bestanden wurden.

Belohnung

Nach den oben genannten ZusammenfĂŒhrungen haben wir die Belohnungsauszahlungen wieder aktiviert und das Verhalten ĂŒber mehrere Teilungen hinweg ĂŒberprĂŒft. Es wurden einige kleine Probleme gefunden und behoben, und an einigen anderen wird noch gearbeitet, bei denen nach einigen Teilungen ein ĂŒbermĂ€ĂŸiger CPU- und Speicherverbrauch auftritt.

Obwohl die Belohnungsauszahlungen jetzt funktionieren, könnten wir sie anscheinend noch weiter vereinfachen. Daher werden wir versuchen, ein großes StĂŒck Logik fĂŒr die Auszahlung bei der Knotenverlagerung wegzuschneiden und stattdessen die Belohnungsauszahlungen in die Abschnittsmappe aufzunehmen Teilt.

Lazy Messaging

Daneben haben wir die Lazy-Messaging-Implementierungen in den Bibliotheken aktualisiert und sn_node an den aktualisierten Messaging-Code angepasst. Das Aktualisieren von „sn_routing“ fĂŒr diese Änderungen war eine große Aufgabe, da fĂŒr jede Routing-Nachricht jetzt ein eigener Header erforderlich ist, der die Details des Ziels enthĂ€lt, der vom EmpfĂ€nger auf Richtigkeit ĂŒberprĂŒft und zum Aktualisieren des Absenders oder EmpfĂ€ngers mit dem aktuellen Wert verwendet wird Netzwerkstatus, wenn sie zurĂŒckbleiben. Kernimplementierungen sind vorhanden und wir aktualisieren dort die letzten Tests. Sobald wir dies haben, können wir das Lazy-Messaging-Muster in sn_node erstellen, um eine einfache Handhabung der Aktualisierung von Knoten zu ermöglichen.

Routing Nachbarn

Beim Routing haben wir das Nachbarkonzept entfernt. Um sich zu erinnern, mĂŒssen Knoten Informationen ĂŒber andere Abschnitte im Netzwerk aufbewahren, damit sie (unter anderem) wissen, wie sie Nachrichten an sie senden können, und so weiter. FrĂŒher haben wir nur die Abschnitte behalten, die „Nachbarn“ unseres Abschnitts waren. Dies wurde willkĂŒrlich als diejenigen Abschnitte definiert, deren PrĂ€fix sich von unserem PrĂ€fix um genau ein Bit unterscheidet. Dies bedeutete, dass wir, wenn wir eine Nachricht an einen Bereich senden wollten, der nicht unser Nachbar war, diese ĂŒber unsere Nachbarn weiterleiten mussten. Wir haben vor langer Zeit erkannt, dass dies unnötige KomplexitĂ€t ist, und wir haben beschlossen, sie zu entfernen, und diese Woche haben wir es endlich geschafft. Jetzt speichern die Knoten Informationen ĂŒber alle Abschnitte im Netzwerk, sodass keine Weiterleitung erforderlich ist, da sie immer die endgĂŒltigen EmpfĂ€nger kennen. Dies vereinfacht das Design und verbessert die Leistung. Man könnte sich Sorgen machen, ob dies eine große Menge an Speicher erfordert, aber es stellt sich heraus, dass dies nicht der Fall ist. Wir haben berechnet, dass wir mehrere hunderttausend Abschnitte unterstĂŒtzen können, bevor der Speicher zum Problem wird. Wir werden uns mit diesem Problem befassen, wenn wir dort ankommen. Im Rahmen dieser Änderung haben wir auch die Lazy-Messaging-Logik ĂŒberarbeitet und in ein separates Modul extrahiert, wodurch wir weitere Komponententests hinzufĂŒgen und das Vertrauen in den Code erhöhen konnten.

API und CLI

Nachdem wir die Änderungen abgeschlossen hatten, die fĂŒr den neuen CRDT-Datentyp „Register“ in den Kisten „sn_node“ und „sn_client“ erforderlich sind, haben wir begonnen, die Codebasis „sn_api“ und ihre API anzupassen, um dies zu unterstĂŒtzen.

Der Hauptaspekt dieser Änderungen hĂ€ngt mit der Tatsache zusammen, dass wir dem Benutzer der API nun die Möglichkeit offenlegen wĂŒrden, auf Verzweigungen in den Daten zu stoßen. Diese Verzweigungen könnten unbeabsichtigt von der Anwendung verursacht worden sein, wenn mehrere Instanzen gleichzeitig Werte in dasselbe „Register“ schreiben, aber sie könnten sehr gut absichtlich von der Anwendung erstellt werden, beispielsweise eine Blockchain-Anwendung, bei der Gabeln einfach auftreten und ebenfalls aufgelöst werden.

Wir haben auch damit begonnen, alle unsere Abstraktionen (NRS, FilesContainer und Wallets) anzupassen, um diesen Datentyp zu verwenden. Hier sehen wir eine grĂ¶ĂŸere Herausforderung in Bezug auf UX, da das Lesen eines FilesContainer dazu fĂŒhren kann, dass mehr als ein Status angezeigt wird, wie oben erlĂ€utert. Daher suchen wir jetzt nach dem besten Weg, dies in unserer API verfĂŒgbar zu machen, damit der Benutzer und / oder Entwickler einer Anwendungon kann entscheiden, was in solchen Situationen zu tun ist. Beispielsweise kann der Endbenutzer aufgefordert werden, nicht nur zu entscheiden, welcher Zweig gelesen werden soll, sondern möglicherweise auch, wie er wieder zu einem einzigen Zweig zusammengefĂŒhrt werden soll. Wie Sie bereits sehen können, gibt es verschiedene Möglichkeiten, wie der Benutzer oder Entwickler das Auftreten von Verzweigungen in den Daten beheben möchte. Dies ist jetzt der Haupttreiber fĂŒr das neue Design dieser APIs.

Wenn es um die sichere CLI geht, mĂŒssen wir einige Entscheidungen darĂŒber treffen, welche Optionen dem Endbenutzer zum Auflösen von Datenzweigen angeboten werden sollen. Ein Beispiel hierfĂŒr ist, dass die CLI beim Abrufen eines FilesContainer mit zwei ungelösten ZustĂ€nden wahrscheinlich detaillierte Informationen zu diesen ZustĂ€nden anzeigen und den Benutzer entscheiden lassen kann, welcher nachgeschlagen werden soll.

CRDT

Wir haben die Forschung an der Bounded Counter-Arbeit fortgesetzt und diese Woche daran gearbeitet, sie byzantinisch fehlertolerant zu machen und einen PoC zu implementieren. Hoffentlich haben wir in der nÀchsten Woche etwas Konkretes, das wir an dieser Front teilen können.

Wir haben auch das Design fĂŒr ein neues MultiMap CRDT basierend auf dem MerkleReg ausgearbeitet. Dies wird wahrscheinlich die Grundlage fĂŒr NRS-Subdomain-Datentypen sowie eine flexible Struktur fĂŒr andere Anwendungen sein, die einen kartenĂ€hnlichen Datentyp benötigen.

Community & Marketing

Weitere Fragen gehen an die AMA und eine weitere Antwort auch. Diesmal geht @jimcollinson einen von @dimitar an: _Ist es fĂŒr den Online-Datenschutz zu spĂ€t? Haben sie nicht schon alle unsere Informationen? _

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!