Einführung

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

Wie beim Konzept des absolut sicheren chiffrierten Protokolls aus der Kryptographie versuchen die realen "Publicly Verifiable Random Beacon" (im Folgenden PVRB) Protokolle nur, der idealen Schematik möglichst nahe zu kommen, da sie in realen Netzwerken nicht in reiner Form anwendbar sind: Es muss streng über ein einzelnes Bit verhandelt werden, es sollten viele Runden stattfinden, und alle Nachrichten müssen ideal schnell und immer zugestellt werden. In realen Netzwerken ist dies natürlich nicht der Fall. Daher gibt es bei der Gestaltung von PVRB für bestimmte Aufgaben in modernen Blockchains, neben der Unfähigkeit, den erhaltenen Zufall und die kryptografische Sicherheit zu kontrollieren, auch viele rein architektonische und technische Probleme.

Die Blockchain selbst fungiert für PVRB im Grunde als Kommunikationsumgebung, in der Nachrichten=Transaktionen sind. Dies ermöglicht es, sich teilweise von Netzwerkproblemen, Nachrichtenverlusten und Problemen mit Zwischen-Software zu abstrahieren — all diese Risiken übernimmt das dezentrale Netzwerk, und der größte Wert für PVRB ist die Unmöglichkeit, eine bereits gesendete Transaktion zurückzuziehen oder zu beschädigen — dies verhindert, dass Teilnehmer die Teilnahme am Protokoll ablehnen, es sei denn, sie haben einen erfolgreichen Angriff auf den Konsens durchgeführt. Dieses Sicherheitsniveau ist akzeptabel, daher muss PVRB gegenüber Absprachen der Teilnehmer ebenso robust sein wie die Haupt-Blockchain. Außerdem deutet dies darauf hin, dass PVRB Teil des Konsenses sein muss, wenn sich das Netzwerk über die Haupt-Blockchain geeinigt hat, lassen Sie es uns gleichzeitig auch über den einzigen ehrlichen resultierenden Zufall einigen. Alternativ kann PVRB ein einfaches eigenständiges Protokoll sein, das durch einen Smart Contract implementiert wird und asynchron zum Blockchain und den Blöcken arbeitet. Beide Ansätze haben ihre Vor- und Nachteile, und die Wahl zwischen ihnen ist äußerst nicht trivial.

Zwei Möglichkeiten zur Implementierung von PVRB

Lassen Sie uns die zwei Varianten der Implementierung von PVRB näher beschreiben — die Standalone-Version, die mit einem vom Blockchain unabhängigen Smart Contract arbeitet, und die consensus-integrated — in das Protokoll integriert, gemäß dem sich das Netzwerk über die Blockchain und die einbezogenen Transaktionen einigt. In allen Fällen werde ich beliebte Blockchain-Engines im Sinn haben: Ethereum, EOS und alle, die ihnen in Bezug auf die Bereitstellung und Verarbeitung von Smart Contracts ähnlich sind.

Standalone-Vertrag

In dieser Variante ist PVRB ein Smart Contract, der Transaktionen von Random-Producern (im Folgenden RP) akzeptiert, sie verarbeitet, die Ergebnisse kombiniert und schließlich zu einem Wert gelangt, den jeder Benutzer aus diesem Vertrag erhalten kann. Dieser Wert muss nicht direkt im Vertrag gespeichert werden, sondern kann nur durch Daten dargestellt werden, aus denen deterministisch ein einziges Ergebnis des Randoms abgeleitet werden kann. In diesem Schema sind RP die Benutzer der Blockchain, und jeder kann am Generierungsprozess teilnehmen.

Die Variante mit dem Standalone-Vertrag ist gut:

Portabilität (Verträge können von Blockchain zu Blockchain getragen werden)
Einfachheit der Umsetzung und des Testens (Verträge lassen sich leicht schreiben und testen)
Bequemlichkeit bei der Umsetzung wirtschaftlicher Modelle (es ist einfach, einen Token zu erstellen, dessen Logik den Zielen von PVRB dient)
Möglichkeit der Ausführung in bereits bestehenden Blockchains

Es hat jedoch auch Nachteile:

starke Einschränkungen der Ressourcen bei Berechnungen, Transaktionsvolumen und Speicher (einfach gesagt CPU / RAM / IO)
Einschränkungen für Operationen innerhalb des Vertrags (nicht alle Befehle sind verfügbar, schwierig externe Bibliotheken zu integrieren)
Unmöglichkeit, einen schnelleren Nachrichtenaustausch zu organisieren als Transaktionen in die Blockchain aufgenommen werden

Diese Variante eignet sich zur Implementierung von PVRB, das in einem bereits bestehenden Netzwerk gestartet werden muss, das keine komplexe Kryptografie enthält und nicht viele Interaktionen erfordert.

Konsens-integriert

In dieser Variante ist PVRB im Code des Blockchain-Nodes implementiert, ist eingebettet oder arbeitet parallel zum Nachrichten Austausch zwischen den Nodes der Blockchain. Die Ergebnisse des Protokolls werden direkt in die erzeugten Blöcke geschrieben, während die Nachrichten des Protokolls über das P2P-Netzwerk zwischen den Nodes gesendet werden. Da das Protokoll Zahlen als Ergebnis hat, die in den Blöcken festgehalten werden müssen, muss das Netzwerk einen Konsens darüber erreichen. Das bedeutet, dass die PVRB-Nachrichten wie auch die Transaktionen von den Nodes validiert und in die Blöcke aufgenommen werden müssen, damit jedes Netzwerk-Mitglied die Einhaltung des PVRB-Protokolls validieren kann. Dies führt automatisch zu einer offensichtlichen Lösung: Wenn das Netzwerk sich über den Konsens bezüglich eines Blocks und der darin enthaltenen Transaktionen einigt, dann sollte PVRB Teil des Konsenses sein und kein eigenständiges Protokoll. Andernfalls könnte es sein, dass ein Block aus Sicht des Konsenses gültig ist, aber das PVRB-Protokoll nicht eingehalten wird. Aus Sicht von PVRB könnte der Block dann nicht akzeptiert werden. Wenn also die „konsens-integrierte“ Variante gewählt wird, wird PVRB zu einem wichtigen Teil des Konsenses.

Bei der Beschreibung der Implementierungen von PVRB auf Konsensebene im Netzwerk können die Fragen zur Finalität auf keinen Fall umgangen werden. Finalität ist ein Mechanismus, der in deterministischen Konsensen verwendet wird, um einen Block (und die ihn führende Kette) zu fixieren, der final ist und niemals verworfen wird, selbst wenn ein paralleler Fork entsteht. Zum Beispiel gibt es in Bitcoin keinen solchen Mechanismus – wenn eine Kette mit größerer Schwierigkeit veröffentlicht wird, ersetzt sie jede weniger komplexe, unabhängig von der Länge der Ketten. In EOS hingegen sind die sogenannten Last Irreversible Blocks final, die im Durchschnitt alle 432 Blöcke erscheinen (12*21 + 12*15, pre-vote + pre-commit). Dieser Prozess ist im Wesentlichen das Warten auf 2/3 der Unterschriften der Block-Produzenten (BP). Bei dem Auftreten von Forks, die älter sind als der letzte LIB, werden sie einfach verworfen. Dieser Mechanismus ermöglicht es, garantiert zu behaupten, dass eine Transaktion in die Blockchain aufgenommen wurde und niemals zurückgezogen wird, egal welche Ressourcen der Angreifer hat. Außerdem sind finalisierte Blöcke die Blöcke, die von 2/3 der BP in Hyperledger, Tendermint und anderen pBFT-basierten Konsensen unterschrieben wurden. Zudem ergibt es Sinn, ein Protokoll zur Sicherstellung der Finalität als Erweiterung über dem Konsens zu gestalten, da es asynchron mit der Produktion und Veröffentlichung von Blöcken arbeiten kann. Hier ist eine gute Artikel über die Endgültigkeit in Ethereum.

Die Endgültigkeit ist für Nutzer von entscheidender Bedeutung, da sie sonst Opfer einer "Double Spend"-Attacke werden können, wenn BP Blöcke "vorhält" und diese veröffentlicht, nachdem das Netzwerk eine gute Transaktion "gesehen" hat. Wenn es keine Endgültigkeit gibt, ersetzt der veröffentlichte Fork den Block mit der "guten" Transaktion durch einen anderen aus dem "schlechten" Fork, in dem dieselben Mittel auf die Adresse des Angreifers übertragen werden. Im Falle von PVRB werden die Anforderungen an die Endgültigkeit sogar noch strenger, da der Aufbau von Forks für PVRB die Möglichkeit für den Angreifer bedeutet, mehrere Varianten von Zufällen vorzubereiten, um den vorteilhaftesten zu veröffentlichen und die mögliche Angriffszeit zu begrenzen - eine gute Lösung.

Daher ist die beste Lösung, PVRB und Endgültigkeit in ein Protokoll zu integrieren - dann ist der finalisierte Block = finalisierter Zufall, und das ist genau das, was erreicht werden sollte. Jetzt erhalten die Spieler garantierten Zufall in N Sekunden und können sicher sein, dass er nicht zurückgesetzt oder erneut gespielt werden kann.

Die Option mit dem konsens-integrierten Ansatz ist gut:

