{"id":32343,"date":"2019-10-31T21:46:27","date_gmt":"2019-10-31T18:46:27","guid":{"rendered":"https:\/\/prohoster.info\/blog\/cluchajnyj-orakul-na-osnove-tsifrovoj-podpisi-v-blokchejne\/"},"modified":"2019-10-31T21:46:27","modified_gmt":"2019-10-31T18:46:27","slug":"cluchajnyj-orakul-na-osnove-tsifrovoj-podpisi-v-blokchejne","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/cluchajnyj-orakul-na-osnove-tsifrovoj-podpisi-v-blokchejne","title":{"rendered":"Zuf\u00e4lliger Oracle basierend auf digitaler Signatur in der Blockchain","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

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 \u00fcberpr\u00fcfbarer pseudozuf\u00e4lliger Zahlen auf dieser Grundlage.<\/p>\n

<\/p>\n

\"Zuf\u00e4lliger<\/p>\n

<\/a><\/noindex><\/p>\n

Idee<\/h1>\n

<\/p>\n

Im Herbst 2018 wurden in der Blockchain Waves die ersten Smart Contracts aktiviert<\/a><\/noindex>, sofort stellte sich die Frage nach der M\u00f6glichkeit, pseudozuf\u00e4llige Zahlen<\/a><\/noindex>, denen man vertrauen kann.<\/p>\n

<\/p>\n

Nach intensiven \u00dcberlegungen kam ich zu dem Schluss: Jede Blockchain ist eine Zelle, einen vertrauensw\u00fcrdigen Entropiequelle in einem geschlossenen System zu erhalten, ist unm\u00f6glich.<\/p>\n

<\/p>\n

Aber eine Idee gefiel mir dennoch: Wenn zuf\u00e4lliges Oracle<\/a><\/noindex> die Signatur der Benutzerdaten mit einem deterministischen Algorithmus erstellt, kann der Benutzer immer diese Signatur mit dem \u00f6ffentlichen Schl\u00fcssel pr\u00fcfen und wird sicher sein, dass der erhaltene Wert einzigartig ist. Das Oracle ist bei allem Wunsch nicht in der Lage, etwas zu \u00e4ndern, der Algorithmus liefert ein eindeutiges Ergebnis. Im Wesentlichen fixiert der Benutzer das Ergebnis, wei\u00df es jedoch nicht, bis das Oracle es ver\u00f6ffentlicht. So kann man dem Oracle grunds\u00e4tzlich nicht vertrauen, aber das Ergebnis seiner Arbeit pr\u00fcfen. In diesem Fall kann, wenn die Pr\u00fcfung erfolgreich ist, eine solche Signatur als Entropiequelle f\u00fcr eine pseudozuf\u00e4llige Zahl gelten.<\/p>\n

<\/p>\n

In der Blockchain-Plattform Waves wird das Signaturschema EdDSA<\/a><\/noindex> Variante Ed25519<\/a><\/noindex>. In diesem Schema besteht die Signatur aus den Werten R und S, wobei R von einem zuf\u00e4lligen Wert abh\u00e4ngt und S auf der Basis der zu signierenden Nachricht, des geheimen Schl\u00fcssels und der gleichen Zufallszahl wie R berechnet wird. Es ergibt sich, dass es keine eindeutige Abh\u00e4ngigkeit gibt; f\u00fcr dasselbe Benutzermeldung existieren viele g\u00fcltige Signaturen.<\/p>\n

<\/p>\n

Es ist offensichtlich, dass eine solche Signatur im reinen Zustand nicht als Quelle f\u00fcr pseudozuf\u00e4llige Zahlen verwendet werden kann, da sie nicht deterministisch ist und daher leicht Manipulationen durch das Oracle ausgesetzt sein kann.<\/p>\n

<\/p>\n

Aber wie sich herausstellte, ist es tats\u00e4chlich m\u00f6glich, sie deterministisch zu machen.<\/p>\n

<\/p>\n

Ich hatte gro\u00dfe Hoffnungen auf pr\u00fcfbare Zufallsfunktion (VRF)<\/a><\/noindex>, 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\u00fcr Manipulationen durch den Orakel er\u00f6ffnet. Insbesondere wird bei der Berechnung des Wertes k (Abschnitt 5.1<\/a><\/noindex>) ein geheimer Schl\u00fcssel verwendet, der dem Benutzer unbekannt bleibt. Das bedeutet, der Benutzer kann die Korrektheit der Berechnung von k nicht \u00fcberpr\u00fcfen, sodass das Orakel jeden f\u00fcr es notwendigen Wert k verwenden kann und gleichzeitig eine Datenbank von Zuordnungen zwischen k und den zu signierenden Daten f\u00fchrt, 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\u00fcssels sehen, k\u00f6nnen Sie sich dar\u00fcber auslassen: auf die Notwendigkeit hinweisen, entweder den Schl\u00fcssel preiszugeben oder ihn aus der Berechnung von k auszuschlie\u00dfen. Dann w\u00fcrde der geheime Schl\u00fcssel automatisch bei der ersten Unterschrift selbst offengelegt. Insgesamt, wie bereits erw\u00e4hnt, eine seltsame Methode f\u00fcr ein zuf\u00e4lliges Orakel.<\/p>\n

<\/p>\n

Nachdem ich etwas nachgedacht und Unterst\u00fctzung von lokalen Analysten erhalten hatte, entstand das Konzept der Funktionsweise von VECRO.<\/p>\n

<\/p>\n

VECRO ist ein Akronym f\u00fcr Verifiable Elliptic Curve Random Oracle, was auf Deutsch \u00fcberpr\u00fcfbarer Zufallsorakel auf elliptischen Kurven bedeutet.<\/p>\n

<\/p>\n

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\u00e4tzlich 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\u00fcr pseudorandomisierte Zahlen verwendet werden.<\/p>\n

<\/p>\n

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\u00f6ffentlicht. Alles genau so, wie wir es wollten!<\/p>\n

<\/p>\n

Wenn wir \u00fcber das feste R sprechen, beachten Sie, dass ein wiederverwendetes R<\/a><\/noindex> Die Unterzeichnung verschiedener Nachrichten entschl\u00fcsselt eindeutig den privaten Schl\u00fcssel im EdDSA-Schema. F\u00fcr den Besitzer des Orakels ist es \u00e4u\u00dferst wichtig, die M\u00f6glichkeit der Wiederverwendung von R f\u00fcr die Signierung verschiedener Nachrichten des Benutzers auszuschlie\u00dfen. Das hei\u00dft, bei jeglichen Manipulationen oder Absprachen riskierte das Orakel immer den Verlust seines privaten Schl\u00fcssels.<\/p>\n

<\/p>\n

Insgesamt muss das Orakel den Benutzern zwei Funktionen bereitstellen: eine Initialisierung, die den Wert von R festh\u00e4lt, und eine Signatur, die den Wert von S zur\u00fcckgibt. Dabei ist das Paar R, S eine gew\u00f6hnliche \u00fcberpr\u00fcfbare Signatur der Benutzer-Nachricht, die den festen Wert R und willk\u00fcrliche Benutzerdaten enth\u00e4lt.<\/p>\n

<\/p>\n

Man k\u00f6nnte einwenden, dass dieses Schema f\u00fcr die Blockchain nichts anderes ist als ein gew\u00f6hnliches Commit-Entschl\u00fcsselungsschema<\/a><\/noindex>. Im Grunde genommen, ja, das ist es. Aber es gibt einige Nuancen. Erstens arbeitet das Orakel immer mit demselben Schl\u00fcssel in allen Operationen, beispielsweise ist dies praktisch f\u00fcr Vertr\u00e4ge. Zweitens besteht das Risiko, dass das Orakel den privaten Schl\u00fcssel bei unsachgem\u00e4\u00dfem Verhalten verliert, z. B. wenn das Orakel erlaubt, Ergebnisse zu \u00fcberpr\u00fcfen; dann reichen zwei \u00dcberpr\u00fcfungen aus, um den privaten Schl\u00fcssel zu erfahren und vollen Zugriff auf das Wallet zu erhalten. Drittens ist die nativ \u00fcberpr\u00fcfbare Signatur in der Blockchain, die die Quelle der Zuf\u00e4lligkeit ist \u2014 das ist sch\u00f6n.<\/p>\n

<\/p>\n

Sechs Monate lang reifte die Idee der Umsetzung im Kopf, bis schlie\u00dflich die Motivation in Form von einem Zuschuss von Waves Labs<\/a><\/noindex>kam. Mit einem gro\u00dfen Zuschuss kommt gro\u00dfe Verantwortung, also wird es das Projekt geben!<\/p>\n

<\/p>\n

Implementierung<\/h1>\n

<\/p>\n

So wurde in diesem Projekt VECRO implementiert<\/a><\/noindex> auf der Blockchain von Waves im Anfrage-Antwort-Modus mithilfe von \u00dcberweisungs-Transaktionen zwischen Benutzer und Orakel. Dabei wurde im Konto des Orakels ein Skript eingerichtet, das die Arbeit streng gem\u00e4\u00df der oben beschriebenen Logik \u00fcberwacht. Die Transaktionen des Orakels durchlaufen eine \u00dcberpr\u00fcfung, bei der die gesamte Interaktionskette mit dem Benutzer wiederhergestellt wird. An der \u00dcberpr\u00fcfung des Endwertes sind alle vier Transaktionen beteiligt, und der Smart Contract f\u00fcgt sie an einen strengen \u00dcberpr\u00fcfungsfaden an, der Schritt f\u00fcr Schritt alle Werte pr\u00fcft und keinen Platz f\u00fcr irgendwelche Manipulationen l\u00e4sst.<\/p>\n

<\/p>\n

Noch einmal, damit es klar ist. Das Orakel arbeitet nicht nur nach dem vorgeschlagenen Schema. Seine Arbeit wird vollst\u00e4ndig auf der Ebene der Blockchain kontrolliert. mit einem Smart Contract fest verbunden<\/a><\/noindex>. 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 \u00fcberpr\u00fcfen, denn das haben bereits Hunderte von Knoten im Netzwerk erledigt.<\/p>\n

<\/p>\n

Aktuell ist im Waves-Hauptnetz ein VECRO gestartet (Sie k\u00f6nnen Ihr eigenes starten, es ist nicht schwer, schauen Sie einfach in das Beispiel f\u00fcr die Konfiguration ). Der aktuelle Code l\u00e4uft auf PHP (auf<\/a><\/noindex>WavesKit , \u00fcber das<\/a><\/noindex>ich fr\u00fcher berichtet habe Um den Oracle-Service zu nutzen, muss man:<\/a><\/noindex>).<\/p>\n

<\/p>\n

R festlegen;<\/p>\n

<\/p>\n