Blade Games lance un moteur de jeu ZK : pour créer des jeux décentralisés et sans intermédiaire
TechFlow SélectionTechFlow Sélection
Blade Games lance un moteur de jeu ZK : pour créer des jeux décentralisés et sans intermédiaire
Les jeux ZK sans confiance (Trustless Games) inaugureront la prochaine vague de jeux entièrement sur chaîne.
Dédié à des analyses Web3 approfondiesRédaction : Blade Research, Delphinus Lab
Version courte :
Blade Games et Delphinus Lab collaborent pour créer un moteur de jeu sans confiance (trustless game engine) basé sur WebAssembly et zkWASM.
Notre moteur de jeu zk prend en charge des catégories de jeux à faible fréquence d’interaction comme les jeux de défense contre les vagues (tower defense), les RPG, ainsi que les jeux idle, les jeux de cartes/auto-battlers et les romans interactifs. En résumé, nous exécutons la logique du jeu au sein de zkWASM (un « serveur zk » dédié au calcul), et chaque partie génère une preuve zkSNARK avant publication. Ce moteur supporte déjà C++, Go et Rust, avec bientôt le support de C# et Unity.
Prenons l'exemple d'un jeu de défense contre les vagues typique : une partie de 6 minutes avec 100 vagues d'ennemis nécessite environ 3 minutes pour générer la preuve zkSNARK. Il s'agit encore de résultats préliminaires, car nous optimisons rapidement le temps de génération des preuves. (La génération d'une preuve ZKP pour 1 million d'instructions prend 19 secondes ; chaque vague représente 80 000 instructions, soit 8 millions d'instructions par partie. Avec 8 preuves zkSNARK générées dans le cloud, le temps total est d’environ 3 minutes.)
Dans les jeux sans confiance basés sur ZKVM, les coûts principaux proviennent de la génération des preuves ZK, des services RPC / accès aux données, et des frais de validation et de règlement sur chaîne. Grâce à la mise à jour Cancun (EIP-4844) sur les L2, le coût d’exécution d’un jeu sans confiance a considérablement diminué.
En outre, grâce à la mise en œuvre future de la récursion des preuves zkSNARK et du service d’agrégation de preuves de Nebra, nous pouvons encore réduire davantage le coût des preuves ZKP.
Nos partenaires de jeux incluent :
Dune Factory (@BladeGamesHQ) : un jeu de stratégie mêlant construction de base et tour de défense dans un univers post-apocalyptique punk
0xPioneer : un jeu multijoueur en ligne de survie similaire à Don’t Starve
Craftpunk : un RPG en monde ouvert spatial avec vaisseaux modifiables et cartes générées procéduralement
Texte principal :
Ce moteur de jeu ZK est conjointement développé par Blade Games et Delphinus Lab. Cet article est co-écrit par les deux parties afin d’aider davantage de développeurs de jeux web2 et de jeux entièrement blockchain à comprendre les avantages et les voies de développement d’un moteur de jeu ZK.
Il s’agit d’un guide sur le développement de jeux navigateur Web3 sans confiance. (Une présentation complémentaire est disponible sur YouTube, voir aussi lien associé).
Avec le développement continu du Web3, les jeux entièrement sur chaîne refont surface. Ils revendiquent des avantages supérieurs en matière de décentralisation, de transparence, d’absence de confiance et de gouvernance communautaire. Toutefois, ces jeux héritent également du dilemme classique de la blockchain entre décentralisation, sécurité et évolutivité — ce qui signifie que les développeurs doivent composer avec des difficultés liées au contenu du jeu, à la fréquence des interactions, à la décentralisation, à l’équité sans confiance et à la gestion communautaire.
Par conséquent, lors du dernier cycle, les développeurs ont fait certains compromis architecturaux, aboutissant à une architecture largement adoptée appelée « architecture Web2.5 ».
Plus précisément, le terme Web2.5 désigne une approche hybride combinant Web3 et jeux traditionnels. Le Web2.5 met l’accent sur l’expérience de jeu, car ses promoteurs estiment que le public cible principal reste ancré dans le Web2. Parallèlement, ils intègrent des éléments Web3 (NFT, modèle économique, play-to-earn) pour se démarquer.
L’architecture type d’un jeu Web2.5 ressemble à ceci :
Le schéma de gauche illustre le contrôle du moteur de jeu sur la machine à états du jeu et sa réponse aux actions des joueurs. Celui de droite montre certaines modifications de l’état du jeu, révélant les données les plus précieuses stockées sur chaîne.
La mécanique centrale du jeu s’exécute principalement sur un serveur centralisé, tandis que les données les plus importantes (NFT, récompenses en jetons, historiques, etc.) sont suivies sur la blockchain.
Les avantages de cette architecture sont nombreux : le serveur de jeu peut traiter massivement les transactions utilisateur en mode centralisé, avec des délais de quelques secondes. De plus, un serveur centralisé peut gérer des mécaniques complexes et continues, trop coûteuses à exécuter directement sur une blockchain native.
Toutefois, dans cette architecture, le canal de communication entre le moteur de jeu et le protocole blockchain est généralement protégé par des signatures, donc pas sans confiance. De plus, le contenu du jeu peut être modifié sans consensus communautaire, ce qui nuit parfois aux intérêts acquis des joueurs existants (mise à jour de l’économie, du contenu ou même des récompenses).
En outre, il est difficile de vérifier sur chaîne si les données transmises reflètent fidèlement les résultats du gameplay. Le serveur peut profiter de sa position pour traiter différemment certaines actions des joueurs (par exemple favoriser un compte privé du développeur).
Étant donné que les jeux Web2 excellent généralement en contenu et gameplay, confier l’équilibre et la justice au fournisseur du jeu est acceptable. Toutefois, lorsqu’un jeu Web2 entre dans l’écosystème Web3, il doit attirer des joueurs natifs de la cryptographie soucieux de l’économie, de la propriété et de la capture de valeur pendant le jeu. Ces joueurs ne se contentent pas de profiter du jeu, mais souhaitent que leurs résultats aient une certaine signification (ex. « durabilité ») voire une valorisation. Cette attente accrue de durabilité rend les choix en jeu plus sérieux — augmentant ainsi le coût cognitif et décisionnel des joueurs, renforçant leur exigence quant à l’équité et la prévisibilité des règles.
Finalement, les joueurs exigeront un contrôle sur les caractéristiques « Web3 » du jeu — la justice et l’absence de confiance ne devraient pas dépendre de l’opérateur/développeur, mais être appliquées par un code immuable, menant vers un jeu plus décentralisé, entièrement construit sur chaîne.
Face à cela, une solution simple serait de déplacer tout le contenu du schéma de gauche vers la partie droite (la blockchain), conduisant à l’architecture suivante :
Clairement, cette approche entraînerait plusieurs « dégradations » du gameplay :
- Chaque action du joueur doit être représentée par une signature sur chaîne pour autorisation
- L’échelle du moteur de jeu exécuté sur la blockchain est limitée
- Des frais élevés de gaz sont requis
- La fréquence d’interaction entre le joueur et le jeu doit être réduite pour respecter la limite TPS (transactions par seconde) de la blockchain
Cela signifie-t-il que nous devons abandonner des contenus complexes et riches au profit de la « philosophie full-chain » ?
Avant l’apparition des machines virtuelles à connaissance nulle (ZKVM), la réponse aurait été « oui ». Mais désormais, grâce aux progrès et à l’adoption croissante de cette technologie, nous disposons d’une « troisième voie » : combiner les jeux entièrement sur chaîne avec le calcul sans confiance. Comment cela fonctionne-t-il ?
La ZKVM, ou machine virtuelle à connaissance nulle, combine preuve à connaissance nulle et technologie de machine virtuelle. Pour bien la comprendre, examinons deux composants clés :
- Preuve à connaissance nulle (ZKP) : méthode cryptographique permettant à une partie de prouver à une autre qu’elle connaît une valeur (ex. une clé) sans divulguer aucune information sur cette valeur. Les ZKP protègent à la fois la confidentialité et la sécurité, en validant une affirmation sans partager les données sous-jacentes.
- Machine virtuelle (VM) : simulation logicielle d’un ordinateur physique. Elle exécute un système d’exploitation et des applications comme un vrai ordinateur, mais entièrement en logiciel. Les VM sont largement utilisées dans le cloud et pour exécuter plusieurs systèmes sur un seul appareil.
En combinant ces deux concepts : une ZKVM est d’abord une machine virtuelle capable d’exécuter des programmes ou contrats, tout en offrant les avantages de confidentialité et de sécurité des ZKP. Cela signifie que nous pouvons exécuter le moteur de jeu (ou serveur de jeu) dans une zkVM, et utiliser celle-ci pour générer une preuve ZK attestant que les changements d’état sont conformes à la logique du jeu. Ainsi, le serveur de jeu ne peut pas manipuler les données envoyées à la blockchain sous-jacente.
Dans ce contexte, l’architecture complète d’un jeu full-chain pourrait ressembler à ceci :
Nous appelons ce type de jeu full-chain sans confiance : Trustless Game.
2. Facteurs à considérer lors du développement d’un Trustless Game
2.1 À retenir pour les débutants
Le développement de jeux est généralement perçu comme complexe, impliquant des technologies avancées, de la créativité précieuse et une gestion de projet délicate. Lorsqu’on applique la technologie ZKVM aux Trustless Games, les facteurs à prendre en compte sont les suivants :
Complexité technique : Dans un Trustless Game, la logique du jeu doit être séparée de sa visualisation, et cette logique doit être déterministe afin que la ZKVM puisse générer une preuve. De plus, comme la preuve est générée sur des segments d’exécution, les développeurs doivent découper le gameplay en blocs exécutables et synchroniser régulièrement avec le contrat sur chaîne.
Art et design : Pour les artistes et designers, le travail reste identique à celui des autres jeux, car leurs réalisations ne font pas partie de la logique à prouver. Dans un Trustless Game, le développement visuel repose sur l’état global du jeu, et l’interface UI/UX sert aussi à collecter les actions des joueurs.
Expérience de jeu globale : Contrairement aux jeux full-chain classiques, les joueurs n’ont pas besoin de signer chaque mouvement sur chaîne, ce qui rend possible la création de jeux à « interaction fréquente » — ceux qui encouragent ou nécessitent de nombreuses interactions.
Toutefois, en raison du temps nécessaire à la génération des preuves ZKVM, les interactions très rapides restent irréalisables pour les Trustless Games, comme les RTS (stratégie en temps réel) ou les MOBA (ex. DOTA), où les joueurs doivent constamment contrôler des unités et ajuster leurs stratégies. Ces genres sont difficiles à développer sur ZKVM.
En revanche, les jeux de simulation et les jeux idle/farming conviennent parfaitement : les joueurs y ajustent périodiquement leurs ressources, participent à des marchés ou gèrent des personnages pour progresser. Ces genres s’adaptent bien au concept de Trustless Game.
De même, les jeux narratifs interactifs et les romans graphiques sont d’excellents candidats. Bien qu’ils n’exigent pas d’interactions continues, ils captivent par des points de décision répétés, façonnant l’histoire et incitant à interagir fréquemment pour découvrir les conséquences des choix.
Passons maintenant à la monétisation et à la durabilité.
Généralement, le contenu d’un jeu évolue pour attirer de nouveaux joueurs et fidéliser les anciens. Cela rend la logique du jeu dynamique, impactant les programmes exécutés dans la ZKVM — ce qui peut obliger à modifier et mettre à jour le contrat de validation.
Deux solutions permettent d’éviter des mises à jour fréquentes du contrat de validation ZK :
- Évolution du gameplay : définir une couche protocolaire abstraite pour le gameplay, en formalisant les éléments dynamiques comme des règles. Ces règles peuvent être stockées sur chaîne et inscrites dans un hachage. Lorsque le moteur exécute la logique, il vérifie d’abord que le hachage actuel correspond à celui attendu.
- Évolution des récompenses : le système de récompenses peut être indépendant du gameplay. On peut considérer les algorithmes de récompense comme des rappels (callbacks) déclenchés par certains événements du jeu. Ces callbacks peuvent être placés sur chaîne et invoqués selon les événements.
Par exemple, on peut avoir la boucle suivante :
zkgame {
// Logique du jeu
output(events)
}
Les événements générés deviennent des instances de preuve. On peut alors ajouter des callbacks au contrat :
2.2 Où placer la logique du jeu ?
La logique du jeu s’exécute principalement à deux endroits : côté client (frontend) ou côté serveur.
Placer la logique côté frontend simplifie l’architecture par rapport au modèle client-serveur classique. Cette approche permet au frontend de simuler le jeu, de construire la trajectoire d’exécution, puis de générer une preuve zk (zk-proof). Ensuite, il utilise un prouveur zk local ou un service distant pour produire la preuve ZK via la ZKVM, puis envoie cette preuve à la blockchain pour déclencher le contrat de règlement.
À l’inverse, placer la logique côté serveur transfère la simulation du jeu et les interactions utilisateur vers un composant spécialisé (le serveur de jeu). Cela améliore l’expérience globale :
- Un gameplay mieux synchronisé : la simulation serveur garantit que tous les joueurs vivent le jeu de manière aussi cohérente que possible. Pour les jeux multijoueurs, un état cohérent sur tous les clients connectés est essentiel pour une expérience fluide et compétitive.
- Une meilleure gestion des ressources : le frontend peut se concentrer sur le rendu et l’UI/UX, tandis que le serveur agit comme contrôleur séquentiel centralisé et fournisseur de stockage d’arbres de Merkle.
Pour les jeux solo PVE (ou PVP multijoueur) simples, sans besoin de données historiques ni de logique séquentielle complexe, placer tout côté frontend est une bonne option. Pour des jeux complexes comme les SLG multijoueurs (jeux de simulation) ou les AW (mondes autonomes), la version serveur est préférable.
2.3 Choix de l’architecture de développement
Comme nous combinons le développement de jeux traditionnel avec la ZKVM, le choix des outils est crucial.
1. Langage de programmation
Il faut d’abord décider d’utiliser un langage classique (C#, Rust, C, C++, Go) ou un langage spécifique à la ZKVM.
Les langages classiques génèrent généralement du bytecode MIPS, WASM, RISC-V ou x86. Comme peu de ZKVM supportent ces formats, si votre programme compile en RISC-V, choisissez Risc0 ; s’il compile en WASM, privilégiez zkWASM.
WebAssembly (WASM) est un format de bytecode bas niveau, utilisé comme cible de compilation pour des langages avancés (C, C++, Rust, etc.). Il permet d’exécuter du code presque à vitesse native dans le navigateur. WASM complète JavaScript en permettant l’utilisation d’autres langages dans le développement web, tout en préservant sécurité et performance.
2. Moteur de jeu
Une fois le langage choisi, sélectionnez un moteur adapté. Si vous optez pour un langage ZKVM-spécifique, vous devrez peut-être créer votre propre framework, car peu d’options matures existent. Pour Rust, C ou TypeScript, de nombreux frameworks sont disponibles, notamment Unity et Cocos2D.
3. Coût de génération des preuves
Le coût des preuves est souvent mesuré en temps pour 1 million d’instructions. Il dépend donc de la trajectoire d’exécution (nombre d’instructions par interaction), de la taille du bytecode et des performances de la ZKVM. Pour des jeux simples, certaines ZKVM (comme Miden) génèrent une preuve en quelques secondes. Pour des jeux complexes (RISC-V 32 bits, WASM 64 bits), la preuve prend environ 12 secondes sur GPU (Risc0) à 30 secondes (zkWASM).
3. Utilisation du modèle MVC (Modèle-Vue-Contrôleur) dans ZKWASM pour les jeux full-chain
3.1 Présentation du modèle MVC
Bien que le modèle MVC soit traditionnellement associé aux applications web ou d’entreprise, il peut s’appliquer au développement de jeux — avec quelques adaptations. Voici comment fonctionnent les composants MVC dans un jeu :
Modèle (Model) :
Dans un jeu, le modèle représente les données et la logique. Cela inclut l’état du jeu (score, niveau, statistiques), les objets du jeu et les règles du monde. Le modèle gère les données et l’état, sans connaître la façon dont ils seront affichés.
Vue (View) :
La vue affiche l’état du jeu aux joueurs : rendu graphique, sons, éléments d’interface (score, barres de vie, menus). Elle observe le modèle et met à jour la représentation visuelle et sonore du jeu. Dans de nombreux moteurs, la vue est intégrée au moteur de rendu et au système UI.
Contrôleur (Controller) :
Le contrôleur interprète les entrées (clavier, souris, manette) et les traduit en actions dans le jeu. Par exemple, quand un joueur appuie sur un bouton pour faire sauter son personnage, le contrôleur transmet cette action au modèle. Il sert d’intermédiaire entre les périphériques d’entrée et la logique du jeu.
Appliquer le modèle MVC au développement de jeux présente plusieurs avantages :
- Séparation des préoccupations : MVC aide à organiser le code en dissociant logique et interface, facilitant le développement et la maintenance.
- Flexibilité : MVC permet de créer différentes vues pour un même modèle, utile pour offrir plusieurs perspectives ou supports d’affichage.
- Compatibilité ZK : en séparant logique et représentation, seul le modèle doit être exécuté de façon sans confiance. En plaçant le modèle dans ZKWASM, les mécanismes centraux du jeu sont naturellement prouvés.
3.2 Configuration du moteur de jeu dans ZKWASM
Supposons que le contrôleur soit relié au modèle via des gestionnaires (handlers). Nous pouvons ajouter une couche d’encodage/décodage des commandes :
3.3 Génération d’une preuve de gameplay
On peut voir une partie du gameplay comme une série d’appels du contrôleur aux gestionnaires. La preuve ZK sans confiance du gameplay devient alors :
fn execution(cs: Vec<command>) {
for command in cs {
global_state = handler(command);
}
}
Pendant le jeu, il est difficile de déterminer quelle est la dernière commande envoyée par le contrôleur, et de tout regrouper dans une seule preuve ZK. La meilleure pratique consiste donc à diviser les commandes en plusieurs segments, à prouver chacun, puis à les agréger en une seule preuve pour validation sur chaîne.
Remarque : deux aspects manquent dans cette approche :
- Comment assurer la continuité d’état entre chaque segment d’exécution
- Comment gérer les scénarios multijoueurs où les contrôleurs de différents clients interfèrent
Nous aborderons brièvement dans les chapitres suivants la sérialisation multijoueur (sequencing) et la disponibilité des données (DA). Chaque sujet étant vaste, nous prévoyons des publications détaillées ultérieurement.
4. Sérialisation des interactions utilisateur dans les jeux multijoueurs
Dans l’architecture modulaire des blockchains, le sérialiseur est le composant responsable de l’ordonnancement des interactions avant leur confirmation finale. Cette architecture sépare les différentes couches fonctionnelles (exécution, consensus, disponibilité des données) afin d’optimiser indépendamment évolutivité, sécurité et efficacité.
Pour les jeux multijoueurs, nous avons besoin d’un composant similaire pour ordonner les interactions entre utilisateurs. Nous réutilisons donc ici le terme « sérialisation » issu de cette architecture.
Étant donné que les jeux exigent une faible latence, il est préférable d’utiliser un sérialiseur centralisé capable de produire rapidement un ordre. Le moteur de jeu peut coopérer étroitement avec lui pour récupérer les transactions ordonnées.
Protocole d’interaction pour un seul joueur
Ici (voir image ci-dessous), nous décrivons le protocole depuis le point de vue du joueur. Dans la transaction utilisateur, celui-ci décrit son entrée et prouve son identité via des entrées publiques et confidentielles, organisées comme suit :
Entrées publiques et entrées témoins :
Logique de traitement des interactions :
pub fn zkmain() -> i64 {
let mut hasher = Sha256::new();
// obtenir la longueur des commandes
let commands_len = unsafe {wasm_input(0)};
// traiter toutes les commandes et
// hacher les commandes pour vérification ultérieure
for _ in 0..commands_len {
let command = unsafe {wasm_input(0)};
hasher.update(command.to_le_bytes());
step(command);
}
let msghash = hasher.finalize();
let pk = unsafe {BabyJubjubPoint {
x: U256([
wasm_input(0),
wasm_input(0),
wasm_input(0),
wasm_input(0),
]),
y: U256([
wasm_input(0),
wasm_input(0),
wasm_input(0),
wasm_input(0),
]),
}};
zkwasm_rust_sdk::dbg!(“process sig\n”);
let sig = unsafe {JubjubSignature {
sig_r: BabyJubjubPoint {
x: U256([
wasm_input(0),
wasm_input(0),
wasm_input(0),
wasm_input(0),
]),
y: U256([
wasm_input(0),
wasm_input(0),
wasm_input(0),
wasm_input(0),
]),
},
sig_s: [
wasm_input(0),
wasm_input(0),
wasm_input(0),
wasm_input(0),
]
}};
let msghash_u64 = [
u64::from_be_bytes(msghash[24..32].try_into().unwrap()),
u64::from_be_bytes(msghash[16..24].try_into().unwrap()),
u64::from_be_bytes(msghash[8..16].try_into().unwrap()),
u64::from_be_bytes(msghash[0..8].try_into().unwrap()),
];
sig.verify(&pk, &msghash_u64);
5. Analyse des coûts
5.1 Aperçu des coûts
Dans les jeux sans confiance basés sur ZKVM, les coûts principaux proviennent de la génération des preuves ZK, des services RPC rapides, des services d’accès aux données et des frais de validation et de règlement sur chaîne. Grâce à la mise à jour Cancun (EIP-4844) sur les L2, le coût d’exécution d’un jeu sans confiance a fortement diminué. En outre, grâce à la mise en œuvre future de la récursion des preuves zkSNARK et du service d’agrégation de preuves de Nebra, nous pouvons encore réduire le coût des preuves ZKP.
5.2 Coût de génération des preuves ZK
Premièrement, la ZKVM exécute l’application et génère une trajectoire d’exécution (execution trace). Cette trajectoire est fondamentale, car la ZKVM doit prouver :
- Que la trajectoire respecte la sémantique du bytecode supporté par la ZKVM
- Habituellement, la ZKVM est sans état (stateless). Pour supporter le stockage avec état (stateful storage), elle utilise l’idée de transformer les opérations de lecture/écriture en preuves de Merkle
- La ZKVM divise souvent la trajectoire en segments et génère des preuves séparées. Ces preuves sont ensuite agrégées en une seule preuve finale vérifiable
Supposons que notre ZKVM utilise des instructions prédéfinies comme appels système (ou API hôte dans ZKWASM) pour gérer les preuves de Merkle. Le coût total de génération d’une preuve ZK est alors :
Coût de preuve = Coût de preuve ZKVMGuest + Coût de preuve de Merkle + Coût de preuve groupée (BatchProofCost)
Généralement, les deux premiers termes n’ajoutent pas de coût significatif au-delà de la preuve ZK pure. Cependant, le coût du deuxième terme est subtil, car il dépend de services de stockage de données.
Revenons sur les composants d’une preuve de Merkle :
1. Construction de l’arbre de Merkle
Nous abstrayons les données globales en blocs, que nous hachons individuellement. Ces hachages deviennent les feuilles de l’arbre. Puis, nous hachons les paires de feuilles pour former les nœuds du niveau supérieur, et répétons jusqu’à obtenir un seul hachage au sommet : la racine de Merkle, représentation unique de toutes les données.
2. Preuve d’inclusion des données
Cette preuve comprend le bloc de données concerné, son hachage, et quelques hachages supplémentaires provenant de l’arbre. Ces derniers permettent au vérificateur de recalculer la racine de Merkle avec un minimum d’informations.
3. Vérification de la preuve
Le vérificateur connaît la racine de Merkle mais pas nécessairement toutes les données. Il utilise le bloc fourni et les hachages supplémentaires pour reconstruire le chemin vers la racine. Si la racine calculée correspond à celle connue, la preuve est valide, confirmant que le bloc appartient bien aux données et n’a pas été altéré.
Pour maintenir un jeu ZK avec état, une base de données Merkle est nécessaire pour suivre les feuilles et offrir un service rapide de requêtes. Ce service ne peut guère être entièrement hébergé sur chaîne, car les modifications et accès (lecture/écriture) sont trop fréquents.
Une fois la transaction terminée, les données d’appel et l’état final (représenté par la nouvelle racine de Merkle) doivent être accessibles. Cela se fait généralement via une couche DA ou un stockage txdata sur chaîne.
5.3 Coût des données
Selon l’analyse de Blade Games, en se basant sur ZKWASM, Eth Storage, le calculateur de coût de stockage BNB Greenfield DA et le calculateur de stockage Google Cloud, nous arrivons à la conclusion suivante : exécuter un jeu sur chaîne avec 5 000 joueurs (supposés jouer en continu — ce qui donne en réalité un nombre d’utilisateurs actifs bien supérieur) coûterait environ 90 000 $ par mois, un coût comparable à celui d’un serveur MMORPG haute performance anti-DDOS.
Méthode d’estimation de Blade Games :
Ils convertissent les événements utilisateur exportés depuis Unity en code binaire, exécuté dans ZKWASM (ZKVM développé par Delphinuslab, supportant le bytecode WASM). ZKWASM génère alors une trajectoire d’exécution, qu’il publie compressée sur la couche DA. Parallèlement, ils publient sur chaîne le hachage de la trajectoire, accompagné d’une signature pour garantir l’immutabilité.
Selon les tests ETHstorage et zkwasm, 1 seconde d’exécution d’un binaire WASM génère 1 million de lignes de trajectoire, chaque ligne faisant 40 octets.
Nous pouvons choisir de prouver toutes les trajectoires, ou simplement les conserver et ne générer une preuve qu’en cas de contestation.
1. Méthode ZK : preuve de toutes les trajectoires
Si nous prouvons toutes les trajectoires, 1 million d’instructions prennent environ 25 secondes sur une carte RTX4090, pour un coût estimé à 0,5 cent (soit 2000M d’instructions par dollar). Dans cette solution, le coût principal provient du pouvoir de preuve, des frais de validation sur chaîne et du stockage des données d’appel sur la couche DA. Soutenir un jeu multijoueur générant 100 milliards de trajectoires par heure coûterait environ 50 $/heure (soit 36 000 $/mois) en frais de preuve.
2. Méthode de preuve de fraude (fraud proof)
Supposons 5 000 joueurs, jouant en moyenne 2 heures chacun, produisant 86,4 trillions de trajectoires par heure. La consommation quotidienne de stockage est donc : 60 secondes ×
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
Blade Research
