Über Anonymität in account-basierten Blockchains

Wir interessieren uns schon lange für das Thema Anonymität in Kryptowährungen und versuchen, die Entwicklungen in diesem Bereich zu verfolgen. In unseren Artikeln haben wir bereits ausführlich die Funktionsweise erklärt von vertraulichen Transaktionen in Monero und haben auch einen vergleichenden Überblick über die Technologien gegeben, die in diesem Bereich existieren. Dennoch basieren alle anonymen Kryptowährungen bis heute 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 Mobius oder Aztec) versucht, das UTXO-Modell in Smart Contracts zu reproduzieren.

Im Februar 2019 veröffentlichte eine Gruppe von Forschern der Stanford University und Visa Research wurde veröffentlicht einen Preprint mit dem Titel „Zether: Auf dem Weg zur Privatsphäre in der Welt der Smart Contracts“. Die Autoren schlugen erstmals einen Ansatz zur Gewährleistung der Anonymität in account-basierten Blockchains vor und präsentierten zwei Varianten von Smart Contracts: für vertrauliche (Verbergung von Salden und Überweisungsbeträgen) und anonyme (Verbergung von Empfänger und Absender) Transaktionen. Wir finden die vorgeschlagene Technologie interessant und möchten deren Funktionsweise teilen sowie darüber sprechen, warum das Problem der Anonymität in account-basierten Blockchains als sehr komplex angesehen wird und ob es den Autoren gelungen ist, dies vollständig zu lösen.

Über die Funktionsweise dieser Datenmodelle

Im UTXO-Modell besteht eine Transaktion aus „Eingängen“ und „Ausgängen“. Ein direkter Vergleich zu „Ausgängen“ wäre die Banknoten in Ihrer Geldbörse: jeder „Ausgang“ hat einen bestimmten Nennwert. Wenn Sie jemandem bezahlen (eine Transaktion durchführen), verwenden Sie einen oder mehrere „Ausgänge“, wobei diese zu den „Eingängen“ der Transaktion werden und die Blockchain sie als ausgegeben markiert. Der Empfänger Ihrer Zahlung (oder Sie selbst, wenn Sie Wechselgeld benötigen) erhält neu generierte „Ausgänge“. Schematisch lässt sich das so darstellen:

Account-basierte Blockchains funktionieren in etwa wie Ihr Bankkonto. Sie operieren nur mit dem Betrag auf Ihrem Konto und dem Überweisungsbetrag. Wenn Sie einen Betrag von Ihrem Konto übertragen, verbrennen Sie keine „Ausgänge“, das Netzwerk muss sich nicht merken, welche Coins ausgegeben wurden und welche nicht. Im einfachsten Fall reduziert sich die Überprüfung der Transaktion auf die Prüfung der Unterschrift des Absenders und des Betrags auf seinem Guthaben:

Überprüfung der Technologie

Als Nächstes werden wir besprechen, wie Zether die Beträge von Transaktionen, den Empfänger und den Absender verbirgt. Im Laufe der Beschreibung der Funktionsweise werden wir die Unterschiede zwischen der vertraulichen und der anonymen Version hervorheben. Da es viel einfacher ist, in auf Konten basierenden Blockchains Vertraulichkeit zu gewährleisten, werden einige der durch Anonymisierung auferlegten Einschränkungen für die vertrauliche Version der Technologie irrelevant sein.

Verbergung von Kontoständen und Überweisungsbeträgen

Zur Verschlüsselung von Kontoständen und Überweisungsbeträgen verwendet Zether ein Verschlüsselungsverfahren von ElGamal. Es funktioniert folgendermaßen. Wenn Alice Bob b Münzen an die Adresse (seinen öffentlichen Schlüssel) Ysenden möchte, wählt sie eine zufällige Zahl r und verschlüsselt den Betrag:

wo C — der verschlüsselte Betrag, D — ein Hilfswert, der zur Entschlüsselung dieses Betrags benötigt wird, G — ein fester Punkt auf der elliptischen Kurve, bei dessen Multiplikation mit dem geheimen Schlüssel der öffentliche Schlüssel entsteht.

Wenn Bob diese Werte erhält, addiert er sie einfach zu seinem ebenfalls auf die gleiche Weise verschlüsselten Kontostand, was dieses Verfahren praktisch macht.

Auf ähnliche Weise subtrahiert Alice aus ihrem Kontostand dieselben Werte, nur dass sie als Y ihren öffentlichen Schlüssel verwendet.

Verbergung von Empfänger und Absender

