← Projets

CCG Pokémon — Jeu de Cartes Collectibles Décentralisé

Sorbonne UniversitéDéveloppement des Algorithmes d'Application Réticulaire (DAAR)Oct. 2024

Plateforme de jeu de cartes à collectionner (CCG) décentralisée sur la blockchain Ethereum. Chaque carte est représentée comme un NFT suivant le standard ERC-721, garantissant l'unicité vérifiable, la propriété sécurisée et la transférabilité entre joueurs. Le thème Pokémon illustre l'adaptabilité du système : les sets et cartes sont récupérés depuis l'API Pokémon officielle et mintés on-chain.

Architecture globale

Le système s'articule en trois couches indépendantes :

  • Backend — récupération des sets et cartes depuis l'API Pokémon, exposition des données au frontend, gestion des cartes sauvegardées par utilisateur.
  • On-chain — smart contracts Solidity (Collection.sol + Main.sol) gérant la création de collections, le minting des NFT et le suivi de propriété sur Ethereum.
  • Off-chain — interface React intégrée à MetaMask permettant de parcourir les sets, sélectionner des cartes, les minter et consulter sa collection.
Vue d'ensemble de l'architecture globale — backend, on-chain et off-chain

Composant on-chain — smart contracts

Deux contrats Solidity collaborent pour gérer l'ensemble du cycle de vie des NFT :

Collection.sol

Définit la structure de chaque collection de cartes. Hérite de ERC721Enumerable (suivi de propriété) et ERC721URIStorage (métadonnées par token). Le constructeur assigne un nom et une capacité maximale (cardCount) à la collection. La fonction mintNFT, réservée au propriétaire du contrat, assigne une URI unique à chaque token minté.

Main.sol

Gestionnaire central de plusieurs collections. La fonction createCollection instancie de nouveaux contrats Collection stockés dans un mapping pour un accès O(1). La fonction mintCard permet au propriétaire de minter une carte dans n'importe quelle collection active et de la transférer à une adresse Ethereum cible. Un tableau owners trace les détenteurs de chaque collection.

Des fonctions utilitaires complètent le contrat : balanceOf retourne le solde de cartes d'un utilisateur sur l'ensemble des collections, tokenOfOwnerByIndex permet d'interroger un token précis par son index de propriété.

Choix ERC-721 vs ERC-1155

ERC-721 a été retenu pour son modèle d'unicité stricte — chaque token est distinct et indivisible, ce qui correspond à l'objectif de créer des cartes one-of-a-kind vérifiables. ERC-1155, bien que plus flexible (tokens fongibles et non-fongibles mixtes), dilue la notion d'unicité recherchée. Les bibliothèques OpenZeppelin ont été utilisées pour la sécurité et l'optimisation gas.

Composant off-chain — interface React

L'interface est organisée en cinq pages :

  • Home — sidebar de navigation commune avec compteur de cartes dans le panier.
  • Sets — liste des sets Pokémon récupérés depuis le backend ; clic sur un set → redirection vers la page Cards.
  • Cards — affichage de toutes les cartes du set sélectionné avec sélection multiple pour ajout au panier.
  • Transfer — initie le minting : récupération de l'adresse MetaMask connectée, chargement de l'objet Ethereum du navigateur, accès au contrat Main via son ABI et son adresse de déploiement. Une pop-up MetaMask demande confirmation de la transaction.
  • Minted Cards — affiche tous les NFT associés au compte MetaMask courant.
ERC-721standard NFT — unicité stricte par token
2 contratsCollection.sol + Main.sol
3 couchesbackend · on-chain · off-chain React

Stack

SoliditySolidity
ReactReact
Ethereum
MetaMaskMetaMask
OpenZeppelinOpenZeppelin

Équipe

Abdelkader BoumessaoudSorbonne Universitéabdelkader.boumessaoud.pro@gmail.com
Hichem BouzourineSorbonne Université

Encadrant

Guillaume Hivert

Sorbonne Université / LIP6