Was ein Hash-Commitment beweist – und die drei Dinge, die es nicht kann

Der Trick, in einem Absatz

Ein kryptografischer Hash verwandelt jede Eingabe in einen Fingerabdruck fester Länge mit zwei hier entscheidenden Eigenschaften: Man kann vom Fingerabdruck nicht auf die Eingabe zurückrechnen, und man kann keine zwei Eingaben mit demselben Fingerabdruck finden. Zeigt dir also jemand heute den Fingerabdruck eines Geheimnisses und morgen das Geheimnis selbst, kannst du das Geheimnis hashen und prüfen, ob es passt. Wenn ja, ist das gezeigte Geheimnis dasselbe, das er gestern hatte. Er konnte es zwischenzeitlich nicht austauschen, denn ein anderes Geheimnis hätte einen anderen Fingerabdruck – und er konnte das Geheimnis auch nicht passend zum Fingerabdruck wählen, denn das würde bedeuten, den Hash umzukehren.

Das ist ein Commitment-Schema, und das ist der gesamte kryptografische Inhalt von „provably fair“. Das Haus erzeugt einen Server-Seed, veröffentlicht dessen SHA-256-Hash, spielt Runden, die aus dem Seed abgeleitet werden, und deckt den Seed auf, wenn das Paar ausgemustert wird. Alles andere ist reine Verrohrung.

ENGINE-VERIFIED_shared/seedApi.ts: getRandomKey liefert {serverSeedHashed, clientSeed, nonce}; renewRandomKey liefert ein frisches Paar zusammen mit previousServerSeed und previousServerSeedHashed, der Aufdeckung. _shared/SeedPanel.tsx beschriftet das Feld mit „server seed (sha-256 commitment)“. _shared/rng.ts: sha256Hex() berechnet den Fingerabdruck und hmacSha256Utf8() den Hash pro Runde, mit dem Kommentar, dass die Demo-Engine „Ergebnisse mit denselben Primitiven ERZEUGT, mit denen der Verifier sie PRÜFT — eine Implementierung, sodass die Demo niemals von dem abweichen kann, was der Verifier akzeptiert“.

Drei Dinge, die es beweist

Was das Commitment festlegt, und wie du jedes davon prüfst

Alle drei Prüfungen sind lokal: Sie benötigen den aufgedeckten Seed, deinen Client-Seed, die Nonce und den Ableitungscode – und nichts vom Haus zum Prüfzeitpunkt.

Die dritte Behauptung ist diejenige, die für einen Spieler den Nutzen bringt, und sie hängt davon ab, dass die Ableitung öffentlich ist. Ein Hash des Seeds sagt dir nichts darüber, wie der Seed zu einem Würfelwurf oder einer Karte wurde. Hier wird diese Funktion mit dem Client ausgeliefert, derselbe Code, den die Demo zur Erzeugung der Ergebnisse verwendet und den der Verifier zur Prüfung nutzt, sodass eine neu berechnete Runde eine echte Neuberechnung ist und keine Anfrage an den Server, sich selbst zu bestätigen.

ENGINE-VERIFIZIERT_shared/demoLocal.ts: uAt() leitet die Zahl pro Runde als u64(hmacSha256Utf8(serverSeed, `${clientSeed}-${nonce}-${cursor}`)) ab, beschrieben als übereinstimmend mit RandomUtils.generateHash auf dem Server; _shared/rng.ts wandelt die ersten sieben Bytes des HMAC in eine gleichverteilte Zahl in [0, 1) um, „bitgenau übereinstimmend mit der Long→Double-Rundung des Servers“. Das Ableitungsmodul jedes Spiels bildet diese Zahl dann auf einen Wurf, eine Karte oder einen Multiplikator ab.

Der Verifizierungs-Walkthrough führt alle drei Schritte an einer echten Runde durch. Wenn du es noch nie gemacht hast, mach es einmal; der Sinn des Schemas ist nicht, dass du jede Runde prüfst, sondern dass du jede beliebige prüfen könntest, und das Haus kann im Voraus nicht wissen, welche.

Drei Dinge, die es nicht beweisen kann

