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

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

Diese Woche gehen wir etwas detaillierter auf die Unverkn├╝pfbarkeit von DBC ein und was die Auswirkungen und Kompromisse f├╝r die Benutzererfahrung und die Netzwerkeffizienz sind.

Allgemeiner Fortschritt

Ein ├ältester ist eine besondere Art von Knoten mit Stimmrechten und F├╝hrungsaufgaben, w├Ąhrend ein Erwachsener Daten speichert und auf Anfrage ausliefert, aber f├╝r den Kunden sehen sie genau gleich aus. @chris.connelly hat einige Fehler durchgearbeitet, bei denen ein Client versucht, zu einem Erwachsenen zu booten, der es dann ignoriert und eine b├Âse Schleife erzeugt.

Chris hat auch daran gearbeitet, das sn_launch-Tool zu verbessern (wie einige von euch bemerkt haben!) und das qp2p-Upgrade zu debuggen.

@JimCollinson hat sich mit dem Thema Anmeldeinformationen befasst und verwendet Multisig, um dem grundlegenden Passwort/Mnemonik weitere Authentifizierungsoptionen hinzuzuf├╝gen, einschlie├člich Hardwareschl├╝ssel, zus├Ątzliche Mnemonik oder Seed-Phrasen usw. Der Benutzer kann beispielsweise festlegen, dass drei beliebige von f├╝nf Anmeldeinformationen m├╝ssen vorgelegt werden, um einen Safe zu entsperren. Multisig ├Âffnet auch die T├╝r, um auf Wunsch n vertrauensw├╝rdige Dritte zur Wiederherstellung eines Kontos zu verwenden. Benutzer von Safe Network verlieren unweigerlich ihre Zugangsdaten, und multisig bietet einen Weg zur sicheren Kontowiederherstellung, der es dem Benutzer erm├Âglicht, die Risikoabw├Ągung nach eigenem Ermessen zu steuern.

@bochaco untersucht, wie der Client ├╝ber AE ├╝berpr├╝ft, ob der Abschnitt, mit dem er spricht, auf dem neuesten Stand ist.

@Qi_Ma untersucht, was passiert, wenn Erwachsene satt werden. Es gibt derzeit ein abweichendes Verhalten bei der Auswahl des n├Ąchsten alternativen, nicht vollwertigen Erwachsenen, um einen Brocken von den ├ältesten zu speichern, und wie die ├ältesten wissen, wo sich der Brocken befindet, da es nicht mehr das XOR ist, das dem Namen des Chunks am n├Ąchsten kommt.

Inzwischen hat @chriso daran gearbeitet, die API zu modernisieren, um den neuen Messaging-Änderungen Rechnung zu tragen, eine Aufgabe, die jetzt fast abgeschlossen ist.

Die Arbeit von @oetyng mit der Integration der verst├Ąrkten Selbstverschl├╝sselung zusammen mit dem Chunk-Handling-Refactor wurde zusammengef├╝hrt. Die Scope-Dualit├Ąt (├Âffentlich/privat) wurde von der Chunk-Ebene auf die Blob-Ebene verschoben - was Code- und Knotenaufgaben stark vereinfacht. Auch der richtige Umgang mit dem de facto geheimen Schl├╝ssel, den die Selbstverschl├╝sselung zusammen mit den verschl├╝sselten Chunks ausgibt, wurde hinzugef├╝gt. Damit kann die Arbeit an der Stapelverarbeitung nun fortgesetzt werden.

Wir haben auch unseren in Arbeit befindlichen Feature-Zweig mit master zusammengef├╝hrt (oder besser gesagt, den HEAD von main hierhin verschoben, wenn Sie in git-Details einsteigen wollenÔÇŽ). Dies bedeutet, dass der Zweig stabiler war als der Hauptzweig. Wir sehen mehr CI-Pass und viel saubereren Code im Allgemeinen. In diesem Zweig wurde viel hinzugef├╝gt, und wir testen und debuggen immer noch verschiedene Abl├Ąufe. Aber mit durchg├Ąngiger AE und einfacherem Codefluss im Knoten wird dies alles immer einfacher. Es gibt zwar noch kein Testnet, mit dem die Leute spielen k├Ânnen, aber wir gehen in die richtige Richtung.

