Safe Network Entwickler Update ­čçę­čç¬ 23. September 2021

Dies ist eine maschinelle ├ťbersetzung. Das Original in Englisch ist hier: Update 23 September, 2021

Heute werden wir uns DBCs und Eigentum genauer ansehen. Das Kernnetzwerk und die DBCs/Mints haben sich parallel weiterentwickelt, aber wir sind kurz davor, sie zusammenzubringen :crossed_fingers:. Momentan ist so viel los - vieles davon leider nicht in einer ├ťbersicht wie diesem zu beschreiben - aber zusammenfassend war es eine gute Woche, um einige langj├Ąhrige und knorrige Probleme mit Stabilit├Ąt, Verbindungen und Tests abzuarbeiten.

Allgemeiner Fortschritt

@oetyng hat den besten Weg untersucht, mit kleinen Dateien umzugehen, die aufgrund ihrer Gr├Â├če nicht selbstverschl├╝sselt werden. Spots enthalten viele Nur-Text-Datendateien, einschlie├člich DataMaps, m├╝ssen also immer noch verschl├╝sselt werden, es sei denn, es handelt sich um ├Âffentlich ver├Âffentlichte Daten.

@yogesh und @joshuef haben einen Fehler behoben, der dazu f├╝hrte, dass eine Nachricht an alle ├ältesten in einem Abschnitt gesendet wurde und nicht nur die Auswahl, die nach einer AE-Aktualisierungsnachricht erforderlich ist. Dies f├╝hrte zu einer drastischen Zunahme der Hin- und Her-Nachrichten im Netzwerk, was zu einer Verst├Ąrkung der Nachrichten f├╝hrte (mehr Nachrichten an ├älteste bedeuteten mehr f├╝r Erwachsene und dann wieder mehr zur├╝ck). Mit dem in PR#473 zusammengef├╝hrten Fix haben sich die Effizienz und der Durchsatz des Netzwerks erh├Âht, was bedeutet, dass unsere E2E-Tests viel konsistenter bestehen.

Die Einf├╝hrung einiger tempor├Ąrer AE-Probing-Meldungen ist ebenfalls in Arbeit. Es wird von Abschnitten verwendet, um regelm├Ą├čig andere Abschnitte im Netzwerk zu untersuchen, nach Aktualisierungen zu suchen, indem AE-Flows ausgel├Âst werden, und hilft den Abschnitten, auf dem neuesten Stand zu bleiben, was dem Netzwerk mehr Stabilit├Ąt verleiht. (Dies sollte schlie├člich veraltet sein, sobald DBC-Datenverkehr ├╝ber das gesamte Netzwerk geleitet wird).

@Yogesh hat auch ein Problem mit den AE-Tests behoben, bei dem Schleifen eine Verst├Ąrkung der Nachrichten├╝bermittlung verursachten.

@ChrisO arbeitet an der CLI und API und aktualisiert sie, damit sie mit den neuesten Versionen des Netzwerks kompatibel sind, und einige Befehle funktionieren jetzt mit dem Genesis-Schl├╝ssel, obwohl diese Arbeit es noch nicht in main geschafft hat, sollte sie bald erscheinen.

@Chris.Connelly und @lionel.faber haben damit experimentiert, den Verbindungspool von qp2p zu entfernen. Der Verbindungspool h├Ąlt Verbindungen nach einem ersten Kontakt offen, ist aber ein stumpfes Instrument und so etwas wie eine Blackbox. Wir wollen mehr Kontrolle, um die Ressourcennutzung zu optimieren, und m├Âchten daher etwas Besseres in die Codebasis von safe_network implementieren.

Fr├╝here Speicherprobleme wurden jetzt gr├Â├čtenteils behoben (wir sind bei den meisten Knoten im Leerlauf von ~80 MB und steigen unter Last auf etwa 250 MB), aber @qi_ma hat einen Randfall gefunden, bei dem sich die Protokolldatei eines neu verlegten Knotens befindet Ballon in der Gr├Â├če, vermutlich weil keine Nachrichten empfangen werden.

DBC-Eigentum

Beim Entwerfen eines DBC-Systems m├╝ssen Sie unter anderem entscheiden, ob DBCs Besitzer haben oder nicht. Bei herrenlosen DBCs kann jeder, der einen DBC in die H├Ąnde bekommt, diesen ausgeben, was sich gut an Goldm├╝nzen ann├Ąhert, aber seine eigenen Probleme hat.

Da jeder, der eine Kopie der DBC besitzt, diese ausgeben kann, ist es g├Ąngige Praxis, eine DBC nach Erhalt sofort neu auszugeben, um sicherzustellen, dass sie nicht zuerst von jemand anderem ausgegeben wird.

Diese Neuauflage beinhaltet das Senden der DBC an eine Mint, um sie in eine neue DBC mit dem gleichen Wert umzuwandeln der DBC wird von einem b├Âswilligen Mint-Knoten gestohlen (denken Sie daran, dass jeder, der eine Kopie des DBC besitzt, diese ausgeben kann und Mints eine Kopie ben├Âtigen, um eine Neuausgabe durchzuf├╝hren).

