RustGamblingReviews

Guides

Comment fonctionne le provably fair sur les sites Rust et comment vérifier tes tirages

Hachage de la server seed, client seeds, nonces et HMAC-SHA256 en mots simples, avec un exemple chiffré reproductible et une routine pas à pas pour vérifier n'importe quel tirage sur un site de skins Rust.

Deux joueurs de Rust en lunettes de vision nocturne visant avec des fusils à pointeur laser dans le noir

Les dix sites de notre classement présentent leurs jeux comme provably fair. L'expression a un sens précis, et la vérification qui se cache derrière, tu peux la lancer toi-même avec un outil de hachage gratuit ou quelques lignes de code. Très peu de joueurs le font. Ce guide explique ce que le système prouve, ce qu'il laisse de côté, et comment vérifier un tirage du début à la fin.

La version courte : avant que tu paries, le site verrouille une valeur secrète et t'en montre une empreinte. Tu ajoutes une entrée de ton côté. Après les paris, le site révèle le secret, et tu peux confirmer que l'empreinte correspond et que chaque résultat découle des entrées. Si les chiffres concordent, le site n'a pas pu modifier une issue après avoir vu ta mise.

Le problème que résout le provably fair

Sur un site de skins, c'est le serveur qui décide de chaque résultat. Quand tu ouvres une caisse, que tu lances un coinflip ou que tu attends un multiplicateur de crash, tu regardes l'animation d'un nombre produit sur une machine que tu ne peux pas inspecter. Sans une forme de preuve, tu dois croire que l'exploitant ne pousse pas discrètement les tirages contre toi quand ta mise est grosse.

Les casinos en ligne agréés répondent généralement à cela par des régulateurs et des audits tiers de leurs générateurs de nombres aléatoires. La plupart des sites de skins s'appuient plutôt sur une approche cryptographique. Elle a un gros avantage pour les joueurs : tu n'as pas besoin de faire confiance à un auditeur, car tu peux refaire le calcul sur ton propre ordinateur.

L'idée s'appelle un schéma d'engagement (commitment). Imagine que le site écrive son secret sur une carte, scelle la carte dans une enveloppe et te remette l'enveloppe avant le début de la partie. Il ne peut pas échanger la carte ensuite sans que tu t'en aperçoives, et tu ne peux pas lire la carte à l'avance.

Les trois entrées : server seed, client seed et nonce

Presque tous les systèmes provably fair des sites Rust utilisent les mêmes ingrédients. Les libellés varient un peu d'un site à l'autre, mais les rôles restent les mêmes.

Server seed

Une longue chaîne aléatoire générée par le site. Elle reste secrète pendant que tu joues, car quiconque la connaîtrait pourrait prédire tous les résultats. Ce que tu vois à la place, c'est son hachage, généralement produit avec SHA-256. Un hachage est une empreinte à sens unique. La même entrée donne toujours la même sortie de 64 caractères, changer un seul caractère de l'entrée change complètement la sortie, et il n'existe aucun moyen pratique de remonter du hachage à la seed.

Client seed

Une chaîne qui vient de ton côté. Les sites en génèrent une par défaut pour toi, et la plupart te laissent la modifier dans le panneau d'équité ou de paramètres. Son rôle est d'empêcher le site de choisir une server seed défavorable à toi en particulier. Le site s'est engagé sur sa seed avant de savoir ce que tu taperais, donc il n'avait aucun moyen d'ajuster l'une à l'autre.

Nonce

Un compteur qui démarre à 0 ou à 1 et augmente de un à chaque pari que tu places avec la même paire de seeds. Il permet de réutiliser une même server seed et une même client seed pour des centaines de paris tout en obtenant un résultat neuf à chaque fois.

Quand tu veux contrôler tes résultats, tu demandes au site de renouveler la seed. Il révèle l'ancienne server seed en clair, te montre le hachage d'une nouvelle et remet le nonce à zéro. Tout ce que tu as joué avec l'ancienne seed peut maintenant être vérifié.

Comment les entrées deviennent un résultat

