Von der Idee zur Implementierung: Ändern des vorhandenen Signaturschemas für elliptische Kurven, um deterministisch zu sein, und Bereitstellen von Funktionen, um innerhalb der Blockchain-Pseudozufallszahlen überprüfbare Werte zu erhalten.
Idee
Im Herbst 2018, als die ersten intelligenten Verträge in der Waves-Blockchain aktiviert wurden , tauchte natürlich das Thema auf, vertrauenswürdige Pseudozufallszahlen zu erhalten .
Als ich darüber nachdachte, kam ich zu dem Schluss, dass jede Blockchain eine Art Käfig ist und es unmöglich ist, eine vertrauenswürdige Entropiequelle in einem geschlossenen System zu erhalten.
Eine Idee hat mir jedoch gefallen. Wenn ein zufälliges Orakel Benutzerdaten mit einem deterministischen Algorithmus signiert, kann der Benutzer eine solche Signatur immer mit dem öffentlichen Schlüssel überprüfen, um sicherzustellen, dass der erhaltene Wert eindeutig ist. Das Orakel könnte keine Änderungen vornehmen, da der Algorithmus ein einwertiges Ergebnis liefert. Grundsätzlich korrigiert der Benutzer das Ergebnis, weiß es aber erst, wenn es vom Orakel veröffentlicht wird. Sie können dem Orakel also möglicherweise überhaupt nicht vertrauen, aber dennoch das Ergebnis seiner Operation überprüfen. Im Falle einer erfolgreichen Verifizierung kann eine solche Signatur eine Entropiequelle für eine Pseudozufallszahl sein.
In der Waves-Blockchain wird das Signaturschema EdDSA- Variante Ed25519 verwendet. In diesem Schema besteht die Signatur aus den Werten R und S. R ist abhängig von einem Zufallswert und S wird auf der Grundlage einer signierten Nachricht, eines privaten Schlüssels und derselben Zufallszahl wie R berechnet. Es gibt keine eindeutige Abhängigkeit. Für dieselbe Benutzernachricht sind mehrere gültige Signaturen vorhanden.
Anscheinend kann diese Art der Signatur allein nicht als Quelle für Pseudozufallszahlen verwendet werden, da sie unbestimmt ist und daher vom Orakel leicht manipuliert werden kann.
Es stellt sich jedoch heraus, dass es tatsächlich möglich ist, es deterministisch zu machen.
Meine großen Hoffnungen wurden auf die überprüfbare Zufallsfunktion (VRF) gesetzt , aber nachdem ich ihre Besonderheiten studiert habe, muss ich diese Option ablehnen. Obwohl VRF eine bestimmte Version einer Signatur und ihrer Beweise anbietet, hat der Algorithmus eine seltsame Stelle, die ein Schwarzes Loch für Manipulationen durch das Orakel öffnet (diese Aussage ist falsch, siehe Update ). Insbesondere wird zur Berechnung des Werts von k ( Abschnitt 5.1 ) ein privater Schlüssel verwendet, der dem Benutzer unbekannt bleibt, sodass der Benutzer die Richtigkeit der Berechnung von k nicht überprüfen kann. Infolgedessen kann das Orakel einen beliebigen Wert von k verwenden und gleichzeitig eine Datenbank für Korrelationen zwischen k und signierten Daten ausführen, um immer ein korrektes Ergebnis für VRF neu berechnen zu können. Wenn Sie eine VRF-basierte Verlosung sehen, ohne den privaten Schlüssel preiszugeben, können Sie angeben und darauf hinweisen, dass der Schlüssel entweder offengelegt oder aus der Berechnung von k entfernt werden muss, damit er sich nach der ersten Signatur automatisch zeigt. Insgesamt ist dies, wie oben erwähnt, ein seltsames Schema für das zufällige Orakel.
Nach einigen Überlegungen und mit Unterstützung lokaler Analysten wurde ein Schema für den VECRO-Betrieb entwickelt.
VECRO steht für Verifying Elliptic Curve Random Oracle. Es stellte sich als ziemlich einfach heraus. Um die Bestimmtheit zu erreichen, müssen wir den Wert von R vor dem Erscheinen einer zu signierenden Nachricht festlegen. Wenn R fest ist und R Teil der Nachricht ist, was zusätzlich garantiert, dass R vor der Nachricht festgelegt ist. Der Wert von S wird vollständig durch eine Benutzernachricht bestimmt und kann daher als Quelle für Pseudozufallszahlen verwendet werden.
In einem solchen Schema ist es irrelevant, wie genau R festgelegt ist, und bleibt in der Verantwortungszone des Orakels. Wichtig ist, dass S vollständig vom Benutzer bestimmt wird, sein Wert jedoch erst nach Veröffentlichung durch das Orakel bekannt gegeben wird. Genau das wollten wir!
Beachten Sie, dass bei der Wiederverwendung von R zum Signieren verschiedener Nachrichten der private Schlüssel im EdDSA-Schema vollständig angezeigt wird. Für den Besitzer des Orakels ist es wichtig, die Wiederverwendung von R zum Signieren verschiedener Benutzernachrichten auszuschließen. Das heißt, bei Manipulationen oder Absprachen riskiert das Orakel immer, seinen privaten Schlüssel zu verlieren.
Das Orakel bietet dem Benutzer also zwei Funktionen: die Initialisierung, die den Wert von R festlegt, und eine Signatur, die den Wert von S zurückgibt. In der Zwischenzeit ist das R, S-Paar eine regelmäßig überprüfbare Signatur für eine Benutzernachricht, die eine feste Nachricht enthält Wert von R und die zufälligen Daten des Benutzers.
Man kann argumentieren, dass dies für Blockchain nichts anderes als ein reguläres Commit-Enthüllungsschema ist . Im Grunde ist es das, was es ist. Aber es gibt ein paar Nuancen. Erstens verwendet das Orakel bei allen Transaktionen denselben Schlüssel, was beispielsweise für Verträge praktisch ist. Zweitens besteht die Gefahr, dass das Orakel aufgrund falscher Leistung einen privaten Schlüssel verliert. Wenn das Orakel beispielsweise das Testen des Ergebnisses erleichtert, reichen nur zwei Tests aus, um den privaten Schlüssel herauszufinden und Zugriff auf die Brieftasche zu erhalten. Drittens ist eine nativ verifizierte Signatur in der Blockchain, die die Quelle der Zufälligkeit ist, einfach wunderschön.
Etwa sechs Monate lang keimte diese Idee, bis eine Motivation zur Umsetzung in Form eines Zuschusses von Waves Labs eintraf. Mit dem großen Stipendium geht eine große Verantwortung einher, es bedeutet, dass das Projekt sein muss!
Implementierung
VECRO wurde in der Waves-Blockchain im Anforderungs- / Antwortmodus mithilfe von Übertragungstransaktionen zwischen dem Benutzer und dem Orakel implementiert . Auf dem Konto des Orakels wird ein Skript festgelegt, das den Betrieb streng gemäß der oben beschriebenen Logik steuert. Die Transaktionen des Orakels werden durch Neuerstellung der gesamten Kette der Benutzerinteraktion überprüft. Alle vier Transaktionen sind an der Überprüfung des Endwerts beteiligt. Ein intelligenter Vertrag fügt sie alle einem strengen Überprüfungsthread hinzu, überprüft die Werte Schritt für Schritt und lässt keinen Raum für Manipulationen.
Versuchen wir es einfach auszudrücken. Das Orakel funktioniert nicht nur nach einem vorgeschlagenen Schema. Sein Betrieb wird auf Blockchain-Ebene durch einen absolut strengen Smart-Vertrag vollständig gesteuert. Jede winzige Umleitung würde zur Ablehnung von Transaktionen führen. Wenn sich die Transaktion also in der Blockchain befindet, müssen Benutzer nichts überprüfen, da die gesamte Überprüfung bereits von Hunderten von Knoten der Blockchain durchgeführt wurde.
Derzeit ist ein VECRO im Mainnet von Waves betriebsbereit. Sie könnten tatsächlich Ihre starten: Es ist einfach, schauen Sie sich einfach das Konfigurationsbeispiel an . Der aktuelle Code funktioniert unter PHP (unter WavesKit , das ich zuvor besprochen habe ).
Um das Orakel zu benutzen, müssen Sie:
- Fixiere R.
- Senden Sie mindestens 0,005 WAVES an den Alias init @ vecr des Orakels.
- Empfangen Sie einen R-Code im Anhangfeld in der 1 R-vecr-Token-Übertragung vom Orakel zum Benutzer.
- Holen Sie sich eine Unterschrift;
- Senden Sie mindestens 0,005 WAVES an den Alias random @ vecr des Orakels. Sie müssen außerdem den empfangenen R-Code und zusätzliche Benutzerdaten in das Anhangsfeld eingeben.
- Empfangen Sie einen S-Code im Anhangfeld in der 1 S-vecr-Token-Übertragung vom Orakel zum Benutzer;
- Verwenden Sie den S-Code als Quelle für Pseudozufallszahlen.
Nuancen der aktuellen Implementierung:
- An das Orakel gesendete WAVES werden als Gebühren für die Rücktransaktion an den Benutzer verwendet, bis zu maximal 1 WAVES.
- R-Code ist eine Verkettung des 'R'-Symbolbytes und des 32-Byte-R-Werts in der Base58-Codierung;
- Der R-Code im Anhang muss den Benutzerdaten vorangehen.
- S-Code ist eine Verkettung des 'S'-Symbolbytes und des 32-Bytes-S-Werts in der Base58-Codierung;
- S ist das Ergebnis einer Modulo-Division und kann nicht als richtige 256-Bit-Pseudozufallszahl verwendet werden (es kann höchstens als 252-Bit-Pseudozufallszahl betrachtet werden);
- Die einfachste Option ist die Verwendung des S-Code-Hash als Quelle für Pseudozufallszahlen.
Beispiele für den Empfang von S-Code:
Aus technischer Sicht ist das Orakel voll funktionsfähig, Sie können es sicher verwenden. Aus der Sicht eines normalen Benutzers gibt es nicht genügend benutzerfreundliche GUI, die warten muss.
Gerne beantworte ich Fragen und nehme Kommentare entgegen, danke.
Update (8. Mai 2019)
Ich habe mich bei VRF geirrt. Ja, es stimmt, dass die ECVRF-Signatur nicht als Quelle für eine Pseudozufallszahl verwendet werden kann, sie wird jedoch nicht für diesen Zweck verwendet. Die Signatur wird benötigt, um die Eindeutigkeit des Gamma-Werts nachzuweisen ( Abschnitt 5.3 , Schritt 6). Der verifizierte Wert von Gamma wird als Quelle für eine Pseudozufallszahl verwendet ( Abschnitt 5.2 , Schritt 5). Dank an Oleg Taraskin Crittografo für den Hinweis auf diesen Moment gebe ich meinen Fehler zu. ECVRF hat das volle Recht zu leben.
Leider gibt es immer noch keine Möglichkeit, ECVRF auf der Waves-Blockchain-Ebene zu verwenden, da in intelligenten Verträgen die erforderlichen mathematischen Funktionen fehlen.
Wenn diese Funktionalität oder RSA-Unterstützung verfügbar wird, können neue Orakel erstellt werden. Das VECRO-Schema nimmt in jedem Fall seine Nische ein und ermöglicht es Ihnen, ohne zusätzliche Funktionen zu arbeiten.