Safe Network Entwickler Update 🇩🇪 11. August 2022

Dies ist eine maschinelle Ăśbersetzung. Das Original in Englisch ist hier: Update 11 August, 2022

Da die Aktivitäten in mehreren unterschiedlichen, wenn nicht gar nicht zusammenhängenden Bereichen andauern, dachten wir, es wäre ein guter Zeitpunkt für eine Zusammenfassung des Gesamtzustands des Projekts, der die wichtigsten Arbeitsstränge abdeckt, wo sie sich befinden und wie sie miteinander verbunden sind.

Allgemeiner Fortschritt

@yogesh hat die Konfiguration des ElasticSearch/Kibana-Servers optimiert, damit wir unsere Droplets einfacher überwachen können, und stellt die Dokumentation für „traceroute“ fertig.

@joshuef hat einen Prozess in sn_node entdeckt, der etwa 1/3 der CPU-Zeit verbraucht und wahrscheinlich unnötig ist, da wir diese Funktionalität an anderer Stelle implementiert haben, also sieht er, was passiert, wenn wir ihn entfernen.

@oetyng und @davidrusu waren federführend bei der Konzeptualisierung der „Genesis DBC“-Erstellung und Auszahlungen, die das Team diese Woche ausgearbeitet hat (siehe unten), während @anselme sich in der Endphase des Refactorings von DKG befindet, wobei Multithreading der Einfachheit halber entfernt wurde , sowie das Entfernen von Zeitüberschreitungen (siehe unten).

Aktivitätsaufschlüsselung

Mitgliedschaft, AE und Konsens – die Punkte verbinden

Bei Mitgliedschaft und Anti-Entropie (AE) geht es darum, dass das System auf dem neuesten Stand bleibt, während Konsens verwendet wird, um Entscheidungen zu treffen, die die Zusammensetzung eines Abschnitts und/oder die darin enthaltenen Daten ändern.

Jede Systemnachricht, die über das Netzwerk gesendet wird, enthält den Abschnittsschlüssel. Der Client sendet das, was er für den aktuellen Abschnittsschlüssel hält, wenn er zum ersten Mal mit dem Abschnitt kommuniziert, und wenn er veraltet ist, senden ihm die Abschnittsältesten den aktuellen Schlüssel im Abschnittsautoritätsanbieter (SAP), die auch eine Liste der Ältesten in der Sektion enthält, damit sie ihre Aufzeichnungen aktualisieren kann, bevor sie es erneut versucht. Das ist AE.

Wir erwägen jetzt auch, Mitgliedschaft in diesen Informationsaustausch aufzunehmen, um die Lücke zwischen dem, was die Nodes verstehen und worüber sie abstimmen, und dem, was innerhalb des SAP geteilt wird, zu schließen. Sie erinnern sich vielleicht, dass Älteste über die Mitgliedschaft die Erwachsenen und anderen Ältesten in ihrer Sektion im Auge behalten, damit sie neue Beitritte, Trennungen, Abwanderungen und Beförderungen handhaben können.

Insbesondere wenn wir Zahlungen an einzelne Erwachsene betrachten, geht es schneller, wenn wir wissen, wo sie sich befinden – Erwachsene wechseln schneller als ältere Menschen und wurden möglicherweise in eine andere Abteilung versetzt oder befördert. Darüber hinaus haben Erwachsene ein „Knotenalter“, und ihre Zahlung wird proportional dazu sein. Wir sehen uns also an, wie wir einige Informationen über die aktuelle Generation der Erwachsenen der Sektion in Nachrichten über Speicherung und Zahlungen aufnehmen können.

Erwachsene können ihre Zahlungen jederzeit einfordern, auch wenn sie Abschnitte verlegt haben usw., da der DBC auf ihren öffentlichen Schlüssel neu ausgestellt wird und sie nachweisen können, dass sie sich zu diesem bestimmten Zeitpunkt als Teil dieser bestimmten Generation in dem Abschnitt befanden. Bei dieser Maßnahme geht es also eher darum, die Anzahl der herumfliegenden Nachrichten zu reduzieren.

Wir haben nicht nur die Mitgliedschaft in den Informationsaustauschprozess aufgenommen, sondern auch einen Konsensmechanismus in seine Funktionsweise eingeführt. Die Mitgliedschaft verwendet Konsens, um Mitglieder in einem Abschnitt auf synchronisierte Weise zu akzeptieren und zu entfernen. Es stellt sicher, dass alle Ältesten die gleiche Ansicht über die Reihenfolge der Joins und Leaves in der Sektion haben. Dies dient dazu, Inkonsistenzen im Mitgliedersatz jedes Ältesten zu vermeiden, da das Mitgliederänderungsprotokoll eine reine Anhängekette ist, bei der ein Konsens mit Supermajorität erforderlich ist, um ein neues Element hinzuzufügen.

Anrufzeit bei Timeouts – mehr Sicherheit bei DGK-Runden