mit der Möglichkeit der asynchronen Umsetzung in Bezug auf die Blockproduktion - Blöcke werden wie gewohnt produziert, aber parallel dazu kann das PVRB-Protokoll arbeiten, das Zufälle nicht bei jedem Block generiert.
mit der Möglichkeit, selbst schwere Kryptografie zu implementieren, ohne die Einschränkungen, die bei Smart Contracts bestehen.
mit der Möglichkeit, den Nachrichten Austausch schneller zu organisieren, als Transaktionen in die Blockchain aufgenommen werden, z.B. kann ein Teil des Protokolls zwischen Knoten arbeiten, ohne Nachrichten im Netzwerk zu verbreiten.

Es hat jedoch auch Nachteile:

Schwierigkeiten beim Testen und Entwickeln - es muss mit Netzwerkfehlern, ausgefallenen Knoten und Hardforks des Netzwerks emuliert werden.
Fehler in der Implementierung erfordern einen Hardfork des Netzwerks.

Beide Implementierungsmethoden von PVRB haben ihre Berechtigung, aber die Umsetzung auf Smart Contracts in modernen Blockchains ist dennoch ziemlich stark durch die Rechenressourcen eingeschränkt, und jeder Übergang zu ernsthafter Kryptografie ist oft einfach unmöglich. Und ernsthafte Kryptografie wird benötigt, wie im Folgenden demonstriert wird. Obwohl dieses Problem eindeutig zeitweilig ist, wird ernsthafte Kryptografie in Verträgen benötigt, um viele Aufgaben zu lösen, und allmählich erscheint sie (z.B. systematische Verträge für zkSNARKs in Ethereum).

Die Blockchain, die einen transparenten und zuverlässigen Kommunikationskanal des Protokolls gewährleistet, macht dies nicht kostenlos. Jedes dezentrale Protokoll muss die Möglichkeit eines Sybil-Angriffs berücksichtigen, da jede Aktion von einer Vielzahl von Konten rechtmäßig durchgeführt werden kann. Daher müssen beim Entwurf die Fähigkeiten der Angreifer zur Schaffung einer beliebigen Anzahl von Teilnehmern berücksichtigt werden, die im Bunde agieren.

PVRB und Blockvariablen.

Ich habe nicht gelogen, als ich sagte, dass es bislang keinen guten PVRB gibt, der durch viele Glücksspielanwendungen überprüft wurde, in Blockchains implementiert. Woher kommt dann die große Anzahl an Glücksspielanwendungen in Ethereum und EOS? Das überrascht mich genauso wie euch, woher haben sie in einer vollständig deterministischen Umgebung so viele "robuste" Zufallswerte?

Die bevorzugte Methode, um Zufall in der Blockchain zu erzeugen, besteht darin, eine "unvorhersehbare" Information aus dem Block zu nehmen und auf dieser Basis Zufall zu generieren, indem man einen oder mehrere Werte einfach hash-iert. Ein guter Artikel über die Probleme solcher Schemata. hier. Man kann eines der "unvorhersehbaren" Werte im Block nehmen, wie zum Beispiel den Block-Hash, die Anzahl der Transaktionen, die Netzwerk-Schwierigkeit und andere im Voraus unbekannte Werte. Dann hash-iert man sie, einen oder mehrere, und theoretisch sollte das der wirklich wahre Zufall sein. Man könnte sogar im Whitepaper hinzufügen, dass euer Schema "post-quantum-sicher" ist (da es quantensichere Hash-Funktionen gibt :)).

Aber selbst quantensichere Hashes sind leider nicht ausreichend. Das Geheimnis liegt in den Anforderungen an den PVRB, an die ich aus dem vorherigen Artikel erinnere:

Das Ergebnis muss eine nachweisbar gleichmäßige Verteilung aufweisen, d.h. es muss auf nachweisbar robuster Kryptografie basieren.
Es ist unmöglich, irgendein Bit des Ergebnisses zu kontrollieren. Folglich kann das Ergebnis nicht im Voraus vorhergesagt werden.
Der Protokollgenerator darf nicht durch Nicht-Teilnahme am Protokoll oder durch Überlastung des Netzwerks mit Angreifer-Nachrichten sabotiert werden.
Alles oben Genannte muss gegenüber Absprachen einer zulässigen Anzahl unredlicher Teilnehmer des Protokolls robust sein (zum Beispiel 1/3 der Teilnehmer).

