Nombre del autor: Lola, Delphinus Lab.

Con la fenomenal popularidad de "Black Myth: Wukong", hay otra voz en el círculo que denigra los juegos Web3. En el reciente entorno de mercado que ha sido muy lento y dudoso, se ha agregado otra capa de desventaja.

¿Es porque a la gente de Web3 no le encantan los juegos? Es cierto que en la etapa inicial de burbuja del mercado, una fuerte atmósfera especulativa es inevitable, pero muchos desarrolladores todavía se lanzan a la industria con la intención de hacer un buen juego, un juego que realmente pertenezca a los jugadores, y Web3 quiere lograrlo. Una adopción verdaderamente masiva, el juego es también el camino que no se puede pasar por alto y que puede penetrar profundamente en el mercado.

Pero la realidad es dura. Cuando la gente quiere contar los juegos de primera línea de Web3, descubre que la cantidad de juegos de calidad es muy pequeña y la mayoría de los juegos son mediocres. No brindan a los jugadores una buena experiencia de usuario ni cumplen con las expectativas de adopción masiva. . Una gran cantidad de equipos de juegos con experiencia práctica exitosa en Web2 han fracasado en Web3. Las razones que entiendo actualmente son principalmente dos puntos:

1. En comparación con los juegos tradicionales, a los juegos Web3 les resulta difícil proporcionar actualizaciones continuas del contenido del juego.

2. Debido a las diferentes audiencias, los juegos Web3 deben considerar más cuestiones económicas además de la jugabilidad que los juegos tradicionales.

Dilema de actualización del contenido del juego

Para que un juego mantenga su vitalidad a largo plazo, las actualizaciones y los parches son esenciales; de lo contrario, los errores no se corregirán y la frescura de los jugadores no durará mucho; En el desarrollo de juegos tradicional, si la estructura de datos no cambia pero la lógica del juego cambia, un simple parche lógico del programa puede completar la actualización relevante.

Sin embargo, la no manipulación de la cadena de bloques añade dificultad a esta implementación aparentemente simple. Tomando como ejemplo el desarrollo de juegos de Solidity, un contrato de juego en línea a menudo determina la estructura general de datos del juego. Dado que la lógica del juego en sí es la migración del estado de los datos, las modificaciones a la lógica del juego a menudo deben coordinarse con las actualizaciones del contrato.

Una vez actualizado el contrato, los datos del contrato anterior a la actualización no se pueden reutilizar continuamente. Para completar la actualización de la lógica del juego, solo hay dos opciones:

1 migración

2. Separe la capa de datos y la capa lógica al comienzo del diseño del contrato.

La segunda opción aumentará el consumo de gas de las llamadas por contrato, por lo que las actualizaciones de contenido de juegos de alta frecuencia a menudo son difíciles de lograr en Web3, lo que perjudica la capacidad de un juego potencial para seguir adquiriendo clientes.

No hay actualización lógica de la interfaz de datos

Se realizó una actualización lógica de la interfaz de datos.

Para resolver este problema, primero debemos resolver el problema de la reutilización y actualización de datos. Cuando se modifica la lógica del juego, aún queremos que los datos originales se conserven intactos. La mejor solución de costo cero aquí es la aplicación independiente como paquete acumulativo. Porque en el paquete acumulativo de aplicaciones, la raíz Merkle de los datos originales se puede reutilizar directamente y la modificación de la lógica solo debe reflejarse en la lógica del código.

Actualización lógica ejecutándose directamente en la máquina virtual

Una vez resueltos los problemas de reutilización de datos y actualización lógica, el problema de la actualización de la estructura de datos seguirá planteando ciertos desafíos a la actualización del juego. La migración de datos ordinaria en la cadena a menudo requiere que un oráculo modifique los datos de acuerdo con un script establecido y luego los ingrese nuevamente en la cadena, lo que lleva mucho tiempo.

En la arquitectura de aplicación como resumen, después de la auditoría de migración de datos, se puede ejecutar en zkVM, de modo que la lógica de migración sea completamente verificable. Dado que la migración de datos implica la reorganización de datos en muchos escenarios, hay menos lógica de cálculo. Si el código involucrado en la reorganización de cada nodo hoja es de aproximadamente 1000 líneas, entonces el seguimiento de ejecución requerido para más de un millón de nodos hoja puede ser de aproximadamente 1000 líneas. 100w. En la actualidad, el tiempo de verificación de cada millón de líneas de rastreo de zkVM ordinario es de 9 a 15 segundos, por lo que el tiempo total de migración de datos de zk sigue siendo un número controlable.

Es precisamente debido a la independencia de datos de Application Rookup que aporta una nueva metodología a la iteración de contenido de juegos Web3.

Dado que la complejidad de otras aplicaciones en cadena y la urgencia de actualizaciones son mucho menores que las de los juegos, zkVM brindará nuevas oportunidades para los juegos de cadena completa o juegos verificables.

