Einführung

function getAbsolutelyRandomNumer() {
        return 4; // gibt eine absolut zufällige Zahl zurück!
}

Ähnlich wie bei der Idee einer absolut sicheren Verschlüsselung in der Kryptografie versuchen echte Protokolle "Publicly Verifiable Random Beacon" (PVRB) lediglich, dem idealen Schema so nah wie möglich zu kommen, da es in realen Netzwerken in seiner reinen Form nicht anwendbar ist: Es muss strikt über ein einzelnes Bit verhandelt werden, es sollte viele Runden geben, und alle Nachrichten müssen perfekt schnell und immer zuverlässig zugestellt werden. In realen Netzwerken ist dies jedoch nicht der Fall. Daher ergeben sich bei der Gestaltung von PVRB für spezifische Aufgaben in modernen Blockchains neben der Unmöglichkeit, die erhaltene Zufälligkeit und kryptografische Sicherheit zu kontrollieren, noch viele rein architektonische und technische Probleme.

Die Blockchain fungiert für PVRB im Wesentlichen als Kommunikationsumgebung, in der Nachrichten gleichbedeutend mit Transaktionen sind. Dies ermöglicht eine teilweise Abstraktion von Netzwerkproblemen, dem Verlust von Nachrichten und Problemen mit Middleware – all diese Risiken werden von einem dezentralen Netzwerk übernommen. Der Hauptvorteil für PVRB liegt in der Unmöglichkeit, eine bereits gesendete Transaktion zurückzuziehen oder zu ändern, was es den Teilnehmern unmöglich macht, die Teilnahme am Protokoll abzulehnen, es sei denn, sie führen einen erfolgreichen Angriff auf den Konsens durch. Dieses Sicherheitsniveau ist akzeptabel; daher muss PVRB gegenüber Kollusionen der Teilnehmer ebenso widerstandsfähig sein wie die Haupt-Blockchain. Dies deutet auch darauf hin, dass PVRB Teil des Konsenses sein muss, wenn das Netzwerk sich über die Haupt-Blockkette einigt, und gleichzeitig muss es sich auch über einen einzigen fairen Zufallswert einigen. Alternativ könnte PVRB einfach ein eigenständiges Protokoll sein, das durch einen Smart Contract implementiert ist und asynchron zur Blockchain und den Blöcken arbeitet. Beide Methoden haben ihre Vorzüge und Nachteile, und die Wahl zwischen ihnen ist alles andere als trivial.

Zwei Möglichkeiten zur Implementierung von PVRB

Lassen Sie uns die beiden Implementierungsvarianten von PVRB näher beschreiben — die Standalone-Version, die mit einem vom Blockchain unabhängigen Smart Contract arbeitet, und die einvernehmliche integrierte Version — die in das Protokoll eingebaut ist, gemäß dem sich das Netzwerk über die Blockchain und die einbezogenen Transaktionen einigt. In allen Fällen werde ich mich auf beliebte Blockchain-Engines beziehen: Ethereum, EOS und alle ähnlichen, die nach demselben Prinzip der Bereitstellung und Verarbeitung von Smart Contracts funktionieren.

Standalone-Vertrag

In dieser Variante ist PVRB ein Smart Contract, der Transaktionen von Random-Produzenten (im Folgenden RP) annimmt, diese verarbeitet, die Ergebnisse kombiniert und schließlich zu einem bestimmten Wert gelangt, den jeder Benutzer aus diesem Vertrag beziehen kann. Dieser Wert wird möglicherweise nicht direkt im Vertrag gespeichert, sondern nur durch Daten dargestellt, aus denen deterministisch ein einziges Ergebnis des Zufallswerts abgeleitet werden kann. In diesem Schema sind RP die Benutzer der Blockchain, und jeder kann am Generierungsprozess teilnehmen.

Die Standalone-Vertragsvariante hat folgende Vorteile:

Portabilität (Verträge können von einer Blockchain zur anderen übertragen werden)
einfacher in der Umsetzung und im Testen (Verträge lassen sich leicht schreiben und überprüfen)
Bequemlichkeit bei der Umsetzung wirtschaftlicher Modelle (einfach, um eigene Token zu erstellen, deren Logik den Zielen von PVRB dient)
die Möglichkeit, in bestehenden Blockchains zu starten

Es hat jedoch auch Nachteile:

starke Einschränkungen bei Ressourcen für Berechnungen, Transaktionsvolumen und Speicherung (einfach gesagt cpu/mem/io)
Einschränkungen bei Operationen innerhalb des Vertrags (nicht alle Anweisungen sind verfügbar, schwierig, externe Bibliotheken anzubinden)
die Unmöglichkeit, Nachrichten schneller zu organisieren, als Transaktionen in die Blockchain aufgenommen werden

Diese Option ist geeignet für die Umsetzung von PVRB, das in einem bestehenden Netzwerk gestartet werden muss, das keine komplexe Kryptografie enthält und keine großen Interaktionen erfordert.

