Safe Network Entwickler Update 🇩🇪 13. April 2023

Dies ist eine maschinelle Übersetzung. Das Original in Englisch ist hier: Update 13 April, 2023

Hat jemand Lust auf einen tieferen Tauchgang?

Vor ein paar Wochen gab uns @oetyng ein Update zu Designs für ein Zahlungsnetzwerk und wie das allein funktionieren könnte.

Da sich der Tech-Stack des Netzwerks jetzt in einem Tempo weiterentwickelt, das wir noch vor zwei Wochen nicht vorhersehen konnten, haben wir uns den Spielraum und die Flexibilität gegeben, eine Vielzahl von Wegen für die Einführung zu verfolgen, sei es ein reines Zahlungsnetzwerk oder ein Aufbruch für das volle Datennetz von Anfang an.

Daher besucht @oetyng die Welt der Zahlungen erneut, um zu erklären, wie sie mit Speicher, Wallets und Client-APIs im neuen vereinfachten Design integriert werden.

Zunächst aber ein Wort dazu, wie sich das Netzwerk entwickelt, wenn wir vom Abschnittsdesign zu Kademlia wechseln. Kademlia erfordert, dass Knoten im gesamten Netzwerk miteinander kommunizieren, und nicht nur mit denen in ihrem Abschnitt. Andernfalls würde die Routing-Tabelle bald veralten und voller toter Knoten sein, und das Netzwerk würde aufgrund einer schlimmen Fehlkommunikation sterben. Die Überprüfung der DBC-Eltern ist eine Möglichkeit, ständig sicherzustellen, dass die Knoten aktiv sind und gleichzeitig eine wichtige Funktion erfüllen, sodass wir dort verdoppeln können.

Transaktionen erfolgen sehr schnell über das Netzwerk, aber Safe ist keine Datenbank und nicht für schnelle Datenmutationen geeignet. Diese Art von Arbeit wird clientseitig erledigt, wobei die Ergebnisse dann auf Safe gespeichert/repliziert werden. CRDTs bedeuten, dass Kunden effektiv, in Echtzeit und konfliktfrei zusammenarbeiten können und die Ergebnisse dieser Zusammenarbeit öffentlich oder privat auf Safe for Nachwelt gespeichert werden können. Der Umzug nach Kademlia verdeutlicht diese Arbeitsteilung.

Ein weiteres Ergebnis der Änderung ist, dass kleine Testnetze wahrscheinlich nicht stabil sind. Das neue Design wird wahrscheinlich 2.000 oder mehr Knoten benötigen, um richtig zu funktionieren. Das ist überhaupt kein Problem, wird aber offensichtlich die Art und Weise verändern, wie wir Testnetze betreiben.

Allgemeiner Fortschritt

Während wir darauf zusteuern, etwas für den öffentlichen Gebrauch freizugeben, arbeitet Jim an der Positionierung, Roadmaps und Nachrichtenübermittlung. Sehen Sie sich seinen Thread What is launch an, falls Sie es noch nicht getan haben.

An diesem Tag in Sicht hat sich @bzee mit NAT-Traversal beschäftigt und wie wir es implementieren können, und @bochaco bereitet unsere Datentypen für die Integration in die neue Netzwerkinfrastruktur vor, einschließlich der Arbeit an APIs, damit Entwickler so schnell wie möglich mit Apps beginnen können da wir etwas stabiles haben. Bochaco sieht sich auch Fehlermeldungen an, um zu sehen, wo wir sie spezifischer und hilfreicher machen können.

Die andere große Arbeit besteht darin, enge Gruppen auszusortieren. Angesichts des Namens eines Datenblocks (derselbe wie seine XOR-Adresse) weiß der Client, welche k Knoten er fragen muss, um ihn abzurufen, aber sollten wir mit 20 beginnen oder so etwas wie 8? Mehr bedeutet, dass mehr Knoten ihre Routing-Tabellen aktualisieren, aber es sind auch mehr Nachrichten. Was ist, wenn wir DBCs speichern? Damit beschäftigen sich @roland und @qi_ma. @roland befasst sich auch erneut mit der Datenreplikation.

Natürlich müssen wir sehen können, was vor sich geht, und @Chriso hat die OpenSearch-Implementierung im Testnet-Repo umgestaltet, um Platz für die Überwachungseinrichtung zu schaffen.

Und @oetting fängt an, all diese Dinge zusammenzuführen. Mehr von ihm unten!

DBCs, Überweisungen und Geldbörsen

Vereinfachung des DBC-Codes

In den letzten Wochen wurde der DBC-Code einer lang benötigten Vereinfachung unterzogen. Es gab sowohl mehr Dokumentation als auch eine kleine Überarbeitung der Terminologie, wobei Benennungen und Konzepte für eine geringere kognitive Belastung angepasst wurden.