La recette la plus courante est HMAC-SHA256. HMAC est une méthode standard pour combiner une clé secrète et un message afin de produire un hachage. Sur la plupart des sites Rust, la server seed est la clé, et le message est la client seed et le nonce accolés, souvent avec deux-points, comme clientseed:nonce. Certains sites ajoutent un numéro de round ou un ID de jeu : lis donc toujours la formule exacte sur la page d'équité du site.

La sortie est une chaîne hexadécimale de 64 caractères. Le site transforme ensuite une partie de cette chaîne en un nombre compris entre 0 et 1. Une méthode typique prend les huit premiers caractères hexadécimaux (32 bits), les convertit en entier et divise par 4 294 967 296, soit 2 puissance 32. Cette décimale est ensuite appliquée au jeu :

  • Dice et upgrader : multiplie par 100 pour obtenir un tirage de 0.00 à 99.99, puis compare-le à la cible.
  • Roulette : multiplie par le nombre de cases de la roue et arrondis à l'entier inférieur pour choisir une case.
  • Caisses : multiplie par le nombre total de tickets de la caisse, de sorte qu'un skin qui possède 1 % des tickets gagne sur 1 % des tirages.
  • Crash : injecte le nombre dans une formule qui le transforme en multiplicateur, avec l'avantage de la maison intégré. Notre guide de stratégie au crash détaille cette formule et ce qu'elle implique pour les cibles de cash-out.

Un exemple chiffré reproductible

Les seeds ci-dessous sont inventées pour cet exemple : tu peux donc vérifier notre arithmétique avec n'importe quel calculateur HMAC-SHA256.

  1. Server seed : example-server-seed-01. Son hachage SHA-256 commence par a5275da7ccca3f73. C'est ce hachage que le site t'afficherait avant de jouer.
  2. Client seed : my-own-client-seed. Nonce : 1. Le message est donc my-own-client-seed:1.
  3. HMAC-SHA256 avec la server seed comme clé et ce message comme entrée donne un résultat qui commence par 4cdcf221.
  4. Le nombre hexadécimal 4cdcf221 vaut 1 289 548 321 en décimal. Divisé par 4 294 967 296, cela donne environ 0,30025.
  5. Sur une échelle de dice de 0 à 100, cela donne un tirage de 30,02. Sur une roulette de 15 cases, 0,30025 fois 15 fait environ 4,5, ce qui arrondi à l'entier inférieur donne la case 4 (en comptant la première case comme 0).

Relance les mêmes seeds avec le nonce 2 et tu obtiens un hachage complètement différent, commençant par 6486ccbd, ce qui donne environ 0,3927. Rien dans le premier tirage ne t'apprend quoi que ce soit sur le second. Cette indépendance est tout l'intérêt : il n'y a aucun schéma à lire dans un historique de paris, car chaque résultat est un hachage neuf.

Comment vérifier un tirage toi-même, étape par étape

La première vérification complète prend un moment. Ensuite, ce ne sont plus que quelques minutes de copier-coller. Fais-la d'abord sur un petit solde, pour connaître la procédure avant qu'un résultat compte vraiment pour toi.

  1. Ouvre le panneau d'équité avant de parier. Il est généralement lié depuis l'écran du jeu, le pied de page ou les paramètres de ton profil. Enregistre la server seed hachée quelque part en dehors du site, comme une note sur ton téléphone ou une capture d'écran.
  2. Définis ta propre client seed. Remplace celle par défaut par quelque chose que tu as tapé toi-même. Tape n'importe quoi au clavier. Elle n'a pas besoin d'être mémorable.
  3. Joue, et note les paris qui t'intéressent. Écris le nonce affiché à chaque pari, ou retrouve-le plus tard dans ton historique de paris.
  4. Renouvelle la seed. Le site révèle l'ancienne server seed. Copie-la.
  5. Vérifie l'engagement. Passe la server seed révélée dans n'importe quel outil SHA-256. La sortie doit correspondre au hachage que tu as enregistré à l'étape 1, caractère pour caractère.
  6. Recalcule le tirage. Utilise HMAC-SHA256 avec la server seed révélée, ta client seed et le nonce, puis applique la conversion publiée par le site. En PHP, c'est un seul appel à hash_hmac, et le module hmac de Python fait la même chose en quelques lignes.
  7. Compare. Le nombre que tu calcules doit produire l'issue enregistrée dans ton historique.