Es kann nicht beweisen, dass der Seed zufällig war. Ein Commitment legt einen Seed fest; es sagt nichts darüber aus, wie der Seed gewählt wurde. Wenn das Haus deinen Client-Seed kannte, als es den Server-Seed erzeugte, könnte es im Prinzip so lange Seeds generieren, bis es einen findet, dessen erste Runden ihm gefallen, und sich auf diesen festlegen. Der Hash würde perfekt aufgehen. Die Standardverteidigung ist die Reihenfolge: Der Server-Seed wird zuerst committet, und der Client-Seed wird danach gesetzt, sodass das Haus – egal worauf es sich committet hat – nicht wusste, womit es kombiniert werden würde.

Diese Reihenfolge ist der Punkt, an dem das Panel dieser Seite eine Grenze hat, die man klar benennen sollte. Das Setzen eines Client-Seeds hier lässt den aktuellen Server-Seed nicht bestehen; es rotiert das Paar, und der neue Server-Seed wird von derselben Anfrage generiert, die deinen neuen Client-Seed übermittelt. Vom Client aus lässt sich nicht zeigen, dass der neue Seed festgelegt wurde, bevor die Anfrage gelesen wurde. Ob der Server den nächsten Seed vorab generiert, wie es manche Betreiber tun, indem sie das nächste Commitment im Voraus veröffentlichen, ist in der API des Clients nicht sichtbar, und es gibt kein Feld „nächster Server-Seed-Hash“, gegen das man prüfen könnte. Dies wurde beim Spiele-Team angesprochen, und die Lösung ist klein: den nächsten Server-Seed committen, bevor der Client-Seed akzeptiert wird, mit dem er gepaart werden soll, und dieses Commitment im Panel anzeigen.

ENGINE-VERIFIZIERT_shared/seedApi.ts: setClientSeed(clientSeed) ruft renewRandomKey mit dem neuen Client-Seed auf und gibt ein frisches Paar bei nonce 0 zurück; rotate() ruft denselben Endpunkt ohne Seed auf. IHouseSeed enthält serverSeedHashed, clientSeed und nonce, plus das vorherige Paar bei Rotation; ein Next-Seed-Commitment ist im Typ nicht vorhanden.

Bis dahin ist die praktische Version der Verteidigung diejenige, die das Schema dir in jeder anderen Hinsicht ohnehin gibt: die Aufdeckung. Ein Haus, das Seeds gegen deinen Client-Seed durchprobiert, müsste trotzdem jeden Seed bei Rotation offenlegen, und jede Runde darunter kann neu berechnet werden. Die Grenze bedeutet, dass eine verdächtige Serie in den ersten Runden nach einem Seed-Wechsel allein durch den Hash nicht ausgeschlossen werden kann; sie kann erst nach der Aufdeckung Runde für Runde untersucht werden.

Es kann nicht beweisen, dass das Spiel im anderen Sinne fair ist. „Provably fair“ bedeutet, dass die Zufälligkeit ehrlich war, nicht dass die Quoten ausgeglichen sind. Ein Würfelspiel kann perfekt überprüfbar sein und trotzdem konstruktionsbedingt 99% zurückgeben; der Hausvorteil steckt in der Auszahlungstabelle, die eine veröffentlichte Zahl und ein separates Versprechen ist. Die Ethik des Hausvorteils handelt von diesem Versprechen. Das Commitment schweigt dazu.

Es beweist nichts über Runden, die niemand überprüft. Das Schema ist ein Abschreckungsmittel, keine Garantie. Eine Runde, die du nie neu berechnest, ist eine Runde, der du vertraut hast, genau wie überall sonst; was sich ändert, ist, dass dieses Vertrauen optional ist, und das Haus kann nicht wissen, wann du davon Gebrauch machst. Das ist eine große Verbesserung gegenüber einer Mischmaschine, in die du nicht hineinsehen kannst, und eine kleinere, als das Wort „Beweis“ vermuten lässt.

Der Hash ist eine Quittung für die Zufälligkeit. Er ist kein Zertifikat für das Spiel. Der Satz, den man sich merken sollte

Was mehr beweisen würde

