Was ist Provably Fair und wie man die Integrität des Spiels überprüft

Was ist Provably Fair (PF)

Provably Fair ist ein Protokoll, mit dem Sie kryptografisch überprüfen können, ob das Ergebnis der Runde zufällig war und nach dem Wetten nicht durch den Betreiber ersetzt werden konnte.

Die Idee: Zuerst wird der Commit (der Hash des versteckten Server-Seeds) veröffentlicht, dann wird nach dem Wetten der Reed (der Server-Seed selbst) enthüllt, und jeder kann den Hash überprüfen und den RNG reproduzieren, wenn man den Client-Seed des Spielers und die IDs der Runde berücksichtigt.

Basis-Protokoll: commit → bet → reveal

1. Commit: Bevor die Runden beginnen, generiert der Server einen zufälligen 'server _ seed' und veröffentlicht seinen Hash:


commit = SHA-256(server_seed         salt )//oder Keccak-256

Der Commit kann in der Historie/Blockchain/Log ausgegeben werden.

2. Wette: Der Spieler wählt oder bestätigt seinen 'client _ seed' (von der Benutzeroberfläche oder seinem eigenen), sendet eine Wette mit:


client_seed, roundId, nonce

3. Reveal: Nachdem die Wetten geschlossen wurden, zeigt der Server 'server _ seed' (und 'salt', falls vorhanden) an, damit jeder überprüfen kann:


SHA-256(server_seed         salt) = = commit//Integritätsprüfung

4. RNG: Die Zufallszahl ist deterministisch und reproduzierbar:


rng = HMAC-SHA256(key=server_seed, msg=client_seed          roundId          nonce)
//oder rng = SHA-256 (server_seed         client_seed          roundId          nonce)

5. Mapping in Exodus: Wir wandeln 'rng' in einen Spielbereich ohne Offset um (siehe unten).

💡 Warum nonce? Damit mit einem 'server _ seed' viele Runden ohne das Risiko der Vorhersehbarkeit gefahren werden können: 'nonce' wird jede Runde/Wette inkrementiert.

So erhalten Sie eine Zahl ohne Offset (bias-free)

Es ist falsch, 'rng% N' zu nehmen - dies ergibt einen modularen Offset, wenn 2 ^ k nicht ein Vielfaches von N ist. Richtig - rejection sampling:

pseudo
// rng_bytes = 32 Bytes Hash → uint256 x = uint256 (rng_bytes)

limit = floor(2^256 / N) N while x >= limit:
rng_bytes = SHA-256 (rng_bytes )//„ mischen “nochmals deterministisch x = uint256 (rng_bytes)

result = x % N

So erhalten wir eine gleichmäßige Verteilung über die N-Ergebnisse (Roulette-Zellen, Trommelsymbole usw.).

Mini-Beispiel (Schritt-für-Schritt-Verifizierung durch den Spieler)

Angenommen:


server_seed = „b2c6... e9 “//aufgedeckt nach der Runde (hex/utf8)
client_seed = „my-client-seed “//ausgewählt von mir roundId =„ R-2025-10-17-001 “
nonce = 42 commit = „c9a1... f3 “//publ. Im Voraus

1) Commit prüfen

Zähle' SHA-256 (server_seed) 'und stelle sicher, dass es mit' commit 'übereinstimmt.

2) Deterministische RNG

Zählen:


rng = HMAC-SHA256(key=server_seed,          msg= client_seed          ":"          roundId          ":"          nonce)

3) Umwandlung in Exodus

Für Roulette (37 Zahlen) → N = 37, Rejection Sampling anwenden und'x% 37 'nehmen.

Für den Slot: Verwenden Sie mehrere RNG-Portionen, um die Walzen/Symbole gemäß der Zuordnungstabelle zu bestimmen.

4) Überprüfen Sie das Ergebnis in der Geschichte

Der Standort muss die gleichen Eingaben zeigen, die in der Berechnung verwendet wurden: 'server _ seed', 'client _ seed', 'roundId', 'nonce', 'hashAlgo', 'rngAlgo', 'mappingVersion'.

Alternative/Verstärkung: VRF (Verifiable Random Function)

Anstelle eines Commits kann der Operator (oder optional) VRF verwenden:

1. Der Smart Contract oder das öffentliche Register fragt beim Anbieter nach 'VRF (Seed)'.

2. Veröffentlicht „(random, proof)“.

3. Jeder kann den 'Proof' des gleichen öffentlichen VRF-Schlüsselpaares überprüfen.

4. Als nächstes sind die gleichen Schritte des RNG-Muppings in das Ergebnis.

Vorteile: weniger Vertrauen in den Betreiber. Nachteile: Abhängigkeit von VRF-Anbieter/Kette und mögliche Kosten.

Wie ein Casino PF korrekt implementieren sollte

Vertrag (PF-Datenvertrag)

Felder in der Rundenhistorie:

`serverSeedHash`, `serverSeedReveal`, `clientSeed`, `roundId`, `nonce`, `hashAlgo`, `rngAlgo`, `mappingVer`, `proofUrl` (опц.) , `calcVer`.
Die Werte sind im WORM-Speicher (immutable), mit Zeitstempeln (UTC).

Erzeugung von Sids

'server _ seed' wird von einem kryptoresistenten PRNG (OS CSPRNG/HSM) generiert.

Sids sollten niemals zwischen Serien wiederholt werden (Rotation).

'client _ seed' - wird vom Spieler ausgewählt oder auf dem Client generiert und bestätigt.

Commits veröffentlichen

Commits sind bis hin zu Wetten verfügbar (Historie, RSS, On-Chain-Anker).

Für Lose können Sie den Merkli-Commit-Baum mit der täglichen Veröffentlichung der Wurzel verwenden.

