ZK Color Sort vérifie les scores du puzzle quotidien on-chain avec des preuves à connaissance nulle

2026-08-19

gaming · zero-knowledge · smart-contracts · mainnet · puzzle · discovery · web · updated

ZK Color Sort vérifie les scores du puzzle quotidien on-chain avec des preuves à connaissance nulle

Un puzzle quotidien avec un tableau de scores cryptographique

Le ZK Color Sort ressemble au jeu de transvasement de couleurs auquel on joue sur son téléphone en attendant un café : douze tubes, dix couleurs, versez jusqu'à ce que chaque tube ne contienne qu'une seule couleur. La particularité réside dans ce que la page demande lorsque vous terminez. « Connectez votre portefeuille Algorand pour débloquer cette fonctionnalité », lit-on à côté d'un bouton « Scores » et d'un compteur de coups. Ce n'est pas un paywall. Connecter un portefeuille pris en charge — actuellement Lute ou Pera — est l'entrée vers le véritable objectif du jeu : soumettre votre score à un smart contract du mainnet d'Algorand, accompagné d'une preuve à connaissance nulle, un certificat cryptographique qui atteste qu'une affirmation est vraie sans révéler les données qui la sous-tendent. Ici, l'affirmation est « j'ai résolu ce puzzle précis en N coups », et les données gardées privées sont la suite de coups elle-même. Jouer au puzzle ne nécessite aucun portefeuille ; le classement verrouillé par preuve est la couche on-chain.

Le puzzle du jour est lui-même tiré de la chaîne. Le frontend demande à un indexeur d'Algorand le premier en-tête de bloc après minuit UTC et en dérive le plateau de manière déterministe à partir de la graine de cet en-tête, si bien que le défi est public et reproductible à partir de l'historique de la chaîne, plutôt que choisi par un développeur. Les règles suivent le format standard de Color Sort, défini avec précision dans le README du projet : douze tubes d'une capacité de quatre ; dix couleurs apparaissant chacune exactement quatre fois ; deux tubes vides pour recevoir les versements ; un versement valide déplace la séquence contiguë maximale d'une seule couleur vers un tube vide ou dont la couleur de surface correspond ; le puzzle est résolu lorsque chaque tube non vide est entièrement monochrome. Le score correspond au nombre de coups, le plus faible étant le meilleur, et les records locaux avec leur historique complet de coups vivent dans le localStorage du navigateur. Le registre on-chain n'accepte jamais un score qui ne bat pas le meilleur score enregistré par le joueur.

Ce que la preuve à connaissance nulle prouve réellement

Tout classement on-chain pour un jeu d'adresse a un problème de crédibilité : un contrat qui accepte un nombre acceptera n'importe quel nombre. Un serveur de confiance qui valide les parties réintroduit la centralisation, et publier la solution gagnante divulgue la stratégie qui l'a produite. ZK Color Sort tente une troisième voie : prouver, sans montrer.

Lorsqu'un joueur soumet, le navigateur exécute un circuit Circom via snarkjs, la bibliothèque open source de génération de preuves en JavaScript, et produit une preuve Groth16, l'un des schémas à connaissance nulle les plus utilisés. La première soumission télécharge la clé de preuve d'environ 55 Mo que le jeu fournit comme ressource statique ; ensuite, tout le pipeline s'exécute côté client, sans serveur de preuve derrière le jeu. Le choix de la pile est délibéré : le README de la bibliothèque snarkjs-algorand note que gnark, le compilateur derrière le vérificateur alternatif AlgoPlonk, ne prend pas en charge WebAssembly, ce qui exclurait la génération de preuves dans le navigateur — snarkjs est en TypeScript et s'exécute là où se trouve le joueur.

Le circuit est calibré sur le profil exact de ce jeu — douze tubes, capacité quatre, jusqu'à 120 coups, dix couleurs, deux tubes vides — et applique la sémantique complète du jeu : un plateau de départ valide, des coups légaux selon les règles de versement ci-dessus, des transitions d'état correctes après chaque coup, un plateau final entièrement résolu, et un nombre de coups égal au nombre de coups actifs. Ce qui est public et ce qui reste privé constitue toute la conception :

Concept	Implication concrète
Public : le plateau de départ	N'importe qui peut confirmer à quel puzzle correspond un score
Public : le nombre de coups	Le nombre que le registre stocke et sur lequel le classement s'appuie
Public : l'identité du puzzle et l'adresse du portefeuille	Intégrés à la preuve, si bien qu'une preuve générée pour un puzzle ou un compte ne peut pas être rejouée pour un autre
Privé : la suite complète des coups	Les observateurs peuvent vérifier l'affirmation sans copier la stratégie gagnante — la mort habituelle des classements on-chain de puzzles

Le registre de scores on-chain

Le destinataire est un smart contract nommé PuzzleScores, écrit en Algorand TypeScript, le langage de contrat moderne compilé par Puya qui a remplacé l'ancien PyTeal. Il conserve un score par paire (puzzle, portefeuille) dans le box storage de l'application — un état clé-valeur attaché au smart contract lui-même. La clé est un code de puzzle de 20 octets concaténé à l'adresse de portefeuille de 32 octets (52 octets au total) ; la valeur est un seul octet, ce qui plafonne les scores stockés à 255 coups, bien au-delà de ce que toute résolution de ce puzzle nécessite. La création d'une entrée coûte exactement l'exigence de solde minimum du box, que le contrat dérive à l'exécution (2,500 microALGO de base plus 400 par octet), et qu'il rembourse si le joueur supprime l'entrée via removeScore. Des méthodes en lecture seule permettent à un joueur de récupérer son propre score ou celui de n'importe qui.