Mehr zu DBCs

Wir setzen unsere Serie ├╝ber DBCs fort und befassen uns diese Woche mit der Eigenschaft der Unlinkability. Wir diskutieren, warum es wichtig ist, und ├╝berpr├╝fen verschiedene M├Âglichkeiten, wie datenschutzorientierte Kryptow├Ąhrungen versuchen, dies zu erreichen.

Hoffentlich kann dieser ├ťberblick dazu dienen, den Lesern mehr Kontext und Hintergrund f├╝r Technologien zu bieten, die wir untersucht haben, wie z.

Unverkn├╝pfbarkeit

Warum ist es also wichtig, dass ein monet├Ąrer Token unverkn├╝pfbar ist? Kurz gesagt, weil dies das technische Mittel ist, um das allgemeinere und h├Âchst w├╝nschenswerte Geldeigentum von Fungibilit├Ąt. Fungibilit├Ąt bedeutet, dass ein Token mit einem anderen austauschbar ist.

Denken Sie an zwei unmarkierte Goldbarren von gleichem Gewicht. Das eine ist so gut wie das andere. Sie sind nicht zu unterscheiden. Wenn diese Barren jedoch mit Seriennummern gekennzeichnet sind und eine zentrale Stelle eine Liste aller Goldb├Ârsen f├╝hrt, die anhand der Seriennummer verfolgt werden, k├Ânnen wir eine Situation haben, in der ein Barren in den K├Âpfen potenzieller Empf├Ąnger weniger wert ist als ein anderer, weil er es war mit einigen ÔÇ×schlechtenÔÇť Aktivit├Ąten in der Vergangenheit verbunden. Oder ein anderes k├Ânnte noch wertvoller sein, weil es durch die H├Ąnde einer ber├╝hmten Person gegangen ist. Mit einem solchen System k├Ânnen die Teilnehmer beginnen, das Vertrauen in die Goldbarren zu verlieren. M├Âglicherweise m├╝ssen sie f├╝r jede Transaktion eine zentralisierte ÔÇ×Gut/Schlecht-ListeÔÇť ├╝berpr├╝fen, um zu verhindern, dass ein ÔÇ×Schlecht-BalkenÔÇť erhalten wird, und das Gesamtsystem wird weniger effizient. Aufgrund des Trackings haben wir die Fungibilit├Ąt verloren. Mehr dazu im oben verlinkten Artikel.

Es gibt auch viele Auswirkungen auf den Datenschutz, wenn Sie eine Zahlung mit einem Token erhalten oder ausf├╝hren, das eine lange Geschichte hat. Das Safe Network hat den Anspruch, allen Netzwerkteilnehmern private, sichere Transaktionen zu erm├Âglichen.

Wie k├Ânnen wir feststellen, ob eine M├╝nze verkn├╝pfbar oder unverkn├╝pfbar ist? Es ist eigentlich ziemlich einfach, wir schauen uns nur die Eingaben und Ausgaben eines Transaktionspaars an.

Hinweis: Bei DBCs verwenden wir h├Ąufig die W├Ârter Transaktion und Neuauflage inaustauschbar

Hier ist ein vereinfachtes Beispiel f├╝r zwei Neuauflagen mit unserem aktuellen DBC-System. Wir k├Ânnen sagen, dass Bob 50 an Alice bezahlt hat (1. Neuauflage) und Alice dann die gleichen 50 an Jim (2. Neuauflage) bezahlt hat. Jede Neuauflage hat also nur einen Eingangs-DBC und einen Ausgangs-DBC. Jeder DBC hat einen zugeordneten Betrag, einen ├Âffentlichen Schl├╝ssel des Besitzers pubkey und eine Mint-Signatur mintsig. In diesem Beispiel werden pubkey, mintsig und hash der K├╝rze halber auf 3 Stellen gek├╝rzt. In Wirklichkeit sind es sehr gro├če eindeutige Zahlen.