Im Allgemeinen verwendet die DKG keinen Konsens, stattdessen stellen die DKG-Teilnehmer sicher, dass niemand schummelt, indem sie signierte Nachrichten versenden, und sobald sie alle Nachrichten der anderen erhalten haben, senden sie ein Set mit den Nachrichten aller und stellen sicher, dass alle dasselbe Set signieren. Bei einer einzigen Unstimmigkeit hören sie auf, an dieser DKG-Runde teilzunehmen, sie gilt als gescheitert und wir erreichen in dieser Runde nie einen Konsens. Dies stellt sicher, dass eine DKG-Runde mit betrügerischen Mitgliedern niemals beendet wird, wir wollen schließlich keine Betrüger als Älteste.

Viele DKG-Runden können gleichzeitig stattfinden, und es ist ein Rennen zwischen ihnen, um die Beendigung zu erreichen (oder auszusterben). Wenn wir eine fertige DKG haben, kann der Übergabekonsens beginnen und über die nächsten Ältesten entscheiden. Da die Übergabe einen Konsens verwendet, wird sichergestellt, dass nur ein DKG-Ergebnis ausgewählt wird, sodass wir mehrere gleichzeitige DKG-Abschlüsse haben können, aber nur einer davon für die Übergabe ausgewählt wird.

Mit der verteilten Schlüsselgenerierung (DKG) erstellen Älteste den Abschnittsschlüssel auf sichere Weise, wobei jeder Älteste nur seinen eigenen Schlüsselanteil kennt. Beim Testen haben wir einige Fälle gefunden, in denen DKG aufgrund der Verwendung von Zeitüberschreitungen beim Warten auf Nachrichten inkonsistent fehlschlug und es erneut versuchte.

Wir überarbeiten unser DKG mit einer saubereren, timerfreien Implementierung. Wenn beispielsweise die ältesten sieben Knoten in einem Abschnitt nicht die aktuellen Ältesten sind, versuchen sie einen DKG-Lauf, um einen neuen Abschnittsschlüssel zu erstellen. Wenn nicht alle älteren Kandidaten teilnehmen, erlauben wir, dass diese DKG nicht beendet wird, und das ist in Ordnung, weil wir nicht wollen, dass inaktive Knoten Älteste werden. Wir können warten, bis eine weitere Mitgliederabwanderung auftritt und eine weitere DKG auslöst. Wir begrüßen es, c zu habenaktuelle DKGs rennen darum, die neuen Ältesten zu werden. Der Übergabekonsens entscheidet, wer letztendlich gewinnt.

@anselme hat viel Zeit damit verbracht, DKG zu bereinigen, nicht benötigte Nachrichtentypen aus dem DKG-Code zu entfernen und das neue DKG zu integrieren. Es sieht jetzt viel besser aus und wir werden es bald testen können.

Knotenänderungen

Wir haben einige Änderungen an unserer sn_node-Binärdatei vorgenommen. Jetzt müssen Sie den Kontaktdateipfad an jeden Knoten weitergeben, der einem Netzwerk beitritt (--network-contacts-file). Anstatt dass der Knoten erwartet, dass irgendwo Kontakte gefunden werden, sind andere Tools dafür verantwortlich, sicherzustellen, dass der Pfad zum Knoten bereitgestellt wird.

Wir haben unser sn_launch_tool aktualisiert, um dies zu tun. Wenn Sie es also verwenden (oder die CLI, die davon Gebrauch macht), stellt das Tool jetzt jedem beitretenden Knoten den Pfad zu --network-contacts-file bereit.

--network-contacts-file ist einfach eine Datei, die einem beitretenden Knoten oder Bootstrapping-Client die Informationen gibt, die er benötigt, um dem Netzwerk beizutreten. Diese Informationen befinden sich im SAP und im SAP-Teil von PrefixMap.

Für neue Knoten verwenden wir die PrefixMap-Datei des Genesis-Knotens, um diese Informationen bereitzustellen (sie befindet sich unter ~/.safe/node/local-test-network/sn-node-genesis/prefix_map), aber das Tool kopiert diese auch Datei an den Ort, an dem die Clients/CLI sie standardmäßig finden (~/.safe/prefix_maps/default).

Wir können die gleiche „PrefixMap“ verwenden, um sowohl einem Knoten zu erlauben, einem Netzwerk beizutreten, als auch einem Client, sich mit dem Netzwerk zu booten, da es die SAPs enthält, mit denen sie sich verbinden können. Aus ihrer Sicht ist es dasselbe wie eine Netzwerkkontaktliste.

In Zukunft können Clients und Knoten andere Arten von Dateien und Formaten unterstützen. Was auch immer sich dort ändert, sie benötigen immer eine Netzwerkkontaktliste, um sich mit einem Netzwerk zu booten/zu verbinden.

Wie in einem aktuellen Update beschrieben, entwickelte sich „PrefixMap“ kürzlich von einer einfachen Datei, die Abschnittspräfixe den aktuellen SAPs zuordnet, zu a komplexere Struktur, die den vollständigen Abschnittsschlüssel DAG/Baum enthält - daher wird diese Datei wahrscheinlich bald umbenannt.

Abschluss der Netzwerkauszahlung der 70 %-Prämien

70 % der SNT werden letztendlich vom Netzwerk erstellt, wenn Clients Daten hochladen.

