Qu'est-ce que Provably Fair et comment vérifier l'honnêteté du jeu

Qu'est-ce que Provably Fair (PF)

Provably Fair est un protocole qui permet de vérifier cryptographiquement que le résultat du tour était aléatoire et ne pouvait pas être remplacé par un opérateur après le pari.

L'idée : d'abord est publié commit (hachage serveur caché seed), puis après la mise est révélée revil (serveur seed lui-même), et n'importe qui peut vérifier le hachage et jouer RNG, compte tenu du client seed joueur et les identifiants de round.

Protocole de base : commit → bet → reveal

1. Commit : avant le début des tours, le serveur génère un 'server _ seed' aléatoire et publie son hash :


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

Commit peut être publié dans l'histoire/blockchain/magazine.

2. Pari : le joueur sélectionne ou confirme son 'client _ seed' (de l'UI ou le sien), envoie le pari avec :


client_seed, roundId, nonce

3. Reveal : après la fermeture des paris, le serveur révèle 'server _ seed' (et 'salt's'il y en avait) afin que tout le monde puisse vérifier :


SHA-256(server_seed         salt) = = commit//contrôle d'intégrité

4. RNG : le nombre de aléas est déterministe et reproductible :


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

5. Mupping en exode : convertir 'rng' en une gamme de jeu sans décalage (voir ci-dessous).

💡 Pourquoi le nonce ? Pour qu'un seul 'server _ seed' puisse faire de nombreux tours sans risque de prévisibilité : 'nonce' incrémente chaque tour/pari.

Comment obtenir un nombre sans décalage (bias-free)

Il n'est pas correct de prendre 'rng % N' - cela donne un décalage modulaire si 2 ^ k n'est pas un multiple de N. C'est vrai - réjection sampling :

pseudo
// rng_bytes = 32 octets de hachage → uint256 x = uint256 (rng_bytes)

limit = floor(2^256 / N) N while x >= limit:
rng_bytes = SHA-256 (rng_bytes )//«  mélanger  »à nouveau de manière déterministe x = uint256 (rng_bytes)

result = x % N

C'est ainsi que l'on obtient une distribution uniforme sur N résultats (cellules de roulette, symboles de tambour, etc.).

Mini-exemple (vérification étape par étape par le joueur)

Supposons :


server_seed = « b2c6... e9  »//divulgué après le tour (hex/utf8)
client_seed = « my-client-seed  »//j'ai choisi roundId =«  R-2025-10-17-001  »
nonce = 42 commit = « c9a1... f3  »//coffre. D'avance

1) Vérifier commit

Comptez 'SHA-256 (server_seed)' et assurez-vous qu'il correspond à 'commit'.

2) RNG déterministe

Compter :


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

3) Convertir en exode

Pour la roulette (37 nombres), → N = 37, appliquer un sampling de réparation et prendre « x % 37 ».

Pour la fente : utiliser plusieurs portions de RNG pour déterminer les rouleaux/symboles selon la table de distribution.

4) Vérifier avec le résultat dans l'histoire

Le site doit afficher les mêmes entrées que celles utilisées dans le calcul : 'server _ seed', 'client _ seed', 'roundId', 'nonce', 'hashAlgo', 'rngAlgo', 'mappingVersion'.

Alternative/gain : VRF (Verifiable Random Function)

Au lieu de commit, l'opérateur peut (ou en option) utiliser VRF :

1. Un contrat intelligent ou un registre public est demandé au fournisseur « VRF (seed) ».

2. Publié par '(random, proof)'.

3. N'importe qui peut vérifier 'proof'avec la même paire de clés publiques VRF.

4. Ensuite, les mêmes étapes de mapping RNG dans l'exode.

Avantages : moins de confiance dans l'opérateur. Inconvénients : dépendance vis-à-vis du fournisseur/circuit VRF et coût possible.

Comment le casino doit mettre en œuvre PF correctement

Contrat (contrat de données PF)

Champs dans l'histoire de la ronde :

`serverSeedHash`, `serverSeedReveal`, `clientSeed`, `roundId`, `nonce`, `hashAlgo`, `rngAlgo`, `mappingVer`, `proofUrl` (опц.) , `calcVer`.
Les valeurs sont dans le stockage WORM (immutable), avec les tampons temporels (UTC).

Génération de sièges

'server _ seed'est généré par le cryptomonnaie PRNG (OS CSPRNG/HSM).

Les sides ne doivent jamais se répéter entre les séries (rotation).

'client _ seed' est sélectionné par le joueur ou généré sur le client et confirmé.

Publication de commits

Les commits sont disponibles avant les paris (historique, RSS, on-chain-ancre).

