Wir setzen unseren Zyklus über den Aufbau der Monero-Blockchain fort, und der heutige Artikel wird dem RingCT-Protokoll (Ring Confidential Transactions) gewidmet sein, in dem vertrauliche Transaktionen und neue Ring-Signaturen vorgestellt werden. Leider gibt es im Internet nur wenige Informationen darüber, wie es funktioniert, und wir haben versucht, diese Lücke zu schließen.
Wir werden darüber sprechen, wie dieses Protokoll das Netzwerk die Beträge der Überweisungen verbirgt, warum von den klassischen Ring-Signaturen für Cryptonote abgesehen wurde und wie sich diese Technologie weiterentwickeln wird.
Da dieses Protokoll eine der komplexesten Technologien in Monero ist, benötigt der Leser grundlegende Kenntnisse über den Aufbau dieser Blockchain und oberflächliche Kenntnisse in der elliptischen Kryptografie (um dieses Wissen aufzufrischen, kann man die ersten Kapitel unseres vorherigen Artikels über ).
Das RingCT-Protokoll
Eine der möglichen Angriffe auf Cryptonote-Währungen ist die Analyse der Blockchain, die auf dem Wissen über den Betrag und die Zeit der gesendeten Transaktion basiert. Dies ermöglicht es, das Suchfeld der interessierenden Ausgänge erheblich einzugrenzen. Um sich vor einer solchen Analyse zu schützen, wurde im Monero-Protokoll für anonyme Transaktionen eingeführt, das die Beträge der Überweisungen im Netzwerk vollständig verbirgt.
Es ist erwähnenswert, dass die Idee, Beträge zu verbergen, nicht neu ist. Einer der ersten, der sie beschrieb, war der Entwickler von Bitcoin Core Greg Maxwell in seinem . Die aktuelle Umsetzung von RingCT stellt eine Modifikation mit der Möglichkeit der Verwendung von Ring-Signaturen dar (wie könnte es auch ohne sie sein), und erhielt so ihren Namen – Ring Confidential Transactions.
Darüber hinaus hilft das Protokoll, Probleme mit dem Mischen von Dust-Ausgängen – Ausgängen mit kleinen Beträgen (die normalerweise als Rückgeld aus Transaktionen entstehen), die mehr Probleme verursachten, als sie wert waren, loszuwerden.
Im Januar 2017 fand ein Hard Fork des Monero-Netzwerks statt, der die optionale Verwendung von vertraulichen Transaktionen ermöglichte. Bereits im September desselben Jahres wurden mit dem Hard Fork der Version 6 solche Transaktionen die einzigen zulässigen im Netzwerk.
RingCT nutzt mehrere Mechanismen: mehrschichtige verknüpfbare spontane anonyme Gruppensignaturen (Multilayered Linkable Spontaneous Anonymous Group Signature, im Folgenden – MLSAG), das Hinterlegungschema (Pedersen Commitments) und Range-Proofs (für diesen Begriff gibt es keine fest etablierte Übersetzung ins Russische).
Das RingCT-Protokoll führt zwei Arten von anonymen Transaktionen ein: simple und full. Die ersten werden vom Wallet generiert, wenn eine Transaktion mehr als einen Eingang verwendet, die zweiten in umgekehrter Situation. Sie unterscheiden sich in der Validierung der Transaktionssummen und den signierten MLSAG-Daten (mehr dazu unten). Volltransaktionen können jedoch mit einer beliebigen Anzahl von Eingängen generiert werden, es gibt keinen grundlegenden Unterschied. In dem Buch wird dazu gesagt, dass die Entscheidung, full Transaktionen auf einen Eingang zu beschränken, hastig getroffen wurde und sich in Zukunft ändern könnte.
MLSAG-Signatur
Erinnern wir uns, was die signierten Eingänge einer Transaktion darstellen. Jede Transaktion gibt bestimmte Mittel aus und generiert. Die Mittel werden durch die Erstellung von Transaktionsausgängen generiert (eine direkte Analogie sind Banknoten), und der Ausgang, den die Transaktion ausgibt (denn im realen Leben geben wir tatsächlich Banknoten aus), wird zum Eingang (hier ist es sehr leicht, verwirrt zu werden).
Der Eingang verweist auf mehrere Ausgänge, gibt jedoch nur einen aus, wodurch eine „Rauchwand“ geschaffen wird, um die Analyse der Transaktionshistorie zu erschweren. Wenn eine Transaktion mehr als einen Eingang hat, kann diese Struktur als Matrix dargestellt werden, wobei die Zeilen die Eingänge und die Spalten die involvierten Ausgänge sind. Um dem Netzwerk zu beweisen, dass die Transaktion tatsächlich ihre Ausgänge ausgibt (d.h. ihre geheimen Schlüssel kennt), signieren die Eingänge mit einer Ringunterschrift. Diese Unterschrift garantiert, dass der Unterzeichner die geheimen Schlüssel aller Elemente einer der Spalten kannte.
Vertrauliche Transaktionen verwenden nicht mehr die klassischen Ringunterschriften, stattdessen kamen MLSAG – eine für mehrere Eingänge angepasste Version ähnlicher einlagiger Ringunterschriften, .
Sie werden als mehrschichtig bezeichnet, weil sie mehrere Eingänge signieren, von denen jeder mit mehreren anderen verwoben ist, d.h. es wird eine Matrix und nicht nur eine Reihe signiert. Wie wir später sehen werden, hilft das, die Größe der Unterschrift zu reduzieren.
Lassen Sie uns betrachten, wie eine Ringunterschrift gebildet wird, anhand einer Transaktion, die 2 reale Ausgänge ausgibt und m – 1 zufällige aus der Blockchain zum Mischen verwendet. Bezeichnen wir die öffentlichen Schlüssel der Ausgänge, die wir ausgeben, als
, und die Schlüsselbilder für sie entsprechend: 
Daher erhalten wir eine Matrix mit der Größe 2 x m. Zunächst müssen wir die sogenannten Challenges für jedes Ausgangspaar berechnen:
Die Berechnungen beginnen mit den Ausgängen, die wir verwenden, indem wir ihre öffentlichen Schlüssel nutzen:
und Zufallszahlen
Am Ende erhalten wir die Werte:
, die wir zur Berechnung der Challenge
des nächsten Ausgangspaares verwenden (um es einfacher zu verstehen, haben wir diese Werte in verschiedenen Farben hervorgehoben). Alle folgenden Werte werden kreisförmig nach den in der ersten Abbildung angegebenen Formeln berechnet. zuletzt wird die Challenge für das Paar der tatsächlichen Ausgänge berechnet.
Wie wir sehen, werden in allen Spalten, außer der, die die realen Ausgänge enthält, zufällig generierte Zahlen verwendet.
. Für πDer Spalte werden sie auch benötigt. Wir transformieren
in s:
Die Signatur selbst ist ein Tuple aller dieser Werte:
Anschließend werden diese Daten in die Transaktion aufgenommen.
Wie wir sehen, enthält MLSAG nur eine Challenge c0, was den Platzbedarf der Signatur reduziert (die ohnehin viel Platz benötigen). Dann stellt jeder Prüfer unter Verwendung der Daten
, die Werte c1,…, cm wieder her und prüft, dass
. So hat sich unser Ring geschlossen und die Signatur wurde verifiziert.
Für RingCT-Transaktionen vom Typ full wird eine weitere Zeile zur Matrix mit den verschachtelten Ausgängen hinzugefügt, aber darüber werden wir später sprechen.
Pedersen Commitments
(häufig wird der englische Begriff — commitments — verwendet) werden verwendet, damit eine Partei beweisen kann, dass sie ein bestimmtes Geheimnis (eine Zahl) kennt, ohne es tatsächlich preiszugeben. Zum Beispiel würfeln Sie eine Zahl, berechnen Sie das Commitment und geben Sie es der prüfenden Partei. So kann der Prüfer bei der Offenlegung der geheimen Zahl das Commitment selbst berechnen und somit sicherstellen, dass Sie ihn nicht getäuscht haben.
In Monero werden Commitments verwendet, um die Beträge der Überweisungen zu verbergen, und verwenden die am weitesten verbreitete Variante — Pedersen Commitments. Übrigens, eine interessante Tatsache — zunächst schlugen die Entwickler vor, die Beträge durch einfaches Mischen zu verbergen, also Ausgänge mit zufälligen Beträgen hinzuzufügen, um Ungewissheit zu schaffen, wechselten aber dann zu Commitments (ohne dass es necessarily zu einer Einsparung bei der Transaktionsgröße führte, wie wir später sehen werden).
Im Allgemeinen sieht ein Commitment wie folgt aus:
Wo C — der Wert des Commitments selbst, a — der verborgene Betrag, H — ein fester Punkt auf einer elliptischen Kurve (zusätzlicher Generator), und x — eine beliebige Maske, ein versteckter Faktor, der zufällig generiert wird. Die Maske ist notwendig, damit eine dritte Partei durch einfaches Ausprobieren den Wert des commitments nicht ermitteln kann.
Bei der Generierung eines neuen Outputs berechnet die Wallet das commitment dafür und nimmt beim Ausgeben entweder den bei der Generierung berechneten Wert oder recalculiert ihn neu — je nach Art der Transaktion.
RingCT einfach
Im Fall von einfachen RingCT-Transaktionen muss sichergestellt werden, dass die Transaktion Ausgaben in Höhe der Summe der Eingaben erzeugt (nicht Geld aus der Luft geschaffen hat), sodass die Summe der commitments der ersten und zweiten gleich sein muss, das heißt:
Die Berechnung des Commitments der Gebühren erfolgt etwas anders — ohne Maske:
Dieser Ansatz ermöglicht es, der prüfenden Partei nachzuweisen, dass wir die gleichen Beträge verwenden, ohne sie preiszugeben.
Um alles klarer zu machen, betrachten wir ein Beispiel. Angenommen, eine Transaktion verwendet zwei Ausgaben (also werden diese zu Eingaben) in Höhe von 10 und 5 XMR und generiert drei Ausgaben in Höhe von insgesamt 12 XMR: 3, 4 und 5 XMR. Gleichzeitig bezahlt es eine Gebühr von 3 XMR. Somit entsprechen die ausgegebenen Gelder plus die generierten und die Gebühr insgesamt 15 XMR. Lassen Sie uns die commitments berechnen und die Differenz ihrer Summen betrachten (erinnern wir uns an die Mathematik):
Hier sehen wir, dass wir, damit die Gleichung aufgeht — die Summen der Masken der Eingaben und Ausgaben gleich sein müssen. Dafür generiert die Wallet zufällig x1, y1, y2 und y3, während der verbleibende x2 so berechnet wird:
Mit diesen Masken können wir jedem Prüfer nachweisen, dass wir nicht mehr Mittel generieren, als wir ausgeben, ohne die Beträge preiszugeben. Originell, nicht wahr?
RingCT voll
Bei Voll-RingCT-Transaktionen erfolgt die Überprüfung der Beträge etwas komplizierter. In diesen Transaktionen recalculiert die Wallet die commitments der Eingaben nicht, sondern verwendet die während ihrer Generierung berechneten. Dabei muss man annehmen, dass die Differenz zwischen den Summen nicht mehr gleich null ist, sondern stattdessen:
Hier z — die Differenz der Masken der Eingaben und Ausgaben. Wenn man zG als öffentlichen Schlüssel betrachtet (was er de facto auch ist), dann z — das ist der private Schlüssel. So wissen wir, welcher öffentliche Schlüssel und der dazugehörige private Schlüssel existieren. Mit diesen Informationen können wir sie in der MLSAG-Ringsignatur zusammen mit den öffentlichen Schlüsseln der vermischten Ausgänge verwenden:
Eine gültige Ringsignatur wird also garantieren, dass wir alle privaten Schlüssel einer der Spalten kennen, und den privaten Schlüssel in der letzten Zeile können wir nur dann kennen, wenn die Transaktion nicht mehr Mittel generiert, als sie ausgibt. Übrigens ist hier die Antwort auf die Frage „Warum führt die Differenz der Summen der commitments nicht zu null“ — wenn zG = 0, dann werden wir die Spalte mit den tatsächlichen Ausgängen offenlegen.
Wie erfährt der Empfänger von Mitteln, wie viel Geld ihm gesendet wurde? Hier ist alles einfach — der Absender der Transaktion und der Empfänger tauschen Schlüssel über das Diffie-Hellman-Protokoll aus, verwenden den Transaktionsschlüssel und den View-Schlüssel des Empfängers und berechnen einen gemeinsamen geheimen Schlüssel. Der Absender notiert in speziellen Feldern der Transaktion die Daten über die Summen der Ausgänge, verschlüsselt mit diesem gemeinsamen Schlüssel.
Range proofs
Was passiert, wenn wir eine negative Zahl als Summe in den commitments verwenden? Dies könnte zur Generierung zusätzlicher Münzen führen! Ein solcher Ausgang ist nicht zulässig, daher ist eine Garantie notwendig, dass die von uns verwendeten Summen nicht negativ sind (ohne diese Summen preiszugeben, versteht sich, sonst wäre all die Mühe umsonst). Mit anderen Worten, wir müssen beweisen, dass die Summe im Intervall [0, 2n — 1].
liegt. Dazu wird die Summe jedes Ausgangs in Binärstellen zerlegt und für jede Stelle ein commitment separat berechnet. Wie dies geschieht, sehen wir am besten an einem Beispiel.
Nehmen wir an, die Summen sind klein und passen in 4 Bits (in der Praxis sind es 64 Bits), und wir erstellen einen Ausgang über einen Betrag von 5 XMR. Wir berechnen die commitments für jede Stelle und das Gesamtergebnis für den gesamten Betrag:
Dann wird jedes commitment mit einem Surrogat gemischt (Ci-2iH) und paarweise mit einer Borromean-Ringsignatur (eine andere Ringsignatur), die 2015 von Greg Maxwell vorgeschlagen wurde, signiert (mehr darüber kann man lesen ):
Das alles wird als Range Proof bezeichnet und ermöglicht es, zu garantieren, dass in den commitments Summen im Intervall verwendet werden. [0, 2n — 1].
Was folgt jetzt?
In der aktuellen Implementierung nehmen Range-Proofs sehr viel Platz ein – 6176 Byte pro Ausgabe. Das führt zu großen Transaktionen und entsprechend höheren Gebühren. Um die Größe der Transaktionen in Monero zu reduzieren, führen die Entwickler anstelle von Schnorr-Signaturen Bulletproofs ein – einen Mechanismus für Range-Proofs ohne bitweise Commitments. , sind sie in der Lage, die Größe von Range-Proofs um bis zu 94% zu reduzieren. Übrigens hat die Technologie Mitte Juli ein von Kudelski Security überstanden, welches keine wesentlichen Mängel in der Technologie und deren Implementierung aufgedeckt hat. Die Technologie wird bereits im Testnetz eingesetzt und könnte mit dem neuen Hardfork wahrscheinlich auch ins Hauptnetz übertragen werden.
Stellen Sie uns Ihre Fragen, schlagen Sie Themen für neue Artikel über Technologien im Bereich der Kryptowährungen vor und abonnieren Sie unsere Gruppe in , um über unsere Veranstaltungen und Veröffentlichungen auf dem Laufenden zu bleiben.
Quelle: habr.com