In diesem Fall wird nur die Anforderung 1 eingehalten, und 2 wird nicht eingehalten. Durch das Hashen von unvorhersehbaren Werten aus dem Block erhalten wir eine gleichmäßige Verteilung und gute Zufallswerte. Aber BP hat mindestens die Möglichkeit, "den Block zu veröffentlichen oder nicht". So kann BP mindestens zwischen ZWEI Varianten von Zufall wählen: "seinen" und den, der entsteht, wenn jemand anderes den Block erstellt. BP kann im Voraus "nachsehen", was passiert, wenn er den Block veröffentlicht, und einfach entscheiden, ob er das tun will oder nicht. So kann er, wenn er zum Beispiel "gerade-ungerade" oder "rot/schwarz" beim Roulette spielt, den Block nur veröffentlichen, wenn er einen Gewinn sieht. Das macht auch die Strategie der Verwendung des Hashes des Blocks "aus der Zukunft" unbrauchbar. In diesem Fall wird gesagt, dass "der Zufall verwendet wird, der durch das Hashen der aktuellen Daten und des Hashes des zukünftigen Blocks mit einer Höhe von beispielsweise N + 42 entsteht, wobei N die aktuelle Blockhöhe ist. Das verstärkt das Schema ein wenig, lässt BP aber dennoch, wenn auch in der Zukunft, wählen, ob er den Block zurückhalten oder veröffentlichen möchte.

Die Software von BP wird in diesem Fall komplizierter, aber nicht stark. Einfach bei der Validierung und Einfügung von Transaktionen in den Block erfolgt eine schnelle Überprüfung, ob es einen Gewinn geben wird, und möglicherweise die Anpassung eines Transaktionsparameters, um eine hohe Gewinnwahrscheinlichkeit zu erzielen. Dabei ist es nahezu unmöglich, einen intelligenten BP bei solchen Manipulationen zu erwischen; man kann jedes Mal neue Adressen verwenden und peu à peu gewinnen, ohne Verdacht zu erregen.

Daher sind die Methoden, die Informationen aus dem Block verwenden, nicht als universelle Implementierung von PVRB geeignet. In einer eingeschränkten Variante, mit Beschränkungen auf die Einsatzgröße, Begrenzungen der Spieleranzahl und/oder KYC-Registrierung (um zu verhindern, dass ein Spieler mehrere Adressen nutzen kann), können diese Systeme für kleine Spiele funktionieren, aber nicht mehr.

PVRB und Commit-Reveal.

Nun, danke dem Hashing und zumindest der relativen Unvorhersehbarkeit des Blockhashes und anderer Variablen. Wenn das Problem des Front-Running von Minern gelöst wird, sollte etwas brauchbareres entstehen. Lassen Sie uns die Benutzer in dieses Schema einbeziehen – sie sollten auch den Zufall beeinflussen: Jeder Mitarbeiter des Supports wird Ihnen sagen, dass das Unberechenbarste in IT-Systemen die Handlungen der Benutzer sind 🙂

Ein naives Schema, bei dem die Benutzer einfach zufällige Zahlen senden und das Ergebnis beispielsweise als Hash ihrer Summe berechnet wird, ist nicht geeignet. In diesem Fall kann der letzte Spieler, der spielt, durch die Auswahl seiner eigenen Zufallszahl kontrollieren, welches Ergebnis entsteht. Daher wird ein sehr weit verbreitetes Muster, das als Commit-Reveal bekannt ist, verwendet. Die Teilnehmer senden zunächst Hashes ihrer Zufallszahlen (Commits) und öffnen dann die Zufallszahlen selbst (Reveals). Die Phase „Reveal“ beginnt erst, nachdem die erforderlichen Commits gesammelt wurden, sodass die Teilnehmer genau die Zufallszahl senden können, deren Hash sie zuvor gesendet haben. Jetzt kombinieren wir all dies mit den Blockparametern, wobei wir besser eine aus der Zukunft auswählen (die Zufallszahl kann nur in einem der zukünftigen Blöcke bekannt gegeben werden), und voilà – die Zufallszahl ist bereit! Jetzt hat jeder Spieler Einfluss auf die resultierende Zufallszahl und kann den böswilligen BP „besiegen“, indem er dessen Zufallszahl mit seiner, im Voraus unbekannten, Zufallszahl überdeckt... Außerdem kann man einen Schutz gegen das Sabotieren des Protokolls hinzufügen, indem man ein Nicht-Reveal in der Reveal-Phase vorschreibt – indem man einfach verlangt, dass beim Commit eine gewisse Summe angehängt wird – eine Sicherheitskaution, die nur während des Reveal-Prozesses zurückgegeben wird. In diesem Fall wäre es unvorteilhaft, einen Commit zu machen und keinen Reveal durchzuführen.

Es war ein guter Versuch, und solche Systeme gibt es auch in Gaming DApps, aber leider reicht das wieder nicht aus. Jetzt kann das Ergebnis nicht nur von einem Miner beeinflusst werden, sondern auch von jedem Teilnehmer des Protokolls. Der Wert selbst kann nach wie vor kontrolliert werden, jedoch mit geringerer Variabilität und gegen Bezahlung, aber wie im Fall des Miners kann der Random-Producer (RP) entscheiden, ob er den Reveal macht und weiterhin aus mindestens zwei zufälligen Optionen auswählen.
Aber es gibt die Möglichkeit, diejenigen zu bestrafen, die einen Commit machen und keinen Reveal durchführen, und dieses Schema wird noch nützlich sein. Ihre Einfachheit ist ein ernsthaftes Plus – ernsthaftere Protokolle erfordern wesentlich leistungsstärkere Berechnungen.