La plupart des sites proposent aussi un vérificateur intégré où tu colles les seeds. C'est pratique, mais il s'exécute avec le propre code de l'exploitant. Pour une vérification qui ne dépend pas du tout du site, utilise au moins une fois un outil indépendant ou ton propre script.

Pourquoi l'étape 2 compte : si tu ne changes jamais la client seed par défaut, c'est le site qui a généré les deux seeds. En théorie, il aurait pu chercher une server seed qui produise une mauvaise série contre cette client seed précise. Choisir ta propre client seed une fois le hachage de la server seed affiché à l'écran ferme cette brèche.

Les jeux partagés fonctionnent un peu différemment

Les modes solo comme le dice, l'upgrader et l'ouverture de caisses en solo peuvent tourner sur ta paire de seeds personnelle. Les jeux où de nombreux joueurs partagent un même résultat, comme le jackpot, le coinflip, les case battles, les rounds de roulette et le crash, ne peuvent pas laisser la client seed d'un joueur décider de l'issue de tous. Les sites gèrent cela de quelques façons courantes.

  • Une chaîne de hachages. Courante au crash. Le site génère à l'avance une longue chaîne de hachages, où le hachage de chaque round est le SHA-256 de celui du round suivant. Il publie le dernier hachage de la chaîne avant que le premier round soit joué, et tu peux vérifier que chaque round révélé se hache vers le précédent. Chaque résultat de la chaîne était fixé avant que quiconque place un pari.
  • Une seed publique extérieure au site. Le site s'engage sur sa server seed, puis y mélange une valeur que personne ne pouvait connaître à l'avance, comme le hachage d'un futur bloc d'une blockchain publique. Comme ce bloc n'existait pas quand le site s'est engagé, le site n'a pas pu ajuster sa seed en conséquence.
  • Des engagements par round. Au jackpot et au coinflip, la seed hachée du round apparaît à l'ouverture du round, et la seed en clair ainsi que le ticket gagnant sont affichés à la fin.

Le principe de vérification est le même dans chaque cas. Trouve l'engagement qui était public avant le round, confirme que la valeur révélée lui correspond, puis recalcule le résultat. Pour comprendre comment un ticket gagnant devient un gagnant dans une cagnotte partagée, consulte notre guide sur les probabilités du coinflip et du jackpot. Les case battles mélangent les deux approches, ce que nous traitons dans les case battles expliquées.

Ce que le provably fair ne prouve pas

Un tirage vérifié prouve une seule chose, étroite : le résultat est issu d'entrées auxquelles le site s'était engagé avant ta mise. C'est utile, mais les joueurs lisent souvent dans le badge bien plus que ce qu'il soutient.

  • Il ne dit rien de l'avantage de la maison. Un jeu de crash avec un gros avantage peut être parfaitement provably fair. L'avantage se trouve dans la formule publiée qui transforme le nombre aléatoire en multiplicateur ou en chance de gain. Équitable signifie que le site a suivi ses propres règles, et ces règles favorisent toujours le site sur la durée.
  • Il ne vérifie pas les prix. Si une caisse liste un skin à une valeur bien supérieure à son prix de vente sur le Marché de la communauté Steam, le tirage peut être équitable alors que la caisse reste une mauvaise affaire. Notre guide de l'upgrader montre comment la valorisation des objets déplace discrètement les vraies probabilités.
  • Il ne couvre pas les retraits. Un site peut faire tourner des seeds irréprochables et pourtant retarder des paiements, geler des comptes ou réécrire ses conditions. C'est pourquoi l'équité n'est qu'une entrée de notre méthode de notation, à côté de la vitesse des retraits et de la confiance.
  • Il ne fonctionne que si quelqu'un vérifie. Un engagement que personne ne compare n'est qu'une suite de caractères sur une page.

