Wir beschäftigen uns schon seit längerem mit dem Thema Anonymität in Kryptowährungen und verfolgen die Entwicklungen in diesem Bereich. In unseren Artikeln haben wir bereits die Funktionsweise in Monero ausführlich behandelt und durchgeführt über die Technologien, die in diesem Bereich existieren. Dennoch basieren alle anonymen Kryptowährungen heutzutage auf dem von Bitcoin vorgeschlagenen Datenmodell — Unspent Transaction Output (UTXO). Für account-basierte Blockchains wie Ethereum haben die bestehenden Lösungen zur Umsetzung von Anonymität und Vertraulichkeit (zum Beispiel oder ) versucht, das UTXO-Modell in Smart Contracts zu reproduzieren.
Im Februar 2019 veröffentlichte eine Forschungsgruppe der Stanford Universität und Visa Research veröffentlicht „Zether: Auf dem Weg zur Privatsphäre in der Welt der Smart Contracts“. Die Autoren haben erstmals einen Ansatz zur Gewährleistung von Anonymität in account-basierten Blockchains vorgeschlagen und zwei Varianten von Smart Contracts vorgestellt: für vertrauliche (Verbergen von Salden und Überweisungsbeträgen) und anonyme (Verbergen von Empfänger und Absender) Transaktionen. Wir finden die vorgeschlagene Technologie interessant und möchten deren Funktionsweise teilen und darüber sprechen, warum das Problem der Anonymität in account-basierten Blockchains als sehr komplex gilt und ob es den Autoren gelungen ist, es vollständig zu lösen.
Über die Struktur dieser Datenmodelle
In der UTXO-Modell besteht eine Transaktion aus „Inputs“ und „Outputs“. Der direkte Vergleich zu den „Outputs“ sind die Geldscheine in Ihrer Brieftasche: Jeder „Output“ hat einen bestimmten Nennwert. Wenn Sie mit jemandem bezahlen (eine Transaktion durchführen), verwenden Sie einen oder mehrere „Outputs“, die dann zu „Inputs“ der Transaktion werden, und die Blockchain kennzeichnet sie als ausgegeben. Dabei erhält der Empfänger Ihrer Zahlung (oder Sie selbst, wenn Sie Wechselgeld brauchen) neu generierte „Outputs“. Schematically kann das so dargestellt werden:
Account-basierte Blockchains funktionieren ähnlich wie Ihr Bankkonto. Sie operieren nur mit dem Betrag auf Ihrem Konto und dem Betrag der Überweisung. Wenn Sie einen Betrag von Ihrem Konto überweisen, verbrennen Sie keine „Outputs“, und das Netzwerk muss sich nicht merken, welche Coins ausgegeben wurden und welche nicht. Im einfachsten Fall beschränkt sich die Überprüfung der Transaktion auf die Überprüfung der Signatur des Absenders und des Betrags auf seinem Guthaben:
Technologischer Überblick
Im Folgenden werden wir erörtern, wie Zether den Betrag der Transaktionen, den Empfänger und den Absender verbirgt. Während wir die Funktionsweise beschreiben, werden wir die Unterschiede zwischen der vertraulichen und der anonymen Version hervorheben. Da es viel einfacher ist, in account-basierten Blockchains die Vertraulichkeit zu gewährleisten, werden einige der Einschränkungen, die durch Anonymisierung entstehen, für die vertrauliche Version der Technologie irrelevant sein.
Verbergung von Guthaben und Überweisungsbeträgen
Für die Verschlüsselung von Guthaben und Überweisungsbeträgen verwendet Zether das -Verschlüsselungsschema. Es funktioniert folgendermaßen: Wenn Alice Bob b Coins an die Adresse (seinen öffentlichen Schlüssel) schicken möchte, Ywählt sie eine Zufallszahl r und verschlüsselt den Betrag:
wobei C — verschlüsselter Betrag, OS-Angriffen — ein Hilfswert, der zur Entschlüsselung dieses Betrags erforderlich ist, G — ein fester Punkt auf einer elliptischen Kurve, bei dem die Multiplikation des geheimen Schlüssels den öffentlichen Schlüssel ergibt.
Wenn Bob diese Werte erhält, addiert er sie einfach zu seinem kryptographisch ähnlichen Guthaben, was dieses Verfahren so praktisch macht.
Ebenso zieht Alice dieselben Werte von ihrem Guthaben ab, allerdings verwendet sie ihren Y öffentlichen Schlüssel.
Verborgene Absender- und Empfängeradressen
Das Mischen von 'Ausgaben' in UTXO entstand bereits in der Frühzeit der Kryptowährungen und hilft, den Absender zu verschleiern. Dafür wählt der Absender beim Durchführen einer Transaktion zufällige 'Ausgaben' aus der Blockchain aus und mischt sie mit seinen eigenen. Anschließend signiert er die 'Ausgaben' mit einer Ring-Signatur – einem kryptographischen Mechanismus, der es dem Prüfer ermöglicht zu bestätigen, dass unter den gemischten 'Ausgaben' auch Münzen des Absenders vorhanden sind. Die gemischten Münzen selbst werden selbstverständlich nicht ausgegeben.
Um den Empfänger zu verschleiern, können wir jedoch keine falschen „Ausgänge“ generieren. Daher hat jeder „Ausgang“ in UTXO seine eigene einzigartige Adresse, die kryptografisch mit der Adresse des Empfängers dieser Münzen verbunden ist. Derzeit gibt es keine Möglichkeit, die Verbindung zwischen der einzigartigen Adresse des „Ausgangs“ und der Adresse des Empfängers zu erkennen, ohne seine geheimen Schlüssel zu kennen.
Im account-basierten Modell können wir keine einmaligen Adressen verwenden (ansonsten wäre es bereits ein „Ausgangs“-Modell). Daher müssen wir den Empfänger und den Absender unter anderen Konten im Blockchain mischen. Dabei wird von den gemischten Konten 0 Münzen verschlüsselt abgezogen (oder 0 hinzugefügt – im Fall des Mischens des Empfängers), was ihren tatsächlichen Betrag nicht verändert.
Da sowohl der Absender als auch der Empfänger immer eine feste Adresse haben, besteht hier die Notwendigkeit, bei Überweisungen an dieselben Adressen dieselben Gruppen zum Mischen zu verwenden. Das lässt sich einfacher anhand eines Beispiels erklären.
Angenommen, Alice möchte eine Spende an Bobs Wohlfahrtsorganisation tätigen, bevorzugt jedoch, dass diese Überweisung für Außenstehende anonym bleibt. Um sich im Absenderfeld zu tarnen, fügt sie zusätzlich Adams und Adeles Konten hinzu. Um Bob zu verbergen, trägt sie im Empfängerfeld zusätzlich Bens und Bills Konten ein. Bei der nächsten Spende beschließt Alice, Alex und Amanda neben sich einzutragen und Bruce sowie Benjen neben Bob. In diesem Fall wird bei der Analyse der Blockchain bei diesen beiden Transaktionen nur ein überlappendes Teilnehmerpaar gefunden – Alice und Bob, was diese Transaktionen de-anonymisiert.
Transaktionsrennen
Wie bereits erwähnt, verschlüsselt der Benutzer in kontobasierten Systemen sein Guthaben und den Überweisungsbetrag, um sein Guthaben zu verbergen. Dabei muss er nachweisen, dass der Restbetrag auf seinem Konto nicht negativ ist. Das Problem besteht darin, dass der Benutzer beim Erstellen einer Transaktion einen Nachweis über seinen aktuellen Kontostand erbringen muss. Was passiert, wenn Bob Alice eine Transaktion sendet und diese akzeptiert wird, bevor die von Alice gesendete? In diesem Fall wird die Transaktion von Alice als ungültig betrachtet, da der Nachweis über das Guthaben vor der Annahme der Transaktion von Bob erbracht wurde.
Die erste Lösung, die in einer solchen Situation in den Sinn kommt, ist, das Konto bis zur Durchführung der Transaktion einzufrieren. Dieser Ansatz eignet sich jedoch nicht, da es in einem verteilten System nicht nur kompliziert ist, eine solche Aufgabe zu lösen, sondern auch in einem anonymen Schema unklar sein wird, welches Konto blockiert werden soll.
Um dieses Problem zu lösen, trennt die Technologie eingehende und ausgehende Transaktionen: Ausgaben haben sofortige Auswirkungen auf den Kontostand, während Einnahmen davon verzögert sind. Zu diesem Zweck wird der Begriff "Epoch" eingeführt – eine Gruppe von Blöcken fester Größe. Die aktuelle "Epoch" wird bestimmt, indem die Blockhöhe durch die Gruppengröße geteilt wird. Bei der Verarbeitung einer Transaktion aktualisiert das Netzwerk sofort den Kontostand des Absenders, während die Mittel des Empfängers in einem Speicher gesammelt werden. Die gesammelten Mittel werden dem Zahlungsempfänger erst bei Beginn der nächsten "Epoch" zur Verfügung gestellt.
Infolgedessen kann der Benutzer Transaktionen senden, unabhängig davon, wie oft er Mittel erhält (vorausgesetzt, sein Kontostand erlaubt es). Die Größe der Epoch wird bestimmt durch die Geschwindigkeit, mit der Blöcke im Netzwerk verbreitet werden, und wie schnell eine Transaktion in einen Block gelangt.
Diese Lösung funktioniert gut für vertrauliche Überweisungen, verursacht jedoch bei anonymen Transaktionen, wie wir später sehen werden, ernsthafte Probleme.
Schutz vor Replay-Angriffen
In account-basierten Blockchains wird jede Transaktion mit dem privaten Schlüssel des Absenders signiert, was den Prüfer davon überzeugt, dass die Transaktion unverändert bleibt und von dem Eigentümer dieses Schlüssels erstellt wurde. Aber was passiert, wenn ein Angreifer, der den Übertragungskanal überwacht, diese Nachricht abfängt und exakt dieselbe zweite Nachricht sendet? Der Prüfer wird die Signatur der Transaktion überprüfen und von ihrer Authentizität überzeugt sein, und das Netzwerk wird denselben Betrag erneut vom Konto des Absenders abziehen.
Dieser Angriff wird als Replay-Angriff bezeichnet. In der UTXO-Modell sind solche Angriffe nicht relevant, da der Angreifer versuchen würde, bereits ausgegebene Ausgänge zu verwenden, was von Haus aus nicht gültig ist und vom Netzwerk abgelehnt wird.
Um dies zu verhindern, wird in die Transaktion ein Feld mit zufälligen Daten eingefügt, das als Nonce oder einfach als „Salt“ bezeichnet wird. Bei einer erneuten Übermittlung der Transaktion mit dem „Salt“ überprüft der Prüfer, ob diese Nonce bereits zuvor verwendet wurde, und wenn nicht, wird die Transaktion als gültig betrachtet. Um nicht die gesamte Historie der Nonces der Benutzer in der Blockchain zu speichern, wird in der ersten Transaktion der Nonce normalerweise auf null gesetzt und dann um eins erhöht. Das Netzwerk muss nur überprüfen, dass der Nonce der neuen Transaktion sich um eins von dem vorherigen unterscheidet.
Im anonymen Übertragungsschema stellt sich das Problem der Validierung der Nonces für Transaktionen. Wir können den Nonce nicht explizit an die Adresse des Absenders binden, da dies offensichtlich die Überweisung de-anonymisieren würde. Wir können auch nicht einfach eins zu den Nonces aller beteiligten Konten addieren, da dies mit anderen Transaktionen in Konflikt geraten könnte, die sich in Bearbeitung befinden.
Die Autoren von Zether schlagen vor, Nonces kryptografisch zu generieren – abhängig von der „Epoche“. Zum Beispiel:
Hier x — der geheime Schlüssel des Absenders, und Gepoch — ein zusätzlicher Generator für die Epoche, der durch das Hashen einer Zeichenkette der Form ‚Zether + ‚ erzeugt wird. Nun scheint das Problem gelöst zu sein — wir geben den Nonce des Absenders nicht preis und mischen uns nicht in die Nonce unbeteiligter Teilnehmer ein. Doch dieser Ansatz bringt eine erhebliche Einschränkung mit sich: Ein Konto kann in einer „Epoche“ nicht mehr als eine Transaktion senden. Leider bleibt dieses Problem ungelöst, und derzeit macht es die anonyme Version von Zether, unserer Meinung nach, kaum brauchbar.
Die Komplexität der Zero-Knowledge-Beweise
Im UTXO muss der Absender dem Netzwerk beweisen, dass er keinen negativen Betrag ausgibt, sonst wäre es möglich, neue Münzen aus dem Nichts zu generieren (warum dies möglich ist, haben wir in einem der vorherigen ). Zudem muss er die „Inputs“ mit einer Ringunterschrift signieren, um zu beweisen, dass unter den vermischten Münzen auch Mittel sind, die ihm gehören.
In der anonymen Version eines konto-basierten Blockchains sind die Ausdrücke für den Beweis deutlich komplizierter. Der Absender muss beweisen, dass:
- Der überwiesene Betrag positiv ist;
- Der Kontostand nicht negativ bleibt;
- Der Absender hat die Beträge der Überweisungen (einschließlich Nullbeträge) korrekt verschlüsselt.
- Der Kontostand ändert sich nur beim Absender und Empfänger.
- Der Absender besitzt den geheimen Schlüssel zu seinem Konto, und dieser ist tatsächlich in der Liste der Absender (unter den Beteiligten) vorhanden.
- Der in der Transaktion verwendete Nonce ist korrekt zusammengesetzt.
Für diesen komplexen Nachweis verwenden die Autoren eine Mischung (einer der Autoren war übrigens an ihrer Entwicklung beteiligt) und , das als Sigma-Bullets bezeichnet wird. Ein formaler Nachweis eines solchen Anspruchs ist eine ziemlich komplexe Aufgabe und schränkt die Anzahl derjenigen, die sich mit der Umsetzung der Technologie befassen wollen, stark ein.
Was ist das Ergebnis?
Unserer Meinung nach kann der Teil von Zether, der Privatsphäre in kontobasierten Blockchains einführt, durchaus bereits jetzt Verwendung finden. Doch derzeit bringt die anonyme Version der Technologie erhebliche Einschränkungen bei ihrer Nutzung mit sich, und ihre Komplexität beeinträchtigt die Implementierung. Man sollte jedoch nicht vergessen, dass die Autoren sie erst vor wenigen Monaten veröffentlicht haben und es möglicherweise jemand anderen gibt, der Lösungen für die heutigen Probleme findet. Genau so funktioniert Wissenschaft.
Quelle: habr.com
