Dilemas y salidas de los juegos Web3

Autor: Lola, Delphinus Lab

Con el éxito sin precedentes de ‘The Myth of Wu Kong’, ha surgido una ola de voces negativas sobre los juegos Web3 en la industria. En el actual entorno de opinión pública del mercado, que ya está muy deprimido y lleno de dudas, se ha sumado un debuff más.

¿Los Web3 no aman los juegos? Es cierto que durante la burbuja temprana del mercado, la intensa atmósfera especulativa es inevitable, pero muchos constructores todavía entran en esta industria con la idea de crear un buen juego, un juego verdaderamente perteneciente a los jugadores. Y si Web3 quiere lograr una verdadera adopción masiva, los juegos son un camino inevitable y la forma más profunda de penetrar en el mercado.

Pero la realidad es cruda. Cuando la gente intenta contar los juegos de primera línea de Web3, se da cuenta de que hay muy pocos juegos de calidad, la mayoría de los juegos son mediocres, no proporcionan una buena experiencia al jugador y están muy lejos de alcanzar las expectativas de adopción masiva. Muchos equipos de juegos con experiencia exitosa en Web2 han fracasado en Web3, y hasta ahora entiendo que las razones principales son dos:

1. En comparación con los juegos tradicionales, los juegos Web3 tienen dificultades para proporcionar actualizaciones de contenido de juego continuas.

2. Debido a las audiencias diferentes, los juegos Web3 necesitan considerar más problemas de economía de juegos que los juegos tradicionales, además de la jugabilidad.

La difícil situación de actualización del contenido del juego

Para que un juego mantenga su longevidad, es imprescindible actualizarlo con parches; de lo contrario, los errores no se podrán corregir y la frescura de los jugadores no perdurará. En el desarrollo tradicional de juegos, si la estructura de datos no cambia pero la lógica del juego sí, un simple parche de lógica de programa puede completar la actualización correspondiente.

Sin embargo, la inmutabilidad de la cadena de bloques añade dificultad a esta aparentemente simple implementación. Tomemos como ejemplo el desarrollo de juegos en Solidity: un contrato de juego en línea determina la estructura global de datos del juego. Dado que la lógica del juego en sí es una migración del estado de los datos, la modificación de la lógica del juego a menudo requiere una actualización del contrato.

Después de la actualización del contrato, no se puede reutilizar continuamente los datos del contrato anteriormente actualizado. Para completar la actualización de la lógica del juego, solo hay dos opciones:

1 migración

2. En el diseño del contrato, separar la capa de datos y la capa lógica desde el principio

La segunda opción aumentará el consumo de gas en las llamadas al contrato, por lo que las actualizaciones frecuentes del contenido del juego a menudo son difíciles de lograr en Web3, lo que perjudica la capacidad de retención de clientes potenciales de un juego con potencial.

No se realizará la mejora lógica de la interfaz de datos

Realizó una actualización lógica de la interfaz de datos

Para resolver este problema, primero debemos abordar el problema de reutilización de datos y actualización de datos. Cuando se modifica la lógica del juego, todavía esperamos que los datos originales se conserven tal como están. La mejor solución de costo cero aquí es el rollup de App independiente. Porque en el rollup de App, el Merkle Root de los datos originales se puede reutilizar directamente, y los cambios en la lógica solo necesitan reflejarse en la lógica del código.

Actualización de lógica que se ejecuta directamente en la Máquina virtual

Una vez resueltos los problemas de reutilización de datos y actualización lógica, la actualización de la estructura de datos seguirá presentando ciertos desafíos para la actualización del juego. La migración de datos on-chain comúnmente requiere el uso de una Máquina de oráculo para modificar los datos según un script establecido antes de volver a ingresarlos a on-chain, lo que consume mucho tiempo.

En la arquitectura de App As A rollup, después de la auditoría de migración de datos, se puede ejecutar en zkVM para lograr una verificación completa de la lógica de migración. Dado que la migración de datos implica la reorganización de datos en muchos escenarios y hay menos lógica de cálculo involucrada, si el código involucrado en la reorganización de cada Nodo hoja es de alrededor de 1000 líneas, entonces los trazados de ejecución necesarios para más de un millón de Nodos hoja podrían ser de alrededor de 1000 * 10 millones. Actualmente, el tiempo de prueba de 1 millón de líneas de trazado en zkVM común es de 9 a 15 segundos, por lo que el tiempo total de migración de datos en zk sigue siendo un número controlable.

Es precisamente la independencia de datos de la aplicación Rookup la que ha traído una nueva metodología para la iteración del contenido del juego Web3.

Debido a la complejidad y la urgencia de actualización de otras aplicaciones en la cadena, zkVM brinda nuevas oportunidades para juegos en toda la cadena o juegos verificables.

El dilema de la economía y la distribución de intereses

El desarrollo de proyectos de juegos es un trabajo complejo e integral, y también es muy tedioso. Si un juego de alta calidad no puede generar beneficios económicos reales, entonces la atracción de Web3 para los desarrolladores disminuirá cada vez más en comparación con el campo de los juegos tradicionales.

Actualmente, la relación entre los proyectos de juegos y las cadenas públicas a menudo se basa en la relación de tráfico como principal y la relación de ingresos como secundaria. Mientras que los proyectos de juegos en el medio de la relación de tráfico a menudo dependen del tráfico de la plataforma y del tráfico inicial proporcionado por la cadena pública, la cadena pública luego disfruta del aumento de usuarios de la cadena pública a través de la absorción de buenos proyectos de juegos en el medio de su lanzamiento.

La relación de ingresos será más complicada y oculta problemas de distribución de beneficios más profundos: por un lado, el comportamiento del usuario generará ingresos, incluidos los ingresos por gas de la cadena y los cargos por consumo de contenido del juego; por otro lado, el tráfico y el consumo del juego han aumentado el valor de la moneda, con un volumen de juegos que generan activos a través de la emisión de Tokens de juego, al mismo tiempo que también han traído efectos ecológicos prósperos a la cadena, lo que aumenta aún más las expectativas de valoración de los Tokens de la cadena.

En estas complejas relaciones de interés, no hay una definición clara de cómo se debe asignar de manera razonable el gasto real del usuario. El arranque en frío del juego requiere una gran cantidad de capital, y los ingresos iniciales del usuario a menudo se destinan principalmente a pagar la tasa de gas a la cadena, lo que hace que el ciclo de retroalimentación positiva para los creadores del juego sea muy largo. A veces, incluso existe la situación en la que el equipo de desarrollo del juego alcanza el valor básico de DAU de la cadena a través de comercio ficticio y luego depende de subvenciones mínimas para recuperar pérdidas. Esto obliga al juego a depender de las expectativas de token en las primeras etapas para atraer a los jugadores a pagar por la interacción de gas. Esta carga de gas ya no puede ser ignorada por un jugador de juegos, lo que hace que sea más difícil para los juegos de cadena guiar a los usuarios a consumir sus propios tokens, es decir, el proceso de comprar tokens de juego, en comparación con los juegos tradicionales.

Debido a que depositar en el juego es el paso más importante para la retroalimentación positiva del juego, la carga de gas retrasa en gran medida la capacidad del juego para atraer clientes. Pero debido a que los juegos en cadena tienen que asumir las obligaciones de la cadena tradicional, incluso en layer2, el gas sigue avanzando sin piedad antes del token nativo del juego depositar. Por lo tanto, Web3 no tiene una verdadera experiencia de juego de ‘jugar primero y luego gastar’.

El comercio de artículos en juegos se considera una de las partes más atractivas de las fases posteriores de juegos en cadena. Los artículos de alto valor obtenidos mediante la inversión en el juego o el esfuerzo a largo plazo se valoran constantemente después de su circulación y colección, lo cual es emocionante tanto para los jugadores como para los diseñadores. Sin embargo, como derivados de juegos, la prima generada por la circulación de los artículos de juego se divide en su mayoría entre otros productos en cadena: las tarifas de transacción de NFT de juegos pueden ser divididas por los intercambios de NFT, mientras que las transacciones de tokens de juego son divididas por DeFi. El valor creado por los buenos juegos no puede fluir de manera efectiva de regreso al equipo de desarrollo del juego.

La fluctuación del valor del token puede provocar una producción dinámica amplificada en el juego. Cuando el valor del token del juego está subestimado, la tasa de juego tiende a ser baja, y la producción de juego y la inversión real en tokens de juego suelen estar positivamente correlacionadas, lo que lleva a un bajo valor del token, un menor costo para consumir el mismo token de juego y, en cambio, una producción más alta. Mientras que en momentos de altos precios de las monedas de juego, el valor excesivo del token de juego obstaculiza el impulso de consumo dentro del juego. Este efecto de amplificación hace que la fluctuación del valor del token de juego esté influenciada por la producción interna y externa, lo que aumenta los desafíos relacionados con el diseño tokenómico.

App As A rollup + zkVM: una posible solución

Al enumerar estos desafíos, descubrimos de manera inesperada que la arquitectura de Application As Rollup puede mitigar eficazmente los problemas relacionados.

En primer lugar, el gas real de rollup propio se reducirá significativamente en los juegos de toda la cadena, soltando a 1/20 o incluso menos. Esto permite al equipo detrás del proyecto evitar por completo la interferencia de las tarifas de gas al comienzo del juego, proporcionando una verdadera experiencia de juego gratuita, y creando un mejor entorno para el arranque en frío de la cantidad de jugadores al comienzo del juego.

En segundo lugar, Application As Rollup puede proporcionar una plataforma de préstamos con un solo clic, permitiendo a los usuarios pedir prestado tokens internos del juego usando USDC al inicio del juego, fomentando así la experimentación con funciones de pago dentro del juego. Dado que se espera que la producción positiva del juego sea mayor que el consumo, una vez que la producción supere al consumo, los usuarios pueden redimir completamente el USDC utilizado como colateral para el préstamo inicial.

