- Rubrique
9k Popularité
13k Popularité
42k Popularité
29k Popularité
676 Popularité
98k Popularité
28k Popularité
26k Popularité
7k Popularité
15k Popularité
- Épingler
9k Popularité
13k Popularité
42k Popularité
29k Popularité
676 Popularité
98k Popularité
28k Popularité
26k Popularité
7k Popularité
15k Popularité
Comment utiliser OPStack pour construire le cycle d'horloge du jeu en chaîne complète ?
Auteur : Gametavers
En général, les jeux sont basés sur des boucles. Une boucle de jeu est un processus itératif qui consiste généralement à traiter les entrées de l'utilisateur, à mettre à jour l'état du jeu et à rendre le monde du jeu. Cette boucle continue pendant que le jeu est en cours d'exécution, s'exécutant généralement des dizaines à des centaines de fois par seconde pour maintenir le monde du jeu fluide.
Cependant, l'architecture de la blockchain est basée sur le push. La blockchain est une base de données distribuée qui partage et stocke des informations via des nœuds du réseau. Lorsqu'un nœud génère une nouvelle transaction (telle qu'un transfert, un appel de contrat, etc.), la transaction sera transmise au réseau, et d'autres nœuds la vérifieront et l'ajouteront à la blockchain après avoir reçu la transaction. Il s'agit d'un processus passif, les nœuds ne rechercheront pas activement de nouvelles transactions, mais attendront que d'autres nœuds du réseau envoient de nouvelles transactions. Par conséquent, l'architecture de la blockchain est dite basée sur le push.
Par conséquent, il est très important d'implémenter un système de cycle avec des cycles d'horloge dans le jeu en chaîne complète. Après tout, dans le soi-disant "monde autonome", nous espérons tous que certains PNJ ou environnements virtuels pourront évoluer automatiquement au fil du temps, au lieu d'évoluer passivement en suivant les entrées de transaction poussées vers la blockchain.
@therealbytes a développé une chaîne de ticks de preuve de concept (chaîne avec des cycles d'horloge) basée sur l'OP Stack, qui exécute une implémentation automatique tick-tick du jeu de la vie de Conway, voyons comment il l'a implémenté.
Pour garder la traduction simple, nous traduisons littéralement tick en "tic", ce qui signifie "cycle cycle d'horloge".
Ticking-Optimism est une implémentation de preuve de concept de la "Ticking Blockchain" basée sur l'architecture de cumul Optimism Bedrock.
Dans la chaîne de ticks, il existe un contrat intelligent spécial appelé "contrat de ticks", et chaque bloc sera automatiquement appelé par le protocole. Cela permet à d'autres contrats intelligents de se déclencher automatiquement à des moments ou à des intervalles spécifiques sans obliger les utilisateurs à envoyer des transactions.
Comment y parvenir
La nouvelle architecture de cumul modulaire d'Optimism, Optimism Bedrock, introduit un nouveau type de transaction appelé "transaction de dépôt". Contrairement aux transactions régulières, les transactions de dépôt :
Blocs de la couche 1.
Aucune vérification de signature requise.
Achetez du gaz L2 sur L1, donc le gaz L2 n'est pas remboursable.
Dans le Bedrock original, les transactions de dépôt étaient utilisées pour deux choses :
Exécuter les transactions envoyées directement à L1.
Définissez les propriétés L1 (numéro, horodatage, hachage, etc.) pour les contrats L2 pré-déployés dans chaque bloc.
Dans ce dernier cas, les transactions sont créées par des nœuds cumulatifs. Il ne paie pas le gaz et le gaz utilisé n'est pas déduit du pool de gaz.
Ticking-Optimism modifie le nœud cumulatif et crée également une "transaction tick" qui fonctionne de la même manière, mais au lieu de définir la propriété L1, il appelle la fonction tick() dans le contrat pré-déployé pour adresser 0x4200000000000000000000000000000000000A0. Ce contrat peut appeler un autre contrat en définissant sa variable cible.
Motivation
Pour illustrer la puissance des tickchains, imaginez un jeu sur la blockchain où plusieurs PNJ (personnages non-joueurs) se déplacent sur la carte. Sans chaîne de tiques, nous avons deux approches de conception principales :
Mise à jour paresseuse. Côté client, les PNJ semblent se déplacer en permanence, mais leurs positions ne sont mises à jour en chaîne que lorsque les utilisateurs envoient des transactions pour interagir avec eux. Le contrat calcule ensuite le nouvel emplacement du PNJ en fonction de sa dernière mise à jour en chaîne et du nombre de blocs qui se sont écoulés depuis lors.
Tic-tac manuel. Nous définissons une fonction de mise à jour qui définit la position de chaque PNJ sur la carte, et un compte externe l'appelle périodiquement.
Avec une tickchain, la solution est similaire au ticking manuel, mais le contrat de tick appelle la fonction de mise à jour automatiquement au lieu de manuellement.
Les avantages d'utiliser le "auto-tic" de la chaîne de ticks au lieu des ticks manuels sont :
Les mises à jour sont garanties par accord.
La mise à jour sera effectuée avant toutes les transactions dans le bloc et ne peut pas être présentée car elle fait partie du protocole lui-même.
Les transactions de mise à jour ne participent pas au marché régulier du gaz.
Cependant, les ticks automatiques nécessitent une blockchain personnalisée. Si le taux de mise à jour est le même, les ticks manuels et automatiques nécessitent les mêmes ressources de calcul sur le nœud. Les mises à jour paresseuses, en revanche, sont généralement moins chères car les mises à jour en chaîne sont plus petites et moins fréquentes.
De plus, le coût de calcul des transactions de ticks augmente à mesure que l'état qui doit être mis à jour augmente. Cela exerce une pression supplémentaire sur les développeurs pour qu'ils conçoivent leurs applications de manière à ce que les coûts ne dépassent jamais ce que la chaîne peut supporter.
Malgré ces énormes inconvénients, les ticks automatiques sont mieux adaptés que les mises à jour paresseuses pour certains types d'applications.
Les ticks permettent aux contrats intelligents d'accéder, à coût constant, à un état dynamique mis à jour à l'aide d'expressions de forme ouverte.
L'état (dans l'exemple ci-dessus, l'emplacement du PNJ) est toujours lisible sur la chaîne à un coût de gaz constant et relativement faible. Mais le coût du calcul de l'état actuel augmentera avec le nombre de blocs depuis la dernière mise à jour, et le coût du gaz augmentera davantage.
Si nous mettons à jour la position d'une entité se déplaçant à une vitesse constante, nous pouvons calculer où elle devrait se trouver dans un morceau donné à partir de sa dernière position définie et du nombre de morceaux depuis la mise à jour. Le coût de cette opération n'augmente pas avec le nombre de blocs entre les mises à jour.
D'autre part, si l'état que nous mettons à jour est quelque chose comme le jeu de la vie de Conway (ou une simulation à trois gravités), le coût de la mise à jour augmente de manière linéaire avec le nombre d'étapes depuis la dernière mise à jour. C'est un problème car cela peut aller au-delà de ce que les utilisateurs sont prêts à payer ou de ce que la chaîne peut supporter.
Avec les mises à jour différées, la logique de mise à jour doit être implémentée à la fois dans le contrat intelligent et dans le client. Avec le tic-tac, il suffit de l'implémenter sur la blockchain, et les clients peuvent simplement réagir aux événements en chaîne.
Les mises à jour paresseuses permettent aux développeurs de répartir leur logique de mise à jour sur de nombreuses fonctions et contrats intelligents, chaque fonction n'étant déclenchée que lorsque certaines transactions sont exécutées. En revanche, l'approche tick-tick ne nécessite qu'une fonction de mise à jour dont le déclenchement périodique est garanti. Ce dernier facilite le maintien de la cohérence et de l'intégrité de l'état.
De plus, chaque fois qu'un nouvel état de mise à jour paresseux est ajouté (par exemple, un nouveau type de PNJ), toutes les fonctions de mise à jour peuvent devoir être modifiées pour en tenir compte. Cela rend la base de code plus complexe et sujette à des problèmes.
Le coût des mises à jour paresseuses varie souvent considérablement et les utilisateurs peuvent concevoir leurs transactions de manière à ce que la majeure partie du fardeau des mises à jour incombe aux autres. Avec les ticks, le coût de toutes les opérations est relativement stable et non vulnérable aux attaques MEV.
Démo du jeu de la vie de Conway
J'ai construit une démo de tickchain qui exécute une version interactive du jeu de la vie de Conway. La chaîne a été modifiée pour inclure la logique d'automate cellulaire dans le moteur d'exécution, ce qui la rend plus efficace, permettant un plateau de jeu plus grand que celui qui pourrait être implémenté en tant que bytecode de contrat intelligent.
Le code source de la démo :
Vidéo de démonstration :