Das Mischen von 'Ausgängen' in UTXO entstand bereits in den Anfängen von Kryptowährungen und hilft, den Absender zu verbergen. Dazu wählt der Absender bei der Überweisung zufällige 'Ausgänge' aus der Blockchain aus und mischt diese mit seinen eigenen. Danach signiert er die 'Ausgänge' mit einer Ringunterschrift — einem kryptografischen Mechanismus, der es ermöglicht, den Prüfer zu überzeugen, dass unter den gemischten 'Ausgängen' die Münzen des Absenders sind. Die gemischten Münzen werden selbstverständlich nicht ausgegeben.

Um den Empfänger jedoch zu verbergen, können wir keine falschen 'Ausgänge' generieren. Daher hat jeder 'Ausgang' in UTXO seine eigene eindeutige Adresse, die kryptografisch mit der Adresse des Empfängers dieser Münzen verbunden ist. Momentan gibt es keine Möglichkeit, die Verbindung zwischen der eindeutigen Adresse des 'Ausgangs' und der Adresse des Empfängers zu erkennen, ohne seine geheimen Schlüssel zu kennen.

In einem account-basierten Modell können wir keine einmaligen Adressen verwenden (ansonsten wäre das bereits ein Modell der „Ausgänge“). Daher müssen der Empfänger und der Absender unter anderen Konten in der Blockchain vermischt werden. Bei diesen vermischten Konten werden verschlüsselte 0 Münzen abgebucht (oder 0 hinzugefügt – im Fall des Vermischens des Empfängers), ohne das tatsächliche Guthaben zu verändern.

Da sowohl der Absender als auch der Empfänger immer eine permanente Adresse haben, entsteht hier die Notwendigkeit, bei Überweisungen an dieselben Adressen dieselben Gruppen für die Vermischung zu verwenden. Es lässt sich einfacher anhand eines Beispiels erklären.

Angenommen, Alice hat sich entschlossen, eine Spende an die Wohltätigkeitsorganisation von Bob zu machen, möchte aber, dass diese Überweisung anonym bleibt für einen außenstehenden Beobachter. Um sich im Absenderfeld zu tarnen, trägt sie noch die Konten von Adam und Adele ein. Und um Bob zu verbergen, fügt sie im Empfängerfeld zusätzlich die Konten von Ben und Bill hinzu. Bei der nächsten Spende entschied sich Alice, neben sich Alex und Amanda sowie neben Bob Bruce und Benjamin einzutragen. In diesem Fall findet man bei der Analyse der Blockchain in diesen beiden Transaktionen lediglich ein sich überschneidendes Pärchen von Teilnehmern — Alice und Bob, was diese Transaktionen deanonimisiert.

Transaktionsrennen

Wie bereits erwähnt, verschlüsselt der Benutzer sein Guthaben und den Überweisungsbetrag, um sein Guthaben in account-basierten Systemen zu verbergen. Dabei muss er nachweisen, dass der Rest auf seinem Konto nicht negativ ist. Das Problem besteht darin, dass der Benutzer beim Erstellen einer Transaktion einen Nachweis über seinen aktuellen Kontostand erstellt. Was passiert, wenn Bob Alice eine Transaktion zusendet und diese früher akzeptiert wird als die von Alice gesendete? Dann wird Alices Transaktion als ungültig angesehen, da der Nachweis des Guthabens vor der Annahme von Bobs Transaktion erstellt wurde.

Die erste Lösung, die in dieser Situation einfällt, ist, das Konto bis zur Durchführung der Transaktion einzufrieren. Aber dieser Ansatz ist nicht praktikabel, da neben der Schwierigkeit, eine solche Aufgabe in einem verteilten System zu lösen, in einem anonymen Schema unklar bleibt, wessen Konto blockiert werden soll.

Um dieses Problem zu lösen, trennt die Technologie eingehende und ausgehende Transaktionen: Der Einsatz von Mitteln hat sofortige Auswirkungen auf den Kontostand, während Einnahmen verzögert erfolgen. Dazu wird der Begriff „Epoche“ eingeführt – eine Gruppe von Blöcken fester Größe. Die aktuelle „Epoche“ 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 stehen dem Empfänger der Zahlung erst zur Verfügung, wenn die neue „Epoche“ einsetzt.

Infolgedessen kann der Nutzer Transaktionen senden, unabhängig davon, wie oft er Mittel erhält (sofern sein Kontostand es zulässt, versteht sich). Die Größe der Epoche wird bestimmt durch die Geschwindigkeit, mit der sich Blöcke im Netzwerk verbreiten, und wie schnell eine Transaktion in einen Block gelangt.