En el proceso de circulación, Application As a Rollup puede actuar eficazmente como un puente cross-chain para los activos de juego. Cuando necesitamos transferir activos en diferentes cadenas, solo necesitamos depositar en el juego y luego retirar en la otra cadena. Esta función nativa de interacción cross-chain permite que parte del valor de las transacciones de productos derivados del juego sea capturado por el propio juego.

Más radical es que los juegos pueden ofrecer la función de depósito de moneda estable para préstamos, permitiendo que el valor de TVL, que antes solo podía capturarse en la cadena, ahora pueda ser capturado por el propio juego. Por último, Application Rollup puede proporcionar un mecanismo similar al gas para los jugadores de pago en el juego, capturando en última instancia los costos tradicionales de gas de la cadena. Un diseño potencialmente factible de este mecanismo es que el costo del gas sea más bajo cuando el valor del token es alto, y más alto cuando el valor del token es bajo: en esencia, se beneficia de la vinculación del valor del gas y el valor del token a través de la independencia de layer3 para mitigar la fluctuación del valor del token.

Por supuesto, todo esto no sucederá de la noche a la mañana, Delphinus Lab zkWASM, como uno de los primeros jugadores en llevar zkVM a las aplicaciones de juegos, recientemente lanzó zkWASM Mini Rollup. Esta es una herramienta para el desarrollo rápido y implementación de aplicaciones ZK Rollup. Permite a los desarrolladores escribir código Rust, compilarlo a WebAssembly y ejecutarlo en un entorno Node.js. Este SDK maneja transacciones, genera pruebas de conocimiento cero y interactúa con la cadena de bloques.

Su proceso principal es: recibir transacciones, procesar transacciones en la Máquina virtual WASM, generar pruebas utilizando el servicio en la nube zkWASM, y finalmente presentar las pruebas para validación y Asentamiento en la cadena de bloques. Este proceso garantiza la privacidad y seguridad de las transacciones, al tiempo que mejora significativamente la escalabilidad de la cadena de bloques. Los desarrolladores solo necesitan seguir la lógica de la aplicación, sin la necesidad de comprender en detalle la compleja tecnología de Prueba de conocimiento cero. También incluye un sistema de monitoreo Rollup que puede desencadenar Asentamiento on-chain utilizando pruebas y datos de transacciones, asegurando la validación de acuerdo con el orden de la raíz de Merkle on-chain. Además, este SDK simplifica la configuración del entorno de desarrollo local: solo es necesario iniciar MongoDB y Redis, ejecutar dbservice, y luego ejecutar npm run server en el directorio ts para iniciar el servicio local completo.

La aparición del SDK zkWASM Mini Rollup proporciona una solución potencialmente poderosa para los desafíos duales que enfrentan los juegos Web3. Con la arquitectura de Application As A Rollup, no solo simplifica el proceso de actualización del contenido del juego, sino que también ofrece nuevas posibilidades para optimizar el modelo económico del juego.

Este enfoque innovador primero aprovecha la compatibilidad de WASM, permitiendo a muchos desarrolladores tradicionales utilizar sus lenguajes de programación favoritos como Rust para escribir el código del juego; en segundo lugar, permite a los desarrolladores de juegos lograr fácilmente la reutilización de datos y la actualización lógica, lo que reduce considerablemente los costos de gas e incluso puede lograr una experiencia real de “jugar primero y gastar después”. Al mismo tiempo, proporciona más oportunidades para capturar valor en proyectos de juegos, incluyendo la transferencia de activos y la funcionalidad de préstamo entre cadenas, lo que ayuda a construir un sistema económico de juegos más sostenible.

Usar zkWASM para lanzar rollup con un solo clic significa que estamos dando un paso sólido hacia la adopción masiva tanto por parte de los desarrolladores como de los usuarios. Aunque esta tecnología aún está en sus primeras etapas y los juegos de Web3 también enfrentan la desconfianza tanto dentro como fuera de la comunidad, señala un camino para abordar los problemas fundamentales que enfrentan los juegos de Web3 en la actualidad.

A medida que más desarrolladores de juegos adopten esta tecnología, y cada vez más operadores de juegos y protocolos de préstamo estén dispuestos a participar en el modelo económico antes mencionado, hay razones para creer que los juegos Web3 superarán gradualmente las dificultades existentes. No esperamos tener nuestro propio mito negro Wukong o Call of Duty, pero al hacer lo difícil pero correcto, trabajando incansablemente hacia el objetivo final en lugar de ser oportunistas, los juegos Web3 eventualmente marcarán el comienzo de su propio momento de “enfrentar la voluntad de Dios” e impulsarán a toda la industria a través de la larga víspera de la adopción masiva.