原标题: Comment j'ai appris à arrêter de m'inquiéter et d'aimer le partage
Lien vidéo:
Conférencier : Scott Sunarto (@smsunarto) lors de la Journée de la recherche
Édition et finition de l'article : Justin Zhao (@hiCaptainZ)
Bonjour, je suis Scott (@smsunarto), fondateur d'August Labs (@ArgusLabs_). Aujourd'hui, je vais parler d'un sujet que nous n'avons pas abordé depuis un moment. Les roll-ups devenant le courant dominant de l'époque, nous ne discutons pas autant du partage d'exécution que du partage de données. Alors, revenons sur ce sujet quelque peu négligé - le partitionnement d'exécution.
Ce sera une conversation facile. Je sais que vous avez entendu des concepts complexes toute la journée, alors je vais essayer de rendre cette discussion aussi pratique que possible. J'ai préparé une conception de diapositive appropriée pour cette présentation.
Pour ceux qui ne me connaissent pas, le plus drôle, c'est que je suis connue sur Twitter comme une anime girl. J'ai aussi raté mon diplôme universitaire juste pour être ici, au grand désarroi de mes parents. Actuellement, je suis le fondateur d'Argus Labs. Nous nous considérons comme une société de jeux, et non comme une société d'infrastructure ou de crypto-monnaie. L'une de mes plus grandes bêtes noires est que tout le monde dans les jeux cryptographiques veut créer des outils, mais personne ne veut créer de contenu ou d'applications. Nous avons besoin de plus d'applications que les utilisateurs peuvent réellement utiliser.
Auparavant, j'ai co-créé Dark Forest (@darkforest_eth) avec mes amis intelligents Brian Gu (@gubsheep) et Alan Luo (@alanluo_0). Brian dirige maintenant 0xPARC (@0xPARC) et il est beaucoup plus intelligent que moi.
La discussion d'aujourd'hui se concentrera sur l'exécution du sharding, mais dans un contexte, la plupart des gens ne sont pas familiers avec les discussions sur l'exécution du sharding. Nous discutons généralement du partage d'exécution dans le contexte de la couche 1, comme le partage Ethereum ou le partage proche. Mais aujourd'hui, je veux changer un peu le contexte. Réfléchissons à ce à quoi ressemblerait le sharding dans un environnement roll-up.
La question fondamentale ici est de savoir pourquoi une société de jeux construirait son propre roll-up, et que pouvons-nous apprendre de World of Warcraft pour concevoir des roll-ups. De plus, nous explorerons comment l'espace de conception des roll-ups va bien au-delà des réalités actuelles.
Pour répondre à ces questions, revenons à 2020, lorsque l'idée de la Forêt Sombre a été conçue pour la première fois. Nous nous sommes demandé, et si nous créions un jeu où chaque action de jeu était une transaction en chaîne ? La prémisse était ridicule à l'époque, et elle l'est toujours pour beaucoup de gens aujourd'hui. Mais c'était une hypothèse intéressante, alors nous l'avons construite, et Dark Forest est né.
Dark Forest est un jeu MMORTS d'exploration spatiale à chaîne complète entièrement basé sur Ethereum, propulsé par ZK-Snarks. En 2020, ZK n'était pas aussi populaire qu'aujourd'hui car il n'y avait pratiquement aucune documentation. La seule documentation disponible pour Circom est Google Docs de Jordi Baylina (@jbaylina). Malgré les défis, nous avons beaucoup appris en cours de route, et Dark Forest est l'incarnation de ces apprentissages.
Dark Forest est une expérience plus importante que nous ne le pensions. Nous avons plus de 10 000 joueurs, des billions de gaz dépensés, le chaos dans le jeu, des gens poignardant dans le dos sur la chaîne. La chose la plus fascinante à propos de Dark Forest et des jeux en chaîne est la nature de la plate-forme. En ayant un jeu en chaîne complète, vous ouvrez la porte à un espace de conception pour les comportements émergents, permettant aux gens de créer des contrats intelligents qui interagissent avec le jeu, ainsi que des clients et des modes de jeu alternatifs, tels que Dark Forest Arena et les mineurs GPU.
Cependant, un grand pouvoir s'accompagne d'une grande responsabilité. Lorsque nous avons lancé Dark Forest sur xDai, maintenant connu sous le nom de Gnosis Chain, nous avons fini par remplir tout l'espace de bloc de la chaîne. Cela rend la chaîne fondamentalement inutilisable pour quoi que ce soit d'autre, y compris DeFi, NFT ou toute autre chose xDAI.
Et maintenant ? Avons-nous atteint une impasse? Les jeux en chaîne complète ne deviendront-ils jamais une réalité ? Ou allons-nous recommencer à créer des jeux où seules de petites images JPEG sont en chaîne et convaincre les gens que l'argent pousse sur les arbres ? La réponse est que nous laissons les logiciels faire les choses. Beaucoup d'entre nous ont une vision très rigide de la blockchain et des roll-ups, comme s'il n'y avait pas beaucoup de place à l'amélioration. Mais je ne suis pas d'accord. Nous pouvons expérimenter et trouver de nouvelles possibilités.
Nous nous sommes posé une question : si nous devions concevoir de toutes pièces une blockchain pour les jeux et uniquement les jeux, à quoi ressemblerait-elle ? Nous avons besoin d'un débit élevé, nous devons donc mettre à l'échelle les lectures et les écritures. La plupart des blockchains sont conçues pour être lourdes en écriture. Les transactions par seconde (TPS) sont une mesure dont les gens se vantent, mais en réalité, les lectures sont tout aussi importantes. Comment savoir où se trouve un joueur si vous ne pouvez pas lire à partir d'un nœud blockchain ? C'est en fait le premier goulot d'étranglement que nous avons trouvé dans la construction de la blockchain.
Dark Forest a un problème où les nœuds complets sont fortement utilisés et les E/S explosent parce que nous devons lire les données à partir de l'état en chaîne. Cela a entraîné des milliers de dollars en coûts de serveur, qui ont été généreusement couverts pour nous par l'équipe xDAI. Cependant, ce n'est pas idéal pour le long terme. Nous avons besoin d'un débit élevé, non seulement pour les transactions écrites par seconde, mais aussi pour les lectures, telles que la récupération de données à partir de la blockchain elle-même.
Nous avons également besoin d'une blockchain évolutive horizontalement pour éviter le problème Noisy Neighbor. Nous ne voulons pas qu'un jeu populaire commence soudainement à planter sur la blockchain, arrêtant tout travail. Nous avons également besoin de flexibilité et de personnalisation afin de pouvoir modifier la machine d'état à concevoir pour le jeu. Cela inclut d'avoir une boucle de jeu, de la rendre auto-exécutable, etc.
Enfin, pour ceux qui ne sont pas familiers avec l'architecture des jeux en ligne, c'est peut-être un peu vague, il faut un taux de tick élevé. Les ticks sont l'unité atomique de temps dans le monde du jeu. Dans le contexte des blockchains, nous avons des blocs en tant qu'unités atomiques de temps. Dans les jeux, nous avons des ticks. C'est presque similaire lorsque vous construisez un jeu en chaîne complète, où le taux de génération de ticks ou de blocs de votre blockchain est égal au tick du jeu lui-même.
Par conséquent, nous avons besoin d'une blockchain avec un débit élevé, une évolutivité horizontale, une flexibilité et une personnalisation, et un taux de tick élevé. Une telle conception peut répondre aux besoins de la blockchain que nous avons conçue de toutes pièces pour le jeu.
Si vous avez un taux de tick plus élevé ou plus de blocs par seconde, le jeu se sentira plus réactif. À l'inverse, si votre taux de tick est faible, le jeu semblera lent. Une chose essentielle à retenir est que si des morceaux sont retardés, vous subirez un décalage notable dans le jeu. C'est une mauvaise expérience. Si vous avez déjà eu affaire à des joueurs en colère criant sur l'ordinateur pour avoir perdu une partie, c'est une situation absolument terrible.
Actuellement, nos rollups ont un bloc par seconde, ce qui équivaut à un tick. Si nous voulons avoir des jeux plus cool, nous avons besoin de taux de ticks plus élevés. Par exemple, Minecraft, un simple jeu de pixel art, a 26 ticks par seconde. Nous sommes encore loin de construire un jeu aussi réactif que Minecraft.
Une solution possible consiste à déployer notre propre rollup. Bien qu'il semble résoudre le problème, il ne résout pas réellement la cause première du problème. Par exemple, vous aurez un débit d'écriture plus élevé, mais pas tout à fait au niveau dont les jeux ont besoin. Bien sûr, si votre jeu compte une centaine de joueurs, cela suffira. Cependant, si vous souhaitez créer un jeu qui nécessite un débit plus élevé, il existe des contraintes très strictes en raison de la manière dont les E/S sont effectuées dans la version actuelle.
Côté lecture, on n'obtient pas vraiment de gain de performances. Vous devez toujours compter sur les indexeurs. Vous n'avez pas vraiment d'évolutivité horizontale. Si vous essayez de démarrer un nouveau cumul pour mettre à l'échelle horizontalement votre jeu, vous détruisez votre écosystème de contrats intelligents existant. Les places de marché déployées par les joueurs ne fonctionneront pas avec les autres chaînes que vous lancez pour faire évoluer horizontalement votre jeu. Cela soulève beaucoup de questions.
Enfin, le taux de tic-tac élevé et les blocs par seconde sont toujours un défi, bien que nous puissions le pousser aussi fort que possible, nous pouvons obtenir deux blocs par seconde, peut-être trois, mais c'est vraiment ainsi que ces blockchains vont. le plus éloigné, car il y a un tas de choses comme le re-marshalling qui dépendent fortement des cycles de calcul.
Pour répondre à cette question, revenons au début des années 2000 et à la fin des années 1990, lorsque les jeux en ligne comme les MMO venaient juste d'émerger. Ils ont un concept appelé sharding. Ce n'est pas un nouveau concept, il a existé dans le passé. Le mot "sharding" que nous utilisons dans l'architecture de base de données vient en fait d'une référence à Ultima Online. Ils ont été les premiers à utiliser le mot "shard" pour expliquer leurs différents serveurs.
Alors, comment fonctionne le sharding dans les jeux ? Ce n'est pas une solution unique. C'est un outil dans la boîte à outils, et la façon dont vous l'adapterez à votre jeu variera d'un cas à l'autre. Par exemple, la première construction de partitionnement est ce que j'aime appeler le partitionnement basé sur l'emplacement. Un bon modèle mental consiste à imaginer un système de coordonnées cartésien divisé en quatre quadrants, chacun avec sa propre tranche de jeu. A chaque fois que vous voulez traverser un shard, vous envoyez une communication à un autre shard en disant "hey, je veux y aller" et vous êtes téléporté vers votre shard, laissant les joueurs devant vous Body. Ce faisant, vous répartissez la charge de travail du serveur sur plusieurs instances physiques, plutôt que de forcer un serveur à effectuer tous les calculs pour l'ensemble du monde du jeu. La deuxième configuration est maintenant plus populaire. C'est ce qu'on appelle le partage multivers, où vous avez plusieurs instances de jeu qui se reflètent les unes les autres. Vous pouvez choisir le fragment auquel vous voulez accéder, et sa charge est équilibrée par défaut afin que chaque serveur ne soit pas surchargé.
Maintenant, la question clé est de savoir comment mettre ce concept en place ? C'est pourquoi nous avons créé World Engine. World Engine est notre infrastructure phare, essentiellement un trieur de fragments avisé conçu pour le démarrage. Le nôtre est différent et mieux adapté à nos besoins que la plupart des modèles de trieurs d'éclats que nous avons vus au cours des dernières discussions. La direction de notre optimisation est : A, débit, B, nous voulons nous assurer qu'il n'y a pas de verrous bloquant le temps d'exécution pour nous assurer que le taux de tic et le temps de blocage sont aussi efficaces que possible, il est donc synchrone par défaut, la façon dont nous concevons que le trieur est un tri partiel, plutôt que de forcer le tri total (chaque transaction doit se produire après l'autre).
Les éléments clés ici sont que nous avons deux choses principales. Nous avons un partage basé sur EVM, qui est comme une pure chaîne EVM, sur laquelle les joueurs peuvent déployer des contrats intelligents, se combiner avec des jeux, créer des marchés avec des taxes, etc. C'est comme une chaîne normale, non ? Quelque chose comme un bloc par seconde ou quelque chose comme ça, juste assez pour que vous puissiez faire tous vos appareils et marchés typiques.
L'ingrédient secret ici est que nous utilisons également un fragment de jeu, qui est essentiellement une mini-chaîne de blocs conçue comme un serveur de jeu hautes performances. Nous avons une interface d'implémentation personnalisée pour que vous puissiez personnaliser ce fragment à votre guise. Vous pouvez créer vos propres fragments et les injecter dans le fragment de base. Il vous suffit d'implémenter un ensemble d'interfaces standard, tout comme le Cosmos que vous connaissez, Cosmos a une interface ABC. Vous pouvez essentiellement rassembler cela dans une spécification similaire, en apportant vos propres fragments dans la pile World Engine.
La clé ici est que nous avons un taux de tick élevé que nous ne pouvons actuellement pas atteindre avec la construction de partitionnement actuelle. C'est ici que je veux vous présenter Cardinal. Cardinal est la première implémentation de partitionnement de jeu de World Engine. Il utilise Entity-Component-System (ECS) avec une architecture orientée données. Cela nous permet de paralléliser le jeu et d'augmenter le débit des calculs de jeu. Il a un taux de tick configurable jusqu'à 20 ticks par seconde. Pour les gens de la blockchain ici, c'est 20 blocs par seconde.
Nous pouvons également le géolocaliser pour réduire la latence. Par exemple, vous pouvez avoir un trieur aux États-Unis, puis les Asiatiques doivent attendre 300 millisecondes pour que la transaction atteigne le trieur. C'est un énorme problème dans les jeux car 300 ms, c'est long. Si vous essayez de jouer à un jeu FPS avec un décalage de 200 ms, en gros, vous êtes mort.
Un autre point clé qui est également important pour nous est qu'il s'auto-indexe. Nous n'avons plus besoin d'indexeurs externes. Nous n'avons pas besoin de ces frameworks pour mettre en cache l'état du jeu. Cela nous permet également de créer plus de jeux en temps réel sans problèmes de latence, car l'indexeur essaie toujours de rattraper les blocs de tri.
Nous avons également un système de plugin qui permet aux gens de paralléliser la validation ZK, etc. La meilleure partie, du moins pour moi, est que vous pouvez écrire votre code en Go. Il n'est plus nécessaire d'utiliser Solidity pour faire fonctionner votre jeu. Si vous avez déjà essayé de créer un jeu blockchain avec Solidity, cela a été un cauchemar.
Cependant, le point clé de notre construction de fragments est que vous pouvez construire n'importe quoi en tant que fragment. Ils sont fondamentalement comme un espace de conception infini, comme ce que peut être un fragment.
En supposant que vous n'aimez pas écrire votre code de jeu dans Go, vous pouvez choisir d'autres méthodes. Cependant, nous travaillons sur un fragment de jeu Solidity qui vous permettra d'implémenter des jeux dans Solidity d'une manière qui offre des possibilités de codage tout en conservant de nombreux avantages de Cardinal. Vous pouvez également créer un fragment frappé NFT avec un mempool unique et une construction de commande, résolvant le problème Noisy Neighbor similaire à la frappe de base. Vous pouvez même créer un fragment d'identité de jeu et utiliser NFT pour représenter votre identité de jeu, de sorte que vous puissiez facilement effectuer des transactions d'identité de jeu via NFT au lieu de partager des clés privées.
Il s'agit d'une architecture de haut niveau, et je n'entrerai pas trop dans les détails aujourd'hui en raison des contraintes de temps. Fondamentalement, nous permettons aux contrats intelligents EVM d'être combinés avec des fragments de jeu en utilisant un choix et un passage personnalisés. Nous avons créé un wrapper autour de Geth pour permettre la communication entre eux, ce qui ouvre beaucoup d'espace de conception dans les deux sens. Nous sommes synchrones par défaut et pouvons interagir de manière transparente et composable entre les fragments sans verrous.
Notre trieur partagé est différent en ce sens qu'il n'utilise pas la construction de séquences partagées de faisceaux atomiques qui donnent la priorité au tri global, ce qui nécessite un mécanisme de verrouillage et provoque des problèmes tels que le blocage du thread principal, entraînant des taux de ticks et des temps de blocage erratiques, et le résultat est décalage dans le jeu. Il impose également des limites sur les temps de bloc par partition et nécessite diverses cryptoéconomies et constructions pour empêcher le déni de service. Il y a aussi un gros problème que je n'ai pas vu mentionné dans de nombreuses constructions de trieur VCR : si vous avez différents fragments qui dépendent les uns des autres et provoquent des blocages, comment le résolvez-vous ? Avec la conception asynchrone, ce n'est pas un problème, car chacun fait ce qu'il veut faire, puis laisse faire.
En fait, les faisceaux atomiques et les enroulements à travers les fragments ne sont généralement pas nécessaires. Pour notre cas d'utilisation, nous n'avons besoin de rien qui nécessite des faisceaux atomiques, et nous ne pensons pas non plus que ce soit quelque chose que nous devrions concevoir nos Roll-Ups autour de la pureté du cas d'utilisation. Cela apporte également de nombreuses autres fonctionnalités intéressantes. Par exemple, chaque fragment de jeu pourrait avoir une couche DA distincte pour la chaîne de base. Par exemple, vous pouvez utiliser le fragment de base pour envoyer des données à Ethereum, et le fragment de jeu peut envoyer des données à Celestia (similaire au comité de disponibilité des données). Vous pouvez également réduire la configuration matérielle requise pour exécuter un nœud complet, car vous pouvez exécuter le nœud complet Geth du fragment de base séparément, sans exécuter le nœud du fragment de jeu, ce qui facilite l'intégration avec des choses comme Alchemy.
Pour résumer, je veux être honnête ici que beaucoup de gens s'attendent à ce que leurs constructions résolvent tous leurs problèmes, mais nous ne le faisons pas. Nous pensons que notre construction fonctionne pour nous, mais cela pourrait ne pas fonctionner pour votre cas d'utilisation. Il est irréaliste de supposer que nos constructions fonctionneront pour tout le monde. Pour nous, il répond à nos besoins, offre un débit élevé, une évolutivité horizontale, de la flexibilité et des taux de tick élevés, mais ce n'est pas un remède contre le cancer. Si vous avez besoin d'un protocole DeFi qui nécessite une composabilité synchrone, cette construction n'est peut-être pas pour vous.
En général, je crois vraiment au concept d'une architecture blockchain centrée sur l'humain. En concevant autour de rôles d'utilisateurs et de cas d'utilisation spécifiques, vous pouvez mieux faire des compromis, plutôt que d'essayer de résoudre les problèmes de chacun. L'ère de la renaissance est arrivée, et chacun peut concevoir ses propres Roll-Ups pour répondre à ses propres besoins spécifiques, au lieu de s'appuyer sur une solution générale. Je pense que nous devrions accepter l'explosion cambrienne. Ne construisez pas de roll-ups comme la première couche avec une taille unique, car il n'est pas du tout conçu pour résoudre le même problème. Personnellement, j'ai hâte de voir plus de gens explorer davantage l'espace de conception Roll-Up pour les cas d'utilisation. Par exemple, à quoi ressemblerait un Roll-Up spécialement conçu pour l'échange d'actifs ? Sera-t-il basé sur l'intention ? À quoi ressemblerait un Roll-Up spécialement conçu pour les CLOB (Central Limit Order Book) en chaîne ? Ici, je passe le micro à MJ. Merci pour votre invitation.
Version anglaise:
Voir l'original
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
Pourquoi Argus utilise-t-il le sharding pour créer une infrastructure de jeu complète ?
原标题: Comment j'ai appris à arrêter de m'inquiéter et d'aimer le partage
Lien vidéo:
Conférencier : Scott Sunarto (@smsunarto) lors de la Journée de la recherche
Édition et finition de l'article : Justin Zhao (@hiCaptainZ)
Bonjour, je suis Scott (@smsunarto), fondateur d'August Labs (@ArgusLabs_). Aujourd'hui, je vais parler d'un sujet que nous n'avons pas abordé depuis un moment. Les roll-ups devenant le courant dominant de l'époque, nous ne discutons pas autant du partage d'exécution que du partage de données. Alors, revenons sur ce sujet quelque peu négligé - le partitionnement d'exécution.
Ce sera une conversation facile. Je sais que vous avez entendu des concepts complexes toute la journée, alors je vais essayer de rendre cette discussion aussi pratique que possible. J'ai préparé une conception de diapositive appropriée pour cette présentation.
Pour ceux qui ne me connaissent pas, le plus drôle, c'est que je suis connue sur Twitter comme une anime girl. J'ai aussi raté mon diplôme universitaire juste pour être ici, au grand désarroi de mes parents. Actuellement, je suis le fondateur d'Argus Labs. Nous nous considérons comme une société de jeux, et non comme une société d'infrastructure ou de crypto-monnaie. L'une de mes plus grandes bêtes noires est que tout le monde dans les jeux cryptographiques veut créer des outils, mais personne ne veut créer de contenu ou d'applications. Nous avons besoin de plus d'applications que les utilisateurs peuvent réellement utiliser.
Auparavant, j'ai co-créé Dark Forest (@darkforest_eth) avec mes amis intelligents Brian Gu (@gubsheep) et Alan Luo (@alanluo_0). Brian dirige maintenant 0xPARC (@0xPARC) et il est beaucoup plus intelligent que moi.
La discussion d'aujourd'hui se concentrera sur l'exécution du sharding, mais dans un contexte, la plupart des gens ne sont pas familiers avec les discussions sur l'exécution du sharding. Nous discutons généralement du partage d'exécution dans le contexte de la couche 1, comme le partage Ethereum ou le partage proche. Mais aujourd'hui, je veux changer un peu le contexte. Réfléchissons à ce à quoi ressemblerait le sharding dans un environnement roll-up.
La question fondamentale ici est de savoir pourquoi une société de jeux construirait son propre roll-up, et que pouvons-nous apprendre de World of Warcraft pour concevoir des roll-ups. De plus, nous explorerons comment l'espace de conception des roll-ups va bien au-delà des réalités actuelles.
Pour répondre à ces questions, revenons à 2020, lorsque l'idée de la Forêt Sombre a été conçue pour la première fois. Nous nous sommes demandé, et si nous créions un jeu où chaque action de jeu était une transaction en chaîne ? La prémisse était ridicule à l'époque, et elle l'est toujours pour beaucoup de gens aujourd'hui. Mais c'était une hypothèse intéressante, alors nous l'avons construite, et Dark Forest est né.
Dark Forest est un jeu MMORTS d'exploration spatiale à chaîne complète entièrement basé sur Ethereum, propulsé par ZK-Snarks. En 2020, ZK n'était pas aussi populaire qu'aujourd'hui car il n'y avait pratiquement aucune documentation. La seule documentation disponible pour Circom est Google Docs de Jordi Baylina (@jbaylina). Malgré les défis, nous avons beaucoup appris en cours de route, et Dark Forest est l'incarnation de ces apprentissages.
Dark Forest est une expérience plus importante que nous ne le pensions. Nous avons plus de 10 000 joueurs, des billions de gaz dépensés, le chaos dans le jeu, des gens poignardant dans le dos sur la chaîne. La chose la plus fascinante à propos de Dark Forest et des jeux en chaîne est la nature de la plate-forme. En ayant un jeu en chaîne complète, vous ouvrez la porte à un espace de conception pour les comportements émergents, permettant aux gens de créer des contrats intelligents qui interagissent avec le jeu, ainsi que des clients et des modes de jeu alternatifs, tels que Dark Forest Arena et les mineurs GPU.
Cependant, un grand pouvoir s'accompagne d'une grande responsabilité. Lorsque nous avons lancé Dark Forest sur xDai, maintenant connu sous le nom de Gnosis Chain, nous avons fini par remplir tout l'espace de bloc de la chaîne. Cela rend la chaîne fondamentalement inutilisable pour quoi que ce soit d'autre, y compris DeFi, NFT ou toute autre chose xDAI.
Et maintenant ? Avons-nous atteint une impasse? Les jeux en chaîne complète ne deviendront-ils jamais une réalité ? Ou allons-nous recommencer à créer des jeux où seules de petites images JPEG sont en chaîne et convaincre les gens que l'argent pousse sur les arbres ? La réponse est que nous laissons les logiciels faire les choses. Beaucoup d'entre nous ont une vision très rigide de la blockchain et des roll-ups, comme s'il n'y avait pas beaucoup de place à l'amélioration. Mais je ne suis pas d'accord. Nous pouvons expérimenter et trouver de nouvelles possibilités.
Nous nous sommes posé une question : si nous devions concevoir de toutes pièces une blockchain pour les jeux et uniquement les jeux, à quoi ressemblerait-elle ? Nous avons besoin d'un débit élevé, nous devons donc mettre à l'échelle les lectures et les écritures. La plupart des blockchains sont conçues pour être lourdes en écriture. Les transactions par seconde (TPS) sont une mesure dont les gens se vantent, mais en réalité, les lectures sont tout aussi importantes. Comment savoir où se trouve un joueur si vous ne pouvez pas lire à partir d'un nœud blockchain ? C'est en fait le premier goulot d'étranglement que nous avons trouvé dans la construction de la blockchain.
Dark Forest a un problème où les nœuds complets sont fortement utilisés et les E/S explosent parce que nous devons lire les données à partir de l'état en chaîne. Cela a entraîné des milliers de dollars en coûts de serveur, qui ont été généreusement couverts pour nous par l'équipe xDAI. Cependant, ce n'est pas idéal pour le long terme. Nous avons besoin d'un débit élevé, non seulement pour les transactions écrites par seconde, mais aussi pour les lectures, telles que la récupération de données à partir de la blockchain elle-même.
Nous avons également besoin d'une blockchain évolutive horizontalement pour éviter le problème Noisy Neighbor. Nous ne voulons pas qu'un jeu populaire commence soudainement à planter sur la blockchain, arrêtant tout travail. Nous avons également besoin de flexibilité et de personnalisation afin de pouvoir modifier la machine d'état à concevoir pour le jeu. Cela inclut d'avoir une boucle de jeu, de la rendre auto-exécutable, etc.
Enfin, pour ceux qui ne sont pas familiers avec l'architecture des jeux en ligne, c'est peut-être un peu vague, il faut un taux de tick élevé. Les ticks sont l'unité atomique de temps dans le monde du jeu. Dans le contexte des blockchains, nous avons des blocs en tant qu'unités atomiques de temps. Dans les jeux, nous avons des ticks. C'est presque similaire lorsque vous construisez un jeu en chaîne complète, où le taux de génération de ticks ou de blocs de votre blockchain est égal au tick du jeu lui-même.
Par conséquent, nous avons besoin d'une blockchain avec un débit élevé, une évolutivité horizontale, une flexibilité et une personnalisation, et un taux de tick élevé. Une telle conception peut répondre aux besoins de la blockchain que nous avons conçue de toutes pièces pour le jeu.
Si vous avez un taux de tick plus élevé ou plus de blocs par seconde, le jeu se sentira plus réactif. À l'inverse, si votre taux de tick est faible, le jeu semblera lent. Une chose essentielle à retenir est que si des morceaux sont retardés, vous subirez un décalage notable dans le jeu. C'est une mauvaise expérience. Si vous avez déjà eu affaire à des joueurs en colère criant sur l'ordinateur pour avoir perdu une partie, c'est une situation absolument terrible.
Actuellement, nos rollups ont un bloc par seconde, ce qui équivaut à un tick. Si nous voulons avoir des jeux plus cool, nous avons besoin de taux de ticks plus élevés. Par exemple, Minecraft, un simple jeu de pixel art, a 26 ticks par seconde. Nous sommes encore loin de construire un jeu aussi réactif que Minecraft.
Une solution possible consiste à déployer notre propre rollup. Bien qu'il semble résoudre le problème, il ne résout pas réellement la cause première du problème. Par exemple, vous aurez un débit d'écriture plus élevé, mais pas tout à fait au niveau dont les jeux ont besoin. Bien sûr, si votre jeu compte une centaine de joueurs, cela suffira. Cependant, si vous souhaitez créer un jeu qui nécessite un débit plus élevé, il existe des contraintes très strictes en raison de la manière dont les E/S sont effectuées dans la version actuelle.
Côté lecture, on n'obtient pas vraiment de gain de performances. Vous devez toujours compter sur les indexeurs. Vous n'avez pas vraiment d'évolutivité horizontale. Si vous essayez de démarrer un nouveau cumul pour mettre à l'échelle horizontalement votre jeu, vous détruisez votre écosystème de contrats intelligents existant. Les places de marché déployées par les joueurs ne fonctionneront pas avec les autres chaînes que vous lancez pour faire évoluer horizontalement votre jeu. Cela soulève beaucoup de questions.
Enfin, le taux de tic-tac élevé et les blocs par seconde sont toujours un défi, bien que nous puissions le pousser aussi fort que possible, nous pouvons obtenir deux blocs par seconde, peut-être trois, mais c'est vraiment ainsi que ces blockchains vont. le plus éloigné, car il y a un tas de choses comme le re-marshalling qui dépendent fortement des cycles de calcul.
Pour répondre à cette question, revenons au début des années 2000 et à la fin des années 1990, lorsque les jeux en ligne comme les MMO venaient juste d'émerger. Ils ont un concept appelé sharding. Ce n'est pas un nouveau concept, il a existé dans le passé. Le mot "sharding" que nous utilisons dans l'architecture de base de données vient en fait d'une référence à Ultima Online. Ils ont été les premiers à utiliser le mot "shard" pour expliquer leurs différents serveurs.
Alors, comment fonctionne le sharding dans les jeux ? Ce n'est pas une solution unique. C'est un outil dans la boîte à outils, et la façon dont vous l'adapterez à votre jeu variera d'un cas à l'autre. Par exemple, la première construction de partitionnement est ce que j'aime appeler le partitionnement basé sur l'emplacement. Un bon modèle mental consiste à imaginer un système de coordonnées cartésien divisé en quatre quadrants, chacun avec sa propre tranche de jeu. A chaque fois que vous voulez traverser un shard, vous envoyez une communication à un autre shard en disant "hey, je veux y aller" et vous êtes téléporté vers votre shard, laissant les joueurs devant vous Body. Ce faisant, vous répartissez la charge de travail du serveur sur plusieurs instances physiques, plutôt que de forcer un serveur à effectuer tous les calculs pour l'ensemble du monde du jeu. La deuxième configuration est maintenant plus populaire. C'est ce qu'on appelle le partage multivers, où vous avez plusieurs instances de jeu qui se reflètent les unes les autres. Vous pouvez choisir le fragment auquel vous voulez accéder, et sa charge est équilibrée par défaut afin que chaque serveur ne soit pas surchargé.
Maintenant, la question clé est de savoir comment mettre ce concept en place ? C'est pourquoi nous avons créé World Engine. World Engine est notre infrastructure phare, essentiellement un trieur de fragments avisé conçu pour le démarrage. Le nôtre est différent et mieux adapté à nos besoins que la plupart des modèles de trieurs d'éclats que nous avons vus au cours des dernières discussions. La direction de notre optimisation est : A, débit, B, nous voulons nous assurer qu'il n'y a pas de verrous bloquant le temps d'exécution pour nous assurer que le taux de tic et le temps de blocage sont aussi efficaces que possible, il est donc synchrone par défaut, la façon dont nous concevons que le trieur est un tri partiel, plutôt que de forcer le tri total (chaque transaction doit se produire après l'autre).
Les éléments clés ici sont que nous avons deux choses principales. Nous avons un partage basé sur EVM, qui est comme une pure chaîne EVM, sur laquelle les joueurs peuvent déployer des contrats intelligents, se combiner avec des jeux, créer des marchés avec des taxes, etc. C'est comme une chaîne normale, non ? Quelque chose comme un bloc par seconde ou quelque chose comme ça, juste assez pour que vous puissiez faire tous vos appareils et marchés typiques.
L'ingrédient secret ici est que nous utilisons également un fragment de jeu, qui est essentiellement une mini-chaîne de blocs conçue comme un serveur de jeu hautes performances. Nous avons une interface d'implémentation personnalisée pour que vous puissiez personnaliser ce fragment à votre guise. Vous pouvez créer vos propres fragments et les injecter dans le fragment de base. Il vous suffit d'implémenter un ensemble d'interfaces standard, tout comme le Cosmos que vous connaissez, Cosmos a une interface ABC. Vous pouvez essentiellement rassembler cela dans une spécification similaire, en apportant vos propres fragments dans la pile World Engine.
La clé ici est que nous avons un taux de tick élevé que nous ne pouvons actuellement pas atteindre avec la construction de partitionnement actuelle. C'est ici que je veux vous présenter Cardinal. Cardinal est la première implémentation de partitionnement de jeu de World Engine. Il utilise Entity-Component-System (ECS) avec une architecture orientée données. Cela nous permet de paralléliser le jeu et d'augmenter le débit des calculs de jeu. Il a un taux de tick configurable jusqu'à 20 ticks par seconde. Pour les gens de la blockchain ici, c'est 20 blocs par seconde.
Nous pouvons également le géolocaliser pour réduire la latence. Par exemple, vous pouvez avoir un trieur aux États-Unis, puis les Asiatiques doivent attendre 300 millisecondes pour que la transaction atteigne le trieur. C'est un énorme problème dans les jeux car 300 ms, c'est long. Si vous essayez de jouer à un jeu FPS avec un décalage de 200 ms, en gros, vous êtes mort.
Un autre point clé qui est également important pour nous est qu'il s'auto-indexe. Nous n'avons plus besoin d'indexeurs externes. Nous n'avons pas besoin de ces frameworks pour mettre en cache l'état du jeu. Cela nous permet également de créer plus de jeux en temps réel sans problèmes de latence, car l'indexeur essaie toujours de rattraper les blocs de tri.
Nous avons également un système de plugin qui permet aux gens de paralléliser la validation ZK, etc. La meilleure partie, du moins pour moi, est que vous pouvez écrire votre code en Go. Il n'est plus nécessaire d'utiliser Solidity pour faire fonctionner votre jeu. Si vous avez déjà essayé de créer un jeu blockchain avec Solidity, cela a été un cauchemar.
Cependant, le point clé de notre construction de fragments est que vous pouvez construire n'importe quoi en tant que fragment. Ils sont fondamentalement comme un espace de conception infini, comme ce que peut être un fragment.
En supposant que vous n'aimez pas écrire votre code de jeu dans Go, vous pouvez choisir d'autres méthodes. Cependant, nous travaillons sur un fragment de jeu Solidity qui vous permettra d'implémenter des jeux dans Solidity d'une manière qui offre des possibilités de codage tout en conservant de nombreux avantages de Cardinal. Vous pouvez également créer un fragment frappé NFT avec un mempool unique et une construction de commande, résolvant le problème Noisy Neighbor similaire à la frappe de base. Vous pouvez même créer un fragment d'identité de jeu et utiliser NFT pour représenter votre identité de jeu, de sorte que vous puissiez facilement effectuer des transactions d'identité de jeu via NFT au lieu de partager des clés privées.
Il s'agit d'une architecture de haut niveau, et je n'entrerai pas trop dans les détails aujourd'hui en raison des contraintes de temps. Fondamentalement, nous permettons aux contrats intelligents EVM d'être combinés avec des fragments de jeu en utilisant un choix et un passage personnalisés. Nous avons créé un wrapper autour de Geth pour permettre la communication entre eux, ce qui ouvre beaucoup d'espace de conception dans les deux sens. Nous sommes synchrones par défaut et pouvons interagir de manière transparente et composable entre les fragments sans verrous.
Notre trieur partagé est différent en ce sens qu'il n'utilise pas la construction de séquences partagées de faisceaux atomiques qui donnent la priorité au tri global, ce qui nécessite un mécanisme de verrouillage et provoque des problèmes tels que le blocage du thread principal, entraînant des taux de ticks et des temps de blocage erratiques, et le résultat est décalage dans le jeu. Il impose également des limites sur les temps de bloc par partition et nécessite diverses cryptoéconomies et constructions pour empêcher le déni de service. Il y a aussi un gros problème que je n'ai pas vu mentionné dans de nombreuses constructions de trieur VCR : si vous avez différents fragments qui dépendent les uns des autres et provoquent des blocages, comment le résolvez-vous ? Avec la conception asynchrone, ce n'est pas un problème, car chacun fait ce qu'il veut faire, puis laisse faire.
En fait, les faisceaux atomiques et les enroulements à travers les fragments ne sont généralement pas nécessaires. Pour notre cas d'utilisation, nous n'avons besoin de rien qui nécessite des faisceaux atomiques, et nous ne pensons pas non plus que ce soit quelque chose que nous devrions concevoir nos Roll-Ups autour de la pureté du cas d'utilisation. Cela apporte également de nombreuses autres fonctionnalités intéressantes. Par exemple, chaque fragment de jeu pourrait avoir une couche DA distincte pour la chaîne de base. Par exemple, vous pouvez utiliser le fragment de base pour envoyer des données à Ethereum, et le fragment de jeu peut envoyer des données à Celestia (similaire au comité de disponibilité des données). Vous pouvez également réduire la configuration matérielle requise pour exécuter un nœud complet, car vous pouvez exécuter le nœud complet Geth du fragment de base séparément, sans exécuter le nœud du fragment de jeu, ce qui facilite l'intégration avec des choses comme Alchemy.
Pour résumer, je veux être honnête ici que beaucoup de gens s'attendent à ce que leurs constructions résolvent tous leurs problèmes, mais nous ne le faisons pas. Nous pensons que notre construction fonctionne pour nous, mais cela pourrait ne pas fonctionner pour votre cas d'utilisation. Il est irréaliste de supposer que nos constructions fonctionneront pour tout le monde. Pour nous, il répond à nos besoins, offre un débit élevé, une évolutivité horizontale, de la flexibilité et des taux de tick élevés, mais ce n'est pas un remède contre le cancer. Si vous avez besoin d'un protocole DeFi qui nécessite une composabilité synchrone, cette construction n'est peut-être pas pour vous.
En général, je crois vraiment au concept d'une architecture blockchain centrée sur l'humain. En concevant autour de rôles d'utilisateurs et de cas d'utilisation spécifiques, vous pouvez mieux faire des compromis, plutôt que d'essayer de résoudre les problèmes de chacun. L'ère de la renaissance est arrivée, et chacun peut concevoir ses propres Roll-Ups pour répondre à ses propres besoins spécifiques, au lieu de s'appuyer sur une solution générale. Je pense que nous devrions accepter l'explosion cambrienne. Ne construisez pas de roll-ups comme la première couche avec une taille unique, car il n'est pas du tout conçu pour résoudre le même problème. Personnellement, j'ai hâte de voir plus de gens explorer davantage l'espace de conception Roll-Up pour les cas d'utilisation. Par exemple, à quoi ressemblerait un Roll-Up spécialement conçu pour l'échange d'actifs ? Sera-t-il basé sur l'intention ? À quoi ressemblerait un Roll-Up spécialement conçu pour les CLOB (Central Limit Order Book) en chaîne ? Ici, je passe le micro à MJ. Merci pour votre invitation.
Version anglaise: