{"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 auf Basis digitaler Signaturen in der Blockchain","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

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\u00fcfbaren blockchain-basierten Pseudo-Zufallszahlen an.<\/p>\n

<\/p>\n

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

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

Die Idee<\/h1>\n

<\/p>\n

Im Herbst 2018 wurden im Waves-Blockchain die ersten Smart Contracts aktiviert<\/a><\/noindex>, worauf sofort die Frage aufkam, ob es m\u00f6glich sei, Pseudo-Zufallszahlen<\/a><\/noindex>zu erhalten, denen man vertrauen kann.<\/p>\n

<\/p>\n

Nach intensiven \u00dcberlegungen kam ich schlie\u00dflich zu dem Schluss: Jede Blockchain ist ein geschlossenes System; es ist unm\u00f6glich, eine vertrauensw\u00fcrdige Quelle f\u00fcr Entropie in einem abgeschlossenen System zu erhalten.<\/p>\n

<\/p>\n

Aber eine Idee hat mir dennoch gefallen: Wenn ein zuf\u00e4lliger Oracle<\/a><\/noindex> Wenn die Benutzerdaten mit einem deterministischen Algorithmus signiert werden, kann der Benutzer stets diese Signatur mit dem \u00f6ffentlichen Schl\u00fcssel \u00fcberpr\u00fcfen und ist sich sicher, dass der erhaltene Wert einzigartig ist. Ein Oracle ist nicht in der Lage, etwas zu \u00e4ndern, denn der Algorithmus liefert ein eindeutiges Ergebnis. Im Grunde fixiert der Benutzer das Ergebnis, kennt es jedoch nicht, bis das Oracle es ver\u00f6ffentlicht. Es ist also m\u00f6glich, dem Oracle nicht zu vertrauen, aber das Ergebnis seiner Arbeit zu \u00fcberpr\u00fcfen. In diesem Fall kann eine solche Signatur als Quelle von Entropie f\u00fcr eine pseudorandomisierte Zahl angesehen werden.<\/p>\n

<\/p>\n

Auf der Blockchain-Plattform Waves wird ein Signaturschema verwendet EdDSA<\/a><\/noindex> Variante ist gut gelungen. 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 Basis der zu signierenden Nachricht, des privaten Schl\u00fcssels und desselben Zufallswerts berechnet wird, der auch f\u00fcr R verwendet wird. Das bedeutet, dass es keine eindeutige Abh\u00e4ngigkeit gibt; f\u00fcr die gleiche Benutzer-Nachricht existieren viele g\u00fcltige Signaturen.<\/p>\n

<\/p>\n

Offensichtlich kann eine solche Signatur in reiner Form nicht als Quelle f\u00fcr pseudorandomisierte Zahlen verwendet werden, da sie unbestimmt ist und daher leicht von einem Oracle manipuliert werden 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 eine verifizierbare Zufallsfunktion (VRF)<\/a><\/noindex>, aber nach dem Studium der Materie musste ich von dieser Variante Abstand nehmen. Obwohl die VRF eine deterministische Option f\u00fcr die Signatur und deren Beweis bietet, gibt es im Algorithmus einen merkw\u00fcrdigen Punkt, der ein Schlupfloch f\u00fcr Manipulationen durch das Oracle \u00f6ffnet. Genauer gesagt, bei der Berechnung des Wertes k (Abschnitt 5.1<\/a><\/noindex>) wird ein geheimer Schl\u00fcssel verwendet, der dem Benutzer unbekannt bleibt. Das bedeutet, dass der Benutzer die Richtigkeit der Berechnung von k nicht \u00fcberpr\u00fcfen kann. Daher kann der Oracle einen beliebigen Wert f\u00fcr k verwenden und gleichzeitig eine Datenbank mit den Entsprechungen von k und den signierten Daten f\u00fchren, um immer das korrekte Ergebnis aus der Sicht des VRF neu berechnen zu k\u00f6nnen. Wenn Sie eine VRF-basierte Auslosung ohne Offenlegung des geheimen Schl\u00fcssels sehen, k\u00f6nnen Sie klug anmerken: Sie m\u00fcssten entweder den Schl\u00fcssel offenlegen oder ihn aus der Berechnung von k ausschlie\u00dfen, sodass der geheime Schl\u00fcssel automatisch bei der ersten Signatur offengelegt wird. Insgesamt, wie bereits erw\u00e4hnt, ist dies ein seltsames Schema f\u00fcr einen zuf\u00e4lligen Oracle.<\/p>\n

<\/p>\n

Nach einigem Nachdenken und mit Unterst\u00fctzung lokaler Analysten wurde das VECRO-Arbeitsmodell entwickelt.<\/p>\n

<\/p>\n

VECRO steht f\u00fcr Verifiable Elliptic Curve Random Oracle, was auf Deutsch \u00fcberpr\u00fcfbarer zuf\u00e4lliger Oracle auf elliptischen Kurven bedeutet.<\/p>\n

<\/p>\n

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\u00e4tzlich R in der selbst signierten Nachricht garantiert, wird der Wert S eindeutig durch die Benutzer-Nachricht bestimmt und kann daher als Quelle f\u00fcr pseudorandomisierte Zahlen verwendet werden.<\/p>\n

<\/p>\n

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\u00f6ffentlicht. Genau wie wir es wollten!<\/p>\n

<\/p>\n

Wenn wir von fixiertem R sprechen, beachten Sie, dass wiederverwendetes R<\/a><\/noindex> bei der Signierung verschiedener Nachrichten eindeutig den privaten Schl\u00fcssel im EdDSA-Schema offenbart. F\u00fcr den Eigent\u00fcmer des Orakels ist es von gr\u00f6\u00dfter Bedeutung, die M\u00f6glichkeit der Wiederverwendung von R zur Signierung verschiedener Benutzer-Nachrichten auszuschlie\u00dfen. Das hei\u00dft, bei allen Manipulationen oder Verschw\u00f6rungen wird das Orakel immer das Risiko eingehen, seinen privaten Schl\u00fcssel zu verlieren.<\/p>\n

<\/p>\n

Insgesamt sollte der Oracle den Nutzern zwei Funktionen bereitstellen: eine Initialisierung, die den Wert R festlegt, und eine Signatur, die den Wert S zur\u00fcckgibt. Dabei ist das Paar R, S eine standardm\u00e4\u00dfige \u00fcberpr\u00fcfbare Signatur der Nutzer-Nachricht, die einen festgelegten Wert R und beliebige Nutzerdaten enth\u00e4lt.<\/p>\n

<\/p>\n

Es k\u00f6nnte argumentiert werden, dass dieses Schema f\u00fcr die Blockchain nichts anderes ist als ein gew\u00f6hnliches Commit-Reveal-Schema<\/a><\/noindex>. Im Wesentlichen ist das korrekt, aber es gibt einige Nuancen. Erstens arbeitet der Oracle bei allen Operationen immer mit demselben Schl\u00fcssel, was beispielsweise in Vertr\u00e4gen praktisch ist. Zweitens besteht das Risiko, dass der Oracle seinen privaten Schl\u00fcssel bei fehlerhaftem Verhalten verliert, beispielsweise wenn der Oracle die Resultate testet; in diesem Fall reichen zwei Proben aus, um den privaten Schl\u00fcssel zu ermitteln und vollen Zugriff auf das Wallet zu erhalten. Drittens ist die nativ \u00fcberpr\u00fcfbare Signatur in der Blockchain, die als Quelle der Zuf\u00e4lligkeit dient \u2013 das ist eine elegante L\u00f6sung.<\/p>\n

<\/p>\n

Sechs Monate lang reifte die Idee zur Umsetzung in meinem Kopf, bis schlie\u00dflich die Motivation in Form eines Stipendiums von Waves Labs kam.<\/a><\/noindex>. Mit einem gro\u00dfen Zuschuss kommt gro\u00dfe Verantwortung, was bedeutet, dass das Projekt realisiert werden muss!<\/p>\n

<\/p>\n

Implementierung<\/h1>\n

<\/p>\n

In diesem Projekt wurde VECRO<\/a><\/noindex> 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\u00e4t strikt gem\u00e4\u00df der oben beschriebenen Logik \u00fcberwacht. Die Transaktionen des Oracles werden \u00fcberpr\u00fcft, indem die gesamte Interaktionskette mit dem Benutzer wiederhergestellt wird. Bei der \u00dcberpr\u00fcfung des Endwerts spielen alle vier Transaktionen eine Rolle; der Smart Contract reiht sie auf eine strenge Pr\u00fcfungsleine und \u00fcberpr\u00fcft Schritt f\u00fcr Schritt alle Werte, ohne Spielraum f\u00fcr Manipulationen zu lassen.<\/p>\n

<\/p>\n

Noch einmal, damit es klarer ist. Das Oracle arbeitet nicht nur nach dem vorgeschlagenen Schema. Seine Funktionalit\u00e4t wird vollst\u00e4ndig auf Blockchain-Ebene durch den implementierten festgelegten Smart Contract<\/a><\/noindex>. 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\u00fcfen, denn alles wurde bereits von hunderten Knoten im Netzwerk \u00fcberpr\u00fcft.<\/p>\n

<\/p>\n

Aktuell ist ein VECRO im Hauptnetz von Waves aktiv (Sie k\u00f6nnen Ihren eigenen starten, es ist ganz einfach, schauen Sie einfach in das Beispiel der Konfiguration<\/a><\/noindex>). Der aktuelle Code basiert auf PHP (auf WavesKit<\/a><\/noindex>, \u00fcber das ich zuvor gesprochen habe.<\/a><\/noindex>).<\/p>\n

<\/p>\n

Um den Oracle-Service zu nutzen, m\u00fcssen Sie:<\/p>\n

<\/p>\n