PVRB und deterministische Signaturen.

Es gibt noch einen weiteren Weg, um RP zu einem pseudorandomisierten Wert zu bringen, auf den er keinen Einfluss nehmen kann, wenn ihm ein „Vorbild“ gegeben wird — dies ist eine deterministische Signatur. Eine solche Signatur ist zum Beispiel RSA, und nicht ECS. Wenn RP ein Schlüsselpaar hat: RSA und ECC, und er mit seinem privaten Schlüssel einen bestimmten Wert signiert, dann erhält er im Fall von RSA EINE UND NUR EINE Signatur, während er im Fall von ECS eine beliebige Anzahl von unterschiedlichen gültigen Signaturen generieren kann. Dies geschieht, weil bei der Erstellung einer ECS-Signatur eine zufällige Zahl verwendet wird, die vom Unterzeichner gewählt wird, und diese kann nach Belieben ausgewählt werden, wodurch der Unterzeichner die Möglichkeit hat, eine von mehreren Signaturen auszuwählen. Im Fall von RSA: „ein Eingabewert“ + „ein Schlüsselpaar“ = „eine Signatur“. Es ist nicht möglich vorherzusagen, welche Signatur von einem anderen RP erstellt wird, daher kann PVRB mit deterministischen Signaturen durch Kombination von RSA-Signaturen mehrerer Teilnehmer organisiert werden, die denselben Wert signiert haben. Zum Beispiel — der vorherige Zufallswert. In einem solchen Schema werden viele Ressourcen gespart, da die Signaturen gleichzeitig auch eine Bestätigung der korrekten Verhaltensweise gemäß dem Protokoll und eine Quelle für Zufallswerte darstellen.

Dennoch bleibt selbst mit deterministischen Signaturen das Schema anfällig für das „Last Actor“-Problem. Der letzte Teilnehmer kann immer noch entscheiden, ob er seine Signatur veröffentlicht oder nicht, und somit das Ergebnis kontrollieren. Man kann das Schema weiterentwickeln, Hashes von Blöcken hinzufügen, Runden erstellen, um das Ergebnis im Voraus unvorhersehbar zu machen, aber all diese Tricks lassen das Problem des Einflusses eines einzelnen Teilnehmers auf das kollektive Ergebnis in einer untrusted Umgebung ungelöst und funktionieren nur unter wirtschaftlichen und zeitlichen Einschränkungen. Darüber hinaus ist die Größe der RSA-Schlüssel (1024 und 2048 Bit) recht groß, während die Größe für Blockchain-Transaktionen ein äußerst wichtiger Parameter ist. Offenbar ist es nicht einfach, das Problem zu lösen, also gehen wir weiter.

In der Kryptographie gibt es Systeme, die es einem Netzwerk ermöglichen können, sich auf genau einen Wert PVRB zu einigen, wobei solche Systeme gegen böswillige Handlungen eines Teils der Teilnehmer robust sind. Ein nützliches Protokoll, mit dem man sich vertraut machen sollte, ist das Shamir Secret Sharing. Es dient dazu, ein Geheimnis (zum Beispiel einen geheimen Schlüssel) in mehrere Teile aufzuteilen und diese Teile an N Teilnehmer zu verteilen. Das Geheimnis wird so verteilt, dass für die Wiederherstellung M Teile aus N ausreichend sind, wobei es beliebige M Teile sein können. Einfach ausgedrückt, wenn man einen Graphen einer unbekannten Funktion hat, tauschen die Teilnehmer Punkte auf dem Graphen aus, und nach Erhalt von M Punkten kann die gesamte Funktion wiederhergestellt werden.
Eine gute Erklärung findet sich in wiki und es ist praktisch, damit zu experimentieren, um das Protokoll im Kopf durchzugehen, auf Demo Seite.

Wäre das FSSS-Schema (Fiat-Shamir Secret Sharing) in seiner reinsten Form anwendbar – das wäre ein unzerstörbarer PVRB. In der einfachsten Variante könnte das Protokoll so aussehen:

Jeder Teilnehmer generiert einen eigenen Zufallswert und verteilt Shares davon an die anderen Teilnehmer.
Jeder Teilnehmer gibt seine Anteile der Geheimnisse der anderen Teilnehmer preis.
Wenn der Teilnehmer mehr als M Shares hat, kann die Zahl dieses Teilnehmers berechnet werden, und sie wird eindeutig sein, unabhängig von der Auswahl der aufgedeckten Teilnehmer.
Die Kombination der aufgedeckten Zufallswerte ist der gesuchte PVRB.

