¿Podría un juego como @RuneScape pronto funcionar en la cadena?Contenido escrito originalmente por @lordOfAFewTod@s aspiramos a un mundo autónomo, libre de corrupción, malicia y desprecio; un mundo que sea persistente, eterno y autónomo.¿Cómo logramos esto? Al igual que en el trilema de la blockchain, siempre habrá un nivel de compromiso requerido en estos esfuerzos.Los Mundos Autónomos (AWs) enfrentan el mismo trilema. Los AWs necesitan la capacidad de escalar a millones de jugadores concurrentes, lo cual es un problema difícil de resolver.Los rollups resuelven parcialmente el trilema convirtiéndolo en un dilema, gracias a heredar la seguridad de la capa de liquidación, siempre que existan activos nativos de Capa 1 (L1) y salidas sin permisos.Con un rollup optimista, debes elegir entre escalabilidad y seguridad, por lo que algunos enfoques de rollup comprometen la seguridad utilizando disponibilidad de datos alternativa (alt DA) o plasma DA para lograr escalabilidad. Sin embargo, con un ZK Rollup, puedes probar la integridad del estado con mínimas suposiciones de confianza, buscando abordar los tres desafíos: escalabilidad, seguridad y descentralización. Zk es el objetivo final.Donkey Kong con integridad - de onchain a comprobable y de regresoLos juegos en la cadena nos prometen libertad de expresión y soberanía sobre nuestra información. Poseen estas propiedades porque funcionan en una blockchain verificada por consenso. Los juegos comprobables, utilizando pruebas zk, permiten la verificación del estado del juego y de los cálculos sin grandes esquemas de consenso. Escritos en lenguajes como Cairo, Noir o ejecutándose en RISC-Zero, estos juegos pueden operar de forma independiente en un zkVM aislado como un navegador, con salidas verificables que aseguran una ejecución veraz. Esto amplía nuestras posibilidades en la industria de los juegos en la cadena.Un ejemplo ilustrativo es un juego como Donkey Kong. Actualmente, para que tu puntuación alta sea reconocida en la tabla de líderes, debes jugar en una máquina certificada para evitar trampas, mientras grabas tu partida. Sin embargo, si Donkey Kong fuera un juego comprobable, los jugadores podrían competir en aislamiento. Lograr una puntuación alta simplemente requeriría enviar una prueba a la organización de Donkey Kong para su verificación. Este método permite a los jugadores establecerse como el Rey de Kong desde la comodidad de su hogar, sin necesidad de grabar su partida.Ejecutar juegos completos dentro de zkVMs aislados es actualmente un desafío. Para abordar esto, el ecosistema Dojo está trabajando para simplificar el proceso minimizando la complejidad. Equipos como Tonk están avanzando en el ámbito de los juegos comprobables, con un logro notable siendo la ejecución de Doom en un zkVM, anunciando "Doom Comprobable". A medida que los costos de prueba disminuyen y nuevos probadores, como Stwo, se vuelven disponibles, el potencial para diseñar juegos y aplicaciones comprobables se amplía.No necesariamente necesitamos operar nuestros juegos comprobables dentro de un zkVM aislado para beneficiarnos de sus atributos comprobables. En su lugar, podemos ejecutar nuestros juegos en redes mini-StarkNet con un número mínimo de participantes y aún lograr una seguridad garantizada.Es importante notar que el enfoque no es binario. Por ejemplo, podrías operar un juego en la cadena en un EVM y luego superponer un juego basado en Cairo, mejorando el juego principal mientras amplías sus capacidades.¿Por qué molestarse con juegos comprobables?Imagina si el mundo de RuneScape de repente se cerrara, borrando para siempre las estadísticas de juego de todos. Habría algunos jugadores furiosos. Este escenario está destinado a ocurrir en algún momento cuando los desarrolladores decidan cerrar los servidores. ¿Podemos hacerlo mejor? ¿Podemos crear un mundo tan rico, diverso e intenso como RuneScape que esté libre de que esto ocurra?Este desafío es lo que toda la escena de juegos en la cadena está tratando de resolver actualmente: crear un mundo que sea persistente, eterno y autónomo. Numerosos equipos están explorando diversos enfoques, que es exactamente el tipo de innovación y experimentación que se necesita.Se está invirtiendo mucha innovación en juegos en la cadena, pero nuestro enfoque está en explorar el árbol de tecnología de juegos comprobables utilizando Cairo y Starknet VM.Este artículo tiene como objetivo traducir algunos conceptos de juegos demostrables en un ejemplo práctico, inspirado en el legendario juego RuneScape.Duendes DemostrablesConstruyamos un mundo donde podamos probar que los duendes existen y usemos RuneScape como ejemplo, nos enfocaremos en la zona inicial del juego, Lumbridge, y sus alrededores para explorar:- Castillo de Lumbridge- Bosques Boscosos- Duendes- Artículos de InventarioPara los duendes demostrables necesitamos:- Simular movimientos dinámicos de duendes y criaturas para un mundo de juego animado.- Permitir actualizaciones de inventario en tiempo real cuando los jugadores recojan artículos.- Rastrear y guardar la progresión de los jugadores a nivel global para un juego consistente.- Diseñar mecánicas para prevenir la explotación, asegurando la integridad del juego.- Soportar escalabilidad para millones de jugadores concurrentes.Escalando Juegos Tradicionales ModernosEl desarrollo de juegos tradicionales depende de servidores centralizados para funciones esenciales como progresión, comportamiento de NPC, gestión del estado del jugador, control de artículos y aplicación de reglas. Para escalar, se añaden más servidores y el estado del juego se divide (sharding), permitiendo instancias separadas de áreas de juego para diferentes grupos de jugadores. Aunque es una solución de escalado efectiva, esta centralización significa que los desarrolladores tienen control absoluto, incluyendo la capacidad de apagar servidores. Por eso se creó la industria de juegos en cadena - para poder tener un RuneScape sin confianza…El Enfoque Tradicional de BlockchainAl intentar replicar la funcionalidad de un servidor centralizado utilizando un enfoque de blockchain tradicional, aunque teóricamente es factible, se vuelve impráctico y casi imposible escalar más allá de unos pocos miles de usuarios concurrentes debido a varias limitaciones:Validación de TransaccionesLas transacciones, o acciones de los jugadores, deben ser verificadas y procesadas por múltiples nodos en la red. Si bien este método garantiza seguridad al replicar el procesamiento y utilizar consenso para dificultar la compromisión del sistema, también introduce un cuello de botella significativo en términos de velocidad de procesamiento de transacciones - es decir, TPS. Ahora, esto, por supuesto, puede eludirse utilizando un secuenciador central único (como prácticamente todos los L2), sin embargo - más supuestos de confianza.Transacciones Por SegundoEl límite de TPS en una VM de blockchain restringe la capacidad de un juego para procesar acciones de los jugadores. A medida que el número de jugadores y sus acciones exceden la capacidad de TPS de la blockchain, se forma un retraso, lo que lleva a picos en las tarifas y a una experiencia del jugador en deterioro. Esto efectivamente limita el número de jugadores concurrentes que un único secuenciador de blockchain puede gestionar. Para superar estas limitaciones, Ethereum se centró en una hoja de ruta centrada en rollups, moviendo la ejecución a la capa de rollup.Operar nuestro mundo en un rollup puede mejorar significativamente la escalabilidad, pero sin Pruebas zk, aún dependemos de grandes mecanismos de consenso o amplios supuestos de confianza potencialmente poco fiables, que introducen riesgos. Así, zk se considera la solución definitiva para escalar, aunque aún no se ha realizado completamente.Supuesto de confianza de capas ZK en comparación con capas OP. El supuesto ZK sigue siendo fuerte con un bajo nivel de participación, permitiendo que existan mini rollups zk.Una Manera Demostrable - Utilizando Pruebas Recursivas y múltiples capasEl objetivo de cualquier blockchain es permitir que los usuarios tengan una confianza absoluta en sus acciones. Este principio a menudo se olvida en la industria; si no estamos buscando crear sistemas sin confianza, ¿cuál es el sentido de nuestros esfuerzos? Más vale depender de servidores centrales, que sobresalen en sus funciones.En nuestro mundo de RuneScape, nos enfocaremos en la escalabilidad recursiva, pionera utilizando STARKs. Tarrence ha escrito un artículo en profundidad sobre este tema, destacando la importancia de las pruebas recursivas para mantener supuestos de confianza mínimos en la Capa 2, Capa 3.En nuestro mundo, podemos aprovechar las pruebas recursivas para escalar y dividir el mundo mientras aseguramos que el duende que cualquiera derrota es, de hecho, un duende.Un diagrama rudimentario:Descomponamos esto.L1 EthereumEstablecemos el estado final aquí, por lo que cualquiera puede reconstruir el L2 si lo desea. Esto es lo que hace cada verdadero rollup.L2 StarknetEstablecemos el estado L3 aquí, por lo que cualquiera puede reconstruir el L3 si lo desea. Aquí es donde mantenemos un estado del mundo entero.L3 Realms World u Otro L3La capa de ejecución de alto rendimiento que soporta el estado global para los jugadores. Guardamos el estado final de los Lumbridge Shards aquí. Esto permite que nuevos shards se creen rápidamente cuando sea necesario, restaurando los saldos de los jugadores.Shard Lumbridge Efímero"Efímero" significa temporal, enfatizando la importancia de gestionar de manera eficiente y segura el estado del juego de cada jugador, una preocupación primordial para todos los jugadores. Al adoptar el sharding en cadena para limitar cada shard a un máximo de 30 jugadores, un número teórico que podría ser mayor pero que sirve como un ejemplo manejable, reflejamos la estructura de los servidores tradicionales con una mejora crucial: la utilización de pruebas zk para asegurar la integridad de los cambios en el estado. Esto nos permite escalar horizontalmente a miles de shards, sin sacrificar ningún rendimiento para el jugador.Aplicando este método a RuneScapeAl igual que el concepto de escalado horizontal en los servidores de juegos tradicionales, estamos aplicando una estrategia similar aquí. Al dividir el mundo del juego en numerosos shards más pequeños, permitimos que el sistema escale y acomode millones de usuarios concurrentes de manera efectiva.La clave diferencia entre los servidores de juegos tradicionales y este enfoque es que los jugadores mantienen el control total sobre su estado de juego, asegurando una mayor autonomía y seguridad. ¡Cada bit de estado puede ser reconstruido!Veamos un ejemplo:Cuando los jugadores llegan a Lumbridge, se les asigna a una cadena efímera que tiene capacidad, facilitando interacciones con hasta 29 otros jugadores mientras se asegura un alto rendimiento a través de transacciones rápidas y de bajo costo. Ahora más en profundidad:Bosques, con recursos como maderaCon esta cadena efímera, se puede rastrear el movimiento de los jugadores mientras viajan al bosque, haciendo cumplir un nivel de física de movimiento, lo hacemos con la potencia de cómputo económica que este shard permite. Luego pueden proceder a talar madera, sumándola a su saldo y avanzando su jugador.Duendes y otros monstruos de bajo nivelLos duendes podrían ser simulados de manera efectiva por un tick de juego incorporado en el secuenciador. Cuando el juego hace tick, el secuenciador avanza el estado y su ubicación hasta que un usuario llega y los derrota. Podríamos tomar una cantidad significativa del ancho de banda de los shards en esto si lo elegimos, ya que estamos limitando la cantidad de jugadores, podemos maximizar los movimientos de los NPC.Varios objetos esparcidos o dejados por monstruosLos objetos pueden ser recogidos y almacenados en el saldo de un jugador. Cuando el jugador termina su sesión, estos objetos se guardarán en el estado global. Estos valores no son efímeros y se guardan en el L3 para su uso en la próxima sesión.Finalizando la SesiónAl concluir su sesión de juego, los estados de los jugadores se preservan en un estado global al regresar al L3, preparando el escenario para su próxima zona o sesión. Esto se verifica en StarkNet L2 y, posteriormente, se verifica en L1, estableciendo de manera efectiva un RuneScape demostrablemente justo. Ahora, el siguiente paso es hacer realidad esta visión...Todo el stack que estamos construyendo es de código abierto - únete al discord de dojo o contribuye directamente al núcleo.¿Qué hay de la conexión entre estas capas? ¿No será una pesadilla para los jugadores?Sí, la conexión es problemática en este momento. Sin embargo, hay una solución clara para este problema que ya se está utilizando en el ecosistema Starknet y que pronto estará disponible en otras Layer 2. Estas se llaman Pruebas de Almacenamiento.¿Por qué Pruebas recursivas y Cadenas efímeras sobre otros métodos?Para aclarar, este es el enfoque que Dojo, Cartridge y el ecosistema Realms están adoptando para escalar el mundo que imaginamos. Es importante señalar que este no es el único método, y explorar una variedad de enfoques es beneficioso.Algunas de las mentes más brillantes también están abordando los problemas más desafiantes en este espacio, y su trabajo definitivamente vale la pena revisarlo.Lattice - OP Plasma con Redstone permite transacciones muy económicas.Playmint - Motor Optimista Único para un juego rápidoPoP - Fragmentación EVM a medidaArgus - Fragmentos de juego EVM personalizadosCurio - Enfoque modificado del servidor EVMUn momento para regresar a RunescapeCrear un RuneScape gratuito y abierto capaz de soportar millones de jugadores concurrentes no es una tarea sencilla. Sin embargo, la inteligencia colectiva y la creatividad de la industria de los videojuegos en cadena son fuerzas formidables. Por lo tanto, es razonable anticipar la aparición de juegos como este y otros en los próximos 12-24 meses.Enlace del artículo: https://t.co/xoozUyhOcq
