Einführung

function getAbsolutelyRandomNumer() {
        return 4; // returns absolutely random number!
}

Wie beim Konzept einer absolut starken Verschlüsselung aus der Kryptographie versuchen echte „Publicly Verifiable Random Beacon“ (im Folgenden PVRB) Protokolle nur, dem idealen Schema so nahe wie möglich zu kommen, denn In realen Netzwerken ist es in seiner reinen Form nicht anwendbar: Es ist notwendig, sich strikt auf ein Bit zu einigen, es muss viele Runden geben und alle Nachrichten müssen absolut schnell sein und immer zugestellt werden. Dies ist in realen Netzwerken natürlich nicht der Fall. Daher treten beim Entwurf von PVRBs für bestimmte Aufgaben in modernen Blockchains neben der Unmöglichkeit, die resultierende Zufälligkeit und kryptografische Stärke zu kontrollieren, noch viele weitere rein architektonische und technische Probleme auf.

Für PVRB ist die Blockchain selbst im Wesentlichen ein Kommunikationsmedium, bei dem Nachrichten = Transaktionen sind. Dadurch können Sie teilweise von Netzwerkproblemen, der Nichtzustellung von Nachrichten und Problemen mit der Middleware abstrahieren – all diese Risiken werden vom dezentralen Netzwerk übernommen, und sein Hauptwert für PVRB ist die Unfähigkeit, eine bereits gesendete Transaktion zu widerrufen oder zu beschädigen – das ist der Fall Erlauben Sie den Teilnehmern nicht, die Teilnahme am Protokoll zu verweigern, es sei denn, sie haben einen erfolgreichen Angriff auf den Konsens durchgeführt. Dieses Maß an Sicherheit ist akzeptabel, daher sollte PVRB genauso resistent gegen Absprachen der Teilnehmer sein wie die Haupt-Blockchain-Kette. Dies deutet auch darauf hin, dass der PVRB Teil des Konsenses sein muss, wenn sich das Netzwerk auf die Hauptblockchain einigt, selbst wenn es sich auch auf den einzig fairen resultierenden Zufall einigt. Oder PVRB ist einfach ein eigenständiges Protokoll, das durch einen Smart Contract implementiert wird und asynchron in Bezug auf die Blockchain und die Blöcke arbeitet. Beide Methoden 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 zwei Möglichkeiten zur Implementierung von PVRB genauer beschreiben – die eigenständige Version, die mithilfe eines von der Blockchain unabhängigen Smart Contract funktioniert, und die in das Protokoll integrierte konsensintegrierte Version, nach der sich das Netzwerk auf die Blockchain und das Netzwerk einigt einzubeziehende Transaktionen. In allen Fällen meine ich beliebte Blockchain-Engines: Ethereum, EOS und alle, die ihnen in der Art und Weise ähneln, wie sie Smart Contracts hosten und verarbeiten.

Eigenständiger Vertrag

In dieser Version handelt es sich bei PVRB um einen Smart Contract, der Transaktionen von Zufallsproduzenten (im Folgenden RP genannt) akzeptiert, diese verarbeitet, die Ergebnisse kombiniert und dadurch zu einem bestimmten Wert gelangt, den jeder Benutzer aus diesem Vertrag erhalten kann. Dieser Wert wird möglicherweise nicht direkt im Vertrag gespeichert, sondern nur durch Daten repräsentiert, aus denen ein und nur ein Wert des resultierenden Zufalls deterministisch ermittelt werden kann. In diesem Schema sind RPs Benutzer der Blockchain, und jeder kann am Generierungsprozess teilnehmen.

Die Option mit Standalone-Vertrag ist gut:

• Portabilität (Verträge können von Blockchain zu Blockchain gezogen werden)
• Einfache Implementierung und Tests (Verträge sind einfach zu schreiben und zu testen)
• Bequemlichkeit bei der Umsetzung von Wirtschaftsplänen (es ist einfach, einen eigenen Token zu erstellen, dessen Logik den Zwecken von PVRB dient)
• Möglichkeit des Starts auf bereits funktionierenden Blockchains

Es hat auch Nachteile:

• Starke Einschränkungen bei Rechenressourcen, Transaktionsvolumen und Speicher (mit anderen Worten: CPU/Speicher/IO)
• Einschränkungen des Betriebs innerhalb des Vertrags (nicht alle Anweisungen sind verfügbar, es ist schwierig, externe Bibliotheken anzubinden)
• Unfähigkeit, Nachrichten schneller zu organisieren, als Transaktionen in die Blockchain aufgenommen werden

Diese Option eignet sich für die Implementierung eines PVRB, der in einem vorhandenen Netzwerk ausgeführt werden muss, keine komplexe Kryptografie enthält und keine große Anzahl von Interaktionen erfordert.

Konsensintegriert