Hier hat ein einzelner Teilnehmer keinen Einfluss mehr auf die Ergebnisse des Protokolls, es sei denn, seine Teilnahme ist entscheidend für das Erreichen des Schwellenwerts für die Offenlegung der Zufallswerte. Daher funktioniert dieses Protokoll, solange genügend Teilnehmer, die dem Protokoll folgen, und verfügbare RP vorhanden sind, und erfüllt die Anforderungen an kryptographische Robustheit und ist gegen das Problem des "letzten Akteurs" resistent.

Das könnte die ideale Variante sein, dieses PVRB-Schema auf der Basis von Secret Sharing nach Fiat-Shamir wird beispielsweise in dieser einem Artikel beschrieben. Aber wie bereits erwähnt, wenn man versucht, es direkt im Blockchain-Bereich 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öffentlichen Shares des Teilnehmers: Code. Der Code zeigt, dass die Validierung des Proofs mehrere skalare Multiplikationen erfordert und die Zahlen sehr groß sind. Dabei muss man verstehen, dass die Verifizierung in Blockchains zum Zeitpunkt erfolgt, an dem der Blockproduzent die Transaktion verarbeitet, und allgemein sollte jeder Teilnehmer die Korrektheit des Protokolls leicht überprüfen können, weshalb die Anforderungen an die Geschwindigkeit der Verifizierungsfunktion sehr hoch sind. In dieser Variante hat sich herausgestellt, dass sie nicht funktionierte, da die Verifizierung die Transaktionszeitgrenze (0,5 Sek.) nicht einhielt.

Die Effizienz der Verifizierung ist eines der wichtigsten Anforderungen an die Nutzung praktisch aller fortgeschrittenen kryptografischen Schemata in der Blockchain. Die Erstellung von Proofs, die Vorbereitung von Nachrichten — diese Verfahren können off-chain ausgelagert und auf Hochleistungssystemen durchgeführt werden, aber die Verifizierung kann nicht umgangen werden — dies ist ein weiteres wichtiges Anforderung an PVRB.

PVRB und Threshold-Signaturen

Nachdem wir uns mit dem Schema der geheimen Teilung vertraut gemacht hatten, eröffneten wir eine ganze Klasse von Protokollen, die durch das Schlüsselwort „Threshold“ verbunden sind. Wenn zur Offenlegung bestimmter Informationen die Teilnahme von M ehrlichen Teilnehmern aus N erforderlich ist und die Gruppe der ehrlichen Teilnehmer beliebige Teilmengen von N sein kann, spricht man von „Threshold“-Schemata. Diese ermöglichen es, das Problem des „letzten Akteurs“ zu lösen; jetzt, wenn ein Angreifer seinen Teil des Geheimnisses nicht offenbart, wird dies von einem anderen ehrlichen Teilnehmer erledigt. Diese Schemata ermöglichen es, sich auf einen und nur einen Wert zu einigen, selbst wenn einige Teilnehmer das Protokoll sabotieren.

Die Kombination aus deterministischen Signaturen und Threshold-Schemata ermöglicht die Entwicklung eines sehr benutzerfreundlichen und vielversprechenden Schemas zur Implementierung von PVRB - dies sind deterministische Threshold-Signaturen. Hier ist Artikel Über verschiedene Anwendungen von Threshold-Signaturen, und hier ist ein weiteres gutes Beispiel Longread von Dash.

Im letzten Artikel werden BLS-Signaturen beschrieben (BLS steht für Boneh-Lynn-Shacham, hier Artikel ), die eine sehr wichtige und äußerst praktische Eigenschaft für Programmierer besitzen – öffentliche, geheime, öffentliche Schlüssel und BLS-Unterschriften können durch einfache mathematische Operationen miteinander kombiniert werden, wobei ihre Kombinationen gültige Schlüssel und Unterschriften bleiben, was es ermöglicht, viele Unterschriften in einer und viele öffentliche Schlüssel in einem zu aggregieren. Sie zeichnen sich auch durch Determinismus aus und liefern bei denselben Eingabedaten immer dasselbe Ergebnis. Aufgrund dieser Eigenschaft sind die Kombinationen von BLS-Unterschriften selbst gültige Schlüssel, was es ermöglicht, ein Szenario zu realisieren, bei dem M von N Teilnehmern eine einzige und eindeutige Unterschrift erstellen, die deterministisch, öffentlich verifizierbar und unvorhersehbar ist, bis sie vom M-ten Teilnehmer geöffnet wird.

Im Schema mit Schwellenwert-BLS-Unterschriften unterschreibt jeder Teilnehmer mit BLS etwas (zum Beispiel den vorherigen Zufallswert), und die gesamte 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 es, viele interessante Algorithmen zu realisieren, die beispielsweise eine effiziente Aggregation von Nachrichten im Protokoll ermöglichen.

Wenn Sie also PVRB in Ihrer Blockchain implementieren, wird es mit großer Wahrscheinlichkeit auf das Schema der BLS-Schwellenwertunterschriften hinauslaufen, das bereits von mehreren Projekten genutzt wird. Zum Beispiel DFinity (hier Benchmark, das das Schema umsetzt, und hier ein Beispiel für die Implementierung von verifiable secret sharing), oder Keep.network (hier ist ihr Zufallsbeacon yellowpaper, aber hier ist Beispiel des Smart Contracts, der das Protokoll bedient).

Implementierung von PVRB

Leider sehen wir immer noch kein fertiges, in den PVRB-Blockchains implementiertes Protokoll, das seine Sicherheit und 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, und dezentrale Systeme sind in allen Rechenressourcen streng begrenzt: CPU, Speicher, Speicherplatz, I/O. Das Design von PVRB ist eine Kombination verschiedener Protokolle, um schließlich etwas zu schaffen, das wenigstens den Anforderungen an eine lebensfähige Blockchain entspricht. Ein Protokoll rechnet effizienter, benötigt aber mehr Nachrichten zwischen RP, während ein anderes extrem wenige Nachrichten erfordert, aber die Erstellung des Proofs kann eine Aufgabe von vielen Minuten oder sogar Stunden sein.

Ich werde die Faktoren auflisten, die Sie bei der Auswahl eines qualitativ hochwertigen PVRB berücksichtigen sollten:

Kryptografische Robustheit. Ihr PVRB sollte strikt unvoreingenommen sein und keine Kontrolle über ein einzelnes Bit zulassen. In einigen Schemen ist dies nicht der Fall, also rufen Sie einen Kryptografen.
Das Problem des "letzten Akteurs". Ihr PVRB sollte gegen Angriffe geschützt sein, bei denen ein Angreifer, der einen oder mehrere RP kontrolliert, eine von zwei Ergebnisoptionen auswählen kann.
Das Problem der Protokollsabottierung. Ihr PVRB sollte gegen Angriffe geschützt sein, bei denen ein Angreifer, der einen oder mehrere RP kontrolliert, entscheidet, ob es zufällig ist oder nicht, und garantierte oder mit einer bestimmten Wahrscheinlichkeit darauf einwirken kann.
Das Problem der Nachrichtenmenge. Ihre RP sollten eine minimale Anzahl von Nachrichten an die Blockchain senden und synchronisierte Aktionen wie "Ich habe Informationen gesendet, warte auf eine Antwort von einem bestimmten Teilnehmer" maximal vermeiden. In P2P-Netzwerken, insbesondere geografisch verteilten, sollte man nicht auf eine schnelle Antwort hoffen.
Das Problem der Berechnungskomplexität. Die Verifizierung jeder Phase von PVRB on-chain sollte extrem einfach sein, da sie von allen vollständigen Knoten des Netzwerks durchgeführt wird. Wenn die Implementierung mittels Smart Contracts erfolgt, sind die Anforderungen an die Geschwindigkeit sehr streng.
Das Problem der Verfügbarkeit und Livelihood. Ihr PVRB sollte darauf abzielen, stabil zu bleiben, auch wenn ein Teil des Netzwerks für eine gewisse Zeit nicht verfügbar ist und einige RP einfach nicht mehr funktionieren.
Das Problem des vertrauenswürdigen Setups und der anfänglichen Verteilung der Schlüssel.. Wenn Ihre PVRB das primäre Setup-Protokoll verwendet, ist das eine ganz andere große und ernste Geschichte. Hier ist Beispiel. Wenn die Teilnehmer vor dem Beginn des Protokolls einander ihre Schlüssel mitteilen müssen, ist das ebenfalls ein Problem, wenn sich die Teilnehmergruppe ändert.
Entwicklungsprobleme. Die Verfügbarkeit von Bibliotheken in den benötigten Sprachen, deren Sicherheit und Leistung, die Öffentlichkeit, komplexe Tests usw.

Zum Beispiel hat es bei der Threshold-BLS-Signatur ein erhebliches Problem – bevor sie mit der Arbeit beginnen können, müssen die Teilnehmer einander unbedingt die Schlüssel aushändigen und eine Gruppe organisieren, innerhalb derer der Threshold funktioniert. Das bedeutet, dass man mindestens eine Runde des Austauschs in einem dezentralisierten Netzwerk abwarten muss, und wenn man bedenkt, dass der erzeugte Zufallswert, zum Beispiel, in Spielen praktisch in Echtzeit benötigt wird, bedeutet dies, dass Sabotage des Protokolls in diesem Stadium möglich ist und die Vorteile des Threshold-Systems verloren gehen. Dieses Problem ist bereits leichter als das vorherige, erfordert aber dennoch die Entwicklung eines separaten Verfahrens zur Bildung von Threshold-Gruppen, das aus wirtschaftlichen Gründen durch Einlagen und das Bestrafen (Slashing) von Teilnehmern, die sich nicht an das Protokoll halten, geschützt werden muss. Zudem lässt sich die BLS-Verifizierung mit einem akzeptablen Sicherheitslevel einfach nicht in eine Standardtransaktion von EOS oder Ethereum integrieren – es fehlt einfach die Zeit für die Verifizierung. Der Code von Smart Contracts ist WebAssembly oder EVM und wird von einer virtuellen Maschine ausgeführt. Kryptografische Funktionen sind bisher nicht nativ implementiert und arbeiten um ein Vielfaches langsamer als gewöhnliche kryptographische Bibliotheken. Viele Protokolle sind aufgrund der Größe von Schlüsseln nicht geeignet, beispielsweise 1024 und 2048 Bit für RSA, was 4-8 Mal mehr ist als die Standardtransaktion in Bitcoin und Ethereum.