Eine andere Sache, die wir jetzt tun könnten, da wir keine Sektionen und Ältesten mehr haben, war, die Netzwerksignierung von DBCs zu entfernen. Das allein ist schon eine massive Vereinfachung. Was wir jetzt haben, ist, dass eine Übertragung vollständig offline erstellt werden kann, und alles, was Sie tun müssen, ist, die Teile des DBC einzusenden, die als * signierte Ausgaben * bezeichnet werden (das heißt, der Schlüssel, der einer DBC-ID entspricht, signiert die Ausgaben von dass DBC - also der Absender der Token die Ausgaben signiert hat). Wenn genügend Peers im Netzwerk diese signierten Ausgaben akzeptiert haben, ist die Transaktion abgeschlossen und gültig.

DBCs im Netzwerk ausgeben (Überweisungen oder Datenzahlungen)

Also, um ein bisschen zurückzutreten.

Anstatt die Ältesten einer Sektion zu bitten, eine Ausgabe (d. h. eine Überweisung oder Datenzahlung) zu validieren und zu unterzeichnen, wie es zuvor getan wurde, senden wir jetzt vom Kunden unterzeichnete Ausgaben an die enge Gruppe der ID des DBC, um sie auszugeben. (Wir nennen es die Adresse. Chunks haben also eine Adresse, Register haben eine Adresse und DBC-Ausgaben haben eine Adresse). Diese enge Gruppe wurde bereits erwähnt. Die Peers der engen Gruppe unterschreiben nichts. Sie validieren einfach die Ausgaben, wobei jeder von ihnen unabhängig handelt, und speichern sie, wenn sie sie für gültig halten. Ein Teil davon, es gültig zu finden, besteht darin, die Eltern einer solchen Ausgabe nachzuschlagen. Das bedeutet, die Ausgaben nachzuschlagen, die zur Erstellung genau dieses DBC geführt haben, das jetzt ausgegeben wird.

Wenn diese Elternausgaben von ihrer jeweiligen engen Gruppe abgerufen werden können, bedeutet dies, dass sie gültig sind, da sie selbst t unterzogen wurdenseinen Prozess zurück, als sie ausgegeben wurden.

Es gibt natürlich noch mehr Validierungen, wie z. B. das Auschecken der blinden Beträge für Ein- und Ausgaben, ob die Schlüssel der Eingabe-DBCs alles ordnungsgemäß signiert haben, und so weiter.

Und wenn das alles als gültig bestätigt wurde, speichert ein Peer einfach diese signierten Ausgaben. Und wenn ein Client überprüfen soll, ob der DBC, den er erhalten hat, gültig ist, bittet er das Netzwerk einfach, die signierten Ausgaben zurückzugeben, die zur Erstellung dieses DBC geführt haben. Wenn die erforderliche Anzahl von Peers es zurückgibt, dann ist es eine Tatsache.

Gruppen schließen

Also eine geschlossene Gruppe. Denken Sie daran, dass diese durch die Nähe zur ID des DBC (oder dem Hash der Daten) gefunden werden. Sie können 4, 8, 16 Peers oder mehr sein. Wir beginnen mit einer Zahl und passen sie im Laufe der Zeit an. Aber es steckt noch mehr dahinter. Wir können Schichten hinzufügen, indem wir die ID/den Namen hashen, und erhalten eine neue Adresse, die deterministisch von der ersten abgeleitet wird. Jetzt können wir denselben Artikel auch in dieser Gruppe speichern. Und so kann es weitergehen, diese Adresse immer wieder hashen und jedes Mal eine weitere Gruppe haben, die das Element besitzt.

Dies sind einige der Hebel, die bereits erwähnt wurden. Wir fangen einfach mit einer einzelnen Gruppe an, weil wir diese zunächst nur in einem Testnetz zum Laufen bringen wollen.

Geldbörsen

Wir haben gerade die erste einfache Implementierung einer Brieftasche abgeschlossen, die DBCs und eine Historie von Transaktionen enthält. Wie bei Daten verwendet die erste Iteration In-Memory-Speicher. Als nächstes wird es lokal auf dem Laufwerk gespeichert, und danach werden wir die Netzwerkspeicherung durchführen. Das Gute ist, dass wir das Wallet so implementieren, dass es eine einfache Schnittstelle hat, die mit jedem der drei (oder allen) der oben genannten Speichermedien verwendet werden kann.

Was dieses Mal auch berücksichtigt wurde, ist, dass alle Kollegen eine Brieftasche für ihre Belohnungen haben müssen. Aber so weit sind wir noch nicht, dafür noch ein, zwei Wochen. (Und ja, jetzt ist es viel einfacher, Zeitschätzungen vorzunehmen.)

Überweisungsgebühren

Diese wurden erst kürzlich in einem Update beschrieben, und da hat sich nicht viel geändert. Die Zahlungen gehen an Knoten, und die Prioritätswarteschlange (früher Mempool genannt) ist dieselbe.
Was wir uns wahrscheinlich etwas früher ansehen werden, ist, wie das gleiche Muster für Datenzahlungen angewendet werden kann.

Und schon sind Sie über den Fortschritt von Überweisungen und Zahlungen auf dem Laufenden.


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!