In dieser Version ist PVRB im Blockchain-Knotencode implementiert, integriert oder läuft parallel zum Nachrichtenaustausch zwischen Blockchain-Knoten. Die Ergebnisse des Protokolls werden direkt in die erzeugten Blöcke geschrieben und Protokollnachrichten werden über das P2P-Netzwerk zwischen Knoten gesendet. Da das Protokoll zu Zahlen führt, die in Blöcken geschrieben werden sollen, muss das Netzwerk einen Konsens darüber erzielen. Das bedeutet, dass PVRB-Nachrichten ebenso wie Transaktionen von Knoten validiert und in Blöcke eingebunden werden müssen, damit jeder Netzwerkteilnehmer die Einhaltung des PVRB-Protokolls validieren kann. Dies führt uns automatisch zur offensichtlichen Lösung: Wenn sich das Netzwerk auf einen Konsens über einen Block und die darin enthaltenen Transaktionen einigt, sollte PVRB Teil des Konsenses und kein eigenständiges Protokoll sein. Andernfalls ist es möglich, dass ein Block aus Konsenssicht gültig ist, das PVRB-Protokoll jedoch nicht befolgt wird und der Block aus PVRB-Sicht nicht akzeptiert werden kann. Wenn also die Option „konsensintegriert“ gewählt wird, wird der PVRB zu einem wichtigen Bestandteil des Konsenses.

Bei der Beschreibung von PVRB-Implementierungen auf Netzwerkkonsensebene kann man Fragen der Endgültigkeit keineswegs vermeiden. Endgültigkeit ist ein Mechanismus, der in deterministischen Konsensvereinbarungen verwendet wird und der einen Block (und die Kette, die zu ihm führt) festlegt, der endgültig ist und niemals weggeworfen wird, selbst wenn eine parallele Verzweigung auftritt. Beispielsweise gibt es bei Bitcoin keinen solchen Mechanismus – wenn Sie eine Kette mit größerer Komplexität veröffentlichen, ersetzt diese jede weniger komplexe, unabhängig von der Länge der Ketten. Und in EOS beispielsweise sind die letzten die sogenannten Last Irreversible Blocks, die im Durchschnitt alle 432 Blöcke erscheinen (12*21 + 12*15, Pre-Vote + Pre-Commit). Dieser Prozess wartet im Wesentlichen auf die Signaturen von 2/3 der Blockproduzenten (im Folgenden als BP bezeichnet). Wenn Forks auftauchen, die älter als die letzte LIB sind, werden sie einfach verworfen. Dieser Mechanismus ermöglicht es sicherzustellen, dass die Transaktion in der Blockchain enthalten ist und niemals zurückgesetzt wird, unabhängig von den Ressourcen des Angreifers. Außerdem sind die letzten Blöcke von 2/3 BP signierte Blöcke in Hyperledger, Tendermint und anderen pBFT-basierten Konsensvereinbarungen. Außerdem ist es sinnvoll, ein Protokoll zur Sicherstellung der Endgültigkeit als Ergänzung zum Konsens zu gestalten, da es asynchron mit der Produktion und Veröffentlichung von Blöcken arbeiten kann. Hier ist ein gutes Exemplar Beitrag über die Endgültigkeit in Ethereum.

Endgültigkeit ist äußerst wichtig für Benutzer, die ohne sie möglicherweise Opfer eines „Double-Spend“-Angriffs werden, bei dem BP Blöcke „hält“ und sie veröffentlicht, nachdem das Netzwerk eine gute Transaktion „gesehen“ hat. Wenn es keine Endgültigkeit gibt, ersetzt der veröffentlichte Fork den Block durch eine „gute“ Transaktion durch eine andere, von einem „schlechten“ Fork, bei der die gleichen Gelder an die Adresse des Angreifers überwiesen werden. Im Fall von PVRB sind die Anforderungen an die Endgültigkeit sogar noch strenger, da der Aufbau von Forks für PVRB für einen Angreifer die Möglichkeit bedeutet, mehrere zufällige Optionen vorzubereiten, um die profitabelste zu veröffentlichen, und die Begrenzung der Zeit eines möglichen Angriffs eine ist gute Lösung.

Daher besteht die beste Option darin, PVRB und Finalität in einem Protokoll zu kombinieren – dann ist der finalisierte Block = finalisierter Zufall, und das ist genau das, was wir brauchen. Jetzt erhalten die Spieler in N Sekunden einen garantierten Zufall und können sicher sein, dass es unmöglich ist, ihn zurückzusetzen oder erneut abzuspielen.

Die konsensintegrierte Option ist gut:

• die Möglichkeit einer asynchronen Implementierung in Bezug auf die Produktion von Blöcken – Blöcke werden wie gewohnt produziert, aber parallel dazu kann das PVRB-Protokoll funktionieren, das nicht für jeden Block Zufälligkeit erzeugt
• die Fähigkeit, selbst umfangreiche Kryptografie zu implementieren, ohne die Einschränkungen, die Smart Contracts auferlegen
• Die Fähigkeit, den Austausch von Nachrichten schneller zu organisieren, als Transaktionen in der Blockchain enthalten sind, ermöglicht beispielsweise einen Teil des Protokolls, der zwischen Knoten funktionieren kann, ohne Nachrichten über das Netzwerk zu verteilen

Es hat auch Nachteile:

• Schwierigkeiten beim Testen und Entwickeln – Sie müssen Netzwerkfehler, fehlende Knoten und Netzwerk-Hard Forks emulieren
• Implementierungsfehler erfordern einen Netzwerk-Hardfork

Beide Methoden zur Implementierung von PVRB haben ein Recht auf Leben, aber die Implementierung von Smart Contracts in modernen Blockchains ist hinsichtlich der Rechenressourcen immer noch recht begrenzt und ein Übergang zu seriöser Kryptographie ist oft einfach unmöglich. Und wir werden ernsthafte Kryptographie brauchen, wie weiter unten gezeigt wird. Obwohl dieses Problem eindeutig vorübergehender Natur ist, ist eine ernsthafte Kryptografie in Verträgen erforderlich, um viele Probleme zu lösen, und sie tritt allmählich auf (z. B. Systemverträge für zkSNARKs in Ethereum).

Blockchain, die einen transparenten und zuverlässigen Protokoll-Messaging-Kanal bietet, ist nicht kostenlos. Jedes dezentrale Protokoll muss die Möglichkeit eines Sybil-Angriffs berücksichtigen; jede Aktion kann durch die konzertierten Kräfte mehrerer Konten ausgeführt werden. Daher muss beim Entwurf die Fähigkeit von Angreifern berücksichtigt werden, eine beliebige Anzahl von Protokollen zu erstellen Teilnehmer handeln in Absprache.

PVRB und Blockvariablen.

Ich habe nicht gelogen, als ich sagte, dass noch niemand ein gutes PVRB, das von vielen Glücksspielanwendungen getestet wurde, in Blockchains implementiert hat. Woher kommen dann so viele Glücksspielanwendungen auf Ethereum und EOS? Das überrascht mich genauso wie Sie: Woher haben sie so viele „persistente“ Zufälle in einer vollständig deterministischen Umgebung?

Der beliebteste Weg, Zufälligkeit in der Blockchain zu erreichen, besteht darin, „unvorhersehbare“ Informationen aus dem Block zu nehmen und darauf basierend eine zufällige Information zu erstellen – einfach durch Hashing eines oder mehrerer Werte. Guter Artikel über die Probleme solcher Systeme hier. Sie können jeden der „unvorhersehbaren“ Werte im Block übernehmen, zum Beispiel den Block-Hash, die Anzahl der Transaktionen, die Netzwerkkomplexität und andere im Voraus unbekannte Werte. Dann hashen Sie sie, einen oder mehrere, und theoretisch sollten Sie einen echten Zufall erhalten. Sie können dem Whitepaper sogar hinzufügen, dass Ihr Schema „post-quantensicher“ ist (da es quantensichere Hash-Funktionen gibt :)).

Aber selbst Post-Quantum-Secure-Hashes reichen leider nicht aus. Das Geheimnis liegt in den Anforderungen für PVRB. Ich möchte Sie an diese aus dem vorherigen Artikel erinnern:

1. Das Ergebnis muss nachweislich gleichmäßig verteilt sein, also auf einer nachweislich starken Kryptographie basieren.
2. Es ist nicht möglich, eines der Bits des Ergebnisses zu steuern. Daher kann der Ausgang nicht im Voraus vorhergesagt werden.
3. Sie können das Generierungsprotokoll nicht sabotieren, indem Sie nicht am Protokoll teilnehmen oder das Netzwerk mit Angriffsnachrichten überlasten
4. Alle oben genannten Punkte müssen einer Absprache mit einer zulässigen Anzahl unehrlicher Protokollteilnehmer (z. B. 1/3 der Teilnehmer) standhalten.