Konsens-integriert

In dieser Variante ist PVRB im Code des Blockchain-Knotens implementiert, entweder integriert oder parallel zum Nachrichtenaustausch zwischen den Blockchain-Knoten aktiv. Die Ergebnisse des Protokolls werden direkt in die erstellten Blöcke geschrieben, während die Protokollnachrichten über das P2P-Netzwerk zwischen den Knoten gesendet werden. Da das Protokoll Ergebnisse in Form von Zahlen hat, die in den Blöcken aufgezeichnet werden müssen, muss das Netzwerk einen Konsens über diese Zahlen erreichen. Das bedeutet, dass die PVRB-Nachrichten, ebenso wie die Transaktionen, von den Knoten validiert und in die Blöcke aufgenommen werden müssen, damit jeder Teilnehmer im Netzwerk die Einhaltung des PVRB-Protokolls überprüfen kann. Dies führt uns automatisch zu einer offensichtlichen Lösung – wenn das Netzwerk einen Konsens über einen Block und dessen darin enthaltene Transaktionen erzielt, muss PVRB Teil des Konsenses sein und darf nicht als getrenntes Protokoll angesehen werden. Andernfalls könnte es passieren, dass ein Block aus Sicht des Konsenses gültig ist, aber das PVRB-Protokoll nicht eingehalten wurde, was bedeutet, dass der Block aus Sicht von PVRB nicht akzeptiert werden kann. Wenn also die Option „konsens-integriert“ gewählt wird, wird PVRB zu einem wichtigen Bestandteil des Konsenses.

Bei der Beschreibung der Implementierungen von PVRB auf Konsensniveau im Netzwerk dürfen die Fragen zur Finalität auf keinen Fall außer Acht gelassen werden. Finalität ist ein Mechanismus, der in deterministischen Konsensen verwendet wird, um einen Block (und die dazugehörige Kette) zu fixieren, der final ist und niemals verworfen wird, selbst wenn ein paralleler Fork auftaucht. Zum Beispiel hat Bitcoin keinen solchen Mechanismus – wenn eine Kette mit größerer Komplexität veröffentlicht wird, ersetzt sie jede weniger komplexe, unabhängig von der Länge der Ketten. In EOS zum Beispiel sind die sogenannten Last Irreversible Blocks (LIB) final, die im Durchschnitt alle 432 Blöcke (12*21 + 12*15, Pre-Vote + Pre-Commit) erscheinen. Dieser Prozess besteht im Wesentlichen darin, auf 2/3 der Unterschriften von Blockproduzenten (BP) zu warten. Forks, die älter sind als der letzte LIB, werden einfach verworfen. Dieser Mechanismus garantiert, dass eine Transaktion in die Blockchain aufgenommen wird und niemals zurückgezogen werden kann, egal über welche Ressourcen der Angreifer verfügt. Auch final sind Blöcke, die von 2/3 der BP in Hyperledger, Tendermint und anderen pBFT-basierten Konsensen signiert wurden. Darüber hinaus ist es sinnvoll, ein Protokoll zur Sicherstellung der Finalität als Erweiterung über den Konsens zu gestalten, da es asynchron zum Produzieren und Veröffentlichen von Blöcken arbeiten kann. Hier ist ein gutes Artikel Über die Finalität in Ethereum.

Finalität ist von entscheidender Bedeutung für Benutzer, die ohne sie Opfer eines „Double Spend“-Angriffs werden können, wenn der Blockproduzent (BP) die Blöcke „hält“ und sie veröffentlicht, nachdem das Netzwerk eine gültige Transaktion „gesehen“ hat. Fehlt die Finalität, ersetzt der veröffentlichte Fork den Block mit der „guten“ Transaktion durch einen anderen aus dem „schlechten“ Fork, in dem dieselben Mittel an die Adresse des Angreifers überwiesen werden. Bei PVRB werden die Anforderungen an die Finalität noch strenger, da das Erstellen von Forks für PVRB bedeutet, dass der Angreifer mehrere Varianten von Zufallszahlen vorbereiten kann, um die für ihn günstigste zu veröffentlichen und die Zeit für einen möglichen Angriff zu begrenzen — eine gute Lösung.

Deshalb ist die beste Lösung, PVRB und Finalität in einem Protokoll zu kombinieren — dann ist der finalisierte Block = finalisierte Zufallszahl, und das ist genau das, was erreicht werden sollte. Jetzt werden die Spieler garantierte Zufallszahlen innerhalb von N Sekunden erhalten und können sicher sein, dass sie zurückgesetzt oder erneut gespielt werden können.

Das Konzept mit integrierter Konsens ist gut:

mit der Möglichkeit zur asynchronen Umsetzung in der Blockproduktion - Blöcke werden wie gewohnt produziert, während gleichzeitig das PVRB-Protokoll läuft, das nicht für jeden Block Zufallszahlen erzeugt.
mit der Möglichkeit, auch komplexe Kryptografie ohne Einschränkungen durch Smart Contracts zu implementieren.
mit der Möglichkeit, Nachrichten schneller zu organisieren, als Transaktionen in die Blockchain aufgenommen werden, beispielsweise kann ein Teil des Protokolls zwischen Knoten kommunizieren, ohne Nachrichten im Netzwerk zu verbreiten.

