Isso claramente está em desacordo com o modelo de desenvolvimento de jogos tradicionais. Jogos tradicionais bem-sucedidos atraem muitos usuários por meio de mecânicas de jogo envolventes, permitindo que os desenvolvedores construam caminhos lucrativos e potencialmente se expandam para mercadorias e IPs relacionados. Esses jogos operam em um ciclo positivo onde os jogadores desfrutam do jogo e frequentemente obtêm benefícios econômicos tanto dentro quanto fora do jogo.

Em contraste, os jogos blockchain atuais atraem principalmente os jogadores por meio de retornos financeiros. Além de sua baixa jogabilidade, os jogos Web3 também enfrentam problemas de longa data, como altas barreiras de entrada e processos de interação complicados.

Qual é a causa raiz desses problemas? As opiniões variam. A equipe TabiChain acredita que um fator significativo é que os talentosos desenvolvedores de jogos tradicionais lutam para entrar no ecossistema Web3 devido a barreiras técnicas e de aprendizado. Para aqueles que não estão familiarizados com o desenvolvimento de jogos ou software, a transição do Web2 para o Web3 pode parecer apenas uma mudança de narrativa e ambiente, mas a realidade é muito mais severa.

Então, como podemos criar um ambiente mais acolhedor para desenvolvedores de jogos tradicionais ou empresas relacionadas por meio da tecnologia? Nas próximas seções, analisaremos minuciosamente os desafios enfrentados pelos jogos Web3 e suas soluções, explicando como a indústria de jogos Web3 do futuro pode ser tecnicamente adaptada para atender melhor aos desenvolvedores de jogos tradicionais.

Razões Técnicas Impedindo Desenvolvedores de Jogos Tradicionais de Entrar no Ecossistema Web3

No artigo anterior, mencionamos brevemente que a tecnologia não amigável e os altos custos de aprendizado são os principais fatores que impedem os praticantes de jogos tradicionais de entrarem no ecossistema web3. A chamada tecnologia não amigável e os altos custos de aprendizado podem ser expandidos para os seguintes pontos:

1. A diferença entre aplicações web3 e estruturas de software tradicionais

Blockchain e as aplicações nela (dApps) são fundamentalmente diferentes da arquitetura de software tradicional e exigem que os desenvolvedores tenham um novo sistema de conhecimento, como o princípio de funcionamento do blockchain, protocolos de consenso, modelos de programação de contratos inteligentes, etc. Os desenvolvedores de jogos tradicionais precisam passar muito tempo aprendendo Solidity ou outras linguagens de contratos inteligentes e precisam entender como o EVM funciona.

Além disso, a lógica de jogo tradicional geralmente é executada em um servidor centralizado, que pode lidar de forma flexível com estados de jogo complexos e interações de alta frequência. Executar a lógica de jogo na blockchain requer um alto grau de simplificação ou refatoração, porque cada operação deve ser publicada na rede distribuída para execução e depois enviada para a cadeia, o que é severamente limitado pelo desempenho e custo da blockchain.

1. Limitações de design de contratos inteligentes

Embora o EVM seja completo em Turing e possa teoricamente expressar lógica arbitrária, suas características são muito desfavoráveis para o desenvolvimento de jogos, tais como:

• Falta de temporizador. Todas as operações na cadeia Ethereum devem ser acionadas manualmente pela conta EOA. Para obter um efeito semelhante a um temporizador, os desenvolvedores precisam implantar um serviço adicional e manter uma conta EOA e uma lista de eventos para acionar manualmente tarefas programadas. Devido ao problema de atraso na cadeia, não é possível garantir que essas tarefas programadas sejam concluídas no prazo.

• Não há callback e outros mecanismos, e não suporta multithreading e assíncrono. Como o Solidity é projetado para o desenvolvimento de contratos inteligentes Ethereum, seu ambiente de execução é significativamente diferente dos ambientes de execução tradicionais. A operação do EVM é transacional, e cada chamada de função precisa ser completamente executada em uma transação. Não há conceito de "assíncrono" no sentido tradicional. Isso significa que uma chamada de função em Solidity é atômica do início ao fim e não pode ser interrompida por outras transações.
• Não há capacidade de referenciar dados externos. Embora existam oráculos como Chainlink, quer do ponto de vista da integração quer do ponto de vista da chamada de dados, a facilidade de uso é muito diferente de obter diretamente chamadas de dados por meio de solicitações https, o que permite aos desenvolvedores adicionar integrações adicionais. Ônus e dependência.
• Limitações de escalabilidade e desempenho. A lógica do jogo deve ser simplificada ou dividida em várias transações simples para evitar que a taxa de gás de uma única transação se torne muito alta ou exceda o limite máximo, o que limita a implementação de interações e funções complexas.

