Von der Idee zur Umsetzung: Modifizieren des bestehenden Schemas der digitalen Signatur auf einer elliptischen Kurve, um es deterministisch zu gestalten, und Bereitstellung von Funktionen zum Erhalt überprüfbarer pseudozufälliger Zahlen auf dieser Grundlage.

Idee

Im Herbst 2018 wurden in der Blockchain Waves die ersten Smart Contracts aktiviert, sofort stellte sich die Frage nach der Möglichkeit, pseudozufällige Zahlen, denen man vertrauen kann.

Nach intensiven Überlegungen kam ich zu dem Schluss: Jede Blockchain ist eine Zelle, einen vertrauenswürdigen Entropiequelle in einem geschlossenen System zu erhalten, ist unmöglich.

Aber eine Idee gefiel mir dennoch: Wenn zufälliges Oracle die Signatur der Benutzerdaten mit einem deterministischen Algorithmus erstellt, kann der Benutzer immer diese Signatur mit dem öffentlichen Schlüssel prüfen und wird sicher sein, dass der erhaltene Wert einzigartig ist. Das Oracle ist bei allem Wunsch nicht in der Lage, etwas zu ändern, der Algorithmus liefert ein eindeutiges Ergebnis. Im Wesentlichen fixiert der Benutzer das Ergebnis, weiß es jedoch nicht, bis das Oracle es veröffentlicht. So kann man dem Oracle grundsätzlich nicht vertrauen, aber das Ergebnis seiner Arbeit prüfen. In diesem Fall kann, wenn die Prüfung erfolgreich ist, eine solche Signatur als Entropiequelle für eine pseudozufällige Zahl gelten.

In der Blockchain-Plattform Waves wird das Signaturschema EdDSA Variante Ed25519. In diesem Schema besteht die Signatur aus den Werten R und S, wobei R von einem zufälligen Wert abhängt und S auf der Basis der zu signierenden Nachricht, des geheimen Schlüssels und der gleichen Zufallszahl wie R berechnet wird. Es ergibt sich, dass es keine eindeutige Abhängigkeit gibt; für dasselbe Benutzermeldung existieren viele gültige Signaturen.

Es ist offensichtlich, dass eine solche Signatur im reinen Zustand nicht als Quelle für pseudozufällige Zahlen verwendet werden kann, da sie nicht deterministisch ist und daher leicht Manipulationen durch das Oracle ausgesetzt sein kann.

Aber wie sich herausstellte, ist es tatsächlich möglich, sie deterministisch zu machen.

Ich hatte große Hoffnungen auf prüfbare Zufallsfunktion (VRF), aber nach dem Studium des Materials musste ich auf diese Variante verzichten. Obwohl VRF eine deterministische Signatur und deren Beweis anbietet, gibt es im Algorithmus einen seltsamen Punkt, der ein schwarzes Loch für Manipulationen durch den Orakel eröffnet. Insbesondere wird bei der Berechnung des Wertes k (Abschnitt 5.1) ein geheimer Schlüssel verwendet, der dem Benutzer unbekannt bleibt. Das bedeutet, der Benutzer kann die Korrektheit der Berechnung von k nicht überprüfen, sodass das Orakel jeden für es notwendigen Wert k verwenden kann und gleichzeitig eine Datenbank von Zuordnungen zwischen k und den zu signierenden Daten führt, um immer in der Lage zu sein, das VRF-konforme Ergebnis erneut zu berechnen. Wenn Sie eine Verlosung auf der Grundlage von VRF ohne Offenlegung des geheimen Schlüssels sehen, können Sie sich darüber auslassen: auf die Notwendigkeit hinweisen, entweder den Schlüssel preiszugeben oder ihn aus der Berechnung von k auszuschließen. Dann würde der geheime Schlüssel automatisch bei der ersten Unterschrift selbst offengelegt. Insgesamt, wie bereits erwähnt, eine seltsame Methode für ein zufälliges Orakel.

Nachdem ich etwas nachgedacht und Unterstützung von lokalen Analysten erhalten hatte, entstand das Konzept der Funktionsweise von VECRO.

VECRO ist ein Akronym für Verifiable Elliptic Curve Random Oracle, was auf Deutsch überprüfbarer Zufallsorakel auf elliptischen Kurven bedeutet.

Es stellte sich als ziemlich einfach heraus. Um Determiniertheit zu erreichen, muss der Wert R vor dem Erscheinen der zu signierenden Nachricht festgelegt werden. Wenn R festgelegt ist und Teil der zu signierenden Nachricht wird, was zusätzlich die Festlegung von R in der zu signierenden Nachricht garantiert, wird der Wert S eindeutig durch die Benutzer-Nachricht bestimmt und kann somit als Quelle für pseudorandomisierte Zahlen verwendet werden.

In einem solchen Schema ist es unwichtig, wie R festgelegt wird; das bleibt in der Verantwortung des Orakels. Wichtig ist, dass S eindeutig durch den Benutzer bestimmt wird, aber dessen Wert unbekannt bleibt, bis das Orakel ihn veröffentlicht. Alles genau so, wie wir es wollten!

