Mundos Autónomos(AWs) se enfrentan al mismo trilema. Los AWs necesitan la capacidad de escalar a millones de jugadores concurrentes, este es un problema difícil de resolver.

Las rollups resuelven parcialmente el trilema convirtiéndolo en un dilema, gracias a heredar la seguridad de la capa de liquidación, siempre y cuando haya activos nativos de la Capa 1 (L1) y salidas sin permiso.

Con un rollup optimista, necesitas elegir entre escalabilidad y seguridad, por eso algunos enfoques de rollup comprometen la seguridad al utilizar disponibilidad de datos alternativos (DA alt) o plasma DA para lograr escalabilidad. Sin embargo, con un ZK Rollup, puedes demostrar la integridad del estado con suposiciones mínimas de confianza, con el objetivo de 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 vuelta

Los juegos Onchain nos prometen libertad de expresión y soberanía sobre nuestra información. Poseen estas propiedades porque se ejecutan en una cadena de bloques verificada por consenso.Juegos comprobables, usando pruebas zk, permiten la verificación del estado del juego y cálculos sin grandes esquemas de consenso. Escrito en lenguajes como Cairo, Noiro correr 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 juegos onchain.

Un ejemplo ilustrativo es un juego como Donkey Kong. Actualmente, para que su puntuación más alta sea reconocida en la tabla de clasificación, debe jugar en una máquina certificada para evitar trampas, mientras graba su juego. 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 juego!

Ejecutar juegos completos dentro de zkVMs aislados actualmente es un desafío. Para abordar esto, el ecosistema Dojo está trabajando para simplificar el proceso al minimizar la complejidad. Equipos como Tonk están avanzando en el campo del juego demostrable, con un logro notable que es la ejecución de Doomen un zkVM, anunciando "Doom Probable." A medida que los costos de prueba disminuyen y nuevos probadores, como Stwo, convertirse disponible, el potencial para diseñar juegos y aplicaciones probables se amplía.

No necesariamente tenemos que 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 así lograr una seguridad garantizada.

Es importante tener en cuenta que el enfoque no es binario. Por ejemplo, podrías operar un juego onchain en un EVM y luego añadir un juego basado en Cairo en la parte superior, mejorando el juego principal mientras amplías sus capacidades.

¿Por qué molestarse con juegos comprobables?

Imagina si el mundo de RuneScape se cerrara repentinamente, 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 alguna vez?

Este desafío es lo que toda la escena de juegos en cadena está tratando de resolver actualmente: crear un mundo persistente, eterno y autónomo. Numerosos equipos están explorando varios enfoques, que es exactamente el tipo de innovación y experimentación necesaria.

Se está invirtiendo mucha innovación en los juegos en 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 comprobables en un ejemplo práctico, inspirado en el legendario juego RuneScape.

Inspirado para escribir esto después del legendario discurso de Skystrife chad Kooshobas en Eth Estambul

Goblins demostrables

Construyamos un mundo donde podamos demostrar que los goblins existen y usemos RuneScape como ejemplo, nos enfocaremos en la zona inicial del juego, Lumbridge, y sus alrededores para explorar:

• Castillo de Lumbridge
• Bosques de madera
• Duendes
• Artículos de inventario

Para Goblins comprobables necesitamos:

• Simular movimientos dinámicos de duendes y criaturas para un mundo de juego animado.
• Habilitar actualizaciones de inventario en tiempo real cuando los jugadores recogen objetos.
• Seguir y guardar la progresión del jugador a nivel mundial para un juego consistente.
• Diseñar mecánicas para prevenir la explotación, garantizando la integridad del juego.
• Soporte de escalabilidad para millones de jugadores concurrentes.

Escalando Juegos Tradicionales Modernos

El desarrollo tradicional de juegos depende de servidores centralizados para funciones esenciales como la progresión, el comportamiento de PNJ, la gestión del estado del jugador, el control de objetos y la aplicación de reglas. Para escalar, se agregan más servidores y el estado del juego se divide (fragmentación), lo que permite instancias separadas de áreas de juego para diferentes grupos de jugadores. Aunque es una solución de escalado eficaz, esta centralización significa que los desarrolladores tienen un control absoluto, incluida la capacidad de cerrar servidores. Por eso se creó la industria de juegos en cadena: para poder tener un RuneScape sin confianza...