1. Limitações no armazenamento e recuperação de dados

• Contratos inteligentes têm espaço de armazenamento caro e design limitado, tornando-os inadequados para armazenar grandes quantidades de dados de jogos.
• Logs de eventos podem ser necessários para rastrear indiretamente o status do jogo, e a captura de eventos pode não ser estável. Problemas como quando atualizar o estado do jogo frequentemente exigem que os jogadores ou operadores do jogo o acionem manualmente.
• A estrutura de dados da conta adotada pelo EVM resulta em capacidades pobres de indexação de dados. Quando você consulta os dados de uma conta, só é possível saber o saldo de seu ETH ou token nativo da cadeia, mas não é possível saber diretamente quais ativos ERC-20 ela possui e o saldo de cada ativo. O mesmo vale para os NFT. Essas informações estão encapsuladas no contrato exclusivo de cada ativo, em vez de serem armazenadas na própria conta do usuário.

Podemos ver que tipo de token e informações de saldo um determinado endereço possui de ferramentas como Etherscan. Estes são indexados por ferramentas periféricas como navegadores de blockchain, e estes últimos precisam construir um banco de dados dedicado enorme e rastreá-lo completamente. Somente coletando todos os dados de bloco ou monitorando eventos na cadeia, todos os dados na cadeia podem ser resumidos.

Os desenvolvedores Web3 geralmente têm que integrar provedores de dados de terceiros como Etherscan, NFTscan, The Graph, etc., e até mesmo pagar pela sua API KEY. Além disso, esses serviços de terceiros são essencialmente bancos de dados off-chain, o que pode causar atrasos, erros, exceder os limites de chamadas, indisponibilidade de serviço e outras falhas.

Vamos comparar as diferenças entre a forma de banco de dados da maioria dos jogos e os métodos de armazenamento de dados na blockchain. A diferença entre os dois é óbvia. A estrutura de dados da maioria dos jogos é completamente personalizada por si só, tem boas capacidades de expressão e indexação, e não precisa depender de quaisquer serviços de terceiros.

1. Desafios na integração de ativos de jogos existentes com blockchain

Os ativos de jogo existentes (como adereços e personagens) geralmente não são criados e gerenciados na blockchain. Migrar esses ativos para a blockchain geralmente envolve a conversão de tipos de dados comuns, mas de longo prazo, em NFTs ou Tokens padrão, o que envolve um trabalho de migração e integração complexo e afetará o sistema econômico de jogo existente.

1. Atualizações, patches e prevenção de desastres

No Ethereum, uma vez que um contrato inteligente é implantado, o código é imutável, tornando os upgrades e patches mais complexos do que o software tradicional. Os desenvolvedores frequentemente usam contratos de proxy ou padrões de versionamento para contornar essa limitação, mas isso aumenta a complexidade da estrutura geral. Os contratos de proxy precisam ser usados com cuidado especial para evitar a corrupção de dados causada por conflitos de slots de armazenamento. Além disso, o risco de vazamento de direitos administrativos também é sério.

A atualização de código de jogos tradicionais não é tão complicada em termos de estrutura técnica. A única coisa que pode precisar ser restrita é a autoridade centralizada de atualização. Isso pode ser alcançado por meio de métodos como DAO, em vez de depender de contratos inteligentes.

Além disso, os jogos tradicionais costumam tirar instantâneos ou backups do banco de dados. Isso pode não ser muito importante normalmente, mas se você encontrar um bug importante na atualização, você pode rapidamente reverter os dados, o que é basicamente um fantasia na blockchain. Mesmo que alguns dados do jogo sejam revertidos reconstruindo o contrato, como migrar os dados e o status do contrato antigo para o novo contrato ainda é complicado.

1. Fragmentação ecológica e problemas de experiência do usuário

Diferentes cadeias públicas e VMs têm idiomas de contratos inteligentes, arquiteturas, estruturas de dados, etc., completamente diferentes. No Web2, os desenvolvedores de jogos escolherão motores front-end multiplataforma como Unity, que podem fazer um conjunto de códigos ligeiramente adaptados para serem executados em ambientes diferentes, como iPhone, Android e desktop. Como o back-end não é executado no terminal do usuário, não há problemas de multiplataforma.

Em Web3, isso é basicamente um luxo. Migrar para uma cadeia ou VM diferente significa reconstruir o projeto inteiro e incorrer em custos enormes. Além disso, os desenvolvedores que são novos no Web3 não têm nenhuma experiência para escolher um ecossistema que lhes convém. Isso é visto de uma perspectiva técnica ou ecológica?

No nível da experiência do usuário, as interações em blockchain são extremamente complexas. O conceito de abstração de conta, que era tão popular anteriormente, surgiu precisamente para resolver os problemas de experiência do usuário do web3, então não vou entrar em detalhes aqui.

Depois de listar os 6 principais argumentos acima, vamos resumir: os desenvolvedores da web2 para a web3 enfrentam um grande limiar de adaptação. Se eles são os principais desenvolvedores na web2, não há necessidade de abandonar sua carreira na web2 e ir para um estranho como a web3. Neste ambiente, estamos desenvolvendo alguns negócios que não sabemos se podem ser bem-sucedidos ou não.

Pode-se dizer que a maioria dos principais desenvolvedores de jogos não entraram no Web3. Em certa medida, isso faz com que a maioria dos jogos Web3 sejam tendenciosos para a especulação financeira em vez de terem uma jogabilidade e diversão particularmente altas.

Os obstáculos da mesma natureza também existem no lado do usuário. Os jogos Web3 têm uma série de etapas de operação que dificultam as taxas de conversão do usuário, resultando em um grande grupo de usuários do Web2 que não estão dispostos a experimentar ou até mesmo completamente inconscientes da existência dos jogos Web3.

Existe algum projeto de infraestrutura que possa resolver os problemas acima? Tabi Chain pode ser um projeto muito próximo de uma das soluções finais para jogos Web3. Seu conceito principal é a 'Camada de Execução Omni': os desenvolvedores não precisam mais se preocupar com as diferenças entre várias VMs ou ambientes de operação. Eles podem usar diretamente seus ambientes de operação familiares ou até personalizáveis para desenvolver ou portar jogos diretamente.

Além disso, a Tabi Chain também possui consenso modular, camada de segurança e outras funcionalidades. Tudo é modular e personalizável para atender às necessidades de diferentes jogos e aplicativos.

Camada de Execução Omni: Selecionando o Ambiente de Execução com Base nas Necessidades do Desenvolvedor

Vamos revisitar o conceito fundamental de blockchain. Enquanto alguns podem descrevê-lo como um livro-razão descentralizado e imutável, é mais precisamente definido como a sincronização verificável do estado permanente de uma máquina de estado dentro de uma rede distribuída.

Essencialmente, o blockchain mantém uma máquina de estado universalmente aceita e seu status operacional:

• Cada entrada é determinística, registrada em cada bloco;
• A função de transição de estado é determinística, representada pela VM ou tempo de execução dentro do cliente de blockchain;
• O estado de saída também é determinístico, registrado em todos os blocos;

Assim, o sistema de consenso de uma blockchain não precisa se limitar a uma única camada de execução (como apenas EVM). Independentemente do número de camadas de execução, desde que a cadeia consiga verificar os estados em várias camadas, permitindo que cada jogo opere em seu próprio ambiente, podemos abordar as várias questões discutidas anteriormente.

Em Tabi, cada jogo ou dApp pode construir seu próprio Serviço independente. Todos os Serviços submetem seus próprios blocos gerados ao sistema de consenso da cadeia; Os Nós Supervisores incluem o tempo de execução/VM em todos os Serviços para verificar o status dos blocos de serviço. O núcleo da camada de execução abrangente do Tabi pode ser considerado como uma VM com capacidades polimórficas, por isso é chamado de VM de Polimorfismo.

Para as VMs de blockchain existentes, uma VM de Polimorfismo precisa integrar essas VMs dentro de seu ambiente de tempo de execução e fornecer os métodos de chamada de interface necessários. O conceito de "integração" aqui pode ser implementado de duas maneiras:

Estado do Mundo Compartilhado: Semelhante ao Ethermint, que suporta a EVM no Cosmos. A EVM atua como uma camada superficial, focando nas interações do usuário e nas operações de contrato, fazendo com que todas as atividades do lado do usuário pareçam ser executadas na EVM. No entanto, os resultados finais e os dados dessas operações são armazenados em outros módulos do Cosmos. Assim, essa compatibilidade com a EVM é essencialmente um mapeamento dos dados subjacentes.

Esta relação de mapeamento pode ser estendida para outras Máquinas Virtuais também. Por exemplo, o Ethermint pode incorporar uma camada de módulo SVM adicional, onde tanto o SVM quanto o EVM correspondem aos mesmos dados subjacentes.

Isso é semelhante ao uso do VMWare em um PC para executar uma máquina virtual do Windows. O VMWare pode acessar tanto o disco rígido virtual da máquina virtual quanto o disco rígido físico do computador. Se você então iniciar uma máquina virtual do Mac, ela pode montar os dados do disco físico da mesma maneira. Essa configuração permite efetivamente que várias máquinas virtuais compartilhem os recursos e o estado do mesmo ambiente.

O Serviço Principal da Tabi Chain utilizará uma abordagem de estado mundial compartilhado. Isso significa que, desde que a VM correspondente seja adaptada, os dApps desenvolvidos para essa VM podem ser implantados diretamente no Serviço Principal sem a necessidade de criar um serviço separado.

Independent World State: Diferentes aplicativos e jogos têm requisitos únicos, e alguns jogos usam runtimes personalizados. Portanto, uma abordagem universal de integrar todas as VMs por meio de um “estado de mundo compartilhado” na VM de Polimorfismo não é adequada para todos os casos. Um estado de mundo independente também é necessário, pois é mais simples de implementar e ideal para serviços com dados totalmente separados.

Independentemente da abordagem usada, ela deve ser verificável pelos nós do supervisor. Isso significa que a VM de polimorfismo deve incluir todas as VMs ou tempos de execução usados pelos vários métodos de implementação.

Exemplo de portabilidade de jogos Web2

O VM de Polimorfismo é altamente personalizável, o que o torna particularmente benéfico para desenvolvedores Web2. Eles podem usar linguagens e estruturas familiares para portar qualquer lógica de negócios para o VM de Polimorfismo.

Suponha que o Minecraft queira fazer a portabilidade para Tabi. O processo geral seria o seguinte:

1. Modificar o Código do Servidor: Modificar ligeiramente o código do servidor Minecraft (Java ou qualquer outro idioma), movendo os dados que precisam estar na cadeia para um banco de dados (ou um conjunto de bancos de dados). Identificar e selecionar todas as funções que podem alterar esse banco de dados (ou seja, funções de transição de estado).
2. Empacote os Componentes: Empacote este banco de dados e estas funções em um arquivo JAR, que é um programa executável em Java. Inclua o JRE (Ambiente de Tempo de Execução Java) neste pacote. Este pacote inteiro é então carregado na VM de Polimorfismo, garantindo que todos os dados estejam na cadeia.
3. Executar Lógica Fora da Cadeia: Executar outras lógicas de backend que não precisam estar na cadeia (como formação de equipe, chat, etc.) em servidores fora da cadeia.
4. Iniciar um Serviço: Inicie um Serviço na Cadeia Tabi e notifique o VM de Polimorfismo dos Nós Supervisores para carregar o mesmo JRE.
   

Com isso, todo o processo está completo.

Para os desenvolvedores, essas modificações são feitas dentro da linguagem e estrutura Java existente. O mesmo conceito se aplica aos jogos desenvolvidos usando qualquer outro método. Para os usuários, a interação do jogo permanece em grande parte inalterada. Claramente, este método de portar jogos Web2 é muito rápido e eficiente, potencialmente se tornando o modelo fundamental para a adoção em massa de jogos Web3.

Detalhes das Funções do Jogo STR (State Transition Runtime)

O exemplo anterior forneceu uma visão geral geral de como portar um jogo Web2. Para obter uma compreensão mais profunda, precisamos nos aprofundar em mais detalhes. Desta vez, usaremos um exemplo geral em vez de um jogo específico para ilustrar os detalhes envolvidos na execução da Camada de Execução Omni.

Essencialmente, personalizar o ambiente de execução de um jogo pode ser visto como criar a máquina de estados do jogo na blockchain, referida como Tempo de Execução de Transição de Estado (TET) no Tabi.

O exemplo acima é o processo geral de portabilidade de jogos Web2. Ainda precisamos saber mais sobre os detalhes. Desta vez, usamos um exemplo geral em vez de um exemplo de jogo específico para mostrar os detalhes envolvidos na execução em tempo de execução na camada de execução onipotente.

Basicamente, personalizar o ambiente de execução de um jogo pode ser considerado como criar uma máquina de estados para um determinado jogo na blockchain, que é chamado de Tempo de Execução de Transição de Estado em Tabi.

STR pode ser integrado ao Polymorphism VM na forma de binário ou módulo.

Em um sistema semelhante a blockchain, precisamos garantir a transparência das entradas, visibilidade pública das transições de estado e expressividade do estado global. Para atender a esses requisitos, precisamos construir um tempo de execução com as seguintes características:

1. World DBContém todos os dados do usuário dentro do aplicativo que precisam ser registrados na blockchain. Esses dados devem ser valiosos e importantes, portanto, é necessária uma estrutura semelhante à blockchain para garantir sua disponibilidade. Portanto, nem todos os dados precisam ser registrados na blockchain. Por exemplo, em jogos, o conteúdo do chat do usuário geralmente não é importante e é descartável, portanto, não há necessidade de colocá-lo na blockchain.
2. Ele pode expressar o estado completo do mundo. Em muitos cenários, como em jogos, essa expressão não implica necessariamente um alto grau de rastreabilidade - um simples acumulador será suficiente, o que significa que uma estrutura de dados como uma árvore de Merkle nem sempre é necessária. No entanto, não importa qual estrutura de dados seja usada para representar o estado do mundo, é crucial que o estado do mundo do banco de dados possa ser expresso de forma resumida.
3. Qualquer função que possa causar alterações no banco de dados mundial é chamada de função de transição de estado e deve ser encapsulada no tempo de execução da transição de estado. Qualquer modificação no banco de dados mundial fora do tempo de execução deve ser considerada ilegal e rejeitada.
4. As interfaces de entrada e saída devem estar em conformidade com o design do Interpretador de Entrada e do Propositor de Bloco. Isso é relativamente simples e não será explicado em detalhes aqui.

As seguintes estruturas organizacionais são elementos essenciais deste STR. O Gate fornecerá um SDK por padrão para facilitar os desenvolvedores a criarem o tempo de execução.

World DB

Na prática, um jogo ou aplicativo provavelmente usará mais de um banco de dados, e esses bancos de dados podem ser de tipos diferentes. Vamos supor que um jogo específico use tanto um banco de dados relacional quanto um banco de dados chave-valor.

O seguinte é um exemplo simples de banco de dados relacional:

1. UID: Representa um usuário único, que pode ser uma chave pública ou outro identificador.
2. Nonce: usado para evitar ataques de repetição.
3. Campos de dados adicionais: qualquer tipo de dados.

Este é um banco de dados simples de chave-valor:

Função de Transição de Estado

Esta é uma função de transição de estado simples. Quando esta função recebe entrada do usuário, simplesmente a multiplica por 5 e modifica os dados no banco de dados relacional.

Acumulador de Estado Mundial

Podemos construir um acumulador de hash simples para representar o estado do mundo:

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

Este método garante que, após qualquer modificação no banco de dados mundial, sempre haverá um estado único e definitivo correspondente a essa modificação.

É importante notar que cada função de transição de estado deve implementar este método. Este requisito pode ser aplicado usando modificadores, interfaces, ganchos ou outros mecanismos específicos da linguagem. Devido às diferentes características de várias linguagens de programação, não entraremos em detalhes específicos aqui.

O processo de atualização para um banco de dados chave-valor (KVDB) segue o mesmo princípio.

Números Aleatórios

As funções de transição de estado não devem incluir números aleatórios, pois isso causaria resultados diferentes quando validados por verificadores diferentes, quebrando a consistência. Números aleatórios devem ser incluídos como parte dos parâmetros de entrada do sistema.

Resumo

A partir dos exemplos acima, podemos ver que a Camada de Execução Omni da Tabi Chain fornece aos desenvolvedores de jogos significativa flexibilidade por meio de uma abordagem modular. Devido a restrições de espaço, não podemos discutir todos os detalhes aqui, mas os pontos principais mencionados são suficientes para demonstrar que a solução da Tabi Chain é ao mesmo tempo prática e inovadora.

No ecossistema Web3 atual, os trabalhos desenvolvidos em diferentes blockchains e VMs geralmente carecem de portabilidade. Para os jogos da Web2 fazerem a transição para a Web3, muitas vezes significa reescrever o jogo em idiomas e ambientes desconhecidos, enfrentando várias restrições incompreensíveis.

Com o Tabi, os desenvolvedores podem usar sua linguagem original, plataforma de desenvolvimento e mecanismo. Eles só precisam fazer adaptações e modificações simples, semelhantes a chamar um SDK, para trazer seus projetos para o mundo da blockchain. Isso resulta em melhorias exponenciais na eficiência e reduções na complexidade.

Esperamos que o Tabi Chain possa se tornar um catalisador para a adoção em massa de jogos Web3, atraindo talentosos desenvolvedores de jogos Web2 e trazendo jogos verdadeiramente divertidos e jogáveis para o espaço Web3.

Aviso Legal：

1. Este artigo é reproduzido de [GateWeb3 Gate]. Todos os direitos autorais pertencem ao autor original [罗奔奔]. Se houver objeções a este reenvio, entre em contato com o Gate Learnequipe e eles vão lidar com isso prontamente.
2. Responsabilidade de Isenção: As opiniões e pontos de vista expressos neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe Gate Learn. A menos que mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.