Neuauflage 1 (r1):
Ôćĺ input = a {amount=50, pubkey = 567, mintsig=233}, hash(a) = 223
Ôćĺ Ausgabe = b {Betrag = 50, Pubkey = 725, Mintsig=112}, Hash(b) = 787

Neuauflage 2 (r2):
Ôćĺ Eingabe = b {Betrag = 50, Pubkey = 725, Mintsig=112}, Hash(b) = 787
Ôćĺ Ausgabe = c {Betrag = 50, Pubkey = 212, Mintsig=455}, Hash(c) = 993

Hinweis: a, b und c sind Labels f├╝r dieses Beispiel. Sie erscheinen nicht in einer Neuauflage. Betr├Ąge sind jetzt durch Verpflichtungen ausgeblendet, aber f├╝r diese Analyse nicht relevant.

Wir k├Ânnen leicht sehen, dass Eingabe b f├╝r r2 mit Ausgabe b f├╝r r1 ├╝bereinstimmt. Wir k├Ânnen sie miteinander verkn├╝pfen durch: pubkey == 725 oder mintsig == 112 oder hash == 787.

Dadurch wird festgelegt, dass die Neuausgaben r1 und r2 miteinander verkn├╝pft sind, da sie einen gemeinsamen DBC verwenden. ├ťber eine Reihe von Neuauflagen hinweg entsteht so eine Kette, der man folgen kann.

Das ist mit Verkn├╝pfbarkeit gemeint.

Auch wenn der Betrag ein sehr eindeutiger Wert (oder eine Wertzusage) ist, k├Ânnte er verwendet werden, um Transaktionen zu verkn├╝pfen.

Ein wichtiger Punkt ist, dass selbst wenn wir die Felder pubkey und mintsig entfernen und nur ein zuf├Ąlliges ID-Feld verwenden (um doppelte Ausgaben zu vermeiden), die DBCs immer noch durch ihren Hash-Wert identifiziert werden k├Ânnen. Mit anderen Worten, wenn dieselben Daten als Ausgabe f├╝r eine Neuausgabe und als Eingabe f├╝r eine andere verwendet werden, dann sind die Neuausgaben verkn├╝pfbar. Dies ist auf jede Kryptow├Ąhrung verallgemeinerbar, wobei das Wort Transaktion f├╝r Neuausgabe ersetzt wird.

Sie fragen sich vielleicht: Was ist, wenn wir mehrere Eingaben und Ausgaben und unterschiedliche Mengen verwenden, um Token aufzuteilen und zusammenzuf├╝hren? Nun, solche Techniken k├Ânnen es schwieriger machen, sich der Spur eines einzelnen Tokens sicher zu sein. Das ist die Basis von CoinJoin, CoinShuffle und ├Ąhnlichen Mischalgorithmen. Sie machen mehr m├Âgliche Links zum Folgen/Auswerten. Aber sie unterbrechen keine LinksÔÇŽ die auf unbestimmte Zeit aufbewahrt werden, damit jeder sie in Ruhe mit statistischen Analysen, Daten von Dritten (zB B├Ârsen) usw. analysieren kann. Solche Techniken werden von Kryptographen im Allgemeinen als ÔÇ×schwache So├čeÔÇť angesehen.

Sie k├Ânnen sich auch fragen: Warum ├╝berhaupt eine eindeutige Kennung im DBC? Die Antwort ist, dass eine Kennung erforderlich ist, um Doppelausgaben zu verhindern. Die M├╝nzst├Ątte muss in der Lage sein, eine ÔÇ×M├╝nzeÔÇť als ausgegeben zu registrieren, um jeden zuk├╝nftigen Versuch, sie erneut auszugeben, abzufangen.

Sobald wir die Verkn├╝pfbarkeit verstanden haben, k├Ânnen wir dar├╝ber nachdenken, wie wir dies verhindern k├Ânnen.

Ein System mit der Eigenschaft unlinkability h├Ątte solche Links nicht. Die gro├če Frage ist, wie man diese Eigenschaft erreicht?

Blinde Unterschriften

Die ├Ąlteste bekannte Technik wurde von David Chaum erfunden und ist als Blind Signatures bekannt. Es hat den Vorteil, dass es das am einfachsten zu implementierende Schema ist und zumindest im Moment am effizientesten, was es sehr gut f├╝r M├╝nzbetriebe geeignet macht.

Sehen wir uns das Grundkonzept einer Blindsignatur an. Chaums Papier verwendet das Beispiel einer aus der Ferne durchgef├╝hrten Wahl. Hier pr├Ąsentieren wir eine komprimierte Version, obwohl auch die von Chaum lesenswert ist.

Eine blinde Unterschrift ist so, als w├╝rde man einen Zettel mit einer Nachricht (zB einer Stimme) in einen mit Kohle kaschierten Umschlag stecken. Mary schickt den ÔÇ×UmschlagÔÇť mit dem ÔÇ×ZettelÔÇť und einer Absenderadresse an den Wahlbeamten Charles. Charles unterschreibt den ÔÇ×UmschlagÔÇť (der auch den ÔÇ×ZettelÔÇť innen unterschreibt) und schickt ihn zur├╝ck. Zu einem sp├Ąteren Zeitpunkt entfernt Mary den Stimmzettel und schickt ihn in einem neuen ÔÇ×UmschlagÔÇť, jedoch ohne R├╝cksendeadresse, an Charles zur├╝ck. Charles ├Âffnet den ÔÇ×UmschlagÔÇť, entfernt den ÔÇ×BelegÔÇť, ├╝berpr├╝ft, ob er eine g├╝ltige Unterschrift von Charles hat, und z├Ąhlt die Stimme - ohne zu wissen, wer diese bestimmte Stimme abgegeben hat oder wann sie unterzeichnet wurde (unter den unterschriebenen Umschl├Ągen).

Der entscheidende Punkt ist, dass es keine Verbindung zwischen dem, was auf einem der Zettel steht, und dem, was auf einem der Umschl├Ąge steht, gibt. Die von jedem der W├Ąhler abgegebene Stimme ist dem Wahlbeamten Charles also unbekannt. (ausgenommen Schreibforensik usw., die f├╝r kryptografische Diskussionen nicht relevant sind).

Ok, also lasst uns unsere beiden Neuauflagen noch einmal durchf├╝hren, diesmal mit Blindsignaturen. Jetzt ist es die DBC Mint, die die Umschl├Ąge blind unterschreibt. F├╝r dieses Beispiel gehen wir davon aus, dass alle DBCs den gleichen Wert haben.

Neuauflage 1 (r1):
Ôćĺ input = a.slip {pubkey = 567, mintsig=233}, hash(a.slip) = 223
Ôćĺ Ausgabe = b.envelope {blind(b.slip)}, hash(b.envelope) = 565

Neuauflage 2 (r2):
Ôćĺ input = b.slip {pubkey = 445, mintsig=112}, hash(b.slip) = 787
Ôćĺ Ausgabe = c.envelope {blind(c.slip)}, hash(c.envelope) = 993

In Worten:

  • Bob pr├Ąsentiert Input A (Slip) zu Minze (wit g├╝ltigem Pr├Ągestempel ├╝ber A) und erh├Ąlt die Pr├Ągesignatur ├╝ber Ausgabe B (Umschlag) mit Pr├Ągestempel, der anzeigt, dass B genauso viel wert ist wie A (Ausweis).
  • Mint markiert auch A (Ausweis) als verbraucht.
  • Bob entfernt B (Briefpapier) von B (Umschlag) und gibt es Alice, die B (Briefpapier) der M├╝nzst├Ątte ├╝berreicht und den Pr├Ągestempel ├╝ber C (Umschlag) im gleichen Wert wie B (Briefpapier) erh├Ąlt.
  • Mint markiert auch B (Schein) als verbraucht.

Das Interessante hier ist, dass B (Umschlag) einen anderen Hash als B (Slip) enth├Ąlt. 565 != 787

Daher stimmen die Hashes nicht ├╝berein zwischen tx1 und tx2 und auch keine Felder. Soweit die M├╝nzst├Ątte sehen kann, verbindet nichts diese beiden Transaktionen miteinander. Wir haben Unverkn├╝pfbarkeit!