• Ein vorab committeter nächster Seed. Die Veröffentlichung des Hashes des nächsten Server-Seeds, bevor irgendein Client-Seed damit gepaart werden kann, schließt die oben genannte Reihenfolgen-Lücke. Es ist die einzige Änderung, die es dem Panel erlauben würde zu beweisen, dass der Seed festgelegt wurde, bevor deine Eingabe bekannt war.
• Eine öffentliche Zufallsquelle. Die Beimischung eines Beacons, den niemand kontrolliert, wie das drand-Netzwerk, entfernt die Frage, wer den Seed gewählt hat, vollständig; inside drand beschreibt, wie das funktioniert und was es kostet.
• Eine veröffentlichte Ableitung, öffentlich gehalten. Hier bereits der Fall, und der Teil, der am leichtesten verloren geht, wenn ein Client neu geschrieben wird. Der Verifizierer ist nur so ehrlich wie der Code, den er ausführt.

Nichts davon ändert, was ein Hash ist. Es ändert, wovon der Hash ein Fingerabdruck ist, und wann. Das Schema ist einfach genug, dass auch seine Grenzen einfach sind, und ein Spieler, der die drei Dinge kennt, die es beweist, ist in einer besseren Position als einer, dem gesagt wurde, es beweise alles.

FAQ

Was ist ein Hash-Commitment in einem provably fair Casino?

Der SHA-256-Fingerabdruck des geheimen Server-Seeds des Hauses, gezeigt vor dem Spiel und bei der Enthüllung gegen den Seed geprüft. Es beweist, dass der Seed vor deinen Wetten feststand und dass der enthüllte Seed derjenige ist, auf den man sich committet hat.

Beweist ein übereinstimmender Hash, dass das Spiel fair war?

Es beweist, dass die Zufälligkeit nach dem Commitment nicht verändert wurde, und, mit einer veröffentlichten Ableitung, dass jedes Ergebnis aus dem Seed-Paar folgt. Es beweist nicht, dass der Seed zufällig gewählt wurde, und es sagt nichts über den Hausvorteil aus, der eine separate veröffentlichte Zahl ist.

Kann das Haus einen Server-Seed wählen, der es begünstigt?

Nur wenn es den Client-Seed kennt, mit dem der Server-Seed gepaart wird, wenn es ihn auswählt. Die Verteidigung besteht darin, den Server-Seed zu committen, bevor der Client-Seed gesetzt wird. Auf dieser Seite rotiert eine Änderung des Client-Seeds das Paar in derselben Anfrage, sodass diese Reihenfolge vom Client aus nicht bestätigt werden kann; der Artikel beschreibt die Schwachstelle und die vorgeschlagene Lösung.

Wie überprüfe ich eine Runde selbst?

Rotiere den Seed, um den zurückgezogenen Server-Seed offenzulegen, hashe ihn, um zu bestätigen, dass er mit dem dir angezeigten Commitment übereinstimmt, und berechne dann HMAC-SHA256 des Server-Seeds über deinen Client-Seed, die Nonce und den Cursor neu, und lasse das Ergebnis durch die veröffentlichte Ableitungsfunktion des Spiels laufen. Das Seed-Panel führt die Neuberechnung in deinem Browser durch.

Warum ist der Ableitungscode wichtig?

Weil der Hash nur den Seed festlegt. Die Umwandlung des Seeds in einen Wurf oder eine Karte ist eine Funktion, und solange diese Funktion nicht öffentlich ist, sagt ein übereinstimmender Hash nichts darüber aus, ob das Ergebnis dem entsprach, was der Seed implizierte. Hier liefert der Client dieselbe Ableitung aus, die auch die Demo zur Erzeugung von Ergebnissen verwendet.

Ist Provably Fair besser als ein lizenziertes RNG-Audit?

Sie beantworten unterschiedliche Fragen. Ein Audit zertifiziert das statistische Verhalten eines Generators über viele Ziehungen hinweg; ein Commitment erlaubt es, eine bestimmte Runde im Nachhinein zu überprüfen. Keines ersetzt das andere, und keines ändert den Hausvorteil.

QUELLEN & REFERENZEN

• Wikipedia — Commitment-Scheme: Hiding und Binding, sowie hashbasierte Commitments
• Wikipedia — HMAC: Keyed Hashing und dessen Verwendung als Pseudozufallsfunktion
• Betkyo-Engine-Quelle: _shared/seedApi.ts (Commit, Reveal und Rotation), _shared/rng.ts (sha256Hex, hmacSha256Utf8, das 7-Byte-Uniform), _shared/demoLocal.ts (uAt-Ableitung), _shared/SeedPanel.tsx

DIE SPIELE IN DIESEM ARTIKELDice — Regeln & kostenlos spielen →Limbo — Regeln & kostenlos spielen →