La forma tradicional de blockchain

Al intentar replicar la funcionalidad de un servidor centralizado utilizando un enfoque de blockchain tradicional, si bien es teóricamente 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 Transacciones

Las transacciones, o acciones de los jugadores, deben ser verificadas y procesadas por múltiples nodos en toda la red. Si bien este método garantiza la seguridad al replicar el procesamiento y utilizar el consenso para dificultar la comprometida del sistema, también introduce una importante restricción en términos de velocidad de procesamiento de transacciones, es decir, TPS. Ahora, por supuesto, esto se puede evitar utilizando un único secuenciador central (como prácticamente todos los L2), sin embargo, incluye más suposiciones de confianza.

Transaciones Por Segundo

El límite de TPS en una VM de blockchain restringe la capacidad de un juego para procesar las acciones de los jugadores. A medida que el número de jugadores y sus acciones supera la capacidad de TPS de la blockchain, se forma un backlog, lo que lleva a picos en las tarifas y a una experiencia de jugador deteriorada. Esto efectivamente limita el número de jugadores concurrentes que un solo secuenciador de blockchain puede manejar. Para superar estas limitaciones, Ethereum se centró en una hoja de ruta centrada en rollup, trasladando 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 mecanismos de consenso grandes o amplias suposiciones de confianza potencialmente frágiles, lo que introduce riesgos. Por lo tanto, zk se considera la solución definitiva para escalar, aunque aún no se ha realizado completamente.

Suposición de confianza de las capas ZK en comparación con las capas OP. La suposición de ZK sigue siendo sólida con un bajo nivel de participación, lo que permite la existencia de mini zk rollups.

Una forma demostrable: utilizando pruebas recursivas y múltiples capas

El objetivo de cualquier blockchain es permitir a los usuarios tener 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 punto de nuestros esfuerzos? Podríamos igualmente depender de servidores centrales, que sobresalen en sus funciones.

En nuestro mundo de RuneScape, nos centraremos en el escalado recursivo, pionero utilizando STARKs.Tarrenceha escrito unartículo detallado sobre este tema, destacando la importancia de las pruebas recursivas en mantener suposiciones mínimas de confianza en la Capa 2, Capa 3.

En nuestro mundo, podemos aprovechar las pruebas recursivas para escalar y fragmentar el mundo mientras nos aseguramos de que el goblin que alguien derrota es realmente un goblin.

Un diagrama rudimentario:

Vamos a analizar esto.

L1 Ethereum

Establecemos el estado final aquí, para que cualquiera pueda reconstruir el L2 si así lo desea. Esto es lo que hace cada rollup verdadero.

L2 Starknet

Establecemos el estado L3 aquí, por lo que cualquiera puede reconstruir el L3 si así lo elige. Aquí es donde mantenemos un estado de todo el mundo.

L3 Realms World u Otros L3

La capa de ejecución de alto rendimiento que soporta el estado global para los jugadores. Guardamos el estado final de las Lumbridge Shards aquí. Esto permite que se creen rápidamente nuevos fragmentos cuando sea necesario para restaurar los saldos de los jugadores.

Fragmentos efímeros de Lumbridge

“Ephemeral” significa temporal, enfatizando la importancia de gestionar de manera eficiente y segura el estado de juego de cada jugador, una preocupación fundamental para todos los jugadores. Al adoptar el fragmentado de cadena para limitar cada fragmento a un máximo de 30 jugadores, un número teórico que podría ser mayor pero que sirve como 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 de estado. Esto nos permite escalar horizontalmente a miles de fragmentos, sin sacrificar rendimiento alguno para el jugador.

Aplicar este método a RuneScape

Al 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 fragmentos más pequeños, permitimos que el sistema escale y acomode de manera efectiva a millones de usuarios concurrentes.