La economía y el dilema de la distribución de beneficios

El desarrollo de proyectos de juegos es una tarea compleja, integral y muy trivial. Si un juego de alta calidad no puede generar beneficios económicos tangibles, en comparación con el campo de los juegos tradicionales, Web3 será cada vez menos atractivo para los desarrolladores.

En la actualidad, la relación entre los proyectos de juegos y las cadenas públicas suele estar dominada por relaciones de tráfico, complementadas por relaciones de ingresos. Los proyectos de juegos de nivel medio con una 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 absorbe buenos proyectos de juegos y disfruta del aumento de usuarios de la cadena pública que genera el juego en el mediano plazo. se lanza el juego.

La relación de ingresos será más compleja y esconde problemas de distribución de intereses 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 de juegos, por otro lado, el tráfico y el consumo de juegos; precios de divisas Los juegos con valor agregado y volumen de transacciones generan ingresos de activos mediante la emisión de tokens de juego y también aportan 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 pública.

En esta compleja relación de intereses, en realidad dista mucho de tener una definición clara de cómo deben asignarse los gastos reales de los usuarios para que sean razonables. El inicio en frío de un juego requiere una gran cantidad de fondos, y los primeros ingresos de los usuarios a menudo se basan en la tarifa de gas pagada a la cadena. Esto hace que el ciclo para que los creadores de juegos obtengan comentarios positivos sea muy largo y, a veces, incluso hay juegos. Equipos de desarrollo que lo hacen ellos mismos. Una vez que la cantidad de pincel alcanza el valor DAU básico de la cadena, la sangre se restaura con una escasa subvención. Esto obliga al juego a depender de las expectativas simbólicas en las primeras etapas para atraer a los jugadores a pagar gasolina por la interacción. Esta parte de la carga de gas no puede ser ignorada por un jugador, por lo que los juegos en cadena están guiando a los usuarios a consumir sus propios tokens, lo que significa que la compra de tokens de juego se ha vuelto más difícil que en los juegos tradicionales.

Dado que la recarga del juego es el paso central de la retroalimentación positiva para el juego, el retraso en la recarga del juego debido a la carga de gas perjudica en gran medida la capacidad del juego para adquirir clientes. Sin embargo, dado que los juegos en cadena deben soportar la carga de las obligaciones en cadena en el sentido tradicional, incluso en la capa 2, el gas todavía precede implacablemente a la primera recarga del token nativo del juego. Por lo tanto, Web3 no ofrece una verdadera experiencia de juego de "jugar primero y gastar después".

El comercio de elementos del juego se considera la parte más atractiva del juego blockchain en las etapas intermedia y tardía. Los artículos de juego de alto valor obtenidos a través de oro kriptón o esfuerzos interactivos a largo plazo continúan apreciando su valor después de su circulación y recolección, lo cual es una experiencia emocionante tanto para los jugadores como para los diseñadores. Sin embargo, como los artículos del juego son derivados del juego, la mayoría de las primas generadas por sus transacciones de circulación se dividen entre otros productos en la cadena: las tarifas de transacción de los NFT del juego pueden dividirse entre los intercambios de NFT, y las transacciones de los tokens del juego se dividen entre las DeFi. . El valor creado por los buenos juegos no puede regresar efectivamente al juego para apoyar al equipo de juego.

Las fluctuaciones del valor de los tokens conducirán a una salida del juego amplificada dinámicamente. Cuando se subestima el valor de los tokens de juego, las tasas de juego son bajas y la producción del juego y la inversión real en tokens de juego a menudo están correlacionadas positivamente, lo que resulta en precios de tokens bajos. El costo de consumir el mismo token de juego es menor, pero la producción es mayor. Cuando la moneda del juego es alta, el valor excesivo de las fichas del juego dificulta el impulso de consumir en el juego. Tal efecto de amplificación hace que las fluctuaciones de valor de los tokens de juego se vean afectadas por la producción tanto interna como externa, lo que aumenta los desafíos relacionados con el diseño económico de los tokens.

App As A rollup + zkVM: una posible salida

Al enumerar esta serie de desafíos, descubrimos inesperadamente que la arquitectura de Application As Rollup puede aliviar de manera adecuada y efectiva los problemas relacionados.

En primer lugar, el gas real del propio rollup se reducirá significativamente a 1/20 o incluso menos que el del juego de cadena completa. Esto permite al equipo del proyecto eliminar por completo la interferencia de las tarifas de gas en la etapa inicial del juego, brindar una experiencia de juego verdaderamente gratuita y crear un mejor entorno para el inicio en frío del juego inicial.

En segundo lugar, Application As Rollup puede proporcionar una plataforma de préstamo con un solo clic. En la etapa inicial del juego, los usuarios pueden usar USDC para pedir prestado el token interno del juego para animarlos a probar la función de pago del juego. Dado que la producción esperada positiva del juego suele ser mayor que el consumo, los usuarios pueden canjear la garantía del USDC utilizada para el préstamo original después de que la producción supere el consumo.