Es hat jedoch auch Nachteile:

Herausforderungen bei der Testung und Entwicklung - es wird erforderlich sein, Netzwerkfehler, ausgefallene Knoten und Netzwerk-Hardforks zu emulieren.
Fehler in der Implementierung erfordern einen Hardfork des Netzwerks.

Beide Implementierungsansätze für PVRB haben ihre Berechtigung, jedoch sind Smart Contracts in modernen Blockchains stark in ihren Rechenressourcen eingeschränkt, sodass der Übergang zu ernsthafter Kryptographie oft schlichtweg nicht möglich ist. Ernste Kryptographie wird jedoch benötigt, wie im Folgenden demonstriert wird. Obwohl dieses Problem offensichtlich temporär ist, ist ernsthafte Kryptographie in Verträgen notwendig, um viele Aufgaben zu lösen, und allmählich wird sie eingeführt (zum Beispiel systematische Verträge für zkSNARKs in Ethereum).

Eine Blockchain, die einen transparenten und zuverlässigen Nachrichtenaustausch über das Protokoll gewährleistet, geschieht nicht kostenlos. Jeder dezentrale Protokoll muss die Möglichkeit einer Sybil-Attacke berücksichtigen; jede Handlung kann durch die vereinbarten Kräfte einer Vielzahl von Konten ausgeführt werden. Daher müssen bei der Planung die Fähigkeiten der Angreifer zur Erstellung einer beliebigen Anzahl von Protokollteilnehmern, die im Einklang agieren, berücksichtigt werden.

PVRB und Blockvariablen.

Ich habe nicht gelogen, als ich sagte, dass es bisher in den Blockchains kein gutes PVRB gibt, das von zahlreichen Glücksspielanwendungen getestet wurde. Woher kommt dann die große Zahl an Glücksspielanwendungen in Ethereum und EOS? Das überrascht mich ebenso wie Sie – woher haben sie in einer vollständig deterministischen Umgebung so viele „stabile“ Zufallszahlen?

Die bevorzugte Methode, um Zufallszahlen in der Blockchain zu generieren, besteht darin, irgendeine „unvorhersehbare“ Information aus einem Block zu verwenden und darauf basierend Zufallszahlen zu erstellen – indem man einfach einen oder mehrere Werte hasht. Ein guter Artikel über die Probleme solcher Ansätze. hierMan kann einen der “unvorhersehbaren” Werte im Block verwenden, zum Beispiel den Block-Hash, die Anzahl der Transaktionen, die Netzwerkschwierigkeit und andere, im Voraus unbekannte Werte. Dann hash man diese, einen oder mehrere, und theoretisch sollte dabei ein echter Zufallswert herauskommen. Man könnte sogar im Whitepaper anmerken, dass Ihr Schema „post-quantum secure“ ist (da es quantenresistente Hashfunktionen gibt :)).

Aber selbst post-quantum sichere Hashfunktionen sind leider nicht ausreichend. Das Geheimnis liegt in den Anforderungen an das PVRB, die ich aus dem vorherigen Artikel noch einmal in Erinnerung rufen möchte:

Das Ergebnis muss nachweislich gleichmäßig verteilt sein, d.h. es basiert auf nachweislich sicherer Kryptografie.
Keiner der Bits des Ergebnisses kann kontrolliert werden. Folglich kann das Ergebnis nicht im Voraus vorhergesagt werden.
Der Protokoll zur Generierung kann nicht durch Nicht-Teilnahme oder durch Überlastung des Netzwerks mit Angriffsnachrichten sabotiert werden.
All das oben Genannte muss widerstandsfähig gegen Kollusionen einer zulässigen Anzahl unehrlicher Teilnehmer im Protokoll sein (z. B. 1/3 der Teilnehmer).

In diesem Fall wird nur die Anforderung 1 erfüllt, während 2 nicht beachtet wird. Durch das Hashen unvorhersehbarer Werte aus dem Block erhalten wir eine gleichmäßige Verteilung und gute Zufallszahlen. Aber der Blockvermittler (BP) hat zumindest die Möglichkeit, "einen Block zu veröffentlichen oder nicht". Somit kann der BP zumindest zwischen ZWEI Zufallsvarianten wählen: seinem eigenen und dem, der entsteht, wenn jemand anderer den Block erstellt. Der BP kann im Voraus "nachsehen", was passiert, wenn er den Block veröffentlicht, und trifft dann die Entscheidung, ob er es tun möchte oder nicht. Beispielsweise kann er beim Spielen von "gerade-ungerade" oder "Rot/Schwarz" beim Roulette einen Block nur veröffentlichen, wenn er einen Gewinn sieht. Dies macht auch die Strategie der Verwendung eines Blockhashs "aus der Zukunft" wirkungslos. In diesem Fall wird gesagt, dass "der Zufall verwendet wird, der durch das Hashen der aktuellen Daten und des Hashs des zukünftigen Blocks mit einer Höhe von beispielsweise N + 42, wobei N die aktuelle Blockhöhe ist, entsteht." Das stärkt das Schema ein wenig, erlaubt dem BP jedoch immer noch, auch in der Zukunft zu wählen, ob er den Block zurückhalten oder veröffentlichen möchte.

