Comment fonctionnent vraiment les dés provably fair — et pourquoi nous publions une chaîne de hachage pour chaque partie

Un tour d'horizon de la génération de dés par commit-reveal en SHA-512, pourquoi c'est important pour le backgammon en ligne, et pourquoi 6proclub est la seule plateforme à fournir une chaîne de hachage vérifiable pour chaque type de jeu.

2026-05-04

Si vous avez déjà vécu en ligne une longue et douloureuse série de défaites, vous avez sans doute eu la même pensée que tout joueur de backgammon depuis la sortie du premier client internet : ce truc est-il truqué ?

La réponse honnête, pour presque tous les sites que vous pourriez citer, c'est que vous n'avez aucun moyen de le savoir. Un serveur quelque part appelle son propre générateur de nombres aléatoires. Vous êtes obligé de lui faire confiance. Toute la mécanique — le RNG, le donneur, les gains — se cache derrière une porte fermée. « Faites-nous confiance » : voilà tout le modèle d'équité.

Nous ne pensons pas que ce soit suffisant, et nous avons conçu 6proclub pour que vous n'ayez à nous croire sur parole pour aucun lancer. Chaque lancer de dés, dans chaque type de jeu que nous proposons, est généré au moyen d'une chaîne de hachage commit-reveal publique que vous pouvez vérifier vous-même, après coup, avec rien de plus que sha256, sha512 et les valeurs que nous publions à la fin de votre partie.

Cet article explique comment cela fonctionne, en langage clair, et pourquoi nous pensons être la seule plateforme de backgammon à le faire sur l'ensemble de ses types de jeu.

Le problème du « faites-moi confiance »

Un jeu de dés traditionnel en ligne ressemble à ceci :

  1. Le serveur choisit deux nombres entre 1 et 6.
  2. Le serveur indique à votre client de quels nombres il s'agit.
  3. Votre client anime les dés et vous jouez votre coup.

C'est tout. Le « hasard », c'est ce que le serveur veut bien dire. Il n'y a aucune piste d'audit. Si l'opérateur ajustait discrètement la distribution au détriment des joueurs sur le point de gagner de l'argent, vous n'en sauriez jamais rien — et un auditeur extérieur muni d'un instantané trimestriel non plus, car le temps que quiconque regarde, la seule preuve qui subsiste est ce que le serveur a bien voulu consigner.

Ce n'est pas une hypothèse. C'est exactement la structure qui a produit chaque scandale d'équité du jeu en ligne de ces vingt dernières années.

Le commit-reveal, en version courte

Un schéma de commit-reveal est la construction cryptographique la plus simple qui résout ce problème. L'idée est la suivante :

  1. Avant qu'aucun lancer n'ait lieu, le serveur choisit une longue graine secrète.
  2. Le serveur publie le hachage de cette graine (le commit).
  3. La partie se déroule. Le serveur utilise la graine, combinée à un compteur par lancer et à votre propre contribution, pour dériver chaque valeur de dé.
  4. À la fin de la partie, le serveur publie la graine d'origine (le reveal).

N'importe qui peut alors reprendre la graine révélée, la passer dans la même fonction de hachage et confirmer que le résultat correspond au commit publié avant le début de la partie. Comme les hachages cryptographiques sont résistants à la préimage, le serveur ne pouvait pas changer d'avis en cours de route et produire une graine dont le hachage correspondrait au même commit tout en générant des lancers différents.

Autrement dit : le serveur doit verrouiller son hasard avant de voir comment la partie va tourner. Cette seule propriété constitue tout le fondement du jeu provably fair.

Comment 6proclub s'y prend concrètement

Nous utilisons deux hachages bien étudiés, chacun pour la tâche à laquelle il excelle : SHA-256 pour la vérification commit/reveal, SHA-512 pour la dérivation de chaque lancer. Pour chaque partie, la chaîne se présente ainsi :

serverSeed       →  secret aléatoire, généré au début de la partie
commit           =  SHA-256(serverSeed)            // publié AVANT tout lancer
roll_n           =  SHA-512(serverSeed : clientSeed : nonce : rollNumber)
                    → réduit à deux valeurs de dés 1..6

Vous apportez votre propre clientSeed — généralement des octets aléatoires issus de votre navigateur. Le serveur ne peut pas biaiser la chaîne à votre détriment, car chaque lancer dépend de votre graine, que le serveur n'a pas vue et ne peut pas prédire au moment où le commit est réalisé.

Lorsque la partie se termine, nous publions :

  • La serverSeed d'origine.
  • La clientSeed.
  • Le compteur de lancers à chaque étape.

Vous hachez vous-même la serverSeed avec SHA-256 et confirmez qu'elle correspond au commit affiché au départ. Si cela correspond, la chaîne est intacte. Et si la chaîne est intacte, les lancers étaient déterminés dès le début de la partie — avant que l'un ou l'autre de nous ne sache comment elle allait tourner.

C'est là tout le contrat d'équité, et il est garanti par les mathématiques, non par notre promesse.

Pourquoi « chaque type de jeu » est ce qui compte

Vous trouverez une poignée de plateformes en ligne qui publient un mécanisme d'équité pour un seul produit — le plus souvent une machine à sous ou un unique jeu de dés. La chaîne est câblée dans ce produit précis, et s'arrête là.

6proclub est la seule plateforme de backgammon à notre connaissance qui fait tourner la même chaîne de hachage vérifiable sur chaque type de jeu que nous proposons — le backgammon, la war, et chaque jeu que nous ajouterons ensuite. Quand nous lançons un nouveau jeu, la couche d'équité n'est pas greffée comme une fonctionnalité ; elle est le socle. Il n'existe pas de « on rendra ça vérifiable plus tard ». Il n'existe aucune version de nos jeux où les dés ou le mélange ne feraient pas partie de la chaîne.

C'est un choix que nous avons fait au niveau de l'architecture, et c'est le choix dont nous sommes le plus fiers.

Ce que vous devriez réellement vérifier

Quand une partie se termine sur 6proclub, ouvrez la page de vérification de cette partie et cherchez trois choses :

  1. Le commit. Assurez-vous qu'il était visible avant le début de la partie — l'horodatage du commit précède le premier lancer.
  2. Le reveal. Hachez vous-même la serverSeed avec SHA-256 et confirmez qu'elle correspond au commit. (echo -n "<seed>" | sha256sum fera l'affaire sous Linux.)
  3. Les lancers. Pour chaque lancer, la dérivation publiée doit reproduire les dés que vous avez réellement vus sur le plateau — appliquez SHA-512 à serverSeed:clientSeed:nonce:rollNumber exactement comme nous le décrivons sur la page de vérification.

Si l'une de ces trois vérifications échoue, nous avons un problème et nous voulons en être informés immédiatement. Écrivez-nous. Nous corrigerons la chaîne ou rembourserons la partie, dans cet ordre.

L'essentiel

La confiance dans le jeu en ligne ne devrait pas être une simple impression. Ce devrait être une propriété que vous pouvez vérifier avec sha512sum et quelques minutes de votre temps. Toute autre approche n'est qu'un argument marketing.

Nous avons bâti 6proclub sur la conviction que plus il est facile pour un joueur sceptique de nous prendre en flagrant délit de triche, plus nous gagnons le droit de demander à quiconque de jouer ici pour de l'argent. La chaîne de hachage, c'est ainsi que nous tenons cette promesse — et elle tourne sous chaque jeu que nous proposerons un jour.

Jouez ici. Vérifiez vos parties. Dites aux autres joueurs ce que vous avez trouvé.