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!