Il existe deux chemins d'écriture : addScore pour une première entrée, et updateScore, que le contrat n'accepte que lorsque le nouveau score est strictement inférieur au score stocké. Les deux exigent une transaction « vérificateur » accompagnante dans le même groupe atomique, et c'est là que la preuve est réellement vérifiée. Le frontend compose un groupe de trois transactions — un paiement de valeur nulle signé par un compte à signature logique (un compte dont l'autorité est un programme plutôt qu'une clé privée, dérivé de la clé de vérification du jeu), le paiement du solde minimum et l'appel à l'application. Le contrat vérifie que le paiement d'attestation provient de l'adresse de vérificateur configurée et que les signaux publics de la preuve correspondent au score déclaré, au code du puzzle et à l'expéditeur ; les calculs de vérification Groth16 s'exécutent eux-mêmes dans le programme à signature logique, qui ne produit le paiement d'attestation que lorsqu'il accepte le témoin. Comme le score, le puzzle et le portefeuille d'un joueur sont tous ancrés dans la même preuve, une soumission générée pour un puzzle ou un compte ne peut pas être recyclée pour un autre. Sur le frontend, le même box store alimente une vue en percentiles : après connexion, le jeu analyse les entrées on-chain du puzzle du jour et indique au joueur combien d'autres joueurs il a devancés.

Sur le mainnet — mais qui joue ?

Le contrat est réel, déployé et opérationnel : l'application 3603459425 a été créée au round 62,209,315, le 16 juin 2026, par le compte à l'origine du projet (qui possède le nom .algo tools.orange.algo), son vérificateur ayant été configuré quelques minutes plus tard. Elle contient désormais 94 boxes de score, et le registre montre des appels à l'application aussi récents que le round 64,130,520 — le 16 août 2026, deux jours avant la rédaction de cet article. Le bundle web confirme que le réseau par défaut du frontend est le mainnet, en accord avec l'ID d'application présent dans la configuration réseau du dépôt.

Le registre des expéditeurs raconte toutefois une histoire d'adoption plus modeste. Le portefeuille du développeur lui-même domine à la fois le journal des transactions et les clés de boxes ; un second portefeuille de soumission a été créé le jour du lancement et financé avec 1 ALGO par le développeur — un compte de test. Deux autres portefeuilles ont reçu leur premier financement de comptes sans lien créés en 2022 et 2024, ce qui correspond à des joueurs extérieurs, même si aucun ne porte de nom .algo. La lecture honnête : il s'agit d'un registre vivant mais de petite taille, dont la plupart des entrées sont attribuables aux tests du développeur, et aucune preuve d'une base de joueurs substantielle n'existe pour l'instant.

Le projet lui-même est l'œuvre d'un seul développeur — le compte GitHub funk-af, dont le profil nomme le propriétaire « Andrew » — et le même compte publie d'autres travaux de contrats Algorand, dont des dépôts décrits comme des smart contracts pour Baanx et pour le protocole de financement de carte flexible Immersve. Le dépôt du jeu affiche 18 commits datant de juin 2026 et aucune activité depuis le 18 juin, tandis que le frontend déployé et le contrat on-chain continuent de fonctionner.

Les limites du modèle de confiance

Trois mises en garde s'imposent à qui voit dans ce registre plus qu'un jeu. Premièrement, la dérivation du puzzle quotidien est une convention du frontend, pas une règle du contrat : le contrat ne vérifie jamais qu'un code de puzzle soumis correspond au puzzle dérivé du bloc du jour, et le circuit ne valide que le fait qu'un puzzle est bien formé et résolu. Une preuve pour tout puzzle bien formé du même profil de circuit serait acceptée ; rien sur la chaîne n'ancre une soumission à la date courante. Deuxièmement, l'adresse du vérificateur et le contrat lui-même sont contrôlés par le créateur — setVerifier et updateApplication sont réservés au portefeuille du créateur — si bien que l'intégrité du registre repose en fin de compte sur un seul développeur qui ne remplace pas le vérificateur ou ne réécrit pas le contrat. Troisièmement, la pile de preuve n'est pas auditée : le README de snarkjs-algorand prévient que le SDK « est un travail en cours et pas encore stable » et que « le code de ce dépôt n'a pas été audité. Utilisation à vos risques et périls ! »

Rien de tout cela ne diminue ce qui est véritablement remarquable ici : une démonstration fonctionnelle de bout en bout de génération de preuves Groth16 côté navigateur alimentant un vérificateur on-chain sur le mainnet d'Algorand, avec un puzzle quotidien alimenté par les en-têtes de blocs de la chaîne elle-même. Si le modèle mûrit — un vérificateur audité, un ancrage des puzzles imposé par le contrat et de vrais joueurs — le jeu d'adresse vérifié par ZK est un créneau doté d'une base crédible. Pour l'instant, c'est une petite expérience honnête, et elle fonctionne.

Source

Source: https://zk-colorsort.netlify.app/