Bonjours chers amis Steemiens,
Cet article sera le premier d'une série qui aboutira (je l'espère) à la création d'un jeu régi par le principe du provably-fair.
Cette série sera elle-même décomposée en sous-parties :
- L'axe cryptographique : comment générer les résultats de manière transparente afin d'avoir la confiance des utilisateurs ?
- L'axe programmation back-end : comment gérer les transferts de crypto-monnaies de manière automatique ? Comment assurer la sécurité du site ? Comment s'assurer qu'aucune triche ne sera possible ? Et toutes les autres questions back-end classiques...
- L'axe programmation front-end : Comment faire un site ergonomique, qui procurera la meilleure expérience à l'utilisateur ?
Donc nous allons aujourd'hui commencer par l'axe cryptographique, qui se décompose lui-même en trois parties :
- Explication du concept de provably-fair (ce que nous allons traiter dans le présent post),
- Présentation de l'algorithme cryptographique SHA256 qui va être utilisé pour la création de ce jeu,
- Comment générer une hash chain (une chaîne de résultats) en Python.
Partie 1 : Qu'est-ce que le provably-fair ?
Explications générales
L'objectif du système provably-fair est d'éliminer la défiance des joueurs envers l'opérateur (qui sera aussi appellé casino pour éviter les trop nombreuses répétitions).
Dans les jeux de hasard / argent, il existe deux grandes catégories de jeux :
- Les jeux où les joueurs jouent les uns contre les autres, et le casino se contente de prendre une commission sur les mises (comme le rake au poker). Pour ces jeux, l'opérateur n'a pas à prouver qu'il est juste (qu'il ne truque pas le résultat des parties, même si ça peut être un plus non négligeable), mais il doit prouver son indépendance (c'est-à-dire qu'il ne favorise pas un joueur par rapport à un autre).
- Les jeux où les joueurs jouent contre la casino lui-même (comme les machines à sous, la roulette) où là, la confiance est essentielle car les joueurs quitteront le jeu s'ils ont l'impression que le jeu est truqué, ou que le casino n'est pas honnête dans sa gestion. Le projet que je vais développer sous vos yeux, qui sera l'objet de ces séries, appartient à cette seconde catégorie.
La seule solution pour l'opérateur de prouver aux joueurs qu'il ne manipule pas le résultat des parties en temps réel (selon le volume de mises, selon la profondeur de sa bankroll à un instant T) est de déterminer à l'avance le résultat des futures parties, et d'offrir aux joueurs le moyen de vérifier que le résultat d'une partie n'a pas été modifié ou altéré et correspond bien à la partie qui était pré-déterminée.
Pour permettre ceci, une solution a été proposée par Dooglus sur Bitcointalk : Solution pour déployer un algorithme provably-fair par Dooglus
Les étapes de création d'un système provably-fair
- La première étape est de générer une hash chain.
Nous allons faire une présentation succinte, car cela sera détaillé très amplement dans la partie 3.
Une hash chain consiste premièrement en une clé secréte de l'opérateur (un mot de passe connu uniquement par le casino, qui, s'il est compromis, peut permettre aux joueurs de prédire les résultats des futures parties), qui une fois hashé via le protocole SHA256 (une entrée, quelle qu'elle soit, une fois hashée via le protocole SHA256 donne une chaîne de 32 nombres hexadécimaux - soit 64 caractères - unique) donnera la première server seed (le hash originel) qui sera elle-même rehashée - toujours par le protocole SHA256 - autant de fois qu'on souhaite avoir de parties pré-déterminées soit n fois, ce qui vous donnera une hash chain de longueur n.
Si vous n'avez pas tout compris, pas d'inquiètude, ce point (relativement technique) sera amplement détaillé dans les parties 2 et 3, lorsque nous expliquerons l'algorithme de cryptage SHA256 puis que nous créerons notre propre hash chain.
Ensuite, le premier hash qui sera utilisé dans le jeu sera le dernier généré (le nième élément de la hash chain), puis on remontera la chaîne en sens inverse pour les jeux suivants (n puis n-1 puis n-2, etc.).
De cette manière, le joueur peut s'assurer que les jeux sont pré-déterminés : en hashant le hash d'une partie, il DOIT obligatoirement retomber sur le hash de la partie précédente (en hashant n-1 il retrouve n), prouvant de cette manière que l'opérateur est bien en train d'utiliser la hash chain qu'il a généré.
Ce premier hash (le nième élément) est rendu public (avant le lancement du jeu), et de cette manière, à partir de cette publicité, la hash chain devient inaltérable (tant que des dispositions adéquates sont prises, comme publier ce premier hash sur une blockchain inaltérable et à condition que les joueurs restent vigilants et vérifient de leur côté que l'opérateur l'utilise bien - mais ceci est très facile).
- La deuxième étape est de choisir une client seed.
Cette étape est essentielle pour prouver aux joueurs que l'opérateur n'a pas généré un très grand nombre de hash chains pour ensuite choisir celle qui lui était le plus favorable.
Comment faire cela ?
En utilisant un élément extérieur qui est inconnu des deux parties (des joueurs et du casino). Généralement, c'est le hash d'un futur block Bitcoin ou Ethereum qui est utilisé.
De cette manière, une fois le jeu présenté publiquement :
- Les joueurs connaissent le dernier hash de la hash chain et sont désormais en capacité de s'assurer que l'opérateur utilise bien ces résultats pré-déterminés dans son jeu.
- Le casino n'a pas choisi une hash chain qui lui était favorable car tous les hashs de sa hash chain seront de nouveau hashés avec la client seed (avant de transformer ce hash en résultat exploitable, selon le jeu en question, mais ce calcul est également public) qui lui est inconnu au moment de la génération de la hash chain et de la publicité de son jeu.
Une fois que le block Bitcoin ou Ethereum choisi pour être la client seed est miné est que le hash du block est connu, l'opérateur peut désormais lancer son jeu, naviguer du dernier au premier élément de sa hash chain, générant de cette manière les résultats de chaque partie. Et les joueurs n'ont plus qu'à miser.
J'espère que vous avez apprécié cette lecture !
Si vous avez des questions, des suggestions ou quoi que ce soit, je me ferai un plaisir de discuter avec vous dans les commentaires !
A bientôt pour la deuxième partie : Le protocole SHA256
N'hésitez pas à consulter mes derniers posts :