En el proceso de circulación, la aplicación como paquete acumulativo puede servir eficazmente como un puente entre cadenas para los activos del juego. Cuando necesitamos transferir activos en diferentes cadenas, sólo necesitamos Depositar en el juego y luego Retirar en otra cadena. Esta función nativa de cadena cruzada permite que el propio juego capture parte del valor de las transacciones de derivados del juego.

Lo que es aún más radical es que el juego puede proporcionar una función de depósito de moneda estable para préstamos, de modo que el valor TVL que solo podía ser capturado por la cadena en el pasado ahora puede ser capturado por el juego mismo. Finalmente, Application Rollup puede proporcionar una manera de capturar eventualmente las tarifas de gas en cadena tradicionales al introducir en el juego un mecanismo similar a una tarifa de gas para los jugadores de Krypton Gold. Un diseño más posible de este mecanismo es que el costo del gas es menor cuando el valor del token es mayor, y el costo del gas es mayor cuando el valor del token es menor: su esencia se debe a la independencia de la capa 3 que une el valor del gas y el Valor del token. Aliviar las fluctuaciones del valor del token.

Por supuesto, nada de esto sucederá de la noche a la mañana. Delphinus Lab zkWASM, uno de los primeros en introducir zkVM en aplicaciones de juegos, lanzó recientemente zkWASM Mini Rollup. Este es un conjunto de herramientas para el rápido desarrollo e implementación de aplicaciones ZK Rollup. Permite a los desarrolladores escribir código Rust, compilarlo en WebAssembly y luego ejecutarlo en un entorno Node.js. Este SDK procesa transacciones, genera pruebas de conocimiento cero e interactúa con la cadena de bloques.

El proceso principal es: recibir transacciones, procesar transacciones en la máquina virtual WASM, utilizar el servicio en la nube zkWASM para generar pruebas y, finalmente, enviar las pruebas a la cadena de bloques para su verificación y liquidación. Todo el proceso garantiza la privacidad y seguridad de las transacciones, al tiempo que mejora enormemente la escalabilidad de blockchain. Los desarrolladores solo necesitan centrarse en la lógica de la aplicación sin tener que comprender en profundidad los detalles técnicos de pruebas complejas de conocimiento cero. También incluye un sistema de monitoreo Rollup que puede usar pruebas y datos de transacciones para activar liquidaciones en cadena, verificar pruebas almacenando raíces de Merkle y verificar API, asegurando que las liquidaciones se realicen en el orden de las raíces de Merkle en la cadena. Además, el SDK también simplifica el establecimiento de un entorno de desarrollo local. Solo necesita 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 de zkWASM Mini Rollup SDK proporciona una solución potencial a los desafíos duales que enfrentan los juegos Web3. A través de la arquitectura de Application As A Rollup, no solo simplifica el proceso de actualización del contenido del juego, sino que también brinda nuevas posibilidades para la optimización del modelo económico del juego.

Este método innovador, en primer lugar, aprovecha la compatibilidad de WASM para permitir que una gran cantidad de desarrolladores tradicionales utilicen sus lenguajes de programación más familiares, como Rust, para escribir código de juegos; en segundo lugar, permite a los desarrolladores de juegos implementar más fácilmente la reutilización de datos y las actualizaciones lógicas; El costo de la gasolina se reduce enormemente e incluso es posible lograr una verdadera experiencia de "juego sin gasolina" y "jugar primero y gastar después". Al mismo tiempo, brinda a los proyectos de juegos más oportunidades para capturar valor, incluida la transferencia de activos entre cadenas, funciones de préstamo, etc., lo que ayuda a establecer un sistema económico de juegos más sostenible.

Usar zkWASM para emitir paquetes acumulativos con un solo clic significa que podemos dar un paso sólido hacia la adopción masiva tanto por parte del desarrollador como del usuario. Aunque esta tecnología aún se encuentra en sus primeras etapas, y los juegos Web3 también enfrentan una doble desconfianza dentro y fuera del círculo durante este ciclo, y luchan por avanzar en medio de dudas, señala una manera de resolver los problemas centrales que enfrenta Web3 actualmente. juegos.

A medida que más desarrolladores de juegos adopten esta tecnología y más operadores de juegos y acuerdos de préstamo estén dispuestos a participar en el modelo económico sugerido anteriormente, tenemos razones para creer que los juegos Web3 superarán gradualmente las dificultades existentes. No esperamos tener nuestro propio Black Myth Wukong o Call of Duty, pero al hacer cosas difíciles y correctas y trabajar incansablemente hacia el objetivo final en lugar de aprovechar las oportunidades, los juegos Web3 eventualmente marcarán el comienzo de su propio momento de "enfrentamiento". destino” e impulso Toda la industria está pasando por la larga víspera de la aplicación a gran escala.