Critère de comparaison : où le state est stocké et où les règles sont exécutées
« On-chain games vs Web2 games » — comparaison de l’architecture des jeux on-chain et des jeux Web2 : où les règles sont exécutées et où le state du jeu est stocké (progression, inventaire, paramètres du personnage).
La différence clé entre les « jeux avec NFT » et le fully on-chain tient au fait que, dans un cas, le token peut être on-chain, tandis que la progression et les règles restent sur le serveur.
- Web2 → objets et progression — enregistrements dans la base du développeur ; l’accès est déterminé par le compte et les règles du service.
- On-chain → une partie de la logique et/ou de l’état est fixée sur la blockchain ; les actifs peuvent être des NFT, et les actions — des transactions.
- Hybride Web3 → le NFT peut être stocké dans un portefeuille, mais le gameplay et la progression sont généralement mis à jour sur le serveur.
- Fully on-chain → les règles et le state se trouvent dans les smart contracts ; les applications clientes peuvent changer, tandis que les règles d’exécution et le state du contrat (événements et enregistrements du contrat) restent sur le réseau.
Conclusion clé : en cas d’arrêt des serveurs Web2, l’accès et la progression cessent généralement. Dans un hybride Web3, le NFT reste souvent dans le portefeuille, mais l’utilité en jeu disparaît si les règles d’usage et la progression étaient côté serveur.
La « source de vérité » — la couche qui stocke les droits sur l’actif et le state final : serveur/base de données du studio ou smart contract et données du réseau.
Actualisation : définitions de l’hybride Web3 et du fully on-chain précisées, critères de vérification de la « source de vérité » ajoutés, ainsi que les conséquences du scénario « server off ».
Conclusion en 4 points : Web2, hybride et fully on-chain
Critères de comparaison : où la progression (state) est stockée et qui valide les règles (serveur ou smart contract).
- L’important n’est pas la présence d’un NFT, mais l’emplacement de stockage de la progression et la couche d’exécution des règles.
- Web2 → le serveur — source de vérité unique et point de défaillance unique.
- Hybride Web3 → le token peut rester dans le portefeuille, mais les règles d’usage sont souvent définies par le serveur.
- Fully on-chain → règles et state dans les contrats, le client — interface vers les données du réseau.
Comparaison des modèles : actifs, progression, dépendance au serveur
Comparaison par couches : source de vérité, actifs, progression, dépendance aux serveurs et conséquences de l’arrêt du service.
| Paramètre | Web2 | Hybride Web3 (partiellement on-chain) |
Fully on-chain |
|---|---|---|---|
| Source de vérité | Serveur/BD du studio | Serveur + blockchain pour une partie des droits/actifs | Smart contracts et données du réseau |
| Actifs | Enregistrement interne au jeu | NFT/tokens dans le portefeuille ; l’utilité est souvent déterminée par le serveur | NFT/tokens + règles d’usage dans le contrat |
| Progression (state) | Côté serveur | Généralement côté serveur | On-chain (state du contrat) |
| « Serveur coupé » | L’accès et la progression cessent généralement | Le NFT peut rester, mais les modes/règles/progression peuvent disparaître | Les règles et le state restent sur le réseau, l’interface peut changer |
| UX/vitesse | Maximales | Moyennes (portefeuille, signatures) | Compromis (frais, latence, infrastructure d’accès) |
| Principaux risques | Centralisation : le studio peut modifier les règles et l’accès | Le token existe, mais l’utilité dépend des serveurs | Sécurité des contrats + scalabilité et UX |
Termes de lecture : NFT, on-chain/off-chain, smart contract, state
Ensemble minimal de notions pour comparer : ce qui constitue l’actif, où le state est stocké et où les règles sont exécutées.
- NFT — token unique sur la blockchain, confirmant la propriété d’un objet numérique (par exemple, un item).
- Smart contract — code sur la blockchain qui exécute les règles et stocke/met à jour les données.
- On-chain — action ou données enregistrées sur le réseau blockchain.
- Off-chain — action ou données stockées en dehors de la blockchain (serveur, client, BD fermée).
- Fully on-chain — logique et état du jeu sur la blockchain ; le client — interface vers les données et les règles du contrat.
- Source de vérité — couche qui détermine l’état final : qui possède l’actif, quel niveau, quel inventaire.
Frontières des modèles : jeu Web2, hybride Web3, fully on-chain
Séparation par critère d’exécution : « actifs tokenisés » et « règles et state dans les contrats » — des modèles différents.
Jeux Web2 : l’état (progression, inventaire, paramètres du personnage) est stocké et mis à jour sur des serveurs centralisés.
Jeux on-chain : actions et/ou état sont enregistrés sur la blockchain, et les règles sont exécutées par des smart contracts.
Hybride Web3 : actifs tokenisés (NFT/tokens), mais une partie importante de la logique et de la progression reste off-chain.
Fully on-chain : la blockchain sert de couche d’exécution : logique et state sont dans les contrats, les interfaces peuvent varier.
Thèse clé : la présence d’un NFT ne garantit pas la persistance de l’utilité. L’utilité ne se maintient que si les règles d’usage et/ou le state critique sont ancrés dans les contrats, ou si un client compatible existe pour lire le state du contrat et appliquer les mêmes règles.
Droits sur les actifs : « dans la base » vs « dans le portefeuille »
La propriété d’un token et l’existence d’une utilité en jeu sont deux états distincts, car ils dépendent de couches différentes.
Web2 : l’actif comme enregistrement dans le système du développeur
L’item existe comme une ligne de base de données, et l’accès correspond au droit d’un compte d’utiliser les fonctions du service.
- Le compte et les règles de la plateforme déterminent quels items et modes sont disponibles.
- Le blocage du compte ou la fermeture du service met généralement fin à l’accès aux items et à la progression.
- Le transfert et l’échange sont le plus souvent limités par les règles du produit et l’infrastructure du studio.
Conséquence : l’actif reste un enregistrement en base, et non un objet indépendant hors du service.
Web3 : l’actif comme token (NFT/token) sur l’adresse du portefeuille
Le propriétaire contrôle le token via ses clés, mais l’utilité dépend de l’endroit où les règles d’usage du token sont exécutées.
- Le token peut persister indépendamment du compte du jeu, car l’enregistrement est sur le réseau.
- Si les règles d’usage du token sont définies par un serveur, le studio peut désactiver l’utilité sans toucher au token lui-même.
- Après la fermeture du service, le prix du token peut chuter en l’absence de clients compatibles ou de règles d’usage on-chain.
Conséquence : le token peut rester sur l’adresse, mais « l’utilité en jeu » disparaît lorsque les règles et la progression côté serveur sont désactivées.
Distinction : « NFT dans le portefeuille » signifie propriété du token. « Le token donne des droits en jeu » dépend de la couche où les règles d’usage sont décrites et exécutées.
Idée clé : le NFT peut persister même si l’utilité n’est plus assurée par le serveur.
Progression et vérifications : state côté serveur vs state du contrat
Question clé : où le state est mis à jour et quelle couche confirme les transitions d’état — serveur ou smart contract.
State côté serveur : progression stockée dans la base du service, la « version officielle » est définie par le serveur.
State du contrat : progression enregistrée dans les données du smart contract et les événements du réseau, transitions vérifiées par la logique du contrat.
| Élément comparé | State côté serveur | State du contrat |
|---|---|---|
| Où la progression est stockée | Base de données du service | Données du contrat + événements du réseau |
| Qui valide les transitions | Logique serveur et règles du service | Logique du smart contract (ce qui est autorisé et interdit) |
| Qui fixe la version finale | Serveur comme arbitre unique | Réseau et contrat comme source de vérité |
| Modifications admin | Possibles (par ex., annulation d’une récompense) | Limitées par les règles du contrat et les transactions |
| Comment le résultat est confirmé | Selon les données du service et du compte | Selon les données du réseau (state du contrat et événements) |
| Si le service est arrêté | La progression et la « version officielle » peuvent disparaître avec la BD | Le state et les événements restent sur le réseau, l’interface peut changer |
Exemple : si le résultat de saison (classement et récompense) est enregistré on-chain, la vérification reste possible via les données du réseau même si le client change ; si le résultat est stocké sur un serveur, la « version officielle » disparaît lors de l’arrêt du service.
Compromis : droits on-chain et résultats on-chain, gameplay off-chain
- On-chain : propriété, récompenses rares et bilans de saison (ce qui doit être vérifiable indépendamment d’un serveur).
- Off-chain : actions à haute fréquence (combat, déplacements, matchmaking) pour la vitesse et l’UX.
- Conséquence : on-chain ancre des événements rares mais significatifs, et non chaque action de gameplay.
Plus les droits et les résultats finaux sont enregistrés dans les contrats, moins la dépendance aux serveurs est forte pour confirmer la propriété et les bilans de saison.
Scénario d’arrêt du service : ce qui se perd selon le modèle
L’arrêt des serveurs affecte actifs et progression différemment, car la source de vérité varie selon les modèles.
Web2 : l’arrêt de l’infrastructure interrompt la mise à jour du state serveur et la fourniture des données au compte.
Conséquence : l’accès à la progression et aux items cesse généralement avec le service.
Hybride Web3 : le NFT reste sur l’adresse comme enregistrement du réseau, mais les éléments côté serveur (progression, modes, règles d’usage) peuvent disparaître.
Conséquence : le token existe, mais l’utilité s’arrête lorsque les serveurs sont coupés.
Fully on-chain : logique et state se trouvent dans les contrats, donc les données restent sur le réseau indépendamment d’une seule entreprise.
Limite : l’accès confortable dépend des applications clientes et de l’infrastructure de lecture (RPC et indexeurs).
Limites du on-chain : frais, latence, UX et risque des contrats
Le on-chain augmente la vérifiabilité, mais ajoute des frais, de la latence et des exigences de gestion des clés.
- Débit et latence : l’enregistrement des actions requiert des transactions et des confirmations.
- Coût des opérations : stocker et mettre à jour le state on-chain peut être coûteux.
- Barrières UX : portefeuille, clés, signatures et récupération d’accès — une couche de risques distincte.
- Infrastructure d’accès : RPC, indexeurs et interfaces influencent le confort et la disponibilité de lecture du state.
- Sécurité des contrats : bugs de code et permissions incorrectes entraînent des conséquences irréversibles pour le state et les actifs.
Conséquence pour le game design : les micro-actions fréquentes sont rarement on-chain ; on-chain ancre plus souvent des événements rares mais significatifs (droits, récompenses, bilans de saison).
Pourquoi l’hybride est populaire : la blockchain sert aux droits et aux événements économiques, tandis que le gameplay à haute fréquence reste off-chain pour éviter des frais et de la latence à chaque action.
Compromis clé : la vérifiabilité on-chain se paie par des frais et une friction UX.
Critères de choix : quand le on-chain apporte de la valeur, et quand non
Filtre d’architecture : où les droits sur les actifs et des résultats vérifiables sont importants, et où la vitesse et une UX fluide priment.
Le on-chain est plus souvent pertinent
Quand la valeur est liée à la propriété, à la provenance et au marché secondaire.
- Items et cartes de collection, où le marché secondaire compte.
- Économies de ressources et crafting avec des règles vérifiables via les événements du réseau.
- Mondes à longue durée de vie, où préserver les droits sur les actifs et les bilans de saison est critique.
Web2 est plus souvent rationnel
Quand la vitesse, une friction minimale et l’absence de frais à chaque action comptent davantage.
- Genres en temps réel (shooters, action), où la latence est critique.
- Jeux casual avec onboarding de masse sans portefeuille ni signatures.
- Projets où les items n’ont aucune valeur hors du service.
Exemples (repères d’approches)
Ce n’est ni une recommandation ni une évaluation de qualité. L’objectif est de montrer comment le marché nomme habituellement différentes architectures.
Vérification par critères : (1) la progression est stockée dans un compte ou dans un contrat ? (2) existe-t-il un client/une consultation du state sans le site officiel ? (3) l’utilité du NFT est-elle définie par le contrat ou par des règles serveur ?
- Actifs tokenisés (souvent hybride) → items et personnages en NFT, tandis que gameplay et progression — off-chain.
- Formats économiques et de collection → ancrent plus souvent on-chain les droits sur les actifs et les règles du marché autour des actifs.
- Directions fully on-chain → tentent de conserver règles et state dans les contrats, et le client — comme interface vers les données du réseau.
Critère de vérification : l’emplacement de stockage de la progression et la couche d’exécution des règles comptent plus que la présence d’un NFT.
Trois erreurs de perception fréquentes
Les erreurs d’attentes viennent souvent du mélange entre « propriété du token », « utilité qui fonctionne » et « source de vérité ».
« Il y a un NFT — donc le jeu ne peut pas fermer »
Le token peut exister sur le réseau, tandis que le gameplay et la progression côté serveur peuvent disparaître.
- La propriété du token n’oblige pas le service à maintenir les règles du jeu.
- Le risque dépend de l’endroit où la progression est stockée et où les règles d’usage du token sont exécutées.
Conséquence : l’analyse doit commencer par la progression et les règles, pas par la présence d’un NFT.
« On-chain = totalement décentralisé »
Le on-chain peut être utilisé ponctuellement : pour les actifs, mais pas pour la progression et les règles du match.
- Des actifs on-chain ne signifient pas une progression on-chain.
- Un modèle hybride peut conserver des dépendances critiques aux serveurs.
Conséquence : la « source de vérité » pour la progression et les règles se trouve soit côté serveur, soit dans le contrat.
« Fully on-chain n’a pas de limites »
Le state du contrat reste sur le réseau, mais les frais, la latence et l’accès via l’infrastructure de lecture influencent l’UX.
- Les frais et confirmations limitent la fréquence des actions on-chain.
- La disponibilité des clients, des RPC et des indexeurs affecte le confort de lecture du state.
Conséquence : évaluer le nombre d’actions on-chain et la possibilité de consulter le state sans un seul frontend est important.
FAQ
Qu’est-ce que le on-chain gaming ?
Quelle est la différence entre les jeux Web2 et Web3, simplement ?
Que devient le NFT si le jeu ferme ?
Est-il possible de jouer à des jeux Web3 sans portefeuille ?
La progression peut-elle être conservée sans serveurs ?
Pourquoi y a-t-il encore peu de jeux fully on-chain ?
Vérification finale : on-chain vs Web2 selon trois critères
L’évaluation du modèle se résume à une question : où se situe la « source de vérité » pour la progression et les règles.
- Progression : les bilans de saison et les récompenses clés sont enregistrés dans un contrat ou restent dans la base du service.
- Règles : les transitions de state sont validées par un smart contract ou par une logique serveur.
- Risque d’arrêt : lorsque le service disparaît, seules les données du réseau et un accès compatible à celles-ci subsistent.
Si la progression et les règles vivent sur un serveur, les éléments on-chain restent des actifs, mais ne conservent pas la « version officielle » du jeu.