Von der Idee bis zur Umsetzung: Wir modifizieren das bestehende digitale Signaturschema mit elliptischen Kurven, sodass es deterministisch ist, und stellen darauf basierend Funktionen zum Erhalten von Pseudozufallszahlen bereit, die innerhalb der Blockchain überprüfbar sind.
Idee
Im Herbst 2018 wurde die Waves-Blockchain aufgenommen , stellte sich sofort die Frage nach der Möglichkeit des Erhalts dem du vertrauen kannst.
Als ich über diese Frage rätselte, kam ich schließlich zu dem Schluss: Jede Blockchain ist eine Zelle; es ist unmöglich, in einem geschlossenen System eine vertrauenswürdige Entropiequelle zu erhalten.
Aber eine Idee gefiel mir trotzdem: wenn signiert Benutzerdaten mit einem deterministischen Algorithmus, dann kann der Benutzer eine solche Signatur jederzeit mithilfe des öffentlichen Schlüssels überprüfen und ist sicher, dass der resultierende Wert eindeutig ist. Das Orakel kann, so sehr es es auch will, nichts ändern; der Algorithmus liefert ein eindeutiges Ergebnis. Im Wesentlichen zeichnet der Benutzer das Ergebnis auf, erfährt es jedoch erst, wenn das Orakel es veröffentlicht. Es stellt sich heraus, dass man dem Orakel überhaupt nicht vertrauen kann, sondern das Ergebnis seiner Arbeit überprüfen kann. Dann kann eine solche Signatur bei erfolgreicher Verifizierung als Entropiequelle für eine Pseudozufallszahl betrachtet werden.
Die Waves-Blockchain-Plattform verwendet ein Signaturschema вариант . In diesem Schema besteht die Signatur aus den Werten R und S, wobei R von einem Zufallswert abhängt und S auf der Grundlage der zu signierenden Nachricht, des privaten Schlüssels und derselben Zufallszahl wie R berechnet wird Es gibt keine eindeutige Abhängigkeit für dieselbe. Es gibt viele gültige Signaturen für eine Benutzernachricht.
Offensichtlich kann eine solche Signatur in ihrer reinen Form nicht als Quelle für Pseudozufallszahlen verwendet werden, da sie nicht deterministisch ist und daher vom Orakel leicht manipuliert werden kann.
Aber wie sich herausstellte, ist es tatsächlich möglich, es deterministisch zu machen.
Ich hatte große Hoffnungen , aber nachdem ich die Hardware studiert hatte, musste ich diese Option aufgeben. Obwohl VRF eine deterministische Version der Signatur und ihres Beweises bietet, gibt es eine seltsame Stelle im Algorithmus, die ein schwarzes Loch für die Manipulation des Orakels öffnet. Nämlich bei der Berechnung des Wertes von k () wird ein privater Schlüssel verwendet, der dem Benutzer unbekannt bleibt, was bedeutet, dass der Benutzer die Richtigkeit der Berechnung von k nicht überprüfen kann, was bedeutet, dass das Orakel jeden benötigten Wert von k verwenden und gleichzeitig eine Datenbank mit Korrespondenzen verwalten kann von k und den vorzeichenbehafteten Daten, um immer das korrekte Ergebnis aus Sicht von VRF neu berechnen zu können. Wenn Sie eine auf VRF basierende Zeichnung ohne Offenlegung des privaten Schlüssels sehen, können Sie schlau sein: Geben Sie die Notwendigkeit an, entweder den Schlüssel offenzulegen oder ihn von der Berechnung von k auszuschließen, dann wird der private Schlüssel automatisch angezeigt, wenn die erste Signatur erscheint . Im Allgemeinen, wie bereits erwähnt, ein seltsames Schema für ein zufälliges Orakel.
Nach kurzer Überlegung und der Unterstützung lokaler Analysten wurde das VECRO-Arbeitsprogramm geboren.
VECRO ist eine Abkürzung für „Verifiable Elliptic Curve Random Oracle“, was auf Russisch „überprüfbares Zufallsorakel auf elliptischen Kurven“ bedeutet.
Es stellte sich heraus, dass alles ganz einfach war: Um Determinismus zu erreichen, müssen Sie den Wert von R festlegen, bevor die zu signierende Nachricht erscheint. Wenn R festgeschrieben ist und Teil der zu signierenden Nachricht ist, was außerdem sicherstellt, dass R in der zu signierenden Nachricht festgeschrieben ist, wird der Wert von S eindeutig durch die Nachricht des Benutzers bestimmt und kann daher als Quelle für Pseudozufallszahlen verwendet werden.
In einem solchen Schema spielt es keine Rolle, wie R festgelegt wird; dies liegt in der Verantwortung des Orakels. Es ist wichtig, dass S vom Benutzer eindeutig bestimmt wird, sein Wert jedoch unbekannt ist, bis das Orakel ihn veröffentlicht. Alles was wir wollten!
Apropos festes R: Beachten Sie das Beim Signieren verschiedener Nachrichten wird der private Schlüssel im EdDSA-Schema eindeutig angezeigt. Für den Eigentümer des Oracle wird es äußerst wichtig, die Möglichkeit der Wiederverwendung von R zum Signieren verschiedener Benutzernachrichten auszuschließen. Das heißt, dass das Orakel bei jeder Manipulation oder Absprache immer das Risiko eingeht, seinen privaten Schlüssel zu verlieren.
Insgesamt muss das Orakel den Benutzern zwei Funktionen zur Verfügung stellen: Initialisierung, die den Wert R festlegt, und Signatur, die den Wert S zurückgibt. In diesem Fall ist das Paar R, S die übliche überprüfbare Signatur einer Benutzernachricht, die einen festen Wert enthält Wert R und beliebige Benutzerdaten.
Man kann argumentieren, dass dieses Schema für die Blockchain nichts weiter als gewöhnlich ist . Im Wesentlichen ja, sie ist es. Aber es gibt mehrere Nuancen. Erstens arbeitet das Orakel bei allen Vorgängen immer mit demselben Schlüssel, was beispielsweise in Verträgen praktisch ist. Zweitens besteht die Gefahr, dass das Orakel den privaten Schlüssel verliert, wenn es sich falsch verhält. Wenn das Orakel beispielsweise erlaubt, Proben des Ergebnisses zu erstellen, dann reicht es aus, nur zwei Tests durchzuführen, um den privaten Schlüssel herauszufinden und den vollen Gewinn zu erzielen Zugriff auf die Brieftasche. Drittens ist eine Signatur, die in der Blockchain nativ überprüfbar ist und eine Quelle der Zufälligkeit darstellt, wunderschön.
Sechs Monate lang schwelte die Idee der Umsetzung in meinem Kopf, bis schließlich die Motivation in der Form auftauchte . Mit einem großen Zuschuss geht eine große Verantwortung einher, also wird das Projekt da sein!
Implementierung
Also, in diesem Projekt auf der Waves-Blockchain im Request-Response-Modus unter Verwendung von Übertragungstransaktionen zwischen dem Benutzer und dem Orakel. Gleichzeitig wird auf dem Oracle-Konto ein Skript installiert, das die Arbeit streng nach der oben beschriebenen Logik steuert. Oracle-Transaktionen werden überprüft und die gesamte Kette der Benutzerinteraktion wird wiederhergestellt. Alle vier Transaktionen sind an der Überprüfung des Endwerts beteiligt; der Smart Contract reiht sie mit einem strengen Überprüfungsthread aneinander, prüft alle Werte Schritt für Schritt und lässt keinen Spielraum für Manipulationen.
Noch einmal, um es beiseite zu legen und es klarer zu machen. Das Orakel funktioniert nicht einfach nach dem vorgeschlagenen Schema. Seine Arbeit wird auf der Blockchain-Ebene vollständig von den etablierten Akteuren kontrolliert . Wenn Sie nach links gehen, wird die Transaktion einfach nicht durchgeführt. Wenn also eine Transaktion in der Blockchain enthalten ist, muss der Benutzer nicht einmal etwas überprüfen; Hunderte von Netzwerkknoten haben bereits alles für ihn überprüft.
Derzeit läuft ein VECRO im Waves-Mainnet (Sie können Ihr eigenes betreiben, es ist einfach nicht schwierig ). Der aktuelle Code läuft in PHP (on , worüber ).
Um den Oracle-Dienst nutzen zu können, müssen Sie:
- Fix R;
- Senden Sie mindestens 0.005 Wellen an Oracle alias init@vecr;
- Erhalten Sie den R-Code im Anhangsfeld bei der Übertragung von 1 R-vecr-Token vom Orakel an den Benutzer;
- Holen Sie sich eine Unterschrift;
- Senden Sie mindestens 0.005 Waves an den Oracle-Alias random@vecr und MÜSSEN außerdem den zuvor empfangenen R-Code und zusätzliche Benutzerdaten im Anhangsfeld angeben.
- Erhalten Sie den S-Code im Anhangsfeld bei der Übertragung von 1 S-vecr-Token vom Oracle an den Benutzer;
- Verwenden Sie S-Code als Quelle für Pseudozufallszahlen.
Nuancen der aktuellen Implementierung:
- An das Orakel gesendete Wellen werden als Provision für die Rücktransaktion an den Benutzer verwendet, bis zu einem Maximum von 1 Welle;
- R-Code ist die Verkettung eines Bytes des „R“-Zeichens und eines 32-Byte-Base58-codierten R-Werts;
- R-Code im Anhang sollte zuerst sein, Benutzerdaten kommen nach R-Code;
- S-Code ist die Verkettung eines Bytes des Zeichens „S“ und eines 32-Byte-Base58-codierten Werts von S;
- S ist das Ergebnis der Modulo-Division, daher können Sie S nicht als vollständige 256-Bit-Pseudozufallszahl verwenden (diese Zahl kann maximal als 252-Bit-Pseudozufallszahl betrachtet werden);
- Die einfachste Möglichkeit besteht darin, den S-Code-Hash als Pseudozufallszahl zu verwenden.
Beispiel für den Empfang von S-Code:
- Initialisierung:
- R-Code abrufen:
- Abfrage des Ergebnisses der R-Code-Signatur und der Benutzerdaten „zufällig“:
- S-Code empfangen:
Aus technischer Sicht ist das Orakel komplett betriebsbereit, Sie können es bedenkenlos nutzen. Aus Sicht der Nutzung durch den Durchschnittsnutzer mangelt es an einer komfortablen grafischen Oberfläche, das wird noch warten müssen.
Gerne beantworte ich Fragen und nehme Kommentare entgegen, vielen Dank.
Source: habr.com