Zero Knowledge Circuits

Ein modernerer Ansatz f├╝r nicht verkn├╝pfbare Transaktionen ist die Verwendung von Zero-Knowledge (ZK)-Beweisschaltungen ala ZCash.

Mit ZK-Proofs versuchen wir, die Mint von etwas zu ├╝berzeugen, ohne sensible Informationen preiszugeben. ZK-Stromkreispr├╝fsysteme wie PLONK haben sich in den letzten Jahren als allgemeine Systeme f├╝r technische ZK-Nachweissysteme herausgebildet.

Angenommen, wir implementieren eine ZK-Schaltung, die sha3_256 simuliert. Diese Schaltung w├╝rde es uns erm├Âglichen, einem Dritten zu beweisen, dass wir die Daten kennen, die zu einem Hash-Hash verarbeitet werden, ohne die Daten selbst preiszugeben. ├ťber diese Daten k├Ânnen wir sogar Eigenschaften nachweisen!

Nehmen wir zum Beispiel an, dass die Daten, die wir hashen, tats├Ąchlich eine komplette Neuausstellungstransaktion sind.

lass neu ausgeben = neu ausgeben {
   Eingaben: { Dbc {Betrag: 9, Besitzer: pk1,..}, Dbc {Betrag: 1, Besitzer: pk2,..},
   Ausgaben: { Dbc {Betrag: 10, Besitzer: pk3,..}
   Eigentumsnachweise: {pk1_sig, pk2_sig}
};

Ich k├Ânnte diese Neuausgabe durch sha3_256 laufen lassen, um einen Hash zu erzeugen: tx_hash = sha3_256(reissue).
Um die M├╝nzpr├Ągeanstalt davon zu ├╝berzeugen, dass dies ein Hash einer g├╝ltigen Transaktion ist, k├Ânnen wir mit unserer sha3_256-Schaltung einen ZK-Beweis generieren.

Eine ZK-Schaltung hat private und ├Âffentliche Eingaben, in diesem Beispiel sind die Neuausgabeinformationen private Eingaben und der ÔÇÜtx_hashÔÇś ist eine ├Âffentliche Eingabe.

privat: [9, pk1, 1, pk2, 10, pk3, pk1_sig, pk2_sig]
├Âffentlich: [tx_hash]

Wir k├Ânnen Einschr├Ąnkungen f├╝r diese privaten/├Âffentlichen Eingaben aufschreiben, diese Einschr├Ąnkungen werden in einen ZK-Schaltkreis codiert, der dann ausgef├╝hrt werden kann, um Beweise zu liefern, dass diese Einschr├Ąnkungen erf├╝llt sind

/// Einschr├Ąnkungen bei der Neuauflage
privat[0] + privat[2] = privat[4] // 9 + 1 = 10
private[1].verify(private[0..6], public[6]) // pk1 hat die Transaktion signiert
private[3].verify(private[0..6], public[7]) // pk2 hat die Transaktion signiert
public[0] = sha3_256(private) // Daten-Hashes erneut an tx_hash ausgeben

Hinweis: Wir beziehen uns auf Eing├Ąnge nach ihrem Index, Schaltkreise haben eine vorbestimmte Gr├Â├če. Diese Gr├Â├če begrenzt die Anzahl der Eingangs-/Ausgangs-DBCs, die wir innerhalb einer einzelnen Neuausstellungstransaktion neu ausgeben k├Ânnen.

Sobald wir diese Einschr├Ąnkungen als ZK-Schaltung kodieren, k├Ânnen wir die Details der Neuausgabe in die privaten Eingabeschlitze und den tx_hash in die ├Âffentlichen Eingabeschlitze der Schaltung einf├╝gen. Wir drehen dann an der Kurbel, um einen Beweis zu erbringen, dass alle Nebenbedingungen erf├╝llt sind.

Wichtig ist, dass dieser Beweis keine Informationen ├╝ber die privaten Eingaben preisgibt. Wir k├Ânnen diesen Beweis zusammen mit dem tx_hash an eine Mint senden und es w├Ąre davon ├╝berzeugt, dass dieser tx_hash ein Hash einer g├╝ltigen Transaktion ist. Die M├╝nzanstalt k├Ânnte dann tx_hash unterschreiben, um die Neuausgabe zu best├Ątigen.

Das ist sehr cool, aber die Forschung in diesem Bereich ist noch jung und die Werkzeuge rund um diese ZK-Schaltsysteme noch ziemlich unausgereift. Beweise sind in der Regel sehr langsam zu erstellen und zu verifizieren, insbesondere f├╝r komplizierte Schaltungen wie sha3_256.

Wenn Sie tiefer gehen m├Âchten diese Serie ist ziemlich gut.

Klingelsignaturen

Ringsignaturen, wie sie in Monero und anderen Kryptow├Ąhrungen verwendet werden, sind eine Methode, um den Transaktionsverlauf zu verschleiern, indem sie sich in einer Gruppe verstecken.

In einer Ringsignatur signiert Alice eine Transaktion unter Verwendung von (1) Alices privatem Schl├╝ssel, (2) Alices ├Âffentlichem Schl├╝ssel und (3) den ├Âffentlichen Schl├╝sseln anderer Personen. Jeder kann Alices Signatur mit dem Satz ├Âffentlicher Schl├╝ssel ├╝berpr├╝fen, aber er kann (normalerweise) nicht feststellen, wer der wahre Unterzeichner war, da es mehrere ├Ąquivalente ├Âffentliche Schl├╝ssel gibt.

Als solche sind Ringsignaturen eine Form des automatischen Mischens. Es gibt noch immer Links, aber es gibt so viele davon, dass es zu schwierig sein kann, sie zu analysieren. In Monero gibt es derzeit 11 m├Âgliche Unterzeichner: den echten plus 10 weitere. Das ist also, als w├╝rde man sich in einer Menge von 11 Leuten versteckenÔÇŽ besser als alleine zu stehen, aber nicht sehr tr├Âstlich, wenn ein Bluthund herumschn├╝ffelt.

Ausgeblendeter Betrag

Ausblenden des Betrags, auch bekannt als Vertrauliche Transaktionen, tr├Ągt ebenfalls zur Verbesserung der Privatsph├Ąre bei, beeintr├Ąchtigt jedoch nicht die [Un]Verkn├╝pfbarkeit.

Amount Hiding ist mit zk-Schaltungen und Ringsignaturen kompatibel, jedoch nicht mit einem blinden Signaturansatz, der normalerweise die Verwendung fester St├╝ckelungen erfordert.

Wir haben Amount Hiding ├╝ber Pedersen-Verpflichtungen in einem vorherigen Update.

Feste St├╝ckelungen

Feste St├╝ckelungen sind eine weitere Form des Datenschutzes, ├Ąhnlich dem Zweck des Verbergens. Das System erlaubt nur eine begrenzte Anzahl von Betr├Ągen. Um einen anderen Betrag darzustellen, muss man die bekannten Betr├Ąge verwenden.

Alle Transaktionen zu zwingen, diese festen Betr├Ąge zu verwenden, bedeutet, dass alle Eingaben und Ausgaben einer Transaktion normal erscheinen. W├Ąhrend der Gesamtbetrag einer bestimmten Transaktion sichtbar ist, kann man einen bestimmten Input oder Output nicht effektiv anhand seines Betrags verfolgen, da er in einen Ozean von anderen Token im Wert des gleichen Betrags verschmilzt. Als solche sind alle Einheiten einer bestimmten Denomination miteinander fungibel.

Daher ist es wichtig, die Gesamtzahl der St├╝ckelungen klein zu halten. Man k├Ânnte zum Beispiel jeden ganzzahligen Wert auf seinen eigenen Nennwert definieren. Dies w├╝rde zwar technisch funktionieren, ist aber schlecht f├╝r die Privatsph├Ąre, da die Leute oft sehr einzigartige Mengen verwenden. Anstatt in einen Ozean zu verschmelzen, wandert ein einzelner Tropfen von selbst.


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!