Wenn Kunden Daten hochladen, müssen sie zuerst die Abschnitte bezahlen, in denen die Daten gespeichert werden. Diese Zahlungen werden zwischen den Knoten in jedem Abschnitt geteilt (höchstwahrscheinlich die Ältesten und Erwachsenen, die die angegebenen Daten speichern, anteilig basierend auf dem Alter.

Ein bestimmter Anteil (zu entscheiden) der Zahlungen wird jedoch auch zur Prägung neuer SNT in Form eines DBC führen. Der Gesamtwert des neuen DBC entspricht dem Zahlungsbetrag. Der neue DBC wird von allen Knoten im Abschnitt gemeinsam genutzt.

Um diejenigen Zahlungen auszuwählen, die zu einem neuen SNT führen, wird ein Test durchgeführt, beispielsweise eine Art Übereinstimmung, die einen Hash der Zahlung und das Präfix der Abschnittsadresse umfasst. Die Wahrscheinlichkeit, den Test zu bestehen, hängt von der gewünschten Rate der SNT-Erzeugung (früher die Farming-Rate) ab.

Älteste prüfen jede Zahlung, um zu sehen, ob sie diesen Test besteht. Der Anreiz für diese Prüfung (die schnell ist und minimale Ressourcen erfordert) ist die Chance, SNT zu verdienen. Die meisten Zahlungen bestehen den Test nicht und werden wie gewohnt fortgesetzt, aber wenn es eine Übereinstimmung gibt, verwenden die Ältesten diese Zahlung, um einen „Genesis DBC“ zu prägen. Dieses Genesis DBC ist brandneu und erhöht den Gesamtbetrag an SNT, der ausgegeben werden kann. Sein Gesamtbetrag ist derselbe wie der Betrag der Upload-Zahlung, und sein Wert wird auf alle Knoten im Abschnitt aufgeteilt, gewichtet nach dem „Knotenalter“.

Damit ein DBC ausgegeben werden kann, muss er auf die öffentlichen Schlüssel des/der neuen Eigentümer(s) neu ausgestellt werden. Dazu übergeben wir den „Genesis DBC“ an den Client zurück und lassen ihn neue DBCs an die Knoten ausgeben – plus einen DBC an sich selbst als Anreiz. Die Höhe dieses Anreizes muss ausgearbeitet werden.

Sobald die DBCs neu ausgegeben wurden, werden die Empfängerknoten benachrichtigt und können nun ihre DBC ausgeben, wie und wann sie es wünschen.

Das Prägen neuer SNT erfolgt nur mit neuer Datenspeicherung. SNT-Übertragungen führen nicht dazu, dass ein neuer DBC erstellt wird.

Wir werden wahrscheinlich den Namen „Genesis DBC“ ändern, da es viele solcher DBCs gibt, sodass das Wort „Genesis“ verwirrend ist.

Landwirtschaft abschlieĂźen/Lagerung bezahlen

Da das Konzept der Token-Emission gut vorankommt, können wir auch sehen, wie unsere Pläne für Datenzahlungen passen, und wir sehen glücklicherweise, dass sie ziemlich gut passen. Es ist ein Ablauf, über den wir bereits gesprochen haben, bei dem Kunden Angebote aus dem Abschnitt für einen bestimmten Datensatz anfordern und dann die entsprechenden Zahlungen dafür leisten. Das Schöne ist, dass dies von Natur aus gestapelt ist, sodass ein Satz von DBC-Neuausgaben für jede Datenmenge funktionieren kann.

Dieser Prozess gibt uns eine Quittung, mit der wir bestätigen können, dass ein bestimmtes Datenelement bezahlt wurde, und die wir an die Daten anhängen können, um sie effektiv „Network Valid“ zu machen, dh sie können erneut hochgeladen werden, ohne dafür bezahlen zu müssen es zum Beispiel.

Diese Quittung bildet dann einen Teil des oben beschriebenen Netzwerkauszahlungsprozesses.

Verwendung von Klatschrunden fĂĽr sektionsinterne Mitgliedschaften undAbschnittsĂĽbergreifende Aktualisierung von PrefixMap

Wir führen einen Gossip-Ansatz für die neue SAP-Erstellung ein, um sicherzustellen, dass das Netzwerk immer von allen Bereichen aus erreichbar ist. Dieser Mechanismus stellt sicher, dass Informationen logarithmisch verteilt werden (sehr schnell und effizient). Wenn ein Ältester einen neuen SAP aus einem beliebigen Teil des Netzwerks erhält, wählt er zwei zufällige Älteste aus einem beliebigen Abschnitt aus und leitet die Nachricht an sie weiter. AE stellt sicher, dass die Knoten in beide Richtungen aktualisiert werden, und beendet auch die Klatschrunde. Das ist „Intersektionsklatsch“ und betrifft nur Älteste.

Innerhalb des Abschnitts haben wir Mitgliedschaftsänderungen, die Erwachsene einschließen. Diese Änderungen folgen dem gleichen Muster, um sicherzustellen, dass alle Mitglieder über alle Mitgliedschaftsänderungen auf dem Laufenden sind. Das ist „Sektionsinterner Klatsch“.


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!