Wenn wir über das feste R sprechen, beachten Sie, dass ein wiederverwendetes R Die Unterzeichnung verschiedener Nachrichten entschlüsselt eindeutig den privaten Schlüssel im EdDSA-Schema. Für den Besitzer des Orakels ist es äußerst wichtig, die Möglichkeit der Wiederverwendung von R für die Signierung verschiedener Nachrichten des Benutzers auszuschließen. Das heißt, bei jeglichen Manipulationen oder Absprachen riskierte das Orakel immer den Verlust seines privaten Schlüssels.

Insgesamt muss das Orakel den Benutzern zwei Funktionen bereitstellen: eine Initialisierung, die den Wert von R festhält, und eine Signatur, die den Wert von S zurückgibt. Dabei ist das Paar R, S eine gewöhnliche überprüfbare Signatur der Benutzer-Nachricht, die den festen Wert R und willkürliche Benutzerdaten enthält.

Man könnte einwenden, dass dieses Schema für die Blockchain nichts anderes ist als ein gewöhnliches Commit-Entschlüsselungsschema. Im Grunde genommen, ja, das ist es. Aber es gibt einige Nuancen. Erstens arbeitet das Orakel immer mit demselben Schlüssel in allen Operationen, beispielsweise ist dies praktisch für Verträge. Zweitens besteht das Risiko, dass das Orakel den privaten Schlüssel bei unsachgemäßem Verhalten verliert, z. B. wenn das Orakel erlaubt, Ergebnisse zu überprüfen; dann reichen zwei Überprüfungen aus, um den privaten Schlüssel zu erfahren und vollen Zugriff auf das Wallet zu erhalten. Drittens ist die nativ überprüfbare Signatur in der Blockchain, die die Quelle der Zufälligkeit ist — das ist schön.

Sechs Monate lang reifte die Idee der Umsetzung im Kopf, bis schließlich die Motivation in Form von einem Zuschuss von Waves Labskam. Mit einem großen Zuschuss kommt große Verantwortung, also wird es das Projekt geben!

Implementierung

So wurde in diesem Projekt VECRO implementiert auf der Blockchain von Waves im Anfrage-Antwort-Modus mithilfe von Überweisungs-Transaktionen zwischen Benutzer und Orakel. Dabei wurde im Konto des Orakels ein Skript eingerichtet, das die Arbeit streng gemäß der oben beschriebenen Logik überwacht. Die Transaktionen des Orakels durchlaufen eine Überprüfung, bei der die gesamte Interaktionskette mit dem Benutzer wiederhergestellt wird. An der Überprüfung des Endwertes sind alle vier Transaktionen beteiligt, und der Smart Contract fügt sie an einen strengen Überprüfungsfaden an, der Schritt für Schritt alle Werte prüft und keinen Platz für irgendwelche Manipulationen lässt.

Noch einmal, damit es klar ist. Das Orakel arbeitet nicht nur nach dem vorgeschlagenen Schema. Seine Arbeit wird vollständig auf der Ebene der Blockchain kontrolliert. mit einem Smart Contract fest verbunden. Ein Schritt nach links, und die Transaktion wird einfach nicht verarbeitet. Wenn die Transaktion also in der Blockchain gelandet ist, muss der Benutzer nicht einmal etwas überprüfen, denn das haben bereits Hunderte von Knoten im Netzwerk erledigt.

Aktuell ist im Waves-Hauptnetz ein VECRO gestartet (Sie können Ihr eigenes starten, es ist nicht schwer, schauen Sie einfach in das Beispiel für die Konfiguration ). Der aktuelle Code läuft auf PHP (aufWavesKit , über dasich früher berichtet habe Um den Oracle-Service zu nutzen, muss man:).

R festlegen;

Mindestens 0,005 Waves an den Alias des Orakels init@vecr senden;
- Den R-Code im Feld der Anhänge bei der Übertragung von 1 R-vecr Token vom Orakel an den Benutzer erhalten;
- Die Signatur erhalten;
Mindestens 0,005 Waves an den Alias des Orakels random@vecr senden und unbedingt den zuvor erhaltenen R-Code sowie zusätzliche Benutzerdaten im Feld der Anhänge angeben;
- Den S-Code im Feld der Anhänge bei der Übertragung von 1 S-vecr Token vom Orakel an den Benutzer erhalten;
- Den S-Code als Quelle für eine pseudo-zufällige Zahl verwenden.
Details zur aktuellen Implementierung:

Die an das Orakel gesendeten Waves werden als Gebühr für die Rücküberweisung an den Benutzer verwendet, bis zu maximal 1 Waves;

R-Code ist die Verkettung des Bytes des Zeichens 'R' und des 32-Byte Wertes R in der base58-Kodierung;
Der R-Code im Anhang muss zuerst stehen, die Benutzerdaten folgen nach dem R-Code;
S-Code ist die Verkettung des Bytes des Zeichens 'S' und des 32-Byte Wertes S in der base58-Kodierung;
S ist das Ergebnis der Modulo-Division, daher kann S nicht als vollwertige 256-Bit pseudo-zufällige Zahl verwendet werden (diese Zahl kann als maximal 252-Bit pseudo-zufällige Zahl angesehen werden);
Die einfachste Variante ist, den Hash des S-Codes als pseudo-zufällige Zahl zu verwenden.
Beispiel für den Erhalt des S-Codes:

Initialisierung: