Ce que prouve un engagement par hachage, et les trois choses qu'il ne peut pas prouver

L'astuce, en un paragraphe

Un hachage cryptographique transforme n'importe quelle entrée en une empreinte de longueur fixe avec deux propriétés importantes ici : on ne peut pas remonter de l'empreinte à l'entrée, et on ne peut pas trouver deux entrées avec la même empreinte. Donc si quelqu'un vous montre l'empreinte d'un secret aujourd'hui et le secret demain, vous pouvez hacher le secret et vérifier qu'il correspond. Si c'est le cas, le secret qu'on vous a montré est bien celui qu'ils avaient hier. Ils n'auraient pas pu le changer entre-temps, car un secret différent aurait une empreinte différente, et ils n'auraient pas pu choisir le secret pour correspondre à l'empreinte, car cela signifierait inverser le hachage.

C'est un schéma d'engagement, et c'est tout le contenu cryptographique du « provably fair ». La maison génère une seed serveur, publie son hachage SHA-256, joue des tours dérivés de la seed, et révèle la seed lorsque la paire est retirée. Tout le reste n'est que plomberie.

VÉRIFIÉ PAR LE MOTEUR_shared/seedApi.ts : getRandomKey renvoie {serverSeedHashed, clientSeed, nonce} ; renewRandomKey renvoie une nouvelle paire ainsi que previousServerSeed et previousServerSeedHashed, la révélation. _shared/SeedPanel.tsx désigne le champ « server seed (sha-256 commitment) ». _shared/rng.ts : sha256Hex() calcule l'empreinte et hmacSha256Utf8() le hachage par tour, avec le commentaire que le moteur de démo « GÉNÈRE des résultats avec les mêmes primitives que celles utilisées par le vérificateur pour les VÉRIFIER — une seule implémentation, afin que la démo ne puisse jamais dévier de ce que le vérificateur accepte ».

Trois choses qu'il prouve

Ce que l'engagement établit, et comment vérifier chacune d'elles

Les trois vérifications sont locales : elles nécessitent la seed révélée, votre seed client, le nonce et le code de dérivation, et rien de la part de la maison au moment de la vérification.

La troisième affirmation est celle qui fait le travail pour un joueur, et elle dépend du fait que la dérivation soit publique. Un hachage de la seed ne vous dit rien sur la façon dont la seed est devenue un jet de dés ou une carte. Ici cette fonction est livrée dans le client, le même code que la démo utilise pour générer des résultats et que le vérificateur utilise pour les vérifier, donc un tour recalculé est un véritable recalcul plutôt qu'une demande au serveur de se confirmer lui-même.

MOTEUR VÉRIFIÉ_shared/demoLocal.ts : uAt() dérive le nombre par round sous la forme u64(hmacSha256Utf8(serverSeed, `${clientSeed}-${nonce}-${cursor}`)), décrit comme correspondant à RandomUtils.generateHash côté serveur ; _shared/rng.ts transforme les sept premiers octets du HMAC en un nombre uniforme dans [0, 1) « correspondant bit à bit à l'arrondi Long→Double du serveur ». Le module de dérivation de chaque jeu associe ensuite ce nombre à un lancer, une carte ou un multiplicateur.

Le tutoriel de vérification effectue les trois étapes sur un round réel. Si vous ne l'avez jamais fait, faites-le une fois ; l'intérêt du système n'est pas que vous vérifiiez chaque round, mais que vous puissiez vérifier n'importe lequel, et la maison ne peut pas savoir à l'avance lequel.

Trois choses que cela ne peut pas prouver

Cela ne peut pas prouver que le seed était aléatoire. Un engagement fixe un seed ; il ne dit rien sur la façon dont ce seed a été choisi. Si la maison connaissait votre client seed au moment de générer le server seed, elle pourrait en principe générer des seeds jusqu'à en trouver un dont elle aime les premiers rounds, et s'engager sur celui-là. Le hash correspondrait parfaitement. La défense standard est l'ordre : le server seed est engagé en premier, et le client seed est défini ensuite, de sorte que quoi que la maison ait engagé, elle ne savait pas avec quoi cela serait combiné.

Cet ordre est précisément là où le panneau de ce site présente une limite qu'il vaut la peine d'énoncer clairement. Définir un client seed ici ne laisse pas le server seed actuel en place ; il fait pivoter la paire, et le nouveau server seed est généré par la même requête qui porte votre nouveau client seed. Depuis le client, il n'est pas possible de démontrer que le nouveau seed a été fixé avant que la requête ne soit lue. Que le serveur pré-génère ou non le prochain seed, comme le font certains opérateurs en publiant à l'avance le prochain engagement, n'est pas visible dans l'API du client, et il n'existe pas de champ « hash du prochain server seed » à vérifier. Cela a été signalé à l'équipe du jeu, et le correctif est mineur : engager le prochain server seed avant que le client seed qui lui sera associé ne soit accepté, et afficher cet engagement dans le panneau.

MOTEUR VÉRIFIÉ_shared/seedApi.ts : setClientSeed(clientSeed) appelle renewRandomKey avec le nouveau client seed et renvoie une paire fraîche au nonce 0 ; rotate() appelle le même endpoint sans seed. IHouseSeed contient serverSeedHashed, clientSeed et nonce, plus la paire précédente lors de la rotation ; aucun engagement sur le prochain seed n'est présent dans le type.

D'ici là, la version pratique de la défense est celle que le système offre déjà à tous les autres égards : la révélation. Une maison qui chercherait des seeds contre votre client seed devrait quand même révéler chaque seed à la rotation, et chaque round sous celui-ci peut être recalculé. Ce que cette limite signifie, c'est qu'une série suspecte dans les premiers rounds après un changement de seed ne peut pas être écartée par le hash seul ; elle ne peut être examinée que round par round, après la révélation.

Cela ne peut pas prouver que le jeu est équitable dans l'autre sens. « Provably fair » signifie que le hasard était honnête, pas que les chances sont équilibrées. Un jeu de dés peut être parfaitement vérifiable et rendre quand même 99% par conception ; l'avantage vit dans la table des gains, qui est un chiffre publié et une promesse distincte. L'éthique de l'avantage de la maison concerne cette promesse. L'engagement reste silencieux à ce sujet.

Cela ne prouve rien sur les rounds que personne ne vérifie. Le système est un moyen de dissuasion, pas une garantie. Un round que vous ne recalculez jamais est un round que vous avez pris sur la confiance, exactement comme partout ailleurs ; ce qui change, c'est que la confiance est optionnelle, et la maison ne peut pas savoir quand vous l'exercerez. C'est une nette amélioration par rapport à une machine à mélanger dont vous ne voyez pas l'intérieur, et une amélioration moindre que ce que le mot « preuve » laisse entendre.

Le hash est un reçu pour le hasard. Ce n'est pas un certificat pour le jeu.la phrase à retenir

Ce qui prouverait davantage

• Un prochain seed pré-engagé. Publier le hash du prochain server seed avant qu'aucun client seed ne puisse lui être associé referme la faille d'ordre mentionnée ci-dessus. C'est le seul changement qui permettrait au panneau de prouver que le seed a été fixé avant que votre saisie ne soit connue.
• Une source publique de hasard. Mélanger un beacon que personne ne contrôle, comme le réseau drand, élimine entièrement la question de savoir qui a choisi le seed ; à l'intérieur de drand décrit comment cela fonctionne et ce que cela coûte.
• Une dérivation publiée, maintenue publique. Déjà le cas ici, et la partie la plus facilement perdue lorsqu'un client est réécrit. Le vérificateur n'est honnête qu'autant que le code qu'il exécute.

Rien de tout cela ne change ce qu'est un hash. Cela change de quoi le hash est l'empreinte, et quand. Le système est assez simple pour que ses limites le soient aussi, et un joueur qui connaît les trois choses qu'il prouve est en meilleure position que celui à qui on a dit qu'il prouve tout.

FAQ

Qu'est-ce qu'un engagement par hash dans un casino provably fair ?

L'empreinte SHA-256 du server seed secret de la maison, montrée avant le jeu et vérifiée par rapport au seed lorsqu'il est révélé. Cela prouve que le seed était fixé avant vos mises et que le seed révélé est bien celui engagé.

Un hash correspondant prouve-t-il que le jeu était équitable ?

Cela prouve que le hasard n'a pas été altéré après l'engagement et, avec une dérivation publiée, que chaque résultat découle de la paire de seeds. Cela ne prouve pas que le seed a été choisi aléatoirement, et cela ne dit rien de l'avantage de la maison, qui est un chiffre publié distinct.

La maison peut-elle choisir une seed serveur qui l'avantage ?

Seulement si elle connaît la seed client avec laquelle la seed serveur sera associée au moment où elle la choisit. La défense consiste à engager la seed serveur avant que la seed client ne soit définie. Sur ce site, un changement de seed client fait tourner la paire dans la même requête, de sorte que cet ordre ne peut pas être confirmé côté client ; l'article décrit cette limite et la correction proposée.

Comment puis-je vérifier une manche moi-même ?

Faites tourner la seed pour révéler la seed serveur retirée, hachez-la pour confirmer qu'elle correspond à l'engagement qui vous a été montré, puis recalculez le HMAC-SHA256 de la seed serveur sur votre seed client, le nonce et le curseur, et passez le résultat par la dérivation publiée du jeu. Le panneau de seed effectue le recalcul dans votre navigateur.

Pourquoi le code de dérivation est-il important ?

Parce que le hash ne fait qu'ancrer la seed. Transformer la seed en un lancer ou une carte est une fonction, et à moins que cette fonction ne soit publique, un hash correspondant ne vous dit rien sur le fait que le résultat était bien celui que la seed impliquait. Ici, le client embarque la même dérivation que celle utilisée par la démo pour générer les résultats.

Le provably fair est-il meilleur qu'un audit de RNG licencié ?

Ils répondent à des questions différentes. Un audit certifie le comportement statistique d'un générateur sur de nombreux tirages ; un engagement vous permet de vérifier une manche spécifique après coup. Ni l'un ni l'autre ne remplace l'autre, et aucun des deux ne change l'avantage de la maison.

SOURCES ET RÉFÉRENCES

• Wikipedia — Schéma d'engagement : dissimulation et liaison, et engagements basés sur le hachage
• Wikipedia — HMAC : hachage à clé et son utilisation comme fonction pseudo-aléatoire
• Source du moteur Betkyo : _shared/seedApi.ts (commit, reveal et rotation), _shared/rng.ts (sha256Hex, hmacSha256Utf8, l'uniforme sur 7 octets), _shared/demoLocal.ts (dérivation uAt), _shared/SeedPanel.tsx

LES JEUX DE CET ARTICLEDice — règles et jeu gratuit →Limbo — règles et jeu gratuit →