In diesem Fall ist nur Anforderung 1 erfüllt und Anforderung 2 nicht. Durch das Hashen unvorhersehbarer Werte aus dem Block erhalten wir eine gleichmäßige Verteilung und gute Zufälle. Aber BP hat zumindest die Möglichkeit, „die Sperre zu veröffentlichen oder nicht“. Somit kann BP zumindest aus ZWEI zufälligen Optionen wählen: „seine eigene“ und diejenige, die sich ergibt, wenn jemand anderes den Block erstellt. BP kann im Voraus „schnüffeln“, was passiert, wenn er einen Block veröffentlicht, und entscheidet einfach, ob er es tut oder nicht. Wenn er beispielsweise beim Roulette „Gerade-Ungerade“ oder „Rot/Schwarz“ spielt, kann er einen Block nur dann veröffentlichen, wenn er einen Gewinn sieht. Dies macht auch die Strategie, beispielsweise einen Block-Hash „aus der Zukunft“ zu verwenden, undurchführbar. In diesem Fall heißt es, dass „Zufallsdaten verwendet werden, die durch Hashing der aktuellen Daten und des Hashs eines zukünftigen Blocks mit einer Höhe von beispielsweise N + 42 erhalten werden, wobei N die aktuelle Blockhöhe ist.“ Dadurch wird das Schema ein wenig gestärkt, aber BP kann, wenn auch in Zukunft, immer noch entscheiden, ob es die Sperre aufrechterhält oder veröffentlicht.

Die BP-Software wird in diesem Fall komplizierter, aber nicht viel. Bei der Validierung und Aufnahme einer Transaktion in einen Block erfolgt einfach eine schnelle Überprüfung, ob es einen Gewinn gibt, und möglicherweise die Auswahl eines Transaktionsparameters, um eine hohe Gewinnwahrscheinlichkeit zu erhalten. Gleichzeitig ist es fast unmöglich, einen klugen BP für solche Manipulationen zu erwischen; jedes Mal können Sie neue Adressen verwenden und nach und nach gewinnen, ohne Verdacht zu erregen.

Daher eignen sich Methoden, die Informationen aus dem Block nutzen, nicht als universelle Implementierung von PVRB. In einer eingeschränkten Version mit Beschränkungen der Einsatzhöhe, Beschränkungen der Anzahl der Spieler und/oder der KYC-Registrierung (um zu verhindern, dass ein Spieler mehrere Adressen verwendet) können diese Schemata für kleine Spiele funktionieren, mehr jedoch nicht.

PVRB und Commit-Reveal.

Okay, dank Hashing und zumindest der relativen Unvorhersehbarkeit des Block-Hashs und anderer Variablen. Wenn Sie das Problem der vordersten Miner lösen, sollten Sie sich etwas Passenderes besorgen. Fügen wir diesem Schema Benutzer hinzu – lassen Sie sie auch die Zufälligkeit beeinflussen: Jeder Mitarbeiter des technischen Supports wird Ihnen sagen, dass die Aktionen der Benutzer das Zufälligste in IT-Systemen sind :)

Ein naives Schema, bei dem Benutzer einfach Zufallszahlen senden und das Ergebnis beispielsweise als Hash ihrer Summe berechnet wird, ist nicht geeignet. In diesem Fall kann der letzte Spieler durch die Wahl seines eigenen Zufalls steuern, wie das Ergebnis aussehen wird. Aus diesem Grund wird das weit verbreitete Commit-Reveal-Muster verwendet. Die Teilnehmer senden zunächst Hashes von ihren Randoms (Commits) und öffnen dann die Randoms selbst (Reveals). Die „Reveal“-Phase beginnt erst, nachdem die erforderlichen Commits gesammelt wurden, sodass die Teilnehmer genau den zufälligen Hash senden können, von dem sie zuvor gesendet haben. Fügen wir das alles nun mit den Parametern eines Blocks zusammen, und zwar besser als mit einem aus der Zukunft (Zufälligkeit kann nur in einem der Zukunftsblöcke gefunden werden), und voilà – fertig ist die Zufälligkeit! Jetzt beeinflusst jeder Spieler die resultierende Zufälligkeit und kann den böswilligen BP „besiegen“, indem er ihn mit seiner eigenen, im Voraus unbekannten Zufälligkeit überschreibt ... Sie können das Protokoll auch vor Sabotage schützen, indem Sie es einfach bei der Enthüllung nicht öffnen indem verlangt wird, dass der Transaktion bei der Begehung ein bestimmter Betrag beigefügt wird – eine Kaution, die erst während des Offenlegungsverfahrens zurückerstattet wird. In diesem Fall wird es unrentabel sein, etwas zu begehen und es nicht preiszugeben.

Es war ein guter Versuch, und solche Schemata gibt es auch in Gaming-DApps, aber leider reicht auch das nicht aus. Nun kann nicht nur der Miner, sondern auch jeder Teilnehmer des Protokolls Einfluss auf das Ergebnis nehmen. Es ist immer noch möglich, den Wert selbst zu kontrollieren, mit geringerer Variabilität und mit geringeren Kosten, aber wie im Fall des Miners gilt: Wenn die Ergebnisse der Ziehung wertvoller sind als die Gebühr für die Teilnahme am PVRB-Protokoll, dann der Zufall -Produzent(RP) kann entscheiden, ob er etwas preisgibt und kann dennoch aus mindestens zwei zufälligen Optionen wählen.
Aber es wurde möglich, diejenigen zu bestrafen, die etwas begehen und es nicht preisgeben, und dieser Plan wird sich als nützlich erweisen. Seine Einfachheit ist ein gravierender Vorteil – seriösere Protokolle erfordern viel leistungsfähigere Berechnungen.