Die Soft-BP wird in diesem Fall zwar kompliziert, aber nicht übermäßig schwierig. Bei der Validierung und Eingliederung der Transaktion in den Block erfolgt eine schnelle Überprüfung, ob ein Gewinn möglich ist und möglicherweise die Anpassung bestimmter Transaktionsparameter, um eine hohe Gewinnwahrscheinlichkeit zu erzielen. Dabei ist es nahezu unmöglich, einen cleveren BP auf solche Manipulationen zu erwischen, da immer wieder neue Adressen verwendet werden können, um schrittweise zu gewinnen, ohne Verdacht zu erregen.

Daher sind Methoden, die Informationen aus dem Block nutzen, nicht als universelle Implementierung von PVRB geeignet. In einer eingeschränkten Variante, mit Begrenzungen für die Einsatzhöhen, Einschränkungen der Anzahl der Spieler und/oder KYC-Registrierung (um einem Spieler zu verbieten, mehrere Adressen zu verwenden), könnten diese Schemen für kleine Spiele funktionieren, aber nicht darüber hinaus.

PVRB und Commit-Reveal.

Gut, danke der Hashing-Technologie und zumindest der relativen Unvorhersehbarkeit des Blockhashes und anderer Variablen. Wenn wir das Problem des Front-Running bei Minern lösen, sollte etwas Besseres dabei herauskommen. Lassen Sie uns die Benutzer in dieses System einbeziehen – sie sollten ebenfalls den Zufall beeinflussen: Jeder Mitarbeiter des technischen Supports wird Ihnen sagen, dass das Unvorhersehbarste in IT-Systemen das Verhalten der Benutzer ist 🙂

Ein naives Schema, bei dem Nutzer einfach zufällige Zahlen senden und das Ergebnis zum Beispiel als Hash ihrer Summe berechnet wird, ist nicht praktikabel. In diesem Fall kann der letzte Spieler mit seiner eigenen Zufallszahl das Ergebnis beeinflussen. Daher wird ein weit verbreitetes Muster namens Commit-Reveal verwendet. Die Teilnehmer senden zunächst Hashes ihrer Zufallszahlen (Commits) und öffnen dann die Zufallszahlen selbst (Reveals). Die Phase "Reveal" beginnt erst, nachdem die notwendigen Commits gesammelt wurden, sodass die Teilnehmer genau die Zufallszahl senden können, deren Hash sie zuvor übermittelt haben. Jetzt integrieren wir all dies mit den Blockparametern, idealerweise aus einem zukünftigen Block (die Zufallszahl kann erst in einem der zukünftigen Blöcke bekannt gegeben werden), und voilà – die Zufallszahl ist bereit! Nun kann jeder Spieler das Ergebnis der Zufallszahl beeinflussen und möglicherweise den böswilligen BP überlisten, indem er dessen Zufallszahl mit seiner eigenen, im Voraus unbekannten Zufallszahl überlagert… Außerdem kann man einen Schutz gegen die Sabotage des Protokolls einfügen, indem man beim Reveal-Stage eine Offenlegung verlangt – indem man zum Beispiel verlangt, dass man beim Commit eine gewisse Summe als Sicherheit hinterlegt, die nur während des Reveal-Verfahrens zurückgegeben wird. In diesem Fall wäre es nachteilig, einen Commit zu machen, ohne auch ein Reveal durchzuführen.

