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