PVRB und deterministische Signaturen.

Es gibt eine andere Möglichkeit, den RP zu zwingen, eine Pseudozufallszahl bereitzustellen, die er nicht beeinflussen kann, wenn er mit einem „Vorbild“ versehen wird – dies ist eine deterministische Signatur. Eine solche Signatur ist beispielsweise RSA und kein 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, und im Fall von ECS kann er eine beliebige Anzahl davon generieren verschiedene gültige Signaturen. Dies liegt daran, dass beim Erstellen einer ECS-Signatur eine Zufallszahl verwendet wird, die vom Unterzeichner ausgewählt wird und auf beliebige Weise ausgewählt werden kann, sodass 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 unmöglich vorherzusagen, welche Signatur ein anderer RP erhalten wird. Daher kann ein PVRB mit deterministischen Signaturen organisiert werden, indem die RSA-Signaturen mehrerer Teilnehmer kombiniert werden, die denselben Wert signiert haben. Zum Beispiel der vorherige Zufall. Dieses Schema spart viele Ressourcen, weil Signaturen sind sowohl eine Bestätigung des korrekten Verhaltens gemäß dem Protokoll als auch eine Quelle der Zufälligkeit.

Selbst mit deterministischen Signaturen ist das Schema jedoch immer noch anfällig für das Problem des „letzten Akteurs“. Der letzte Teilnehmer kann weiterhin entscheiden, ob er die Signatur veröffentlicht oder nicht, und so das Ergebnis steuern. Sie können das Schema ändern, Block-Hashes hinzufügen und Runden erstellen, sodass das Ergebnis nicht im Voraus vorhergesagt werden kann. Alle diese Techniken lassen jedoch selbst unter Berücksichtigung vieler Änderungen das Problem des Einflusses eines Teilnehmers auf das Kollektiv ungelöst Dies führt zu einer nicht vertrauenswürdigen Umgebung und kann nur unter wirtschaftlichen und zeitlichen Einschränkungen funktionieren. Darüber hinaus ist die Größe der RSA-Schlüssel (1024 und 2048 Bit) recht groß und die Größe für Blockchain-Transaktionen ist ein äußerst wichtiger Parameter. Anscheinend gibt es keinen einfachen Weg, das Problem zu lösen. Machen wir weiter.

PVRB und Systeme zur gemeinsamen Nutzung von Geheimnissen

In der Kryptografie gibt es Schemata, die es dem Netzwerk ermöglichen, sich auf einen und nur einen PVRB-Wert zu einigen, während solche Schemata gegenüber böswilligen Handlungen einiger Teilnehmer resistent sind. Ein nützliches Protokoll, mit dem es sich lohnt, sich vertraut zu machen, ist Shamirs Secret-Sharing-Schema. Es dient dazu, ein Geheimnis (z. B. einen geheimen Schlüssel) in mehrere Teile zu zerlegen und diese Teile an N Teilnehmer zu verteilen. Das Geheimnis wird so verteilt, dass M Teile von N ausreichen, um es wiederzugewinnen, und das können beliebige M Teile sein. Wenn an den Fingern ein Diagramm einer unbekannten Funktion vorhanden ist, tauschen die Teilnehmer Punkte auf dem Diagramm aus, und nach Erhalt von M Punkten kann die gesamte Funktion wiederhergestellt werden.
Eine gute Erklärung finden Sie in Wiki Aber es ist nützlich, praktisch damit zu spielen, um das Protokoll im Kopf abzuspielen Demo Seite.

Wenn das FSSS-System (Fiat-Shamir Secret Sharing) in seiner reinen Form anwendbar wäre, wäre es ein unzerstörbares PVRB. In seiner einfachsten Form könnte das Protokoll so aussehen:

• Jeder Teilnehmer generiert seinen eigenen Zufall und verteilt daraus Anteile an andere Teilnehmer
• Jeder Teilnehmer verrät seinen Teil der Geheimnisse der anderen Teilnehmer
• Wenn ein Teilnehmer mehr als M Anteile hat, kann die Anzahl dieses Teilnehmers berechnet werden und ist unabhängig von der Menge der angezeigten Teilnehmer eindeutig
• Die Kombination der aufgedeckten Zufallszahlen ist der gewünschte PVRB

Dabei hat ein einzelner Teilnehmer keinen Einfluss mehr auf die Ergebnisse des Protokolls, außer in Fällen, in denen das Erreichen der Zufälligkeitsoffenlegungsschwelle allein von ihm abhängt. Daher funktioniert dieses Protokoll, wenn ein erforderlicher Anteil an RPs, die am Protokoll arbeiten und verfügbar sind, die Anforderungen an die kryptografische Stärke umsetzt und gegen das Problem des „letzten Akteurs“ resistent ist.