Das war ein guter Versuch, und solche Modelle gibt es auch in Spiel-DApps. Leider ist das jedoch wieder nicht ausreichend. Jetzt kann das Ergebnis nicht nur von den Minern, sondern von jedem Teilnehmer des Protokolls beeinflusst werden. Der Wert selbst kann nach wie vor kontrolliert werden, allerdings mit weniger Variabilität und gegen Zahlung. Doch wie beim Miner, wenn die Ergebnisse der Ziehung wertvoller sind als die Teilnahmegebühr am PVRB-Protokoll, kann der random-producer (RP entscheiden, ob er das Reveal durchführt und hat weiterhin die Möglichkeit, aus mindestens zwei Zufallsoptionen auszuwählen.
Dafür gibt es jetzt die Möglichkeit, diejenigen zu bestrafen, die einen Commit machen, aber kein Reveal durchführen, und dieses Modell wird sich als nützlich erweisen. Seine Einfachheit ist ein ernsthaftes Plus — anspruchsvollere Protokolle erfordern deutlich leistungsfähigere Berechnungen.

PVRB und deterministische Signaturen.

Es gibt noch einen weiteren Weg, RP dazu zu bringen, eine pseudorandomisierte Zahl bereitzustellen, auf die er keinen Einfluss nehmen kann, wenn ihm ein "Prototyp" gegeben wird – das ist eine deterministische Signatur. Eine solche Signatur ist zum Beispiel RSA, während ECS nicht dazu gehört. Wenn der RP ein Schlüsselpaar bestehend aus RSA und ECC hat und mit seinem privaten Schlüssel einen bestimmten Wert signiert, erhält er im Falle von RSA EINE UND NUR EINE Signatur, während er im Falle von ECS beliebig viele verschiedene gültige Signaturen generieren kann. Dies geschieht, weil bei der Erstellung von ECS-Signaturen eine zufällige Zahl verwendet wird, die vom Unterzeichner gewählt wird, und diese beliebig gewählt werden kann, wodurch dem Unterzeichner die Möglichkeit gegeben wird, eine von mehreren Signaturen auszuwählen. Im Fall von RSA: "ein Eingabewert" + "ein Schlüsselpaar" = "eine Signatur". Es ist unmöglich vorherzusagen, welche Signatur ein anderer RP erhalten wird, daher kann PVRB mit deterministischen Signaturen durch die Kombination von RSA-Signaturen mehrerer Teilnehmer organisiert werden, die denselben Wert signiert haben. Zum Beispiel – die vorherige Zufallszahl. In einem solchen Schema werden viele Ressourcen gespart, da die Signaturen gleichzeitig eine Bestätigung der korrekten Protokollverwendung und eine Quelle für Zufälligkeit darstellen.

Dennoch ist das System, selbst mit deterministischen Signaturen, nach wie vor anfällig für das Problem des "letzten Akteurs". Der letzte Teilnehmer kann weiterhin entscheiden, ob er seine Signatur veröffentlicht oder nicht, und damit das Ergebnis steuern. Man könnte das System verbessern, indem man Block-Hashes hinzufügt und Runden erstellt, um vorherzusagen, dass das Ergebnis nicht absehbar ist, aber all diese Methoden, selbst mit vielen Überarbeitungen, lassen das Problem des Einflusses eines Einzelnen auf das kollektive Ergebnis in einem nicht vertrauenswürdigen Umfeld ungelöst. Darüber hinaus ist die Größe der RSA-Schlüssel (1024 und 2048 Bit) ziemlich groß, während die Größe für Blockchain-Transaktionen ein extrem wichtiger Parameter ist. Offenbar wird es keine einfache Lösung für das Problem geben, also lassen Sie uns weitermachen.

In der Kryptografie gibt es Protokolle, die es einem Netzwerk ermöglichen, sich auf genau einen Wert PVRB zu einigen, wobei diese Protokolle gegen böswillige Handlungen von Teilen der Teilnehmer resistent sind. Eines der nützlichen Protokolle, mit denen man sich vertraut machen sollte, ist das Shamir Secret Sharing. Es dient dazu, ein Geheimnis (zum Beispiel einen geheimen Schlüssel) in mehrere Teile zu teilen und diese Teile an N Teilnehmer zu verteilen. Das Geheimnis wird so verteilt, dass zur Wiederherstellung M Teile aus N ausreichen, wobei dies beliebige M Teile sein können. Kurz gesagt, indem die Teilnehmer Punkte auf dem Graphen einer unbekannten Funktion austauschen, können sie, nachdem sie M Punkte erhalten haben, die gesamte Funktion rekonstruieren.
Eine gute Erklärung findet sich in Wiki und um mit ihm praktisch zu experimentieren, ist es hilfreich, das Protokoll im Kopf zu durchspielen bei Demo Seite.

Wenn das FSSS (Fiat-Shamir Secret Sharing) Protokoll im reinen Sinne anwendbar wäre, wäre es ein unzerstörbarer PVRB. In der einfachsten Variante könnte das Protokoll folgendermaßen aussehen:

Jeder Teilnehmer generiert seine eigene Zufallszahl und verteilt Anteile davon an die anderen Teilnehmer.
Jeder Teilnehmer öffnet seinen Teil der Geheimnisse der anderen Teilnehmer.
Wenn ein Teilnehmer mehr als M Anteile hat, kann die Zahl dieses Teilnehmers berechnet werden, und sie wird einzigartig sein, unabhängig von der Menge der geöffneten Teilnehmer.
Die Kombination aus geöffneten Zufallszahlen ist das gesuchte PVRB.

Hier hat ein einzelner Teilnehmer keinen Einfluss mehr auf die Ergebnisse des Protokolls, es sei denn, es hängt ausschließlich von ihm ab, den Schwellenwert für die Offenlegung des Zufalls zu erreichen. Daher funktioniert dieses Protokoll, sofern der notwendige Anteil an funktionierenden Teilnehmern und verfügbaren RPs vorhanden ist, um die Anforderungen an die kryptographische Sicherheit zu erfüllen und ist resistent gegen das Problem des „letzten Akteurs“.

Das könnte eine ideale Lösung sein; dieses PVRB-Schema auf Basis von Secret Sharing von Fiat-Shamir wird beispielsweise in dieser einem Artikel beschrieben. Aber, wie bereits erwähnt, wenn man versucht, es direkt in einer Blockchain anzuwenden, treten technische Einschränkungen auf. Hier ist ein Beispiel für die Testimplementierung des Protokolls in einem Smart Contract auf EOS und der wichtigste Teil davon — die Überprüfung des veröffentlichten Anteils des Teilnehmers: Code. Der Code zeigt, dass die Validierung des Proofs mehrere skalare Multiplikationen erfordert, und die Zahlen sind sehr groß. Dabei ist zu verstehen, dass die Überprüfung in Blockchains erfolgt, wenn der Blockproduzent die Transaktion verarbeitet. Jeder Teilnehmer sollte die Korrektheit des Protokolls problemlos überprüfen können, weshalb die Anforderungen an die Geschwindigkeit der Überprüfung sehr hoch sind. In dieser Variante erwies sich die Lösung als nicht funktionsfähig, da die Verifizierung die Transaktionsgrenze (0,5 Sek.) nicht einhalten konnte.

Die Effizienz der Verifizierung ist eine der wichtigsten Anforderungen für die Verwendung fortschrittlicher kryptografischer Schemata in der Blockchain. Die Erstellung von Proofs und die Vorbereitung von Nachrichten - diese Verfahren können off-chain ausgelagert und auf Hochleistungscomputern durchgeführt werden, aber die Verifizierung kann nicht umgangen werden - dies ist ein weiteres wichtiges Kriterium für PVRB.

PVRB und Schwellenwertsignaturen

Mit dem Konzept des Secret Sharing haben wir eine ganze Klasse von Protokollen entdeckt, die unter dem Schlüsselwort „Threshold“ zusammengefasst sind. Wenn zur Offenlegung bestimmter Informationen die Teilnahme von M ehrlichen Teilnehmern aus N erforderlich ist und die Gruppe der ehrlichen Teilnehmer eine beliebige Teilmenge von N sein kann, spricht man von „Threshold“-Schemen. Diese ermöglichen es, das Problem des „last actor“ zu lösen; selbst wenn ein Angreifer seinen Teil des Geheimnisses nicht offenbart, kann ein anderer ehrlicher Teilnehmer dies übernehmen. Diese Schemen ermöglichen es, sich auf einen einzigen Wert zu einigen, selbst wenn einige Teilnehmer das Protokoll sabotieren.

Die Kombination von deterministischen Unterschriften und Threshold-Schemen hat eine sehr praktische und vielversprechende Methode zur Implementierung von PVRB geschaffen – dies sind deterministische Threshold-Unterschriften. Hier ist Artikel eine Übersicht über verschiedene Anwendungen von Threshold-Unterschriften und hier ist ein weiterer interessanter Longread von Dash.

Im letzten Artikel werden BLS-Unterschriften beschrieben (BLS steht für Boneh-Lynn-Shacham, hier ist Artikel, die eine äußerst wichtige und äußerst praktische Eigenschaft für Programmierer haben – öffentliche, geheime, öffentliche Schlüssel und BLS-Signaturen können durch einfache mathematische Operationen miteinander kombiniert werden, wobei ihre Kombinationen gültige Schlüssel und Signaturen bleiben, die es ermöglichen, viele Signaturen in einer und viele öffentliche Schlüssel in einem zu aggregieren. Sie weisen auch Determinismus auf und liefern bei denselben Eingabedaten dasselbe Ergebnis. Aufgrund dieser Eigenschaft sind Kombinationen von BLS-Signaturen selbst gültige Schlüssel, was die Implementierung eines Szenarios ermöglicht, bei dem M aus N Teilnehmern eine einzige, deterministische, öffentlich überprüfbare und bis zur Enthüllung durch den M-ten Teilnehmer unvorhersehbare Signatur erzeugen.

Im BLS-Signaturen-Schema mit Schwellenwert unterschreibt jeder Teilnehmer mithilfe von BLS etwas (z.B. den vorherigen Zufallswert), und die gemeinsame Schwellenwert-Unterschrift ist der gesuchte Zufallswert. Die kryptografischen Eigenschaften der BLS-Unterschriften erfüllen die Anforderungen an die Qualität des Zufalls, der Schwellenwert-Teil schützt vor "Last-Actor", und die einzigartige Kombinierbarkeit der Schlüssel ermöglicht die Umsetzung vieler interessanter Algorithmen, die beispielsweise die effektive Aggregation von Nachrichten im Protokoll ermöglichen.

Wenn Sie also ein PVRB in Ihrer Blockchain aufbauen, werden Sie mit hoher Wahrscheinlichkeit zu dem Schema der BLS-Schwellenwertsignaturen kommen, das bereits von mehreren Projekten verwendet wird. Zum Beispiel von DFinity (hier Benchmark, der das Schema implementiert, und hier ein Beispiel für die Implementierung von verifiable secret sharing), oder Keep.network (hier ist ihr random beacon yellowpaper, und hier ist Nummer 00 oder Smart Contract, der das Protokoll unterstützt).

Implementierung von PVRB

Leider sehen wir immer noch kein funktionierendes PVRB-Protokoll, das in Blockchains implementiert wurde und seine Sicherheit sowie Stabilität bewiesen hat. Obwohl die Protokolle selbst bereit sind, ist es technisch schwierig, sie auf bestehende Lösungen anzuwenden. Für zentralisierte Systeme macht PVRB keinen Sinn, während dezentrale Systeme streng in ihren Rechenressourcen beschränkt sind: CPU, Speicher, Speicherung, I/O. Die Gestaltung von PVRB erfordert die Kombination unterschiedlicher Protokolle, um etwas zu schaffen, das wenigstens den Anforderungen eines lebensfähigen Blockchain-Systems entspricht. Ein Protokoll berechnet effizienter, erfordert jedoch mehr Nachrichten zwischen RP, während ein anderes extrem wenige Nachrichten benötigt, aber die Erstellung eines Proofs kann eine Aufgabe von mehreren Minuten oder sogar Stunden sein.

Ich werde die Faktoren aufzählen, die Sie bei der Auswahl eines qualitativ hochwertigen PVRB berücksichtigen müssen:

Kryptographische Sicherheit. Ihr PVRB sollte strikt unbeeinflussbar sein, ohne die Möglichkeit, auch nur ein einziges Bit zu kontrollieren. In einigen Schemen ist das nicht der Fall, daher sollten Sie einen Kryptographen zu Rate ziehen.
Das Problem des "letzten Akteurs". Ihr PVRB sollte gegen Angriffe resilient sein, bei denen ein Angreifer, der einen oder mehrere RPs kontrolliert, zwischen zwei Ergebnissen wählen kann.
Das Problem der Protokoll-Sabotage. Ihr PVRB sollte gegen Angriffe resilient sein, bei denen ein Angreifer, der einen oder mehrere RPs kontrolliert, entscheidet, ob es zufällig sein soll oder nicht und garantiert oder mit einer bestimmten Wahrscheinlichkeit darauf Einfluss nehmen kann.
Das Problem der Nachrichtenanzahl. Ihre RPs sollten mindestens an das Blockchain-Netzwerk Nachrichten senden und möglichst synchronisierte Aktionen wie "Ich habe Informationen gesendet, warte auf eine Antwort von einem bestimmten Teilnehmer" vermeiden. In P2P-Netzwerken, insbesondere geografisch verteilten, ist es nicht realistisch, auf eine schnelle Antwort zu hoffen.
Das Problem der Rechenkomplexität. Die Überprüfung jedes PVRB-Phasen on-chain sollte äußerst einfach sein, da sie von allen vollständigen Clients des Netzwerks durchgeführt wird. Wenn die Implementierung durch einen Smart Contract erfolgt, sind die Anforderungen an die Geschwindigkeit sehr streng.
Das Problem der Verfügbarkeit und Liveness. Ihr PVRB sollte bestrebt sein, in Situationen resilient zu sein, in denen ein Teil des Netzwerks vorübergehend nicht verfügbar ist und einige RPs einfach aufhören zu funktionieren.
Problem mit Trusted Setup und der anfänglichen Verteilung der Schlüssel. Wenn Ihr PVRB das primäre Setup-Protokoll verwendet, ist das eine separate große und ernsthafte Angelegenheit. Hier ist Nummer 00 oder. Wenn die Teilnehmer vor Beginn des Protokolls ihre Schlüssel austauschen müssen, ist das ebenfalls ein Problem, wenn sich die Teilnehmerzahl ändert
Entwicklungsprobleme. Die Verfügbarkeit von Bibliotheken in den benötigten Sprachen, deren Sicherheit und Performance, Öffentlichkeit, umfangreiche Tests usw.

Zum Beispiel gibt es bei threshold BLS-Signaturen ein erhebliches Problem: Bevor die Teilnehmer anfangen können zu arbeiten, müssen sie sich unbedingt gegenseitig Schlüssel aushändigen und eine Gruppe bilden, innerhalb derer das threshold-Protokoll arbeitet. Das bedeutet, dass mindestens eine Runde des Austausches in einem dezentralen Netzwerk abgewartet werden muss. Unter Berücksichtigung, dass der erzeugte Zufallswert beispielsweise in Spielen praktisch in Echtzeit benötigt wird, heißt das, dass ein Sabotage des Protokolls in dieser Phase möglich ist und die Vorteile des threshold-Systems verloren gehen. Dieses Problem ist zwar einfacher als das vorherige, erfordert jedoch dennoch die Entwicklung eines separaten Verfahrens zur Bildung der threshold-Gruppen, das wirtschaftlich geschützt werden muss, etwa durch Einlagen und das Slashing von Mitteln bei Teilnehmern, die das Protokoll nicht einhalten. Außerdem kann die BLS-Verifizierung mit einem akzeptablen Sicherheitsniveau einfach nicht in eine Standardtransaktion von EOS oder Ethereum integriert werden – es fehlt einfach die Zeit zur Verifizierung. Der Code der Verträge ist WebAssembly oder EVM und wird von einer virtuellen Maschine ausgeführt. Krypto-Funktionen sind derzeit noch nicht nativ implementiert und arbeiten mehrere Male langsamer als herkömmliche Kryptobibliotheken. Viele Protokolle erfüllen die Anforderungen einfach aufgrund der Schlüsselausgaben nicht, zum Beispiel 1024 und 2048 Bit für RSA, was 4-8 Mal mehr ist als die Standardtransaktion in Bitcoin und Ethereum.

Die Verfügbarkeit von Implementierungen in verschiedenen Programmiersprachen spielt eine Rolle – und davon gibt es nicht viele, insbesondere bei neuen Protokollen. Der Ansatz mit der Integration in den Konsens erfordert, dass das Protokoll in der Sprache der Plattform geschrieben wird, sodass Sie nach Go-Code für Geth, Rust für Parity und C++ für EOS suchen müssen. JavaScript-Code wird jeder suchen müssen, und da JavaScript und Kryptografie nicht die engsten Freunde sind, kann WebAssembly hilfreich sein, das jetzt definitiv als der nächste wichtige Internetstandard gilt.

Fazit

Ich hoffe, im Vorherigen Artikel konnten Sie überzeugen, dass die Generierung von Zufallszahlen auf der Blockchain für viele Aspekte des Lebens dezentraler Netzwerke von entscheidender Bedeutung ist. Mit diesem Artikel habe ich gezeigt, dass diese Aufgabe äußerst ehrgeizig und nicht einfach ist, aber es gibt bereits gute Lösungen. Allgemein kann das endgültige Design des Protokolls nur nach umfassenden Tests erfolgen, die alle Aspekte vom Setup bis hin zur Simulation von Ausfällen berücksichtigen. Daher werden Sie wahrscheinlich keine fertigen Rezepte in den Whitepapers der Teams oder in Artikeln finden, und wir werden in den nächsten ein bis zwei Jahren sicherlich nicht dazu bereit sein zu sagen: „Machen Sie es so, das ist sicher korrekt.“

Bis dahin für unser PVRB in der entwickelten Blockchain Haya, wir haben uns für die Verwendung von Threshold-BLS-Signaturen entschieden. Wir planen die Implementierung von PVRB auf Konsensniveau, da die Verifikation in Smart Contracts mit einem akzeptablen Sicherheitsniveau derzeit noch nicht möglich ist. Möglicherweise verwenden wir sofort zwei Ansätze: Zuerst die kostspielige Secret Sharing-Methode zur Erstellung eines langfristigen Random Seeds, welcher dann als Grundlage für die hochfrequente Generierung von Zufallszahlen durch deterministische Threshold-BLS-Signaturen dient; eventuell beschränken wir uns nur auf einen dieser Ansätze. Es ist bedauerlich, dass wir im Voraus nicht sagen können, wie das Protokoll aussehen wird. Positiv ist jedoch, dass, wie in der Wissenschaft, auch bei ingenieurtechnischen Aufgaben ein negatives Ergebnis immer noch ein Ergebnis ist. Jeder neue Versuch, ein Problem zu lösen, ist ein weiterer Schritt in der Forschung für alle, die sich mit der Problematik beschäftigen. Um die Anforderungen aus der Wirtschaft zu erfüllen, lösen wir eine konkrete praktische Aufgabe – die Bereitstellung einer zuverlässigen Entropiequelle für Spieleanwendungen. Deshalb müssen wir auch der Blockchain und insbesondere den Fragen der Kettenfinalität und der Governance des Netzwerks Beachtung schenken.

Obwohl wir noch keinen nachweislich stabilen PVRB in Blockchains sehen, der ausreichend lange genutzt wurde, um die Prüfungen echter Anwendungen, mehrfacher Audits, Lasten und natürlich realer Angriffe zu bestehen, zeigt die Anzahl der möglichen Wege, dass eine Lösung existiert. Irgendeiner dieser Algorithmen wird letztendlich das Problem lösen. Wir freuen uns darauf, die Ergebnisse zu teilen, und danken den anderen Teams, die ebenfalls an diesem Thema arbeiten, für ihre Artikel und Codes, die es den Ingenieuren ermöglichen, nicht zweimal in die gleiche Falle zu tappen.

Wenn Sie also auf einen Programmierer treffen, der einen dezentralen Zufallsmechanismus entwirft, seien Sie aufmerksam und fürsorglich. Bieten Sie bei Bedarf psychologische Unterstützung an 🙂.

Quelle: habr.com