Diese Lösung funktioniert gut bei vertraulichen Ü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 Überprüfer davon überzeugt, dass die Transaktion nicht verändert wurde und von dem Besitzer dieses Schlüssels erstellt wurde. Was geschieht jedoch, wenn ein Angreifer, der den Übertragungskanal abgehört hat, diese Nachricht abfängt und eine identische zweite sendet? Der Überprüfer vergleicht die Signatur der Transaktion und ist überzeugt von ihrer Herkunft, und das Netzwerk zieht den gleichen Betrag erneut vom Kontostand des Absenders ab.

Dieser Angriff wird als Replay-Angriff bezeichnet. Im UTXO-Modell sind solche Angriffe nicht relevant, da der Angreifer versuchen würde, ausgegebene Ausgänge zu verwenden, was für sich allein nicht gültig ist und vom Netzwerk abgelehnt wird.

Um dies zu verhindern, wird ein Feld mit zufälligen Daten in die Transaktion integriert, das als Nonce oder einfach „Salz“ bezeichnet wird. Bei der erneuten Übertragung einer Transaktion mit „Salz“ prüft der Überprüfer, ob dieser Nonce zuvor verwendet wurde, und wenn nicht, gilt diese Transaktion als gültig. Um nicht die gesamte Geschichte der Nonces von Nutzern 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 vergangenen unterscheidet.

In anonymen Überweisungssystemen tritt das Problem der Validierung von Transaktions-Nonce auf. Wir können den Nonce nicht direkt an die Adresse des Absenders binden, da dies offensichtlich die Überweisung de-anonymisieren würde. Wir können auch nicht zu den Nonce aller beteiligten Konten eins addieren, da dies mit anderen Überweisungen, die in Bearbeitung sind, in Konflikt geraten kann.

Die Autoren von Zether schlagen vor, die Nonce kryptografisch zu generieren — abhängig von der „Ära“. Zum Beispiel:

Hier x — der geheime Schlüssel des Absenders und Gepoch — ein zusätzlicher Generator für die Ära, der durch Hashing eines Strings der Art „Zether + “ erhalten wird. Damit scheint das Problem gelöst zu sein — wir geben die Nonce des Absenders nicht preis und mischen uns nicht in die Nonce unbeteiligter Teilnehmer ein. Aber dieser Ansatz bringt eine ernsthafte Einschränkung mit sich: Ein Konto kann nicht mehr als eine Transaktion in einer „Ära“ senden. Dieses Problem bleibt leider ungelöst und macht die anonyme Version von Zether derzeit, unserer Meinung nach, kaum brauchbar.

Die Komplexität der Null-Wissen-Beweise

In UTXO muss der Absender dem Netzwerk beweisen, dass er keinen negativen Betrag ausgibt, da sonst die Möglichkeit besteht, neue Münzen aus dem Nichts zu generieren (warum dies möglich ist, haben wir in einem der vorherigen Artikel). Außerdem muss er die „Eingänge“ mit einer Ringunterschrift signieren, um zu beweisen, dass unter den gemischten Münzen auch Mittel sind, die ihm gehören.

In der anonymen Version der account-basierten Blockchain wird der Beweis wesentlich komplizierter. Der Absender muss beweisen, dass:

1. Der gesendete Betrag positiv ist;
2. Das Guthaben nicht negativ bleibt;
3. Der Absender die Beträge der Überweisungen (einschließlich null) korrekt verschlüsselt hat;
4. Der Kontostand ändert sich nur beim Absender und beim Empfänger;
5. Der Absender besitz den geheimen Schlüssel seines Kontos und dieser ist tatsächlich in der Liste der Absender (unter den gemischten) vorhanden;
6. Der in der Transaktion verwendete Nonce ist korrekt zusammengesetzt.

Für einen so komplexen Beweis verwenden die Autoren eine Mischung Bulletproof (übrigens war einer der Autoren an seiner Erstellung beteiligt) und Sigma-Protokoll, das sie Sigma-Bullets nennen. Der formale Beweis einer solchen Behauptung ist eine ziemlich komplexe Aufgabe und schränkt die Zahl derjenigen, die sich mit der Umsetzung der Technologie befassen wollen, erheblich ein.

Was kommt dabei heraus?

Nach unserer Ansicht könnte der Zether-Teil, der Vertraulichkeit in account-basierten Blockchains einführt, durchaus bereits jetzt verwendet werden. Aber derzeit bringt die anonyme Version der Technologie erhebliche Einschränkungen für ihre Nutzung mit sich, und ihre Komplexität erschwert die Implementierung. Man sollte jedoch nicht außer Acht lassen, dass die Autoren sie erst vor wenigen Monaten veröffentlicht haben, und vielleicht wird jemand anderes eine Lösung für die heutigen Probleme finden. So funktioniert schließlich Wissenschaft.

Quelle: habr.com