Dies könnte eine ideale Option sein; dieses PVRB-Schema, das auf der gemeinsamen Nutzung von Fiat-Shamir-Geheimnissen basiert, wird beispielsweise in beschrieben diese Artikel. Aber wie oben erwähnt, treten technische Einschränkungen auf, wenn man versucht, es direkt in der Blockchain anzuwenden. Hier ist ein Beispiel für eine Testimplementierung des Protokolls im EOS-Smart-Vertrag und dessen wichtigster Teil – die Überprüfung des veröffentlichten Aktienteilnehmers: Code. Sie können dem Code entnehmen, dass die Beweisvalidierung mehrere Skalarmultiplikationen erfordert und die verwendeten Zahlen sehr groß sind. Es sollte klar sein, dass in Blockchains die Überprüfung in dem Moment erfolgt, in dem der Blockproduzent die Transaktion verarbeitet, und im Allgemeinen muss jeder Teilnehmer die Richtigkeit des Protokolls leicht überprüfen, sodass die Anforderungen an die Geschwindigkeit der Überprüfungsfunktion sehr hoch sind . Bei dieser Option erwies sich die Option als wirkungslos, da die Verifizierung nicht innerhalb des Transaktionslimits (0.5 Sekunden) lag.

Die Effizienz der Verifizierung ist eine der wichtigsten Voraussetzungen für die Verwendung allgemein fortschrittlicher kryptografischer Schemata in der Blockchain. Beweise erstellen, Nachrichten vorbereiten – diese Vorgänge können aus der Kette genommen und auf Hochleistungscomputern durchgeführt werden, aber die Verifizierung kann nicht umgangen werden – dies ist eine weitere wichtige Anforderung für PVRB.

PVRB und Schwellenwertsignaturen

Nachdem wir uns mit dem Secret-Sharing-System vertraut gemacht hatten, entdeckten wir eine ganze Klasse von Protokollen, die unter dem Schlüsselwort „Threshold“ zusammengefasst sind. Wenn die Offenlegung einiger Informationen die Teilnahme von M ehrlichen Teilnehmern von N erfordert und die Menge der ehrlichen Teilnehmer eine beliebige Teilmenge von N sein kann, sprechen wir von „Schwellen“-Systemen. Sie sind es, die es uns ermöglichen, das Problem des „letzten Akteurs“ zu lösen. Wenn nun der Angreifer seinen Teil des Geheimnisses nicht preisgibt, wird es ein anderer, ehrlicher Teilnehmer für ihn tun. Diese Schemata ermöglichen die Einigung auf eine und nur eine Bedeutung, selbst wenn das Protokoll von einigen Teilnehmern sabotiert wird.

Die Kombination von deterministischen Signaturen und Schwellenwertschemata ermöglichte die Entwicklung eines sehr praktischen und vielversprechenden Schemas zur Implementierung von PVRB – das sind deterministische Schwellenwertsignaturen. Hier Beitrag über die verschiedenen Verwendungsmöglichkeiten von Schwellenwertsignaturen, und hier ist noch eine gute lang gelesen von Dash.

Der letzte Artikel beschreibt BLS-Signaturen (BLS steht für Boneh-Lynn-Shacham, hier Artikel), die für Programmierer eine sehr wichtige und äußerst praktische Eigenschaft haben – öffentliche, geheime, öffentliche Schlüssel und BLS-Signaturen können mithilfe einfacher mathematischer Operationen miteinander kombiniert werden, während ihre Kombinationen gültige Schlüssel und Signaturen bleiben, sodass Sie viele problemlos aggregieren können Signaturen in einen und viele öffentliche Schlüssel in einen. Sie sind außerdem deterministisch und liefern für dieselben Eingabedaten das gleiche Ergebnis. Aufgrund dieser Qualität sind Kombinationen von BLS-Signaturen selbst gültige Schlüssel, was die Implementierung einer Option ermöglicht, bei der M von N Teilnehmern eine und nur eine Signatur erzeugen, die deterministisch, öffentlich überprüfbar und unvorhersehbar ist, bis sie vom Mth geöffnet wird Teilnehmer.

In einem Schema mit Schwellenwert-BLS-Signaturen signiert jeder Teilnehmer etwas mit BLS (z. B. dem vorherigen Zufall), und die gemeinsame Schwellenwertsignatur ist der gewünschte Zufall. Die kryptografischen Eigenschaften von BLS-Signaturen erfüllen die Anforderungen an die Zufallsqualität, der Schwellenwertteil schützt vor „Last-Actor“ und die einzigartige Kombinierbarkeit von Schlüsseln ermöglicht die Implementierung vieler weiterer interessanter Algorithmen, die beispielsweise eine effiziente Aggregation von Protokollnachrichten ermöglichen .

