Dernière mise à jour le 27 octobre 2025 par César Fikson
Un outil de vérification dont l'équité est prouvée convient aux utilisateurs qui peuvent saisir la graine du serveur et la graine du client d'un jeu pour vérifier l'équité du mélange ; cela plaît aux joueurs de crypto-casino et renforce l'autorité dans les jeux blockchain.
Outil gratuit de vérification de l'équité prouvée
Vérification prouvable de l'équité (HMAC-SHA256) :
Vérifier les semences, reproduire les résultats, prouver l'intégrité
Cette page permet aux joueurs, aux réviseurs et aux équipes de conformité vérifier les jeux dont l'équité est prouvée en vérifiant le validation de la graine du serveur (SHA-256), en le combinant avec le graine du client et Nonce, ainsi recalculer le résultat. Pas de boîtes noires, pas d'ondes, juste HMAC-SHA256 déterministe et reproductible GNR.
Ce que signifie réellement « prouvablement équitable »
- Engagement de semences du serveur (avant le jeu): l'opérateur publie le hachage SHA-256 d'une graine de serveur secrète.
- JOUER: le résultat est dérivé de HMAC-SHA256(server_seed, pattern(client_seed, nonce)).
- Révélation (après le match): l'opérateur divulgue la graine du serveur ; le la validation doit correspondre.
- Vérification:n'importe qui peut reproduire les résultats avec les mêmes entrées. Si les résultats ne correspondent pas, ce n'est pas juste.
Tags: casino prouvé juste, Validation HMAC-SHA256, révélation de la graine du serveur, graine du client, Nonce, RNG déterministe, outil de vérification de l'équité.
Jeux pris en charge et plages de sortie
| Jeux | Source d'aléatoire | Plage de rendement | Remarques |
|---|---|---|---|
| Les Dés | Ints non biaisés du flux HMAC | 0–99 ou 0–99.99 | Précision sélectionnable. |
| Roulette (UE) | Mod int impartial 37 | 0-36 | Roue à zéro unique. |
| Roulette (États-Unis) | Mod int impartial 38 | 0–36 + 00 | 37 cartes vers « 00 ». |
| Crash (générique) | 52 premiers bits → r; mult=(1−edge)/(1−r) | ≥ 1.00× | Bord et décimales configurables. |
| Mélange de cartes | Fisher–Yates déterministe | permutation de 52 cartes | Sortie des N premières cartes. |
Comment vérifier (étape par étape)
- Collez graine du serveur (révélée) et la validation du hachage fourni avant le jeu.
- Collez graine du client et nonce de départ; choisir nombre de tours.
- Choisissez le jeu. Ajustez la précision/le bord si nécessaire.
- Cliquez à nouveau sur Vérifier et générer.
- Comparez les résultats de l’outil au journal de jeu de l’opérateur. L'engagement doit correspondre et les sorties rondes doivent s'aligner exactement.
Pourquoi l'engagement est important
Sans un hachage pré-engagé, l'opérateur pourrait échanger les graines du serveur a posteriori pour obtenir des résultats favorables. Un SHA-256 valider → révéler garantit préengagement: la graine révélée est soit hachée vers le commit d'origine (honnête) soit elle ne l'est pas (interceptée).
Modèle de sécurité : ce qui est garanti (et ce qui ne l'est pas)
- Garanti: Aucune altération après le match si la validation correspond et que les résultats sont recalculés bit par bit.
- Non garanti : politiques de paiement, RTP, règles d'arrondi, intégrations tierces ou sels hors chaîne non publiés par un opérateur. Vérifiez toujours les modèle de message exact (par exemple,
{client}:{nonce}) et tout sels les documents de l'opérateur.
Pièges courants
- faux modèle de message (ordre des jetons, séparateurs).
- Le mauvais nonce (basé sur 0 contre basé sur 1).
- Comparaison incorrecte entre la roulette UE et américaine (manipulation 00).
- Les décimales/bords du crash ne correspondent pas aux règles de la maison.
- Confusion entre Hex et UTF-8 pour les graines (les opérateurs doivent utiliser graines de texte, pas de blobs hexadécimaux (cet outil attend des chaînes UTF-8).
Avantages en matière de conformité et de confiance
- La piste de vérification:Reproduire les cycles historiques pour les enquêtes KYC/RG.
- Règlement des litiges:La preuve cryptographique est supérieure aux captures d'écran.
- Ressource digne d'un lien:Les blogs affiliés et de conformité citent naturellement vérification prouvable et équitable pages avec outils.
Liste de contrôle de dépannage
- Le
SHA256(server_seed)égal à commit publié? - Est-ce votre graine du client identique (majuscule/espace) ?
- Est le Nonce le même que dans le journal du jeu ?
- Est-ce que modèle de message correspond aux spécifications de l'opérateur ?
- Pour les séries de lots, les résultats s'alignent-ils série par série ?
FAQ (pour les extraits enrichis)
Qu'est-ce qu'un hachage de validation prouvé équitable ?
A Hachage SHA-256 de la graine du serveur est publié avant le jeu. Cela prouve que la graine existait et qu'elle ne pouvait pas être modifiée ultérieurement sans casser le hachage.
Quel hachage/HMAC cet outil utilise-t-il ?
SHA-256 pour les commits et HMAC-SHA256 (graine du serveur comme clé) pour un caractère aléatoire par tour, une approche standard de l'industrie.
Puis-je vérifier les multiplicateurs de crash ?
Oui. L'outil dérive r à partir des 52 premiers bits de la sortie HMAC et calcule mult = (1 − edge) / (1 − r). Configurer bord de la maison et décimales pour correspondre à l'opérateur.
Que se passe-t-il si un opérateur utilise un format différent ?
Utilisez « Avancé » pour définir le modèle de message (par exemple, {client}|{nonce}) et inclure tous les sels supplémentaires documentés par l'opérateur.
Est-ce que cela prouve le RTP ?
Non. Cela prouve intégrité des résultats, pas de calcul de paiement. Le RTP est statistique et dépend de la politique.