Offenlegung (reveal)

Vor der Veröffentlichung des Ergebnisses wird 'server _ seed' geöffnet und protokolliert.

Für eine Reihe von Runden auf einem Sitz - Offenlegung nach dem Ende der Serie (geben Sie die Richtlinie im Voraus an).

Transparentes Mupping

Die Version des Mupping-Algorithmus ('mappingVer') wird festgelegt.

Jede Änderung ('mappingVer '/' rngAlgo') - nur mit Ankündigung und neuer Commitserie.

Audit und Streitigkeiten

Roheingaben + Berechnungsaufzeichnung werden gespeichert; Bei einem Streit wird ein Bericht generiert: Eingaben → RNG → Mapping → Ergebnis.

Streams/Live: Speichern Sie die Hash-Anker von CV/RFID-Ereignissen, Videos in WORM.

Wie der Spieler die Ehrlichkeit überprüft (Checkliste)

1. Öffnen Sie den Rundenverlauf und kopieren Sie: 'serverSeedReveal', 'clientSeed', 'roundId', 'nonce', 'hashAlgo', 'rngAlgo', 'mappingVer'.

2. Zähle den Hash 'serverSeedReveal' und vergleiche ihn mit 'serverSeedHash'.

3. Berechnen Sie den RNG mit dem angegebenen Algorithmus (HMAC/Hash + Eingänge).

4. Wenden Sie „unpositioniertes“ Mupping (Rejection Sampling) auf die Anzahl der Ergebnisse an.

5. Stellen Sie sicher, dass das Ergebnis mit dem angezeigten übereinstimmt.

6. Wenn VRF deklariert ist, überprüfen Sie' proof'(Schaltfläche' Verify 'oder unabhängiges Skript/Block Explorer).

Typische Fehler (Anti-Muster)

'rng% N' ohne Rejection Sampling → verschobene Wahrscheinlichkeiten.

Versteckte oder sich ändernde' client _ seed'(wird vom Server ohne Beteiligung des Spielers generiert).

Übergenerierung von 'server _ seed' nach dem Einsatz (Commit ändert sich rückwirkend).

Undurchsichtige Änderungen an Algorithmen ohne Version/Veröffentlichung.

Wiederholung der Sids zwischen den Serien.

Kein WORM/Zeitstempel - die Reihenfolge der Ereignisse kann nicht nachgewiesen werden.

Eine Mischung aus PF und Geschäftslogik (zum Beispiel wird ein Bonus angewendet, um den Raum der Ergebnisse zu verändern, aber dies wird nicht in 'mappingVer' beschrieben).

FAQ (kurz)

Kann ich Slots und nicht nur Roulette überprüfen?

Ja. Der PF wird auf die Reihenfolge der Auswahl angewendet (z. B. der Index des Symbols auf der Walze). Es ist wichtig, dass die Wahrscheinlichkeitstabellen und die RNG-Leserichtung dokumentiert werden.

Und wenn ich meinen 'client _ seed' eingegeben habe, kann der Operator 'server _ seed' trotzdem 'aufnehmen'?

Nicht, wenn das Commit vor der Wette veröffentlicht wurde. Es erfasst 'server _ seed' und lässt sich nicht nachträglich ersetzen.

Warum werden die Sids manchmal gebündelt geöffnet?

Damit es nicht möglich ist, sid in der Serie „durchzugehen“. Dies ist zulässig, wenn das Commit im Voraus veröffentlicht wird und die Offenlegungspolitik transparent ist.

Mini-Referenzformate

Hashes: SHA-256 oder Keccak-256.

RNG: HMAC-SHA256 (Server-Sid als Schlüssel) oder SHA-256 Verkettung.

Kennungen: 'roundId' (UTC-Stempel + Spiel + Inkrement), 'nonce' (Wettzähler in der Serie).

Версии: `rngAlgo=HMAC-SHA256@1`, `mappingVer=roulette. v2`, `calcVer=wallet-7. 2`.

PF-Implementierungs-Checkliste für den Betreiber

Kryptographie und Sids

CSPRNG/HSM; einzigartige' server _ seed', dokumentierte Rotation.
'client _ seed' - vom Spieler gesteuert, im Verlauf gespeichert.

Veröffentlichungen und Speicherung

Commits vor Wetten, Zugang zum Verlauf/Veröffentlichungskanal/Anker.
WORM-Speicher, UTC-Stempel, Merkli-Batchi für Skalen.

Algorithmen

RNG und Mapping ohne Offset; die Versionierung „rngAlgo/mappingVer“.
Skript/Seite „Überprüfen Sie die Ehrlichkeit“ (Open-Source wünschenswert).

Live und Hybrid

Hash Anker CV/RFID/Phasen der Runde, Zeitschrift „wenn das Wettfenster geschlossen“.
Streitverfahren (Bericht vkhodov→iskhod, Links zu Commits/VRF).

Sicherheit und Audit

Unabhängige Prüfung des PF-Protokolls, Bug-Bounty.
Entscheidungsprotokolle sind unveränderlich; regelmäßige Reproduktionstests.

Provably Fair verwandelt „Vertrauen Sie uns“ in „überprüfen Sie selbst“. Mit Commit/Reed oder VRF, deterministischem RNG und korrektem Mupping ohne Offset wird jede Runde reproduzierbar und überprüfbar. Für den Spieler geht es um Transparenz und Vertrauen. Für den Betreiber gibt es weniger Streit, eine stärkere Marke und die Einhaltung der Vorschriften. Die Hauptsache ist Disziplin: Commits im Voraus zu veröffentlichen, Versionen von Algorithmen zu erfassen, Beweise unveränderlich zu speichern und dem Benutzer ein einfaches Verifizierungswerkzeug zu geben.