Wir interessieren uns schon seit langem für das Thema Anonymität in Kryptowährungen und versuchen, die Entwicklung der Technologien in diesem Bereich zu verfolgen. In unseren Artikeln haben wir die Funktionsprinzipien bereits ausführlich besprochen in Monero, und auch durchgeführt Technologien, die es in diesem Bereich gibt. Allerdings basieren heute alle anonymen Kryptowährungen auf dem von Bitcoin vorgeschlagenen Datenmodell – Unspent Transaction Output (im Folgenden UTXO). Für kontobasierte Blockchains wie Ethereum sind bestehende Lösungen zur Umsetzung von Anonymität und Vertraulichkeit (z. B. oder ) hat versucht, das UTXO-Modell in Smart Contracts zu replizieren.
Im Februar 2019 hat eine Gruppe von Forschern der Stanford University und Visa Research freigegeben „Zether: Auf dem Weg zum Datenschutz in der Welt der Smart Contracts.“ Die Autoren waren die ersten, die einen Ansatz zur Gewährleistung der Anonymität in kontobasierten Blockchains vorschlugen und zwei Versionen eines Smart Contracts vorstellten: für vertrauliche (Verbergung von Guthaben und Überweisungsbeträgen) und anonyme (Verbergung von Empfänger und Absender) Transaktionen. Wir finden die vorgeschlagene Technologie interessant und möchten ihr Design teilen und darüber sprechen, warum das Problem der Anonymität in kontobasierten Blockchains als sehr schwierig angesehen wird und ob es den Autoren gelungen ist, es vollständig zu lösen.
Über den Aufbau dieser Datenmodelle
Im UTXO-Modell besteht eine Transaktion aus „Inputs“ und „Outputs“. Ein direktes Analogon zu „Outputs“ sind die Scheine in Ihrer Brieftasche: Jeder „Output“ hat einen bestimmten Nennwert. Wenn Sie jemanden bezahlen (eine Transaktion durchführen), geben Sie einen oder mehrere „Outputs“ aus. In diesem Fall werden diese zu „Inputs“ der Transaktion und die Blockchain markiert sie als ausgegeben. In diesem Fall erhält der Empfänger Ihrer Zahlung (oder Sie selbst, wenn Sie Wechselgeld benötigen) die neu generierten „Outputs“. Schematisch lässt sich das so darstellen:
Kontobasierte Blockchains sind ähnlich wie Ihr Bankkonto aufgebaut. Sie verarbeiten nur den Betrag auf Ihrem Konto und den Überweisungsbetrag. Wenn Sie einen Betrag von Ihrem Konto überweisen, verbrennen Sie keine „Ausgaben“, das Netzwerk muss sich nicht merken, welche Münzen ausgegeben wurden und welche nicht. Im einfachsten Fall besteht die Transaktionsverifizierung darin, die Unterschrift des Absenders und den Betrag auf seinem Guthaben zu überprüfen:
Analyse der Technologie
Als Nächstes sprechen wir darüber, wie Zether den Transaktionsbetrag, den Empfänger und den Absender verbirgt. Während wir die Funktionsprinzipien beschreiben, werden wir die Unterschiede zwischen der vertraulichen und der anonymen Version beachten. Da es in kontobasierten Blockchains viel einfacher ist, die Vertraulichkeit zu gewährleisten, werden einige der durch die Anonymisierung auferlegten Einschränkungen für die vertrauliche Version der Technologie nicht relevant sein.
Ausblenden von Salden und Überweisungsbeträgen
Zur Verschlüsselung von Guthaben und Überweisungsbeträgen in Zether wird ein Verschlüsselungsschema verwendet . Es funktioniert wie folgt. Als Alice Bob schicken will b Münzen nach Adresse (ihrem öffentlichen Schlüssel) Y, sie wählt eine Zufallszahl r und verschlüsselt den Betrag:
wo C - verschlüsselter Betrag, D - Hilfswert, der zur Entschlüsselung dieses Betrags erforderlich ist, G - ein fester Punkt auf der elliptischen Kurve, durch Multiplikation mit dem geheimen Schlüssel erhält man den öffentlichen Schlüssel.
Wenn Bob diese Werte erhält, fügt er sie einfach auf die gleiche Weise seinem verschlüsselten Guthaben hinzu, weshalb dieses Schema praktisch ist.
In ähnlicher Weise subtrahiert Alice dieselben Werte von ihrem Guthaben, nur als Y verwendet Ihren öffentlichen Schlüssel.
Empfänger und Absender verbergen
Das Mischen von „Ausgaben“ in UTXO geht auf die Anfänge der Kryptowährungen zurück und hilft dabei, den Absender zu verbergen. Dazu sammelt der Absender selbst bei einer Überweisung zufällige „Outputs“ in der Blockchain und mischt diese mit seinen eigenen. Als nächstes signiert er die „Ausgaben“ mit einer Ringsignatur – einem kryptografischen Mechanismus, der es ihm ermöglicht, den Verifizierer davon zu überzeugen, dass sich die Münzen des Absenders unter den beteiligten „Ausgaben“ befinden. Die gemischten Münzen selbst werden natürlich nicht ausgegeben.
Wir werden jedoch nicht in der Lage sein, gefälschte Ausgaben zu generieren, um den Empfänger zu verbergen. Daher hat in UTXO jeder „Ausgang“ seine eigene eindeutige Adresse und ist kryptografisch mit der Adresse des Empfängers dieser Münzen verknüpft. Derzeit gibt es keine Möglichkeit, die Beziehung zwischen der eindeutigen Ausgabeadresse und der Empfängeradresse zu identifizieren, ohne deren geheime Schlüssel zu kennen.
Im kontobasierten Modell können wir keine Einmaladressen verwenden (ansonsten handelt es sich bereits um ein „Exits“-Modell). Daher müssen Empfänger und Absender unter anderen Konten in der Blockchain gemischt werden. In diesem Fall werden verschlüsselte 0 Münzen von den gemischten Konten abgebucht (oder 0 hinzugefügt, wenn der Empfänger gemischt ist), ohne dass sich der tatsächliche Kontostand tatsächlich ändert.
Da sowohl der Absender als auch der Empfänger immer eine feste Adresse haben, ist es erforderlich, bei der Übertragung an dieselben Adressen dieselben Gruppen für die Mischung zu verwenden. Es ist einfacher, dies anhand eines Beispiels zu betrachten.
Nehmen wir an, Alice beschließt, einen Beitrag für Bobs Wohltätigkeitsorganisation zu leisten, möchte aber, dass die Überweisung für einen externen Beobachter anonym bleibt. Anschließend trägt sie, um sich im Absenderfeld zu tarnen, auch die Accounts von Adam und Adele ein. Und um Bob auszublenden, fügen Sie die Konten von Ben und Bill im Empfängerfeld hinzu. Beim nächsten Beitrag beschloss Alice, Alex und Amanda neben sich und Bruce und Benjen neben Bob zu schreiben. In diesem Fall gibt es bei der Analyse der Blockchain in diesen beiden Transaktionen nur ein sich überschneidendes Teilnehmerpaar – Alice und Bob, wodurch diese Transaktionen deanonymisiert werden.
Transaktionsrennen
Wie wir bereits erwähnt haben, verschlüsselt der Benutzer seinen Kontostand und den Überweisungsbetrag, um sein Guthaben in kontobasierten Systemen zu verbergen. Gleichzeitig muss er nachweisen, dass der Saldo auf seinem Konto weiterhin 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 eine Transaktion an Alice sendet und diese vor der von Alice gesendeten Transaktion akzeptiert wird? Dann wird Alices Transaktion als ungültig betrachtet, da der Saldonachweis erstellt wurde, bevor Bobs Transaktion akzeptiert wurde.
Die erste Entscheidung in einer solchen Situation besteht darin, das Konto bis zur Durchführung der Transaktion zu sperren. Dieser Ansatz ist jedoch nicht geeignet, da neben der Komplexität der Lösung eines solchen Problems in einem verteilten System in einem anonymen System nicht klar ist, wessen Konto gesperrt werden soll.
Um dieses Problem zu lösen, trennt die Technologie eingehende und ausgehende Transaktionen: Ausgaben wirken sich sofort in der Bilanz aus, Einnahmen hingegen erst verzögert. Zu diesem Zweck wird das Konzept der „Epoche“ eingeführt – eine Gruppe von Blöcken fester Größe. Die aktuelle „Epoche“ wird ermittelt, indem die Blockhöhe durch die Gruppengröße geteilt wird. Bei der Verarbeitung einer Transaktion aktualisiert das Netzwerk sofort den Kontostand des Absenders und speichert die Gelder des Empfängers in einem Speichertank. Die angesammelten Mittel stehen dem Zahlungsempfänger erst dann zur Verfügung, wenn eine neue „Ära“ beginnt.
Dadurch kann der Nutzer unabhängig davon, wie oft Gelder eingehen, Transaktionen versenden (sofern sein Guthaben dies natürlich zulässt). Die Epochengröße wird basierend darauf bestimmt, wie schnell sich Blöcke durch das Netzwerk ausbreiten und wie schnell eine Transaktion in einen Block eintritt.
Diese Lösung funktioniert gut für vertrauliche Übertragungen, aber wie wir später sehen werden, führt sie bei anonymen Transaktionen zu ernsthaften Problemen.
Schutz vor Replay-Angriffen
In kontobasierten Blockchains wird jede Transaktion mit dem privaten Schlüssel des Absenders signiert, was den Verifizierer davon überzeugt, dass die Transaktion nicht verändert wurde und vom Besitzer dieses Schlüssels erstellt wurde. Was aber, wenn ein Angreifer, der den Übertragungskanal mitgehört hat, diese Nachricht abfängt und genau dieselbe zweite Nachricht sendet? Der Verifizierer überprüft die Signatur der Transaktion und überzeugt sich von deren Urheberschaft. Anschließend bucht das Netzwerk den gleichen Betrag erneut vom Guthaben des Absenders ab.
Dieser Angriff wird als Wiederholungsangriff bezeichnet. Im UTXO-Modell sind solche Angriffe nicht relevant, da der Angreifer versuchen wird, ausgegebene Ausgaben zu verwenden, was an sich ungültig ist und vom Netzwerk abgelehnt wird.
Um dies zu verhindern, wird in die Transaktion ein Feld mit Zufallsdaten eingebaut, das Nonce oder einfach „Salt“ genannt wird. Bei der erneuten Übermittlung einer Transaktion mit einem Salt prüft der Verifizierer, ob die Nonce schon einmal verwendet wurde, und wenn nicht, betrachtet er die Transaktion als gültig. Um nicht den gesamten Verlauf der Benutzer-Nonces in der Blockchain zu speichern, wird dieser normalerweise bei der allerersten Transaktion auf Null gesetzt und dann um eins erhöht. Das Netzwerk kann nur nacheinander prüfen, ob sich die Nonce der neuen Transaktion von der vorherigen unterscheidet.
Beim anonymen Übertragungsschema entsteht das Problem der Validierung von Transaktions-Nonces. Wir können die Nonce nicht explizit an die Absenderadresse binden, da die Übertragung dadurch natürlich deanonymisiert wird. Wir können auch keine Nonces zu den Nonces aller teilnehmenden Konten hinzufügen, da dies zu Konflikten mit anderen verarbeiteten Überweisungen führen kann.
Die Autoren von Zether schlagen vor, die Nonce je nach „Epoche“ kryptografisch zu generieren. Zum Beispiel:
Hier x ist der geheime Schlüssel des Absenders und Gepoch – ein zusätzlicher Generator für die Epoche, der durch Hashing einer Zeichenfolge der Form „Zether +“ erhalten wird. Nun scheint das Problem gelöst zu sein – wir geben die Nonce des Absenders nicht preis und greifen nicht in die Nonce unbeteiligter Teilnehmer ein. Dieser Ansatz bringt jedoch eine gravierende Einschränkung mit sich: Ein Konto kann nicht mehr als eine Transaktion pro „Epoche“ senden. Dieses Problem bleibt leider ungelöst und macht die anonyme Version von Zether unserer Meinung nach derzeit kaum für den Einsatz geeignet.
Die Komplexität von Zero-Knowledge-Beweisen
Bei UTXO muss der Absender dem Netzwerk nachweisen, dass er keinen negativen Betrag ausgibt, sonst wird es möglich, neue Münzen aus dem Nichts zu generieren (warum das möglich ist, haben wir in einem der vorherigen Artikel geschrieben). ). Und unterschreiben Sie die „Eingänge“ auch mit einer Ringsignatur, um zu beweisen, dass sich unter den gemischten Münzen Gelder befinden, die ihm gehören.
In der anonymen Variante der kontobasierten Blockchain sind die Beweisausdrücke deutlich komplexer. Der Absender weist Folgendes nach:
- Der gesendete Betrag ist positiv;
- Der Saldo bleibt nicht negativ;
- Der Absender hat die Überweisungsbeträge korrekt verschlüsselt (einschließlich Null);
- Der Saldo auf dem Kontostand ändert sich nur für den Absender und den Empfänger;
- Der Absender besitzt den privaten Schlüssel zu seinem Konto und steht tatsächlich auf der Liste der Absender (unter den Beteiligten);
- Die in der Transaktion verwendete Nonce ist korrekt zusammengesetzt.
Für einen solch komplexen Beweis verwenden die Autoren eine Mischung (einer der Autoren war übrigens an seiner Entstehung beteiligt) und , die Sigma-Geschosse genannt werden. Der formale Beweis einer solchen Aussage ist eine ziemlich schwierige Aufgabe und schränkt die Zahl der Personen, die bereit sind, die Technologie zu implementieren, erheblich ein.
Das Ergebnis?
Unserer Meinung nach kann der Teil von Zether, der Datenschutz in kontobasierte Blockchains bringt, jetzt genutzt werden. Derzeit stellt die anonyme Version der Technologie jedoch erhebliche Einschränkungen bei der Nutzung und Komplexität bei der Implementierung dar. Es sollte jedoch nicht außer Acht gelassen werden, dass die Autoren es erst vor ein paar Monaten veröffentlicht haben und vielleicht jemand anderes eine Lösung für die heute bestehenden Probleme finden wird. Denn so wird Wissenschaft betrieben.
Source: habr.com