La diferencia clave entre los servidores de juegos tradicionales y este enfoque es que los jugadores mantienen un control completo sobre su estado de juego, lo que garantiza una mayor autonomía y seguridad. ¡Cada bit de estado puede ser reconstruido!

Vamos a caminarlo en el ejemplo:

Cuando los jugadores llegan a Lumbridge, se les asignan a una cadena efímera que tiene capacidad, facilitando interacciones con hasta 29 otros jugadores mientras se garantiza un alto rendimiento a través de transacciones rápidas y de bajo costo. Ahora más profundo:

• Bosques, con recursos como madera

Con esta cadena efímera, los movimientos de los jugadores pueden ser rastreados mientras viajan al bosque, imponiendo un nivel de física de movimiento, lo hacemos con la potencia informática económica que permite este shard. Luego pueden proceder a cortar madera, agregarla a su saldo y avanzar en su jugador.

• Goblins y otros monstruos de bajo nivel

Los trasgos podrían ser simulados de manera efectiva por un tic de juego incorporado en el secuenciador. Cuando el juego avanza, el secuenciador hace avanzar el estado y su ubicación hasta que llega un usuario y son asesinados. Podríamos tomar una cantidad significativa del ancho de banda de las fragmentos en esto si elegimos, ya que estamos limitando la cantidad de jugadores, podemos maximizar los movimientos de los NPC.

• Varios objetos dispersos alrededor o dejados por los monstruos

Los artículos se pueden recoger y almacenar en el saldo del jugador. Cuando el jugador finaliza su sesión, estos artículos 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ón

Al finalizar su sesión de juego, los estados de los jugadores se conservan en un estado global al hacer la transición de regreso a L3, preparando el escenario para su próxima zona o sesión. Esto se verifica luego en StarkNet L2 y posteriormente en L1, estableciendo efectivamente un RuneScape probadamente justo. Ahora, el siguiente paso es hacer realidad esta visión...

Toda la pila que estamos construyendo es de código abierto - únete al dojo discordo contribuir al núcleodirectamente.

¿Qué tal la conexión entre estas capas? ¿No será esto una pesadilla para los jugadores.

Sí, el puenteo es problemático en este momento. Sin embargo, hay una solución clara a este problema que ya se está utilizando en el ecosistema de Starknet y pronto estará disponible en otras Capas 2. Estos se llaman Pruebas de almacenamiento. Sí, estoy incrustando mi propio tweet. La parte 2 discutirá esto.

https://twitter.com/lordOfAFew/status/1762796441494520267

¿Por qué pruebas recursivas y cadenas efímeras sobre otros métodos?

Para aclarar, este es el enfoque que Gate, Cartridge y el ecosistema de Realms están adoptando para escalar el mundo que imaginamos. Es importante tener en cuenta que este no es el único método, y explorar una variedad de enfoques es beneficioso. Algunas de las mentes más brillantes que conozco también están abordando los problemas más desafiantes en este espacio, y definitivamente vale la pena echar un vistazo a su trabajo.

• Rejilla- OP Plasma con Redstone permite transacciones muy baratas.
• Playmint- Motor Optimista Único para una jugabilidad rápida
• PoP- Fragmentación EVM personalizada
• Argus- Fragmentos de juego EVM personalizados
• Curio- Enfoque modificado del servidor EVM

Un momento para regresar a Runescape

Crear un RuneScape libre y abierto capaz de soportar millones de jugadores concurrentes no es una tarea fácil. Sin embargo, la inteligencia colectiva y la creatividad de la industria de juegos 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. Es hora de regresar a RuneScape, o quizás más apropiadamente, dar la bienvenida al amanecer de RealmScape. ;)

Descargo de responsabilidad：

1. Este artículo está reimpreso de [Gate@lordofafew], Todos los derechos de autor pertenecen al autor original [@lordofafew]. If there are objections to this reprint, please contact the Gate Learnequipo, y lo manejarán rápidamente.
2. Descargo de responsabilidad: Las opiniones expresadas en este artículo son únicamente las del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas son realizadas por el equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.