Eigene DBCs l├Âsen diese Probleme, indem sie den ├Âffentlichen Schl├╝ssel der DBC-Besitzer zum DBC hinzuf├╝gen. Dieser Nachweis beinhaltet normalerweise, dass der Eigent├╝mer die Neuausstellungstransaktion unterschreibt.

Mit eigenen DBCs k├Ânnen wir die DBC ohne Angst vor Diebstahl ├Âffentlich speichern, da nur wir die geheimen Schl├╝ssel haben, um unsere DBCs auszugeben.

HINWEIS: Wir k├Ânnen besitzerlose DBCs mit eigenen DBCs modellieren, indem wir den geheimen Schl├╝ssel bei einer Zahlung mit einem DBC verpacken.

Datenschutz und eigene DBCs

Um diesen Abschnitt zu veranschaulichen, stellen Sie sich vor, Sam m├Âchte Spenden in SafeCoin erhalten, Sam sendet seinen ├Âffentlichen Spendenschl├╝ssel online f├╝r alle sichtbar und bittet seine Anh├Ąnger um Ersatzm├╝nzen.

Jeder, der an Sam spenden m├Âchte, w├╝rde einige seiner DBCs an Sam neu ausgeben, indem er Sams Spendenschl├╝ssel als DBC-Besitzer verwendet und die resultierenden DBCs an Sam sendet.

Jetzt k├Ânnte leider jeder, der die Neuausgabeprotokolle von Mints ├╝berpr├╝ft, Sams Transaktionen finden, indem er nach Transaktionen mit Sams Spendenschl├╝ssel scannt. Dies ist nicht das, was wir von einem datenschutzbewussten Geldsystem erwarten.

Wir haben dieses Szenario ausf├╝hrlich diskutiert, aber mit der bestehenden Kryptographie konnten wir keinen Weg finden, einen statischen Spendenschl├╝ssel und DBCs mit Einmalschl├╝sselbesitzern zu kombinieren.

Zum Gl├╝ck ungef├Ąhr zur gleichen Zeit wirdiese Fragen untersuchten, hatte @mav sich mit der Mathematik hinter BLS-Schl├╝sselableitungstechniken befasst und eine wirklich clevere Technik entwickelt, die es uns erm├Âglicht, die Schl├╝sselableitung auf der Seite des ├Âffentlichen Schl├╝ssels durchzuf├╝hren. Die Technik erm├Âglicht es jedem, einen untergeordneten Schl├╝ssel von einem bekannten ├Âffentlichen Schl├╝ssel abzuleiten.

Nehmen wir zum Beispiel im obigen Fall von Sam an, dass Janet 10 US-Dollar an Sam spenden m├Âchte. Janet w├╝rde zuerst einen neuen Besitzerschl├╝ssel mit einem zuf├Ąlligen Index ableiten

Owner_index = random_256bits()
owner_pk = sams_donation_pk.derive_child(owner_index)

Dann w├╝rde Janet einen $10 DBC mit dem Besitzer auf owner_pk neu ausgeben. Dieser $10 DBC wird dann zusammen mit dem owner_index an Sam gesendet. Wenn Sam diese Spende ausgeben will, verwendet er den owner_index, um den geheimen Besitzerschl├╝ssel aus dem geheimen Spendenschl├╝ssel abzuleiten:

owner_sk = sams_donation_sk.derive_child(owner_index)

Um es zusammenzufassen, wir haben den ├Âffentlichen Spendenschl├╝ssel mit einem zuf├Ąlligen Ableitungsindex verschleiert. Dieser Index wird zusammen mit dem gespendeten DBC an Sam gesendet, damit Sam den Besitzerschl├╝ssel ableiten kann, wenn er ihn ausgeben m├Âchte. Da der Ableitungsindex nie an die Mint gesendet wird, k├Ânnen die Audit-Logs keine Verweise auf Sams Spendenschl├╝ssel finden.

The Spentbook und Spend Keys

Die Neuauflage eines DBC beinhaltet immer einen Schreibvorgang in das Spentbook. Das Spentbook ist ein Protokoll aller ausgegebenen DBCs und der Neuausgabetransaktion, f├╝r die die DBC ausgegeben wurde. Es kann als gro├če verteilte Tabelle betrachtet werden, die eine DBC einer Transaktion zuordnet. Jedes Mal, wenn ein DBC ausgegeben wird, wird er dem Spentbook hinzugef├╝gt. Wenn jemand versucht, denselben DBC erneut auszugeben, werden die M├╝nzst├Ątten feststellen, dass es bereits einen Eintrag im Spentbook gibt, und sich weigern, die Neuauflage zu unterzeichnen.