Wenn Sie also PVRB auf Ihrer Blockchain aufbauen, werden Sie höchstwahrscheinlich beim BLS-Schwellenwertsignaturschema landen, das bereits von mehreren Projekten verwendet wird. Zum Beispiel DFinity (hier Benchmark, der die Schaltung implementiert, und hier Beispielimplementierung der überprüfbaren gemeinsamen Nutzung von Geheimnissen) oder Keep.network (hier ist ihr zufälliger Beacon). gelbes Papier, Aber Beispiel Smart Contract, der das Protokoll bedient).

Implementierung von PVRB

Leider sehen wir immer noch kein fertiges Protokoll, das in PVRB-Blockchains implementiert ist und seine Sicherheit und Stabilität unter Beweis gestellt hat. Auch wenn die Protokolle selbst fertig sind, ist ihre technische Anwendung auf bestehende Lösungen nicht einfach. Für zentralisierte Systeme ist PVRB nicht sinnvoll und dezentrale Systeme sind in allen Rechenressourcen streng begrenzt: CPU, Speicher, Speicher, E/A. Das Entwerfen eines PVRB ist eine Kombination verschiedener Protokolle, um etwas zu schaffen, das alle Anforderungen für zumindest eine funktionsfähige Blockchain erfüllt. Ein Protokoll berechnet effizienter, erfordert aber mehr Nachrichten zwischen RPs, während das andere nur sehr wenige Nachrichten erfordert, aber die Erstellung eines Beweises kann eine Aufgabe sein, die mehrere zehn Minuten oder sogar Stunden dauert.

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

• Kryptografische Stärke. Ihr PVRB muss absolut unverzerrt sein und darf kein einziges Bit steuern. Bei einigen Systemen ist dies nicht der Fall. Wenden Sie sich daher an einen Kryptographen
• Das Problem des „letzten Schauspielers“.. Ihr PVRB muss gegen Angriffe resistent sein, bei denen ein Angreifer, der einen oder mehrere RPs kontrolliert, zwischen zwei Ergebnissen wählen kann.
• Problem der Protokollsabotage. Ihr PVRB muss resistent gegen Angriffe sein, bei denen ein Angreifer, der einen oder mehrere RPs kontrolliert, entscheidet, ob er zufällig vorgeht oder nicht, und dies entweder garantiert oder mit einer bestimmten Wahrscheinlichkeit beeinflussen kann
• Problem mit der Anzahl der Nachrichten. Ihre RPs sollten ein Minimum an Nachrichten an die Blockchain senden und synchrone Aktionen so weit wie möglich vermeiden, wie zum Beispiel Situationen wie „Ich habe einige Informationen gesendet, ich warte auf eine Antwort von einem bestimmten Teilnehmer.“ In P2P-Netzwerken, insbesondere in geografisch verteilten Netzwerken, sollten Sie nicht mit einer schnellen Reaktion rechnen
• Das Problem der Rechenkomplexität. Die Überprüfung jeder Phase des PVRB in der Kette sollte äußerst einfach sein, da sie von allen vollständigen Clients des Netzwerks durchgeführt wird. Erfolgt die Umsetzung über einen Smart Contract, sind die Geschwindigkeitsanforderungen sehr streng
• Das Problem der Zugänglichkeit und Lebendigkeit. Ihr PVRB sollte bestrebt sein, Situationen standzuhalten, in denen ein Teil des Netzwerks für einen bestimmten Zeitraum nicht verfügbar ist und ein Teil des RP einfach nicht mehr funktioniert
• Das Problem der vertrauenswürdigen Einrichtung und der anfänglichen Schlüsselverteilung. Wenn Ihr PVRB das primäre Setup des Protokolls verwendet, dann ist dies eine separate große und ernste Geschichte. Hier Beispiel. Wenn sich die Teilnehmer vor Beginn des Protokolls gegenseitig ihre Schlüssel mitteilen müssen, ist dies auch dann ein Problem, wenn sich die Zusammensetzung der Teilnehmer ändert
• Entwicklungsprobleme. Verfügbarkeit von Bibliotheken in den erforderlichen Sprachen, deren Sicherheit und Leistung, Werbung, komplexe Tests usw.