Les signaux d'alerte sur une page d'équité

Vérifier les seeds est une étape de routine quand nous testons un site. Voici ce qui nous rend méfiants, à peu près du plus bénin au plus grave.

Ce que tu voisCe que cela signifieQue faire
Aucune option pour changer la client seedLe site contrôle toutes les entrées de tes tirages personnelsAborde les modes solo avec plus de prudence
Un bouton de vérification mais aucune formule publiéeTu ne peux contrôler les résultats qu'avec le code du siteDemande la formule exacte au support avant de déposer beaucoup
Le hachage de la server seed n'apparaît qu'après ton pariIl n'y a pas de véritable engagementNe considère pas le jeu comme provably fair
Les anciennes server seeds ne peuvent jamais être révéléesRien ne peut être vérifiéPareil
La seed révélée ne se hache pas vers l'engagement enregistréLa seed a été changée, ou la page est casséeArrête de jouer, fais des captures d'écran de tout et contacte le support

Si tu tombes un jour sur la dernière ligne, conserve tes preuves : le hachage enregistré, la seed révélée, les ID de paris et l'heure de chaque pari. Une seule différence peut être un bug d'affichage, mais c'est exactement le genre de signalement crédible de joueur qui nous pousse à revérifier un site.

Une routine raisonnable pour les joueurs ordinaires

Tu n'as pas besoin de vérifier chaque pari. Une routine légère attrape la plupart des problèmes sans transformer une session en devoirs.

  • Définis une nouvelle client seed chaque fois que tu commences à jouer sur un nouveau site.
  • Fais une capture d'écran de la server seed hachée avant de jouer.
  • Renouvelle après la session et contrôle l'engagement, ce qui représente un seul calcul SHA-256.
  • Recalcule le ou les deux résultats qui ont le plus compté, comme une grosse perte à l'upgrader ou une battle que tu étais sûr de devoir gagner.
  • De temps en temps, refais la vérification complète avec un outil indépendant plutôt qu'avec le vérificateur du site.

Une vérification propre signifie que les pertes que tu subis sont celles que les maths publiées prédisent, pas davantage. L'avantage reste là sur chaque tirage. La suite pratique est de décider à l'avance quelle part de ces pertes attendues tu acceptes de payer pour le divertissement ; notre page sur le jeu responsable présente des limites simples et les outils qui aident à les respecter.

  • #provably fair
  • #probabilités
  • #sécurité
  • #guides

Questions fréquentes

Un site provably fair peut-il quand même tricher ?

Il ne peut pas modifier un résultat engagé sans que la vérification du hachage échoue. Il peut quand même appliquer un gros avantage de la maison, surévaluer des objets dans des caisses ou retarder des retraits, car le provably fair ne couvre que la façon dont le tirage est produit.

Dois-je changer ma client seed ?

Non, mais tu devrais. Une client seed choisie après l'affichage du hachage de la server seed signifie que le site n'a pas pu choisir sa seed en pensant à ta valeur.

Pourquoi le site n'affiche-t-il pas simplement la server seed avant que je joue ?

Quiconque connaît à la fois la server seed et la client seed peut calculer tous les résultats à venir. Le hachage permet au site de s'engager sur sa seed sans révéler les tirages futurs.

Quel outil puis-je utiliser pour vérifier les tirages ?

N'importe quel calculateur SHA-256 et HMAC-SHA256 convient, y compris des outils en ligne gratuits et les fonctions intégrées de PHP, Python ou JavaScript. Utilise le vérificateur du site pour la commodité et un outil indépendant pour la vérification qui compte.

SHA-256 est-il assez sûr pour cela ?

Oui. C'est un standard très répandu, aussi utilisé dans le minage du Bitcoin, et il n'existe aucun moyen pratique connu de l'inverser ni de trouver une seconde seed qui produise le même hachage.

Continuer la lecture

Guides liés

Tous les guides