In fr├╝heren Versionen des Safe DBC-Systems lie├čen wir die Mints selbst die Spentbook-Eintr├Ąge bei jeder Neuauflage schreiben, aber vor kurzem sind wir zu einem neuen Modell ├╝bergegangen, bei dem von den Kunden erwartet wird, dass sie in das Spentbook schreiben. Diese ├änderung reduziert die Belastung unserer Mint-Knoten erheblich, da das Schreiben in das Spendbook und die erforderlichen ├ťberpr├╝fungen der Eigentumsnachweise kostspielige Teile des Neuausstellungsablaufs waren.

Um die ├änderung zu veranschaulichen, fahren wir mit dem obigen Beispiel fort: Sam hat eine DBC-Spende von 10 USD erhalten und m├Âchte sie jetzt ausgeben.

Zuerst baut Sam die Transaktion auf, die er ausf├╝hren m├Âchte, hier teilt er seine 10 $ in einen 8 $ DBC und einen 2 $ DBC auf.

let tx = ReissueTransaction {
  Eingaben: { $10DBC }
  Ausgaben: { $8DBC, $2DBC }
}

Nachdem Sam die Transaktion angegeben hat, muss Sam die $10 DBC f├╝r diese Transaktion festlegen, indem er sie im Spentbook protokolliert.

Das Schreiben in das Spentbook erfordert einen Nachweis, dass Sie tats├Ąchlich der Eigent├╝mer der DBC sind. Wir tun dies, indem wir Kunden zwingen, einen DBC-Ausgabenschl├╝ssel abzuleiten und die Eigent├╝merschaft durch Unterzeichnen der Transaktion nachzuweisen.

Schl├╝ssel ausgeben

Ein Spend Key ist die Bezeichnung f├╝r DBCs im Spentbook. Es wird vom DBC-Besitzer abgeleitet, der den Hash des DBC verwendet.

sei dbc = $10DBC;
let spend_key = dbc.owner.derive_child(sha3_256(dbc))

Sie fragen sich vielleicht, warum wir den DBC-Besitzer nicht direkt verwenden? Warum einen anderen Schl├╝ssel ableiten, wenn der Besitzer ein Einmalschl├╝ssel sein soll? Nun, die Mint sieht nicht den zuf├Ąlligen Index, der verwendet wird, um den Besitzer abzuleiten, daher k├Ânnen wir nicht garantieren, dass es sich tats├Ąchlich um einen eindeutigen Schl├╝ssel handelt.

Das Spentbook erfordert, dass wir f├╝r jeden DBC einen eindeutigen Schl├╝ssel haben, daher verwenden wir den Hash des DBC, um einen Spend Key abzuleiten, der garantiert unvorhersehbar ist. Insgesamt haben wir hier also drei Schl├╝ssel am Werk, die in Kette abgeleitet sind:

well_known_key <-- weit verbreitet und mit einer realen Entit├Ąt verbunden
owner_key <-- abgeleitet vom well_known_key unter Verwendung eines zuf├Ąlligen Index
spend_key <-- abgeleitet vom Owner_key unter Verwendung des DBC-Hashs

Zu einer Transaktion verpflichten

Sam hat jetzt eine Transaktion, zu der er sich verpflichten m├Âchte, und einen Ausgabeschl├╝ssel.

lass input_dbc = $10DBC;
let tx = ReissueTransaction {
  Eingaben: { input_dbc }
  Ausgaben: { $8DBC, $2DBC }
}

let spend_key = input_dbc.owner.derive_child(sha3_256(input_dbc))

Sam signiert die Transaktion mit diesem spend_key und sendet tx , spend_key und die Signatur an das Netzwerk, um sie in das Spentbook zu schreiben.

Sobald das Spentbook geschrieben wurde, m├╝ssen Sie nur noch eine Mint-Signatur erhalten, die die G├╝ltigkeit der Transaktion best├Ątigt. Um dies zu tun, sendet Sam einfach die tx-Transaktion an die Mint, jeder Mint-Knoten fragt das Spentbook ab und stellt sicher, dass jede Transaktionseingabe an dieselbe Transaktion ├╝bergeben wird. Wenn dies erfolgreich ist, ├╝berpr├╝fen wir die Standard-Neuausgabebeschr├Ąnkungen, n├Ąmlich die Summe der Eingaben muss zur Summe der Ausgaben ausgeglichen werden und dass jede Eingabe-DBC g├╝ltig ist.

Sobald alle Pr├╝fungen bestanden sind, signiert die M├╝nzanstalt die Neuausgabe und sendet die Signatur an Sam zur├╝ck, der dann die endg├╝ltigen Ausgabe-DBCs aggregiert und bildet. Fertig.

Dieser neue Neuausgabe-Flow f├╝hrt zu Mint-Knoten, die einfach als Validatoren mit einer schreibgesch├╝tzten Ansicht in das Spentbook fungieren. Dies sollte den Ressourcenbedarf an Elder-Knoten reduzieren und uns ein schnelleres Netzwerk erm├Âglichen.


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!