Beispielsweise haben Schwellenwert-BLS-Signaturen ein erhebliches Problem: Bevor die Teilnehmer mit der Arbeit beginnen, müssen sie sich gegenseitig Schlüssel verteilen und eine Gruppe bilden, innerhalb derer der Schwellenwert funktioniert. Dies bedeutet, dass mindestens eine Austauschrunde in einem dezentralen Netzwerk warten muss, und da der generierte Rand beispielsweise in Spielen nahezu in Echtzeit benötigt wird, bedeutet dies, dass in dieser Phase eine Sabotage des Protokolls möglich ist und die Vorteile des Schwellenwertschemas gehen verloren. Dieses Problem ist bereits einfacher als die vorherigen, erfordert aber dennoch die Entwicklung eines separaten Verfahrens zur Bildung von Schwellengruppen, die wirtschaftlich durch Ein- und Auszahlungen (Slashing) von Teilnehmern, die sich nicht daran halten, geschützt werden müssen Protokoll. Außerdem passt eine BLS-Verifizierung mit einem akzeptablen Sicherheitsniveau beispielsweise einfach nicht in eine Standard-EOS- oder Ethereum-Transaktion – es bleibt einfach nicht genügend Zeit für die Verifizierung. Der Vertragscode ist WebAssembly oder EVM und wird von einer virtuellen Maschine ausgeführt. Kryptografische Funktionen sind (noch) nicht nativ implementiert und arbeiten zehnmal langsamer als herkömmliche kryptografische Bibliotheken. Viele Protokolle erfüllen die Anforderungen nicht allein aufgrund des Schlüsselvolumens, zum Beispiel 1024 und 2048 Bit für RSA, 4–8 Mal größer als die Standard-Transaktionssignatur in Bitcoin und Ethereum.

Auch das Vorhandensein von Implementierungen in verschiedenen Programmiersprachen spielt eine Rolle – davon gibt es insbesondere bei neuen Protokollen nur wenige. Die Option mit Integration in den Konsens erfordert das Schreiben eines Protokolls in der Plattformsprache, sodass Sie nach Code in Go für Geth, in Rust für Parity und in C++ für EOS suchen müssen. Jeder wird nach JavaScript-Code suchen müssen, und da JavaScript und Kryptographie keine besonders engen Freunde sind, hilft WebAssembly, das nun definitiv den Anspruch erhebt, der nächste wichtige Internetstandard zu sein.

Abschluss

Ich hoffe auf den vorherigen Artikel Es ist mir gelungen, Sie davon zu ü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 schwierig ist, es aber bereits gute Lösungen gibt. Im Allgemeinen ist das endgültige Design des Protokolls erst nach der Durchführung umfangreicher Tests möglich, die alle Aspekte vom Setup bis zur Fehleremulation berücksichtigen. Daher ist es unwahrscheinlich, dass Sie in Team-Whitepapers und Artikeln vorgefertigte Rezepte finden, und wir werden es ganz sicher nicht tun Entscheide dich in den nächsten ein oder zwei Jahren und schreibe: „Mach es so, genau richtig.“

Tschüss, für unser PVRB in der Blockchain, die gerade entwickelt wird HayaNachdem wir uns für die Verwendung von Schwellenwert-BLS-Signaturen entschieden haben, planen wir, PVRB auf Konsensebene zu implementieren, da eine Überprüfung in Smart Contracts mit einem akzeptablen Sicherheitsniveau noch nicht möglich ist. Es ist möglich, dass wir zwei Schemata gleichzeitig verwenden: Erstens die teure gemeinsame Nutzung von Geheimnissen, um einen langfristigen random_seed zu erstellen, und dann verwenden wir es als Grundlage für die hochfrequente Zufallsgenerierung mithilfe von BLS-Signaturen mit deterministischem Schwellenwert. Vielleicht beschränken wir uns darauf eines der Schemata. Wie das Protokoll aussehen wird, lässt sich leider im Voraus nicht sagen; das einzig Gute ist, dass wie in der Wissenschaft auch bei technischen Problemen ein negatives Ergebnis ein Ergebnis ist und jeder neue Versuch, das Problem zu lösen, einen weiteren Schritt darstellt die Recherche aller an dem Problem Beteiligten. Um Geschäftsanforderungen zu erfüllen, lösen wir ein spezifisches praktisches Problem – die Bereitstellung einer zuverlässigen Entropiequelle für Spieleanwendungen. Daher müssen wir auch auf die Blockchain selbst achten, insbesondere auf die Probleme der Kettenendgültigkeit und der Netzwerkverwaltung.

Und auch wenn wir noch kein nachweislich resistentes PVRB in Blockchains sehen, das lange genug verwendet worden wäre, um durch reale Anwendungen, mehrere Audits, Lasten und natürlich echte Angriffe getestet zu werden, bestätigt die Anzahl möglicher Pfade dies Es gibt eine Lösung und welche dieser Algorithmen werden das Problem letztendlich lösen. Wir freuen uns, die Ergebnisse zu teilen und danken anderen Teams, die ebenfalls an diesem Problem arbeiten, für Artikel und Code, die es Ingenieuren ermöglichen, nicht zweimal auf denselben Rechen zu treten.

Wenn Sie also einen Programmierer treffen, der dezentrale Zufallsgeneratoren entwirft, seien Sie aufmerksam und fürsorglich und leisten Sie bei Bedarf psychologische Hilfe :)

Source: habr.com