Von der Idee zur Umsetzung: Wir passen das bestehende Schema der digitalen Signatur auf elliptischen Kurven an, um es deterministisch zu gestalten, und bieten auf dieser Basis Funktionen zur Erzeugung von prüfbaren blockchain-basierten Pseudo-Zufallszahlen an.
Die Idee
Im Herbst 2018 wurden im Waves-Blockchain , worauf sofort die Frage aufkam, ob es möglich sei, zu erhalten, denen man vertrauen kann.
Nach intensiven Überlegungen kam ich schließlich zu dem Schluss: Jede Blockchain ist ein geschlossenes System; es ist unmöglich, eine vertrauenswürdige Quelle für Entropie in einem abgeschlossenen System zu erhalten.
Aber eine Idee hat mir dennoch gefallen: Wenn Wenn die Benutzerdaten mit einem deterministischen Algorithmus signiert werden, kann der Benutzer stets diese Signatur mit dem öffentlichen Schlüssel überprüfen und ist sich sicher, dass der erhaltene Wert einzigartig ist. Ein Oracle ist nicht in der Lage, etwas zu ändern, denn der Algorithmus liefert ein eindeutiges Ergebnis. Im Grunde fixiert der Benutzer das Ergebnis, kennt es jedoch nicht, bis das Oracle es veröffentlicht. Es ist also möglich, dem Oracle nicht zu vertrauen, aber das Ergebnis seiner Arbeit zu überprüfen. In diesem Fall kann eine solche Signatur als Quelle von Entropie für eine pseudorandomisierte Zahl angesehen werden.
Auf der Blockchain-Plattform Waves wird ein Signaturschema verwendet Variante ist gut gelungen. . In diesem Schema besteht die Signatur aus den Werten R und S, wobei R von einem zufälligen Wert abhängt, und S auf Basis der zu signierenden Nachricht, des privaten Schlüssels und desselben Zufallswerts berechnet wird, der auch für R verwendet wird. Das bedeutet, dass es keine eindeutige Abhängigkeit gibt; für die gleiche Benutzer-Nachricht existieren viele gültige Signaturen.
Offensichtlich kann eine solche Signatur in reiner Form nicht als Quelle für pseudorandomisierte Zahlen verwendet werden, da sie unbestimmt ist und daher leicht von einem Oracle manipuliert werden kann.
Aber wie sich herausstellte, ist es tatsächlich möglich, sie deterministisch zu machen.
Ich hatte große Hoffnungen auf , aber nach dem Studium der Materie musste ich von dieser Variante Abstand nehmen. Obwohl die VRF eine deterministische Option für die Signatur und deren Beweis bietet, gibt es im Algorithmus einen merkwürdigen Punkt, der ein Schlupfloch für Manipulationen durch das Oracle öffnet. Genauer gesagt, bei der Berechnung des Wertes k () wird ein geheimer Schlüssel verwendet, der dem Benutzer unbekannt bleibt. Das bedeutet, dass der Benutzer die Richtigkeit der Berechnung von k nicht überprüfen kann. Daher kann der Oracle einen beliebigen Wert für k verwenden und gleichzeitig eine Datenbank mit den Entsprechungen von k und den signierten Daten führen, um immer das korrekte Ergebnis aus der Sicht des VRF neu berechnen zu können. Wenn Sie eine VRF-basierte Auslosung ohne Offenlegung des geheimen Schlüssels sehen, können Sie klug anmerken: Sie müssten entweder den Schlüssel offenlegen oder ihn aus der Berechnung von k ausschließen, sodass der geheime Schlüssel automatisch bei der ersten Signatur offengelegt wird. Insgesamt, wie bereits erwähnt, ist dies ein seltsames Schema für einen zufälligen Oracle.
Nach einigem Nachdenken und mit Unterstützung lokaler Analysten wurde das VECRO-Arbeitsmodell entwickelt.
VECRO steht für Verifiable Elliptic Curve Random Oracle, was auf Deutsch überprüfbarer zufälliger Oracle auf elliptischen Kurven bedeutet.
Es stellte sich als recht einfach heraus; um Determiniertheit zu erreichen, muss der Wert R vor dem Erscheinen der signierten Nachricht fixiert werden. Wenn R fixiert ist und Teil der signierten Nachricht wird, was zusätzlich R in der selbst signierten Nachricht garantiert, wird der Wert S eindeutig durch die Benutzer-Nachricht bestimmt und kann daher als Quelle für pseudorandomisierte Zahlen verwendet werden.
In einem solchen Schema ist es egal, wie R fixiert wird, das bleibt in der Verantwortung des Orakels. Wichtig ist, dass S eindeutig vom Benutzer definiert wird, aber sein Wert unbekannt bleibt, bis das Orakel ihn veröffentlicht. Genau wie wir es wollten!
Wenn wir von fixiertem R sprechen, beachten Sie, dass bei der Signierung verschiedener Nachrichten eindeutig den privaten Schlüssel im EdDSA-Schema offenbart. Für den Eigentümer des Orakels ist es von größter Bedeutung, die Möglichkeit der Wiederverwendung von R zur Signierung verschiedener Benutzer-Nachrichten auszuschließen. Das heißt, bei allen Manipulationen oder Verschwörungen wird das Orakel immer das Risiko eingehen, seinen privaten Schlüssel zu verlieren.
Insgesamt sollte der Oracle den Nutzern zwei Funktionen bereitstellen: eine Initialisierung, die den Wert R festlegt, und eine Signatur, die den Wert S zurückgibt. Dabei ist das Paar R, S eine standardmäßige überprüfbare Signatur der Nutzer-Nachricht, die einen festgelegten Wert R und beliebige Nutzerdaten enthält.
Es könnte argumentiert werden, dass dieses Schema für die Blockchain nichts anderes ist als ein gewöhnliches . Im Wesentlichen ist das korrekt, aber es gibt einige Nuancen. Erstens arbeitet der Oracle bei allen Operationen immer mit demselben Schlüssel, was beispielsweise in Verträgen praktisch ist. Zweitens besteht das Risiko, dass der Oracle seinen privaten Schlüssel bei fehlerhaftem Verhalten verliert, beispielsweise wenn der Oracle die Resultate testet; in diesem Fall reichen zwei Proben aus, um den privaten Schlüssel zu ermitteln und vollen Zugriff auf das Wallet zu erhalten. Drittens ist die nativ überprüfbare Signatur in der Blockchain, die als Quelle der Zufälligkeit dient – das ist eine elegante Lösung.
Sechs Monate lang reifte die Idee zur Umsetzung in meinem Kopf, bis schließlich die Motivation in Form eines . Mit einem großen Zuschuss kommt große Verantwortung, was bedeutet, dass das Projekt realisiert werden muss!
Implementierung
In diesem Projekt auf der Waves-Blockchain im Anfrage-Antwort-Modus durch Transfertransaktionen zwischen dem Benutzer und dem Oracle implementiert. Dabei ist auf dem Oracle-Konto ein Skript eingerichtet, das die Funktionalität strikt gemäß der oben beschriebenen Logik überwacht. Die Transaktionen des Oracles werden überprüft, indem die gesamte Interaktionskette mit dem Benutzer wiederhergestellt wird. Bei der Überprüfung des Endwerts spielen alle vier Transaktionen eine Rolle; der Smart Contract reiht sie auf eine strenge Prüfungsleine und überprüft Schritt für Schritt alle Werte, ohne Spielraum für Manipulationen zu lassen.
Noch einmal, damit es klarer ist. Das Oracle arbeitet nicht nur nach dem vorgeschlagenen Schema. Seine Funktionalität wird vollständig auf Blockchain-Ebene durch den implementierten . Ein Schritt zur Seite und die Transaktion wird einfach nicht genehmigt. Wenn also eine Transaktion in die Blockchain gelangt, braucht der Benutzer nichts mehr zu prüfen, denn alles wurde bereits von hunderten Knoten im Netzwerk überprüft.
Aktuell ist ein VECRO im Hauptnetz von Waves aktiv (Sie können Ihren eigenen starten, es ist ganz einfach, schauen Sie einfach ). Der aktuelle Code basiert auf PHP (auf , über das ).
Um den Oracle-Service zu nutzen, müssen Sie:
- R sichern;
- Mindestens 0,005 Waves an den Alias des Orakels init@vecr senden;
- Den R-Code im Attachments-Feld 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 Attachments-Feld angeben;
- Den S-Code im Attachments-Feld der Übertragung von 1 S-vecr-Token vom Orakel an den Benutzer erhalten;
- Den S-Code als Quelle für eine pseudozufällige Zahl verwenden.
Details zur aktuellen Implementierung:
- Die an das Orakel gesendeten Waves dienen als Gebühr für die Rücküberweisung an den Benutzer, mit einem Maximum von 1 Waves;
- Der R-Code ist eine Verkettung des Bytes des Zeichens 'R' und des 32-Byte R-Wertes in Base58-Codierung;
- Der R-Code im Anhang muss zuerst stehen, die Benutzerdaten folgen nach dem R-Code.
- S-Code ist die Verkettung eines Bytes des Zeichens 'S' und eines 32-Byte-Wertes S in der Base58-Codierung;
- S ist das Ergebnis einer modulo-Operation, daher kann S nicht als vollständige 256-Bit Pseudorandomzahl verwendet werden (diese Zahl kann maximal als 252-Bit Pseudorandomzahl betrachtet werden);
- Die einfachste Möglichkeit besteht darin, den Hash von S-Code als Pseudorandomzahl zu verwenden.
Beispiel zur Erzeugung von S-Code:
- Initialisierung:
- Erhalt von R-Code:
- Abfrage des Signaturresultats von R-Code und Benutzerdaten 'random':
- Erhalt von S-Code:
Aus technischer Sicht ist das Oracle vollständig betriebsbereit, Sie können es bedenkenlos verwenden. Aus Sicht der allgemeinen Benutzer fehlt jedoch eine benutzerfreundliche grafische Benutzeroberfläche, auf die wir warten müssen.
Ich freue mich, Fragen zu beantworten und Anregungen entgegenzunehmen, danke.
Quelle: habr.com
