Esto está claramente en desacuerdo con el modelo de desarrollo de los juegos tradicionales. Los juegos tradicionales exitosos atraen a muchos usuarios a través de mecánicas de juego atractivas, lo que permite a los desarrolladores construir caminos rentables y potencialmente expandirse a mercancías e IPs relacionadas. Estos juegos operan en un ciclo positivo donde los jugadores disfrutan del juego y a menudo obtienen beneficios económicos tanto dentro como fuera del juego.

Por el contrario, los juegos actuales de blockchain atraen principalmente a los jugadores a través de rendimientos financieros. Además de su baja jugabilidad, los juegos Web3 también enfrentan problemas de larga data como altas barreras de entrada y procesos de interacción engorrosos.

¿Cuál es la causa raíz de estos problemas? Las opiniones varían. El equipo de TabiChain cree que un factor significativo es que los talentosos desarrolladores tradicionales de juegos tienen dificultades para ingresar al ecosistema Web3 debido a barreras técnicas y de aprendizaje. Para aquellos que no están familiarizados con el desarrollo de juegos o software, la transición de Web2 a Web3 podría parecer solo un cambio de narrativa y entorno, pero la realidad es mucho más dura.

Entonces, ¿cómo podemos crear un entorno más acogedor para los desarrolladores de juegos tradicionales o empresas relacionadas a través de la tecnología? En las siguientes secciones, analizaremos a fondo los desafíos enfrentados por los juegos Web3 y sus soluciones, explicando cómo la futura industria de juegos Web3 puede adaptarse técnicamente para satisfacer mejor a los desarrolladores de juegos tradicionales.

Razones técnicas que impiden a los desarrolladores de juegos tradicionales ingresar al ecosistema Web3

En el artículo anterior, mencionamos brevemente que la tecnología poco amigable y los altos costos de aprendizaje son los factores clave que impiden que los practicantes de juegos tradicionales ingresen al ecosistema web3. La llamada tecnología poco amigable y los altos costos de aprendizaje se pueden ampliar a los siguientes puntos:

1. La diferencia entre las aplicaciones web3 y las estructuras de software tradicionales

Blockchain y las aplicaciones en ella (dApps) son fundamentalmente diferentes de la arquitectura de software tradicional y requieren que los desarrolladores tengan un nuevo sistema de conocimiento, como el principio de funcionamiento de blockchain, los protocolos de consenso, los modelos de programación de contratos inteligentes, etc. Los desarrolladores de juegos tradicionales necesitan pasar mucho tiempo aprendiendo Solidity u otros lenguajes de contratos inteligentes y necesitan entender cómo funciona el EVM.

Además, la lógica de juego tradicional generalmente se ejecuta en un servidor centralizado, que puede manejar de manera flexible estados de juego complejos e interacciones de alta frecuencia. Ejecutar la lógica del juego en la cadena de bloques requiere un alto grado de simplificación o refactorización, ya que cada operación debe ser publicada en la red distribuida para su ejecución y luego cargada en la cadena, lo que está severamente limitado por el rendimiento y el costo de la cadena de bloques.

1. Limitaciones de diseño de contratos inteligentes

Aunque EVM es Turing completo y teóricamente puede expresar lógica arbitraria, sus características son muy desfavorables para el desarrollo de juegos, como:

• Falta de temporizador. Todas las operaciones en la cadena de Ethereum deben ser activadas manualmente por la cuenta EOA. Para lograr un efecto similar a un temporizador, los desarrolladores necesitan implementar un servicio adicional y mantener una cuenta EOA y una lista de eventos para activar manualmente las tareas programadas. Debido al problema de retraso en la cadena, no se puede garantizar que estas tareas programadas se completen a tiempo.

• No hay devolución de llamada y otros mecanismos, y no admite la multiprocesamiento y asincrónico. Debido a que Solidity está diseñado para el desarrollo de contratos inteligentes en Ethereum, su entorno de ejecución es significativamente diferente de los entornos de tiempo de ejecución tradicionales. La operación de EVM es transaccional, y cada llamada de función debe ejecutarse por completo en una transacción. No hay concepto de "asincrónico" en el sentido tradicional. Esto significa que una llamada de función en Solidity es atómica de principio a fin y no puede ser interrumpida por otras transacciones.
• No hay capacidad para hacer referencia a datos externos. Aunque existen oráculos como Chainlink, ya sea desde una perspectiva de integración o de llamada de datos, su facilidad de uso es muy diferente de la obtención directa de llamadas de datos a través de solicitudes https, y esto permite a los desarrolladores añadir integraciones adicionales. Carga y dependencia.
• Limitaciones de escalabilidad y rendimiento. La lógica del juego debe simplificarse o desglosarse en múltiples transacciones simples para evitar que la tarifa de gas de una sola transacción se vuelva demasiado alta o exceda el límite máximo, lo que limita la implementación de interacciones y funciones complejas.

1. Limitaciones en el almacenamiento y recuperación de datos

• Los contratos inteligentes tienen un espacio de almacenamiento costoso y un diseño limitado, lo que los hace inadecuados para almacenar grandes cantidades de datos de juego.
• Es posible que se necesiten registros de eventos para rastrear indirectamente el estado del juego, y la captura de eventos puede no ser estable. Problemas como cuándo actualizar el estado del juego a menudo requieren que los jugadores u operadores del juego lo activen manualmente.
• La estructura de datos de la cuenta adoptada por EVM resulta en pobres capacidades de indexación de datos. Cuando consultas los datos de una cuenta, solo puedes conocer el saldo de su ETH o token nativo de la cadena, pero no se puede saber directamente qué activos ERC-20 posee y el saldo de cada activo. Lo mismo ocurre con los NFT. Esta información está encapsulada en el contrato exclusivo de cada activo, en lugar de almacenarse bajo la propia cuenta del usuario.

Podemos ver qué tipo de token e información de saldo tiene una cierta dirección desde herramientas como Etherscan. Estas están indexadas por herramientas periféricas como navegadores de blockchain, y estos últimos necesitan construir una base de datos enorme y dedicada y rastrearla por completo. Solo recopilando todos los datos de bloque o monitoreando eventos en la cadena se puede resumir todos los datos en la cadena.

Los desarrolladores de Web3 generalmente tienen que integrar proveedores de datos de terceros como Etherscan, NFTscan, The Graph, etc., e incluso pagar por su API KEY. Además, estos servicios de terceros son esencialmente bases de datos fuera de la cadena, lo que puede causar retrasos, errores, exceder los límites de llamadas, la falta de disponibilidad del servicio y otras fallas.

Comparemos las diferencias entre la forma de base de datos de la mayoría de los juegos y los métodos de almacenamiento de datos en la cadena de bloques. La diferencia entre los dos es obvia. La estructura de datos de la mayoría de los juegos está completamente personalizada por sí misma, tiene buenas capacidades de expresión e indexación, y no necesita depender de ningún servicio de terceros.

1. Desafíos en la integración de activos de juegos existentes con blockchain

Los activos del juego existentes (como accesorios y personajes) normalmente no se crean ni se administran en la cadena de bloques. Migrar estos activos a la cadena de bloques generalmente implica convertir tipos de datos comunes pero de larga cola en NFTs o Tokens estándar, lo que involucra un trabajo de migración e integración complejo y afectará al sistema económico del juego existente.

1. Actualizaciones, parches y prevención de desastres

En Ethereum, una vez que se implementa un contrato inteligente, el código es inmutable, lo que hace que las actualizaciones y parches sean más complejos que el software tradicional. Los desarrolladores suelen utilizar contratos proxy o patrones de versionado para evitar esta limitación, pero esto aumenta la complejidad de la estructura general. Los contratos proxy deben utilizarse con especial cuidado para evitar la corrupción de datos causada por conflictos de ubicación de almacenamiento. Además, el riesgo de fuga de derechos administrativos también es grave.

La actualización del código de los juegos tradicionales no es tan complicada en términos de estructura técnica. Lo único que puede necesitar ser restringido es la autoridad de actualización centralizada. Esto se puede lograr a través de métodos como DAO en lugar de depender de contratos inteligentes.

Además, los juegos tradicionales a menudo toman instantáneas o copias de seguridad de la base de datos. Esto puede no ser muy importante por lo general, pero si te encuentras con un error importante en la actualización, puedes retroceder rápidamente los datos, lo cual es básicamente una fantasía en la cadena de bloques. Incluso si algunos datos del juego se retroceden reconstruyendo el contrato, todavía es complicado migrar los datos y el estado del contrato antiguo al nuevo contrato.

1. Fragmentación ecológica y problemas de experiencia del usuario

Diferentes cadenas públicas y máquinas virtuales tienen lenguajes de contratos inteligentes, arquitecturas, estructuras de datos, etc. completamente diferentes. En Web2, los desarrolladores de juegos elegirán motores front-end multiplataforma como Unity, que pueden hacer que un conjunto de códigos se adapte ligeramente para ejecutarse en diferentes entornos como iPhone, Android y escritorio. Dado que el back-end no se ejecuta en el terminal del usuario, no hay problemas de plataforma cruzada.

En Web3, esto es básicamente un lujo. Migrar a una cadena o máquina virtual diferente significa reconstruir todo el proyecto y incurrir en costos enormes. Además, los desarrolladores que son nuevos en Web3 no tienen experiencia alguna para elegir un ecosistema que les convenga. ¿Se trata de una perspectiva técnica o una perspectiva ecológica?

A nivel de experiencia de usuario, las interacciones blockchain son extremadamente complejas. El concepto de abstracción de cuenta que era tan popular antes surgió precisamente para resolver problemas de experiencia de usuario web3, así que no entraré en detalles aquí.

Después de enumerar los 6 principales argumentos anteriores, resumamos: los desarrolladores de web2 a web3 enfrentan un umbral de adaptación enorme. Si son los mejores desarrolladores en web2, no es necesario abandonar su carrera en web2 e ir a un desconocido como web3. En este entorno, estamos desarrollando algunos negocios que no sabemos si serán exitosos o no.

Se puede decir, la mayoría de los principales desarrolladores de juegos no han ingresado a Web3. En cierta medida, esto hace que la mayoría de los juegos de Web3 estén sesgados hacia la especulación financiera en lugar de tener una alta jugabilidad y diversión particularmente altas.

También existen obstáculos de la misma naturaleza en el lado del usuario. Los juegos Web3 tienen una serie de pasos de operación que obstaculizan las tasas de conversión de los usuarios, lo que resulta en un gran grupo de usuarios de Web2 que no están dispuestos a experimentar o incluso no son conscientes de la existencia de los juegos Web3.

¿Existe un proyecto a nivel de infraestructura que pueda resolver los problemas mencionados? Tabi Chain puede ser un proyecto muy cercano a una de las soluciones definitivas para los juegos Web3. Su concepto central es la “Capa de Ejecución Omni”: Los desarrolladores ya no necesitan preocuparse por las diferencias entre varios VM o entornos operativos. Pueden usar directamente sus entornos operativos familiares o incluso personalizables para desarrollar o portar juegos directamente.

Además, Tabi Chain también cuenta con consenso modular, capa de seguridad y otras características. Todo es modular y personalizable para satisfacer las necesidades de diferentes juegos y aplicaciones.

Capa de ejecución Omni: Selección del entorno de ejecución basada en las necesidades del desarrollador

Revisitemos el concepto fundamental de blockchain. Mientras que algunos podrían describirlo como un libro contable descentralizado e inmutable, se define más precisamente como la sincronización verificable del estado permanente de una máquina de estados dentro de una red distribuida.

En esencia, la blockchain mantiene una máquina de estado universalmente aceptada y su estado operativo:

• Cada entrada es determinista, registrada en cada bloque;
• La función de transición de estado es determinista, representada por la MV o tiempo de ejecución dentro del cliente de blockchain;
• El estado de salida también es determinista, registrado en cada bloque;

Por lo tanto, el sistema de consenso de una cadena de bloques no necesita estar limitado a una sola capa de ejecución (como solo EVM). Independientemente del número de capas de ejecución, siempre que la cadena pueda verificar los estados en múltiples capas, permitiendo que cada juego opere en su propio entorno, podemos abordar los diversos problemas discutidos anteriormente.

En Tabi, cada juego o dApp puede construir su propio Servicio independiente. Todos los Servicios envían sus propios bloques generados al sistema de consenso de la cadena; Los Nodos Supervisores incluyen el tiempo de ejecución/VM en todos los Servicios para verificar el estado de los bloques de servicio. El núcleo de la capa de ejecución integral de Tabi puede considerarse como una VM con capacidades polimórficas, por lo que se llama Polymorphism VM.

Para las máquinas virtuales de blockchain existentes, una máquina virtual de polimorfismo necesita integrar estas máquinas virtuales dentro de su entorno de tiempo de ejecución y proporcionar los métodos de llamada de interfaz necesarios. El concepto de "integración" aquí se puede implementar de dos maneras:

Estado del mundo compartido: Similar a Ethermint, que admite EVM en Cosmos. El EVM actúa como una capa superficial, centrándose en las interacciones del usuario y las operaciones del contrato, haciendo que todas las actividades del lado del usuario parezcan ejecutarse en el EVM. Sin embargo, los resultados finales y los datos de estas operaciones se almacenan en otros módulos de Cosmos. Por lo tanto, esta compatibilidad con EVM es esencialmente un mapeo de los datos subyacentes.

Esta relación de asignación se puede extender a otras MV también. Por ejemplo, Ethermint puede incorporar una capa de módulo SVM adicional, donde tanto el SVM como el EVM corresponden a los mismos datos subyacentes.

Esto es similar a usar VMWare en una PC para ejecutar una máquina virtual de Windows. VMWare puede acceder tanto al disco duro virtual de la máquina virtual como al disco duro de la computadora física. Si luego inicia una máquina virtual de Mac, puede montar los datos desde el disco físico de la misma manera. Esta configuración permite que múltiples máquinas virtuales compartan los recursos y el estado del mismo entorno de manera efectiva.

El servicio principal de Tabi Chain utilizará un enfoque de estado mundial compartido. Esto significa que siempre que se adapte la VM correspondiente, las dApps desarrolladas para esa VM pueden implementarse directamente en el Servicio Principal sin necesidad de crear un servicio separado.

Estado mundial independiente: Diferentes aplicaciones y juegos tienen requisitos únicos, y algunos juegos utilizan tiempos de ejecución personalizados. Por lo tanto, un enfoque universal de integrar todas las máquinas virtuales a través de un “estado mundial compartido” en la VM de Polimorfismo no es adecuado para todos los casos. Un estado mundial independiente también es necesario, ya que es más simple de implementar e ideal para servicios con datos completamente separados.

Independientemente del enfoque utilizado, debe ser verificable por los Nodos Supervisores. Esto significa que la Máquina Virtual de Polimorfismo debe incluir todas las Máquinas Virtuales o tiempos de ejecución utilizados por los diversos métodos de implementación.

Ejemplo de portabilidad de juegos Web2

El Polymorphism VM es altamente personalizable, lo que lo hace particularmente beneficioso para los desarrolladores de Web2. Pueden utilizar lenguajes y marcos familiares para trasladar cualquier lógica empresarial al Polymorphism VM.

Supongamos que Minecraft quiere portarse a Tabi. El proceso general sería el siguiente:

1. Modificar el código del servidor: Modificar ligeramente el código del servidor de Minecraft (Java u otro lenguaje), moviendo los datos que deben estar en la cadena a una base de datos (o un conjunto de bases de datos). Identificar y seleccionar todas las funciones que podrían alterar esta base de datos (es decir, funciones de transición de estado).
2. Empaque los componentes: Empaque esta base de datos y estas funciones en un archivo JAR, que es un programa ejecutable en Java. Incluya el JRE (Entorno de Ejecución de Java) en este paquete. Este paquete completo se carga luego en la VM de Polymorphism, asegurando que todos los datos estén en la cadena.
3. Ejecutar lógica fuera de la cadena: Ejecutar otra lógica de backend que no necesita estar en la cadena (como formación de equipo, chat, etc.) en servidores fuera de la cadena.
4. Iniciar un Servicio: Iniciar un Servicio en Tabi Chain y notificar al Polimorfismo VM de los Nodos Supervisores para cargar el mismo JRE.
   

Con esto, el proceso completo está completo.

Para los desarrolladores, estas modificaciones se realizan dentro del lenguaje y marco Java existentes. El mismo concepto se aplica a los juegos desarrollados utilizando cualquier otro método. Para los usuarios, la interacción del juego permanece en gran medida sin cambios. Claramente, este método de portar juegos Web2 es muy rápido y eficiente, pudiendo convertirse en el modelo fundamental para la adopción masiva de juegos Web3.

Detalles de la Funciones de Juego STR (State Transition Runtime)

El ejemplo anterior proporcionó una visión general de la portabilidad de un juego Web2. Para obtener una comprensión más profunda, necesitamos adentrarnos en más detalles. Esta vez, utilizaremos un ejemplo general en lugar de un juego específico para ilustrar los detalles involucrados en la ejecución en tiempo de ejecución de la Capa de Ejecución Omni.

Básicamente, personalizar el entorno de ejecución de un juego puede considerarse como la creación de la máquina de estados del juego en la cadena de bloques, conocida como el Tiempo de Ejecución de Transición de Estado (STR) en Tabi.

El ejemplo anterior es el proceso general de portar juegos Web2. Aún necesitamos saber más sobre los detalles. Esta vez usamos un ejemplo general en lugar de un ejemplo de juego específico para mostrar los detalles involucrados en la ejecución en la capa de ejecución omnipotente.

Básicamente, personalizar el entorno de ejecución de un juego puede considerarse como la creación de una máquina de estados para un juego en particular en la cadena de bloques, que se llama Tiempo de Ejecución de Transición de Estado en Tabi.

STR se puede integrar en Polymorphism VM en forma de binario o módulo.

En un sistema similar a blockchain, necesitamos asegurar la transparencia de las entradas, la visibilidad pública de las transiciones de estado y la expresividad del estado global. Para cumplir con estos requisitos, necesitamos construir un tiempo de ejecución con las siguientes características:

1. World DBContiene todos los datos de usuario dentro de la aplicación que deben ser registrados en la cadena de bloques. Estos datos deben ser valiosos e importantes, por lo que se necesita una estructura similar a la de la cadena de bloques para garantizar su disponibilidad. Por lo tanto, no todos los datos necesitan ser registrados en la cadena de bloques. Por ejemplo, en los juegos, el contenido del chat del usuario generalmente no es importante y es desechable, por lo que no es necesario ponerlo en la cadena de bloques.
2. Puede expresar el estado completo del mundo. En muchos escenarios, como en los juegos, esta expresión no implica necesariamente un alto grado de trazabilidad: un simple acumulador será suficiente, lo que significa que una estructura de datos como un árbol de Merkle no siempre es necesario. Sin embargo, sin importar qué estructura de datos se utilice para representar el estado del mundo, es crucial que el estado del mundo de la base de datos mundial pueda expresarse de forma resumida.
3. Cualquier función que pueda causar cambios en la base de datos mundial se llama función de transición de estado, y debe estar encapsulada en el tiempo de ejecución de transición de estado. Cualquier modificación en la base de datos mundial fuera del tiempo de ejecución debe considerarse ilegal y ser rechazada.
4. Las interfaces de entrada y salida deben cumplir con el diseño del Intérprete de Entrada y el Propositor de Bloques. Esto es relativamente simple y no se explicará en detalle aquí.

Los siguientes estructuras organizativas son elementos esenciales de este STR. Tabi proporcionará un SDK por defecto para facilitar a los desarrolladores crear el tiempo de ejecución.

World DB

En la práctica, es probable que un juego o aplicación utilice más de una base de datos, y estas bases de datos pueden ser de diferentes tipos. Supongamos que un juego en particular utiliza tanto una base de datos relacional como una base de datos clave-valor.

El siguiente es un ejemplo simple de base de datos relacional:

1. UID: Representa un usuario único, que puede ser una clave pública u otro identificador.
2. Nonce: utilizado para prevenir ataques de repetición.
3. Campos de datos adicionales: cualquier tipo de datos.

Esta es una base de datos simple de clave-valor:

Función de Transición de Estado

Esta es una función simple de transición de estado. Cuando esta función recibe la entrada del usuario, simplemente la multiplica por 5 y modifica los datos en la base de datos relacional.

Acumulador de Estado Mundial

Podemos construir un acumulador de hash simple para representar el estado del mundo:

A_s+1 = hash(A_s + hash(query))

Este método asegura que después de cualquier modificación en la base de datos mundial, siempre habrá un estado único y definido que corresponda a esa modificación.

Es importante tener en cuenta que cada función de transición de estado debe implementar este método. Este requisito puede ser aplicado usando modificadores, interfaces, ganchos u otros mecanismos específicos del lenguaje. Debido a las diferentes características de varios lenguajes de programación, no entraremos en detalles específicos aquí.

El proceso de actualización de una base de datos clave-valor (KVDB) sigue el mismo principio.

Números Aleatorios

Las funciones de transición de estado no deben incluir números aleatorios, ya que esto causaría resultados diferentes al ser validados por verificadores diferentes, rompiendo la consistencia. Los números aleatorios deben incluirse como parte de los parámetros de entrada del sistema.

Resumir

De los ejemplos anteriores, podemos ver que la Capa de Ejecución Omni de Tabi Chain proporciona a los desarrolladores de juegos una flexibilidad significativa a través de un enfoque modular. Debido a limitaciones de espacio, no podemos discutir todos los detalles aquí, pero los puntos principales mencionados son suficientes para demostrar que la solución de Tabi Chain es tanto práctica como innovadora.

En el ecosistema actual de Web3, las obras desarrolladas en diferentes cadenas y MV generalmente carecen de portabilidad. Para que los juegos de Web2 pasen a Web3, a menudo significa reescribir el juego en lenguajes y entornos desconocidos, enfrentando varias restricciones incomprensibles.

Con Tabi, los desarrolladores pueden utilizar su lenguaje original, plataforma de desarrollo y motor. Solo necesitan hacer adaptaciones y modificaciones simples, similares a llamar a un SDK, para llevar sus proyectos al mundo blockchain. Esto se traduce en mejoras exponenciales en eficiencia y reducciones en complejidad.

Esperamos que Tabi Chain pueda convertirse en un catalizador para la adopción masiva de juegos Web3, atrayendo a talentosos desarrolladores de juegos Web2 y llevando juegos verdaderamente entretenidos y jugables al espacio Web3.

Descargo de responsabilidad：

1. Este artículo está reimpreso de [极客 Web3]. Todos los derechos de autor pertenecen al autor original [罗奔奔]. Si hay objeciones a esta reimpresión, por favor contacte al Gate Learnequipo, y lo resolverá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.