Es spielt auch eine Rolle, ob Implementierungen in verschiedenen Programmiersprachen vorhanden sind – davon gibt es nur wenig, insbesondere für neue Protokolle. Die Option mit der Integration in den Konsens erfordert, dass das Protokoll in der Sprache der Plattform geschrieben wird, daher muss man nach Code in Go für geth, in Rust für Parity, in C++ für EOS suchen. JavaScript-Code wird von allen gesucht werden müssen, und da JavaScript und Kryptographie nicht gerade enge Freunde sind, wird WebAssembly helfen, das now eindeutig den Anspruch auf die Rolle des nächsten wichtigen Internetstandards erhebt.

Fazit

Ich hoffe, dass in der vorherigen Artikel Ich konnte Sie davon überzeugen, dass die Generierung von Zufallszahlen auf der Blockchain für viele Aspekte des Lebens dezentraler Netzwerke von entscheidender Bedeutung ist, und mit diesem Artikel habe ich gezeigt, dass diese Aufgabe äußerst ehrgeizig und komplex ist, aber gute Lösungen bereits existieren. Im Allgemeinen ist das endgültige Design des Protokolls nur nach umfangreichen Tests möglich, die alle Aspekte vom Setup bis zur Simulation von Ausfällen berücksichtigen. Daher werden Sie wahrscheinlich keine fertigen Rezepte in den Whitepapers von Teams oder in Artikeln finden, und wir werden uns in den nächsten ein bis zwei Jahren sicherlich nicht dazu entschließen, „tun Sie dies, das ist definitiv richtig“ zu schreiben.

Bislang für unser PVRB in der entwickelten Blockchain Haya, haben wir uns auf die Anwendung von threshold BLS-Signaturen geeinigt und planen, PVRB auf Konsens-Ebene umzusetzen, da eine Verifizierung in Smart Contracts mit angemessenem Sicherheitsniveau derzeit noch nicht möglich ist. Es ist möglich, dass wir sofort zwei Schemes verwenden: zuerst das teure secret sharing zur Erstellung eines langfristigen random_seed, das wir dann als Grundlage für die hochfrequente Generierung von Zufallszahlen mit deterministischen threshold BLS-Signaturen verwenden; eventuell beschränken wir uns auf nur eines der Schemes. Vorab zu sagen, wie das Protokoll aussehen wird, ist leider unmöglich. Positiv ist lediglich, dass wie in der Wissenschaft bei ingenieurtechnischen Aufgaben ein negatives Ergebnis ebenfalls ein Ergebnis ist und jeder neue Versuch, eine Aufgabe zu lösen, eine weitere Stufe für die Forschung aller ist, die sich mit dem Problem befassen. Um die Anforderungen des Geschäfts zu erfüllen, lösen wir ein konkretes praktisches Problem – die Bereitstellung einer zuverlässigen Quelle von Entropie für Spieleanwendungen. Daher müssen wir auch der Blockchain selbst Beachtung schenken, insbesondere den Fragen der Kettenfinalität und der Governance des Netzwerks.

Auch wenn wir bisher kein nachgewiesenes, robustes PVRB in Blockchains sehen, das ausreichend lange genutzt wurde, um die Prüfungen echter Anwendungen, mehrerer Audits, Belastungen und natürlich realer Angriffe zu bestehen, belegt die Anzahl der möglichen Wege, dass eine Lösung existiert und einer dieser Algorithmen letztendlich das Problem lösen wird. Wir freuen uns darauf, die Ergebnisse zu teilen und danken den anderen Teams, die sich ebenfalls mit diesem Thema befassen, für ihre Artikel und ihren Code, die es Ingenieuren ermöglichen, nicht zweimal in die gleichen Fallen zu tappen.

Wenn Sie also einem Programmierer begegnen, der ein dezentrales Random-Tool entwirft, seien Sie vorsichtig und aufmerksam. Bei Bedarf leisten Sie psychologische Hilfe 🙂

Quelle: habr.com