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