Pour les lots, vous pouvez utiliser l'arbre Merkley Commit avec la publication quotidienne de la racine.

Divulgation (reveal)

Avant de publier le résultat, 'server _ seed' est ouvert et logé.

Pour une série de tours sur un siège - divulgation après la fin de la série (indiquer la politique à l'avance).

Mapping transparent

La version de l'algorithme de mapping ('mappingVer') est fixe.

Toute modification ('mappingVer '/' rngAlgo') n'est faite qu'avec une annonce et une nouvelle série de commits.

Audit et litiges

Les entrées brutes + l'enregistrement des calculs sont conservés ; en cas de litige, un rapport est généré : entrées → RNG → mapping → exode.

Strims/Live : stocker les ancres de hachage des événements CV/RFID, vidéo - dans WORM.

En tant que joueur vérifier l'honnêteté (checklist)

1. Ouvrez l'historique du tour et copiez : 'serverSeedReveal', 'clientSeed', 'roundId', 'nonce', 'hashAlgo', 'rngAlgo', 'mappingVer'.

2. Comptez le hash 'serverSeedReveal' et comparez avec 'serverSeedHash'.

3. Compter le RNG selon l'algorithme indiqué (entrées HMAC/Hash +).

4. Appliquer le mapping « sans place » au nombre de résultats.

5. Assurez-vous que le résultat est le même que celui indiqué.

6. Si VRF est déclaré, vérifiez 'proof' (bouton « Verify » ou script indépendant/bloc explore).

Erreurs types (anti-modèles)

'rng % N' sans réjection sampling → probabilités décalées.

« client _ seed » caché ou changeant (généré par le serveur sans la participation du joueur).

La transgénération 'server _ seed' après le pari (commit change rétroactivement).

Modifications opaques des algorithmes sans version/publication.

Répétition des sièges entre les séries.

Pas de timbres WORM/Time - vous ne pouvez pas prouver l'ordre des événements.

Le mélange de PF et de logique d'entreprise (par exemple, le bonus est appliqué de manière à modifier l'espace des résultats, mais ce n'est pas décrit dans « mappingVer »).

FAQ (court)

Puis-je vérifier les slots, pas seulement la roulette ?

Oui, oui. PF est appliqué à la séquence d'élection (par exemple, l'indice de symbole sur le tambour). Il est important que les tables de probabilités et l'ordre de lecture du RNG soient documentés.

Et si j'entre mon 'client _ seed', l'opérateur peut quand même "choisir 'server _ seed' ?

Pas si le commit a été publié avant le pari. Il fixe 'server _ seed' et ne le remplace pas rétroactivement.

Pourquoi les sièges sont-ils parfois révélés par paquet ?

Pour qu'il n'y ait pas moyen de « faire » un sid dans la série. Cela est acceptable si le commit est publié à l'avance et si la politique de divulgation est transparente.

Mini-référencement des formats

Hashi : SHA-256 ou Keccak-256.

RNG : HMAC-SHA256 (sid serveur comme clé) ou SHA-256 concaténation.

Identifiants : 'roundId' (tampon UTC + jeu + incrément),' nonce '(compteur de paris dans la série).

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

Chèque de mise en œuvre PF pour l'opérateur

Cryptographie et sides

CSPRNG/HSM; unique 'server _ seed', rotation documentée.
'client _ seed' - géré par le joueur, est conservé dans l'histoire.

Publications et stockage

Commits avant les paris, accès à l'historique/canal de publication/ancre.
Stockage WORM, tampons UTC, batchi mercli pour l'échelle.

Algorithmes

RNG et mapping sans déplacement ; versioner 'rngAlgo/mappingVer'.
Script/page « Vérifier l'honnêteté » (open-source souhaitable).

Live et hybride

L'ancre de hachage CV/RFID/phases du cycle, le magazine « quand la fenêtre de paris a été fermée ».
Procédures de litige (rapport vkhodov→iskhod, références aux commits/VRF).

Sécurité et audit

Audit indépendant du protocole PF, bug-bounty.
Les logs de décision sont immuables ; tests de reproduction réguliers.

Provably Fair transforme « croyez-nous » en « vérifiez par vous-même ». Avec commit/revil ou VRF, le RNG déterministe et le mapping correct sans déplacement, tout tour devient reproductible et vérifiable. Pour un joueur, c'est de la transparence et de la confiance. Pour l'opérateur - moins de litiges, plus de marque et de conformité aux exigences des régulateurs. L'essentiel est la discipline : publier les commits à l'avance, enregistrer les versions des algorithmes, stocker les preuves invariablement et donner à l'utilisateur un outil de vérification simple.