Mondes autonomes(AWs) font face au même trilemme. Les AWs ont besoin de la capacité de passer à des millions de joueurs simultanés, c'est un problème difficile à résoudre.
Les Rollups résolvent partiellement le trilemme en le transformant en un dilemme, grâce à l'héritage de la sécurité de la couche de règlement - tant qu'il existe des actifs natifs de la couche 1 (L1) et des sorties sans permission.
Avec un rollup optimiste, vous devez choisir entre la scalabilité et la sécurité, c'est pourquoi certaines approches de rollup compromettent la sécurité en utilisant une disponibilité alternative des données (alt DA) ou un plasma DA pour obtenir la scalabilité. Cependant, avec un ZK Rollup, vous pouvez prouver l'intégrité de l'état avec des hypothèses de confiance minimales, visant à relever les trois défis : la scalabilité, la sécurité et la décentralisation. Zk est le jeu final.
Donkey Kong avec intégrité - de onchain à prouvable et retour
Les jeux Onchain nous promettent la liberté d'expression et la souveraineté sur nos informations. Ils possèdent ces propriétés car ils fonctionnent sur une blockchain vérifiée par consensus.Jeux probables, en utilisant des preuves zk, permettent la vérification de l'état du jeu et des calculs sans de grands schémas de consensus. Écrit dans des langues comme Le Caire, Noirou en coursRISC-Zero, ces jeux peuvent fonctionner de manière indépendante sur un zkVM isolé comme un navigateur, avec des sorties vérifiables garantissant une exécution honnête. Cela élargit nos possibilités dans l'industrie du jeu en chaîne.
Un exemple illustratif est un jeu comme Donkey Kong. Actuellement, pour que votre meilleur score soit reconnu sur le classement, vous devez jouer sur une machine certifiée pour éviter la triche, tout en enregistrant votre gameplay. Cependant, si Donkey Kong était un jeu vérifiable, les joueurs pourraient compétitionner en toute isolation. Atteindre un meilleur score nécessiterait simplement de soumettre une preuve à l'organisation Donkey Kong pour vérification. Cette méthode permet aux joueurs de s'établir en tant que Roi de Kong depuis le confort de leur domicile, sans avoir besoin d'enregistrer leur gameplay!
Exécuter des jeux complets au sein de zkVMs isolés est actuellement difficile. Pour résoudre ce problème, l'écosystème Dojo s'efforce de simplifier le processus en minimisant la complexité. Des équipes comme Tonkavancent dans l'arène du jeu probant, avec une réalisation notable étant l'exécution de Doomsur un zkVM, annonçant "Doom Probable". À mesure que les coûts de preuve diminuent et que de nouveaux prouveurs, tels queStwo, devenez disponibles, le potentiel de conception de jeux et d'applications vérifiables s'élargit.
Nous n'avons pas nécessairement besoin d'exploiter nos jeux vérifiables au sein d'un zkVM isolé pour bénéficier de leurs attributs vérifiables. Au lieu de cela, nous pouvons exécuter nos jeux sur des mini-réseaux StarkNet avec un nombre minimal de participants et obtenir toujours une sécurité garantie.
Il est important de noter que l'approche n'est pas binaire. Par exemple, vous pourriez exploiter un jeu onchain sur un EVM, puis superposer un jeu basé sur Cairo, améliorant le jeu de base tout en élargissant ses capacités.
Pourquoi se soucier des jeux prouvables?
Imaginez si le monde de RuneScape fermait soudainement, effaçant à jamais les statistiques de jeu de tout le monde. Il y aurait des joueurs furieux. Ce scénario est susceptible de se produire à un moment donné lorsque les développeurs décident de fermer les serveurs. Pouvons-nous faire mieux ? Pouvons-nous créer un monde aussi riche, diversifié et intense que RuneScape, à l'abri de ce genre d'événement ?
Ce défi est ce que l'ensemble de la scène du jeu sur chaîne tente actuellement de résoudre : créer un monde persistant, éternel et autonome. De nombreuses équipes explorent différentes approches, ce qui correspond exactement au type d'innovation et d'expérimentation nécessaires.
Beaucoup d'innovation est investie dans les jeux onchain, mais notre focus est d'explorer l'arbre de technologie de jeu prouvable en utilisant Cairo et Starknet VM. Cet article vise à traduire certains concepts de jeu prouvables en un exemple pratique, inspiré par le légendaire jeu RuneScape.
Inspiré pour écrire ceci après le discours légendaire de Skystrife chad Kooshobas à Eth Istanbul
Construisons un monde où nous pouvons prouver que les gobelins existent et utilisons RuneScape comme exemple, nous nous concentrerons sur la zone initiale du jeu, Lumbridge, et ses environs pour explorer :
Pour les gobelins probables, nous devons :
Le développement traditionnel de jeux dépend de serveurs centralisés pour des fonctions essentielles telles que la progression, le comportement des PNJ, la gestion de l'état du joueur, le contrôle des objets et l'application des règles. Pour évoluer, davantage de serveurs sont ajoutés et l'état du jeu est divisé (sharding), permettant des instances séparées des zones de jeu pour différents groupes de joueurs. Bien que cela soit une solution d'évolutivité efficace, cette centralisation signifie que les développeurs ont un contrôle ultime, y compris la possibilité d'arrêter les serveurs. C'est pourquoi l'industrie du jeu sur chaîne a été créée - pour pouvoir avoir un RuneScape sans confiance...
Lorsqu'on tente de reproduire la fonctionnalité d'un serveur centralisé en utilisant une approche blockchain traditionnelle, bien que cela soit théoriquement faisable, cela devient impraticable et presque impossible à mettre à l'échelle au-delà de quelques milliers d'utilisateurs simultanés en raison de plusieurs limitations :
Validation des transactions
Les transactions, ou actions des joueurs, doivent être vérifiées et traitées par plusieurs nœuds à travers le réseau. Bien que cette méthode assure la sécurité en reproduisant le traitement et en utilisant un consensus pour rendre la compromission du système plus difficile, elle introduit également un goulot d'étranglement significatif en termes de vitesse de traitement des transactions - c'est-à-dire le TPS. Bien sûr, cela peut être contourné en utilisant un seul séquenceur central (comme à peu près tous les L2), cependant, cela implique davantage d'hypothèses de confiance.
Transactions Par Seconde
La limite de TPS sur une VM blockchain restreint la capacité d'un jeu à traiter les actions des joueurs. À mesure que le nombre de joueurs et de leurs actions dépasse la capacité TPS de la blockchain, un retard se forme, entraînant des pics de frais et une détérioration de l'expérience du joueur. Cela limite effectivement le nombre de joueurs concurrents qu'un seul séquenceur blockchain peut gérer. Pour surmonter ces limitations, Ethereum s'est concentré sur une feuille de route centrée sur les rollups, déplaçant l'exécution vers la couche rollup.
Faire fonctionner notre monde sur un rollup peut considérablement améliorer la scalabilité, mais sans preuves zk, nous dépendons encore de grands mécanismes de consensus ou de larges hypothèses de confiance potentiellement fragiles, ce qui introduit des risques. Ainsi, zk est considéré comme la solution ultime pour l'évolutivité, bien qu'elle n'ait pas encore été pleinement réalisée.
L'hypothèse de confiance des couches ZK par rapport aux couches OP. L'hypothèse ZK reste forte avec un faible niveau de participation, permettant l'existence de mini rollups zk.
L'objectif de toute blockchain est de permettre aux utilisateurs d'avoir une confiance absolue dans leurs actions. Ce principe est souvent oublié dans l'industrie ; si nous ne visons pas à créer des systèmes sans confiance, alors à quoi bon nos efforts ? Autant compter sur des serveurs centraux, qui excellent dans leurs fonctions.
Dans notre monde RuneScape, nous nous concentrerons sur le dimensionnement récursif, pionnier en utilisant STARKs.Tarrencea écrit un article approfondi sur ce sujet, mettant en lumière l'importance des preuves récursives dans le maintien des hypothèses de confiance minimales sur la couche 2, couche 3.
Dans notre monde, nous pouvons exploiter des preuves récursives pour mettre à l'échelle et fragmenter le monde tout en veillant à ce que le gobelin que quiconque vainc soit effectivement un gobelin.
Un diagramme grossier :
L1 Ethereum
Nous réglons l'état final ici, afin que quiconque puisse reconstruire le L2 s'il le souhaite. C'est ce que fait chaque vrai rollup.
L2 Starknet
Nous réglons l'état L3 ici, donc n'importe qui peut reconstruire le L3 s'ils le choisissent. C'est là que nous maintenons un état du monde entier.
L3 Royaumes Monde ou Autre L3
La couche d'exécution haute performance prenant en charge l'état global pour les joueurs. Nous sauvegardons ici l'état final des éclats de Lumbridge. Cela permet la création rapide de nouveaux éclats lorsque nécessaire pour restaurer les soldes des joueurs.
Éphémères éclats de Lumbridge
«Éphémère» signifie temporaire, mettant l'accent sur l'importance de gérer efficacement et en toute sécurité l'état de jeu de chaque joueur, une préoccupation primordiale pour tous les joueurs. En adoptant le sharding de chaîne pour limiter chaque fragment à un maximum de 30 joueurs, un nombre théorique qui pourrait être plus élevé mais qui sert d'exemple gérable, nous reproduisons la structure des serveurs traditionnels avec une amélioration cruciale : l'utilisation de preuves zk pour garantir l'intégrité des changements d'état. Cela nous permet de mettre à l'échelle horizontalement jusqu'à des milliers de fragments, sans sacrifier les performances pour le joueur.
Tout comme le concept de mise à l'échelle horizontale dans les serveurs de jeux traditionnels, nous appliquons une stratégie similaire ici. En divisant le monde du jeu en de nombreux fragments plus petits, nous permettons au système de s'adapter et d'accueillir efficacement des millions d'utilisateurs simultanés.
La principale différence entre les serveurs de jeux traditionnels et cette approche est que les joueurs conservent un contrôle total sur l'état de leur jeu, garantissant une plus grande autonomie et sécurité. Chaque bit d'état peut être reconstruit!
Marchons-y dans l'exemple :
Lorsque les joueurs arrivent à Lumbridge, ils sont affectés à une chaîne éphémère qui a une capacité, facilitant les interactions avec jusqu'à 29 autres joueurs tout en garantissant des performances élevées grâce à des transactions rapides et peu coûteuses. Maintenant plus en profondeur :
Avec cette chaîne éphémère, les mouvements des joueurs peuvent être suivis lorsqu'ils se déplacent vers la forêt, imposant un niveau de physique des mouvements, nous le faisons avec la puissance de calcul bon marché que cette shard permet. Ils peuvent ensuite procéder à la coupe du bois, l'ajoutant à leur solde et faisant avancer leur joueur.
Les gobelins pourraient être efficacement simulés par un tick de jeu intégré sur le séquenceur. Lorsque le jeu avance, le séquenceur fait évoluer l'état et leur emplacement jusqu'à ce qu'un utilisateur vienne et les tue. Nous pourrions prendre une quantité significative de la bande passante des fragments sur cela si nous choisissons, puisque nous limitons le nombre de joueurs, nous pouvons maximiser les mouvements des PNJ.
Les objets peuvent être ramassés et stockés dans le solde d'un joueur. Lorsque le joueur termine sa session, ces objets seront enregistrés dans l'état global. Ces valeurs ne sont pas éphémères et sont enregistrées dans le L3 pour une utilisation lors de la prochaine session.
À la fin de leur session de jeu, les états des joueurs sont préservés dans un état global en revenant à L3, préparant le terrain pour leur prochaine zone ou session. Cela est ensuite vérifié sur StarkNet L2, puis vérifié sur L1, établissant ainsi de manière efficace un RuneScape provablement équitable. Maintenant, la prochaine étape est de concrétiser cette vision...
L'ensemble de la pile que nous construisons est open source - rejoignez le dojo discordou contribuer au noyaudirectement.
Oui, le pontage pose actuellement problème. Cependant, il existe une solution claire à ce problème qui est déjà utilisée dans l'écosystème de Starknet et sera bientôt disponible sur d'autres couches 2. On les appelle Preuves de stockage. Oui, j'incorpore mon propre tweet. La partie 2 discutera de cela.
https://twitter.com/lordOfAFew/status/1762796441494520267
Pour clarifier, c'est l'approche que Dojo, Cartridge et l'écosystème des Royaumes adoptent pour mettre à l'échelle le monde que nous envisageons. Il est important de noter que ce n'est pas la seule méthode, et explorer une variété d'approches est bénéfique. Certains des esprits les plus brillants que je connais abordent également les problèmes les plus complexes dans cet espace, et leur travail vaut vraiment la peine d'être vérifié.
Créer un RuneScape gratuit et ouvert capable de supporter des millions de joueurs simultanés n'est pas une mince affaire. Cependant, l'intelligence collective et la créativité de l'industrie du jeu sur chaîne de blocs sont des forces redoutables. Par conséquent, il est raisonnable d'anticiper l'émergence de jeux comme celui-ci et d'autres dans les 12 à 24 prochains mois. Il est temps de retourner à RuneScape, ou peut-être plus justement, d'accueillir l'aube de RealmScape. ;)
Mời người khác bỏ phiếu
Mondes autonomes(AWs) font face au même trilemme. Les AWs ont besoin de la capacité de passer à des millions de joueurs simultanés, c'est un problème difficile à résoudre.
Les Rollups résolvent partiellement le trilemme en le transformant en un dilemme, grâce à l'héritage de la sécurité de la couche de règlement - tant qu'il existe des actifs natifs de la couche 1 (L1) et des sorties sans permission.
Avec un rollup optimiste, vous devez choisir entre la scalabilité et la sécurité, c'est pourquoi certaines approches de rollup compromettent la sécurité en utilisant une disponibilité alternative des données (alt DA) ou un plasma DA pour obtenir la scalabilité. Cependant, avec un ZK Rollup, vous pouvez prouver l'intégrité de l'état avec des hypothèses de confiance minimales, visant à relever les trois défis : la scalabilité, la sécurité et la décentralisation. Zk est le jeu final.
Donkey Kong avec intégrité - de onchain à prouvable et retour
Les jeux Onchain nous promettent la liberté d'expression et la souveraineté sur nos informations. Ils possèdent ces propriétés car ils fonctionnent sur une blockchain vérifiée par consensus.Jeux probables, en utilisant des preuves zk, permettent la vérification de l'état du jeu et des calculs sans de grands schémas de consensus. Écrit dans des langues comme Le Caire, Noirou en coursRISC-Zero, ces jeux peuvent fonctionner de manière indépendante sur un zkVM isolé comme un navigateur, avec des sorties vérifiables garantissant une exécution honnête. Cela élargit nos possibilités dans l'industrie du jeu en chaîne.
Un exemple illustratif est un jeu comme Donkey Kong. Actuellement, pour que votre meilleur score soit reconnu sur le classement, vous devez jouer sur une machine certifiée pour éviter la triche, tout en enregistrant votre gameplay. Cependant, si Donkey Kong était un jeu vérifiable, les joueurs pourraient compétitionner en toute isolation. Atteindre un meilleur score nécessiterait simplement de soumettre une preuve à l'organisation Donkey Kong pour vérification. Cette méthode permet aux joueurs de s'établir en tant que Roi de Kong depuis le confort de leur domicile, sans avoir besoin d'enregistrer leur gameplay!
Exécuter des jeux complets au sein de zkVMs isolés est actuellement difficile. Pour résoudre ce problème, l'écosystème Dojo s'efforce de simplifier le processus en minimisant la complexité. Des équipes comme Tonkavancent dans l'arène du jeu probant, avec une réalisation notable étant l'exécution de Doomsur un zkVM, annonçant "Doom Probable". À mesure que les coûts de preuve diminuent et que de nouveaux prouveurs, tels queStwo, devenez disponibles, le potentiel de conception de jeux et d'applications vérifiables s'élargit.
Nous n'avons pas nécessairement besoin d'exploiter nos jeux vérifiables au sein d'un zkVM isolé pour bénéficier de leurs attributs vérifiables. Au lieu de cela, nous pouvons exécuter nos jeux sur des mini-réseaux StarkNet avec un nombre minimal de participants et obtenir toujours une sécurité garantie.
Il est important de noter que l'approche n'est pas binaire. Par exemple, vous pourriez exploiter un jeu onchain sur un EVM, puis superposer un jeu basé sur Cairo, améliorant le jeu de base tout en élargissant ses capacités.
Pourquoi se soucier des jeux prouvables?
Imaginez si le monde de RuneScape fermait soudainement, effaçant à jamais les statistiques de jeu de tout le monde. Il y aurait des joueurs furieux. Ce scénario est susceptible de se produire à un moment donné lorsque les développeurs décident de fermer les serveurs. Pouvons-nous faire mieux ? Pouvons-nous créer un monde aussi riche, diversifié et intense que RuneScape, à l'abri de ce genre d'événement ?
Ce défi est ce que l'ensemble de la scène du jeu sur chaîne tente actuellement de résoudre : créer un monde persistant, éternel et autonome. De nombreuses équipes explorent différentes approches, ce qui correspond exactement au type d'innovation et d'expérimentation nécessaires.
Beaucoup d'innovation est investie dans les jeux onchain, mais notre focus est d'explorer l'arbre de technologie de jeu prouvable en utilisant Cairo et Starknet VM. Cet article vise à traduire certains concepts de jeu prouvables en un exemple pratique, inspiré par le légendaire jeu RuneScape.
Inspiré pour écrire ceci après le discours légendaire de Skystrife chad Kooshobas à Eth Istanbul
Construisons un monde où nous pouvons prouver que les gobelins existent et utilisons RuneScape comme exemple, nous nous concentrerons sur la zone initiale du jeu, Lumbridge, et ses environs pour explorer :
Pour les gobelins probables, nous devons :
Le développement traditionnel de jeux dépend de serveurs centralisés pour des fonctions essentielles telles que la progression, le comportement des PNJ, la gestion de l'état du joueur, le contrôle des objets et l'application des règles. Pour évoluer, davantage de serveurs sont ajoutés et l'état du jeu est divisé (sharding), permettant des instances séparées des zones de jeu pour différents groupes de joueurs. Bien que cela soit une solution d'évolutivité efficace, cette centralisation signifie que les développeurs ont un contrôle ultime, y compris la possibilité d'arrêter les serveurs. C'est pourquoi l'industrie du jeu sur chaîne a été créée - pour pouvoir avoir un RuneScape sans confiance...
Lorsqu'on tente de reproduire la fonctionnalité d'un serveur centralisé en utilisant une approche blockchain traditionnelle, bien que cela soit théoriquement faisable, cela devient impraticable et presque impossible à mettre à l'échelle au-delà de quelques milliers d'utilisateurs simultanés en raison de plusieurs limitations :
Validation des transactions
Les transactions, ou actions des joueurs, doivent être vérifiées et traitées par plusieurs nœuds à travers le réseau. Bien que cette méthode assure la sécurité en reproduisant le traitement et en utilisant un consensus pour rendre la compromission du système plus difficile, elle introduit également un goulot d'étranglement significatif en termes de vitesse de traitement des transactions - c'est-à-dire le TPS. Bien sûr, cela peut être contourné en utilisant un seul séquenceur central (comme à peu près tous les L2), cependant, cela implique davantage d'hypothèses de confiance.
Transactions Par Seconde
La limite de TPS sur une VM blockchain restreint la capacité d'un jeu à traiter les actions des joueurs. À mesure que le nombre de joueurs et de leurs actions dépasse la capacité TPS de la blockchain, un retard se forme, entraînant des pics de frais et une détérioration de l'expérience du joueur. Cela limite effectivement le nombre de joueurs concurrents qu'un seul séquenceur blockchain peut gérer. Pour surmonter ces limitations, Ethereum s'est concentré sur une feuille de route centrée sur les rollups, déplaçant l'exécution vers la couche rollup.
Faire fonctionner notre monde sur un rollup peut considérablement améliorer la scalabilité, mais sans preuves zk, nous dépendons encore de grands mécanismes de consensus ou de larges hypothèses de confiance potentiellement fragiles, ce qui introduit des risques. Ainsi, zk est considéré comme la solution ultime pour l'évolutivité, bien qu'elle n'ait pas encore été pleinement réalisée.
L'hypothèse de confiance des couches ZK par rapport aux couches OP. L'hypothèse ZK reste forte avec un faible niveau de participation, permettant l'existence de mini rollups zk.
L'objectif de toute blockchain est de permettre aux utilisateurs d'avoir une confiance absolue dans leurs actions. Ce principe est souvent oublié dans l'industrie ; si nous ne visons pas à créer des systèmes sans confiance, alors à quoi bon nos efforts ? Autant compter sur des serveurs centraux, qui excellent dans leurs fonctions.
Dans notre monde RuneScape, nous nous concentrerons sur le dimensionnement récursif, pionnier en utilisant STARKs.Tarrencea écrit un article approfondi sur ce sujet, mettant en lumière l'importance des preuves récursives dans le maintien des hypothèses de confiance minimales sur la couche 2, couche 3.
Dans notre monde, nous pouvons exploiter des preuves récursives pour mettre à l'échelle et fragmenter le monde tout en veillant à ce que le gobelin que quiconque vainc soit effectivement un gobelin.
Un diagramme grossier :
L1 Ethereum
Nous réglons l'état final ici, afin que quiconque puisse reconstruire le L2 s'il le souhaite. C'est ce que fait chaque vrai rollup.
L2 Starknet
Nous réglons l'état L3 ici, donc n'importe qui peut reconstruire le L3 s'ils le choisissent. C'est là que nous maintenons un état du monde entier.
L3 Royaumes Monde ou Autre L3
La couche d'exécution haute performance prenant en charge l'état global pour les joueurs. Nous sauvegardons ici l'état final des éclats de Lumbridge. Cela permet la création rapide de nouveaux éclats lorsque nécessaire pour restaurer les soldes des joueurs.
Éphémères éclats de Lumbridge
«Éphémère» signifie temporaire, mettant l'accent sur l'importance de gérer efficacement et en toute sécurité l'état de jeu de chaque joueur, une préoccupation primordiale pour tous les joueurs. En adoptant le sharding de chaîne pour limiter chaque fragment à un maximum de 30 joueurs, un nombre théorique qui pourrait être plus élevé mais qui sert d'exemple gérable, nous reproduisons la structure des serveurs traditionnels avec une amélioration cruciale : l'utilisation de preuves zk pour garantir l'intégrité des changements d'état. Cela nous permet de mettre à l'échelle horizontalement jusqu'à des milliers de fragments, sans sacrifier les performances pour le joueur.
Tout comme le concept de mise à l'échelle horizontale dans les serveurs de jeux traditionnels, nous appliquons une stratégie similaire ici. En divisant le monde du jeu en de nombreux fragments plus petits, nous permettons au système de s'adapter et d'accueillir efficacement des millions d'utilisateurs simultanés.
La principale différence entre les serveurs de jeux traditionnels et cette approche est que les joueurs conservent un contrôle total sur l'état de leur jeu, garantissant une plus grande autonomie et sécurité. Chaque bit d'état peut être reconstruit!
Marchons-y dans l'exemple :
Lorsque les joueurs arrivent à Lumbridge, ils sont affectés à une chaîne éphémère qui a une capacité, facilitant les interactions avec jusqu'à 29 autres joueurs tout en garantissant des performances élevées grâce à des transactions rapides et peu coûteuses. Maintenant plus en profondeur :
Avec cette chaîne éphémère, les mouvements des joueurs peuvent être suivis lorsqu'ils se déplacent vers la forêt, imposant un niveau de physique des mouvements, nous le faisons avec la puissance de calcul bon marché que cette shard permet. Ils peuvent ensuite procéder à la coupe du bois, l'ajoutant à leur solde et faisant avancer leur joueur.
Les gobelins pourraient être efficacement simulés par un tick de jeu intégré sur le séquenceur. Lorsque le jeu avance, le séquenceur fait évoluer l'état et leur emplacement jusqu'à ce qu'un utilisateur vienne et les tue. Nous pourrions prendre une quantité significative de la bande passante des fragments sur cela si nous choisissons, puisque nous limitons le nombre de joueurs, nous pouvons maximiser les mouvements des PNJ.
Les objets peuvent être ramassés et stockés dans le solde d'un joueur. Lorsque le joueur termine sa session, ces objets seront enregistrés dans l'état global. Ces valeurs ne sont pas éphémères et sont enregistrées dans le L3 pour une utilisation lors de la prochaine session.
À la fin de leur session de jeu, les états des joueurs sont préservés dans un état global en revenant à L3, préparant le terrain pour leur prochaine zone ou session. Cela est ensuite vérifié sur StarkNet L2, puis vérifié sur L1, établissant ainsi de manière efficace un RuneScape provablement équitable. Maintenant, la prochaine étape est de concrétiser cette vision...
L'ensemble de la pile que nous construisons est open source - rejoignez le dojo discordou contribuer au noyaudirectement.
Oui, le pontage pose actuellement problème. Cependant, il existe une solution claire à ce problème qui est déjà utilisée dans l'écosystème de Starknet et sera bientôt disponible sur d'autres couches 2. On les appelle Preuves de stockage. Oui, j'incorpore mon propre tweet. La partie 2 discutera de cela.
https://twitter.com/lordOfAFew/status/1762796441494520267
Pour clarifier, c'est l'approche que Dojo, Cartridge et l'écosystème des Royaumes adoptent pour mettre à l'échelle le monde que nous envisageons. Il est important de noter que ce n'est pas la seule méthode, et explorer une variété d'approches est bénéfique. Certains des esprits les plus brillants que je connais abordent également les problèmes les plus complexes dans cet espace, et leur travail vaut vraiment la peine d'être vérifié.
Créer un RuneScape gratuit et ouvert capable de supporter des millions de joueurs simultanés n'est pas une mince affaire. Cependant, l'intelligence collective et la créativité de l'industrie du jeu sur chaîne de blocs sont des forces redoutables. Par conséquent, il est raisonnable d'anticiper l'émergence de jeux comme celui-ci et d'autres dans les 12 à 24 prochains mois. Il est temps de retourner à RuneScape, ou peut-être plus justement, d'accueillir l'aube de RealmScape. ;)