Les jeux Web3 sont le modèle de menace le plus étrange de notre activité. Trois disciplines de sécurité s'appliquent en même temps, game security (anti-cheat, intégrité serveur), fintech security (l'économie in-game, c'est de l'argent réel) et smart contract security (les pièces on-chain). Les joueurs ne les séparent pas. Ils exploiteront la couche qui casse en premier.
Voici le cadre qu'on utilise quand on travaille avec des équipes GameFi, du durcissement pré-lancement à la réponse à incident en live ops.
Trois modèles de menace, un seul produit
La game security, c'est ce que les studios AAA font depuis des décennies. Anti-cheat, état serveur-autoritaire, replay protection, détection d'exploits, infra de bans. Les menaces sont bien comprises : modification client, manipulation de paquets, fermes de bots, partage de comptes.
La fintech security, c'est ce avec quoi processeurs de paiement et exchanges traitent. KYC le cas échéant, anti-fraude, détection d'anomalies sur transactions, conformité réglementaire pour les économies in-game qui touchent au fiat.
La smart contract security, c'est ce avec quoi les protocoles DeFi traitent. Audits des fonctions de mint, transfer, claim, redeem. Résistance à la reentrancy, à la manipulation d'oracle, aux replay attacks. Bug bounties calibrés sur la valeur en jeu.
Un jeu Web3 a les trois problèmes. Le bridge entre game state et chain state, l'instant où une achievement in-game minte un NFT, ou une action de staking déclenche un transfert de token, c'est là que les modèles de menace se composent, pas qu'ils s'annulent.
La revue de design économique
La chose à plus haut levier qu'on fait pour une équipe GameFi, c'est la revue de design économique, qui précède l'audit technique.
Questions dans le périmètre :
- Quel est le montant maximal de currency qui peut entrer dans l'économie en une unité de temps, et par quels mécanismes ?
- Le taux d'entrée de currency est-il plausiblement proportionnel au taux de retrait (sinks) ?
- Quel est le payout maximal d'une action in-game, et quelle fraction de la currency totale ?
- Quelles sont les hypothèses sur le comportement joueur qui doivent tenir pour que l'économie ne s'effondre pas ?
- Que se passe-t-il si ces hypothèses sont fausses, lentement, ou subitement ?
Un jeu dont l'économie dépend d'un comportement que des joueurs motivés vont exploiter est un jeu dont l'économie sera exploitée. La question, c'est quand.
Le mode de défaillance classique : un play-to-earn lance avec un ratio positif de récompenses sur coût d'onboarding. Les nouveaux joueurs se multiplient plus vite que les sinks ne peuvent absorber. Le token inflate. Les early players cashent out. Les nouveaux joueurs se retrouvent avec une currency sans valeur. L'économie s'effondre, souvent avec une communauté qui se sent escroquée.
La défense est mathématique, pas technique. Chaque boucle play-to-earn doit avoir un sink qui se ferme dans des conditions plausibles de marché. Chaque mécanisme de mint doit être borné. Chaque récompense doit être pricée d'une manière qui ne dépend pas d'une croissance perpétuelle de nouveaux joueurs.
L'audit on-chain
Une fois le design économique défendable, les contrats qui l'implémentent ont besoin d'un Smart Contract Audit comme tout autre code DeFi-adjacent. Patterns spécifiques qu'on regarde dans les contrats GameFi :
Mint lié à un état off-chain. Quand le contrat minte sur la base d'une signature serveur (« ce joueur a complété la quête X »), le schéma de signature doit être resistant au replay, lié à la chaîne, borné en expiration et lié à un nonce par joueur. On a vu les quatre omissions en production.
Réclamations de récompense avec race conditions. Une fonction de claim qui calcule les récompenses sur block.timestamp et laisse l'utilisateur appeler à répétition dans le même bloc est exploitable. Pareil pour celle qui utilise une lecture d'état périmée entre les appels.
Mouvement d'objets cross-chain. Beaucoup de jeux bougent des actifs entre un L2 et la L1, ou entre une sidechain et la L1. Chaque direction est un bridge, avec tous les problèmes de bridge, et en général un avec moins d'attention institutionnelle que les gros bridges DeFi.
Pause d'urgence et ajustements. Les jeux devront faire des ajustements économiques en cours de vie, ajuster les drop rates, déprécier des items, corriger des exploits. La surface d'ajustement est privilégiée et doit être verrouillée, time-lockée, revue.
Côté game server
Le pentest GameFi couvre ce que tout studio sait qu'il lui faut, durcissement serveur, authentification, anti-cheat, plus les coutures spécifiques Web3.
Le bridge entre logique de jeu et logique de chaîne est la surface à plus haute priorité dans nos missions Penetration Testing avec des équipes GameFi. Spécifiquement :
- Le service de signature que le game server utilise pour signer les autorisations on-chain. Si un game server compromis peut signer des autorisations arbitraires, l'économie est compromise par le game server.
- Le matchmaker qui détermine l'éligibilité aux récompenses. Si les matchs peuvent être manipulés, les récompenses aussi.
- La couche replay ou anti-cheat. Si les comptes bannis peuvent quand même claim des récompenses on-chain, les bans sont du théâtre.
- Le pipeline de metadata NFT. Si les attributs d'item sont calculés off-chain et mintés on-chain, le pipeline off-chain fait partie de la frontière de confiance.
Live ops : le modèle de menace ne s'arrête jamais
Contrairement à la plupart des logiciels, le GameFi a la propriété que les utilisateurs cherchent activement des bugs. Fermes de bots, clients reverse-engineered, manipulation d'oracle dans les récompenses PvP, exploits de dupe, les patterns d'abus sont continus.
Les équipes qui gèrent ça bien partagent trois pratiques :
Monitoring continu de l'économie elle-même. Currency totale en circulation, currency mintée par jour, top earners par volume quotidien, comptes joueurs avec des patterns de récompense anormaux. Si la currency totale grossit plus vite qu'attendu, quelque chose est exploité.
Une infra de ban et rollback mature. Quand un exploit est trouvé, l'équipe peut identifier les comptes affectés, les geler, rollback l'état on-chain quand possible, communiquer avec transparence. Les équipes sans cette infra sont forcées de choisir entre laisser des exploits live et des hard forks visibles qui cassent la communauté.
Wallet Surveillance sur les wallets opérationnels. Wallets du service de signature, trésorerie, pools de récompense, tous monitorés pour des anomalies suggérant compromission.
Un retainer Réponse à incident. Les exploits d'économie de jeu vont vite et sont extrêmement publics. Une équipe qui a répété la réponse, avec un partenaire d'astreinte, récupère plus vite et avec moins de dégâts réputationnels qu'une équipe qui improvise.
À quoi ressemble un lancement
Un lancement GameFi qu'on a aidé à durcir ressemble à peu près à :
- Revue de design économique six mois avant le lancement. Ajustements aux structures d'incentive selon les findings.
- Audit smart contract trois mois avant le lancement. Re-audit après corrections.
- Pentest des game servers et du bridge on-chain/off-chain deux mois avant.
- Wallet Setup pour la trésorerie et les wallets de signature un mois avant.
- Bug bounty live deux semaines avant le lancement.
- Wallet Surveillance live au lancement.
- Retainer Réponse à incident en place au lancement.
Chaque étape compressée a un coût correspondant en incidents post-lancement. On a vu les maths des deux côtés.
Ce que le GameFi continue de réapprendre
Chaque cycle, une génération de projets GameFi lance avec une revue de design économique insuffisante, a un super premier mois, atteint son pic, puis s'effondre via une combinaison d'exploitation et de game design inflationniste. Les effondrements sont souvent attribués à « la meta a évolué » ou « le marché a tourné », mais les post-mortems montrent invariablement que le design économique n'était pas viable au départ, et que des joueurs motivés ont trouvé l'invariabilité plus vite que l'équipe ne pouvait patcher.
Les projets GameFi qui durent sont ceux qui traitent le design économique avec la même rigueur que le design de code. Les menaces sont différentes de celles de la DeFi, et les joueurs motivés sont infiniment plus nombreux que les auditeurs qu'un projet peut s'offrir. Construire correctement, c'est la seule stratégie viable.