Critério de comparação: onde o state é armazenado e onde as regras são executadas
«On-chain games vs Web2 games» — comparação da arquitetura de jogos on-chain e jogos Web2: onde as regras são executadas e onde o state do jogo (progresso, inventário, parâmetros do personagem) é armazenado.
A principal diferença entre «jogos com NFT» e fully on-chain é que, em um caso, o token pode estar on-chain, enquanto o progresso e as regras permanecem no servidor.
- Web2 → itens e progresso — registros no banco de dados do desenvolvedor; o acesso é determinado pela conta e pelas regras do serviço.
- On-chain → parte da lógica e/ou do estado é registrada no blockchain; os ativos podem ser NFT, e as ações — transações.
- Híbrido Web3 → o NFT pode ficar armazenado na carteira, mas o gameplay e o progresso normalmente são atualizados no servidor.
- Fully on-chain → regras e state ficam em smart contracts; os aplicativos clientes podem mudar, mas as regras de execução e o state do contrato (eventos e registros do contrato) permanecem na rede.
Conclusão principal: quando os servidores Web2 são desligados, o acesso e o progresso geralmente deixam de existir. Em um híbrido Web3, o NFT costuma permanecer na carteira, mas a utilidade do jogo desaparece se as regras de uso e o progresso forem server-side.
A «fonte da verdade» — a camada que armazena os direitos sobre o ativo e o state final: servidor/banco de dados do estúdio ou smart contract e dados da rede.
Atualização: as definições de híbrido Web3 e fully on-chain foram уточнены, foram adicionados critérios para verificar a «fonte da verdade» e foram incluídas as consequências do cenário «server off».
Conclusão em 4 pontos: Web2, híbrido e fully on-chain
Critérios de comparação: onde o progresso (state) é armazenado e quem valida as regras (servidor ou smart contract).
- O importante não é a presença de NFT, e sim onde o progresso é armazenado e em qual camada as regras são executadas.
- Web2 → o servidor é a única fonte da verdade e o único ponto de falha.
- Híbrido Web3 → o token pode permanecer na carteira, mas as regras de uso muitas vezes são definidas pelo servidor.
- Fully on-chain → regras e state ficam nos contratos, e o cliente é uma interface para os dados da rede.
Comparação dos modelos: ativos, progresso, dependência do servidor
Comparação por camadas: fonte da verdade, ativos, progresso, dependência de servidores e consequências do desligamento do serviço.
| Parâmetro | Web2 | Híbrido Web3 (parcialmente on-chain) |
Fully on-chain |
|---|---|---|---|
| Fonte da verdade | Servidor/BD do estúdio | Servidor + blockchain para parte de direitos/ativos | Smart contracts e dados da rede |
| Ativos | Registro interno do jogo | NFT/tokens na carteira; a utilidade muitas vezes é definida pelo servidor | NFT/tokens + regras de uso no contrato |
| Progresso (state) | Server-side | Geralmente server-side | On-chain (state do contrato) |
| «Servidor desligado» | O acesso e o progresso geralmente deixam de existir | O NFT pode permanecer, mas modos/regras/progresso podem desaparecer | Regras e state permanecem na rede; a interface pode mudar |
| UX/velocidade | Máximos | Médios (carteira, assinaturas) | Compromisso (taxas, latência, infraestrutura de acesso) |
| Principais riscos | Centralização: o estúdio pode mudar regras e acesso | O token existe, mas a utilidade depende de servidores | Segurança dos contratos + escalabilidade e UX |
Termos para leitura: NFT, on-chain/off-chain, smart contract, state
Conjunto mínimo de conceitos para comparação: o que é o ativo, onde o state é armazenado e onde as regras são executadas.
- NFT — token único no blockchain que comprova a posse de um objeto digital (por exemplo, um item).
- Smart contract — código no blockchain que executa regras e armazena/atualiza dados.
- On-chain — ação ou dados são registrados na rede blockchain.
- Off-chain — ação ou dados são armazenados fora do blockchain (servidor, cliente, BD privada).
- Fully on-chain — a lógica e o estado do jogo ficam no blockchain; o cliente é uma interface para os dados e regras do contrato.
- Fonte da verdade — a camada que determina o estado final: quem possui o ativo, qual o nível, qual inventário.
Limites dos modelos: jogo Web2, híbrido Web3, fully on-chain
Separação pelo critério de execução: «ativos tokenizados» e «regras e state nos contratos» são modelos diferentes.
Jogos Web2: o estado (progresso, inventário, parâmetros do personagem) é armazenado e atualizado em servidores centralizados.
Jogos on-chain: ações e/ou estado são registrados no blockchain e as regras são executadas por smart contracts.
Híbrido Web3: os ativos são tokenizados (NFT/tokens), mas uma parte significativa da lógica e do progresso permanece off-chain.
Fully on-chain: o blockchain é usado como camada de execução: lógica e state ficam nos contratos, e as interfaces podem variar.
Tese principal: a existência de NFT não garante a preservação da utilidade. A utilidade só se mantém se as regras de uso e/ou o state crítico estiverem fixados nos contratos, ou se existir um cliente compatível que leia o state do contrato e aplique as mesmas regras.
Direitos sobre ativos: «no banco de dados» vs «na carteira»
Possuir um token e ter utilidade no jogo são estados diferentes, porque são definidos por camadas diferentes.
Web2: ativo como registro no sistema do desenvolvedor
O item existe como uma linha no banco de dados, e o acesso é o direito da conta de usar as funcionalidades do serviço.
- A conta e as regras da plataforma determinam quais itens e modos estão disponíveis.
- O bloqueio da conta ou o encerramento do serviço geralmente interrompem o acesso a itens e progresso.
- Transferência e negociação costumam ser limitadas pelas regras do produto e pela infraestrutura do estúdio.
Consequência: o ativo permanece como registro em banco de dados, e não como objeto independente fora do serviço.
Web3: ativo como token (NFT/token) no endereço da carteira
O proprietário controla o token pelas chaves, mas a utilidade é determinada por onde as regras de uso do token são executadas.
- O token pode permanecer independentemente da conta do jogo, porque o registro está na rede.
- Se as regras de uso do token forem definidas pelo servidor, o estúdio pode desativar a utilidade sem afetar o token em si.
- Após o encerramento do serviço, o preço do token pode cair se não houver clientes compatíveis ou regras on-chain de uso.
Consequência: o token pode permanecer no endereço, mas a «utilidade no jogo» desaparece quando regras e progresso server-side são desligados.
Separação: «NFT na carteira» significa posse do token. «O token dá direitos no jogo» depende da camada em que as regras de uso estão descritas e são executadas.
Ideia central: o NFT pode permanecer, mesmo que a utilidade não seja mais suportada pelo servidor.
Progresso e verificações: state server-side vs state do contrato
Pergunta-chave: onde o state é atualizado e qual camada confirma as transições de estado — servidor ou smart contract.
State server-side: o progresso é armazenado no banco de dados do serviço; a «versão oficial» é definida pelo servidor.
State do contrato: o progresso é registrado nos dados do smart contract e nos eventos da rede; as transições são verificadas pela lógica do contrato.
| O que é comparado | State server-side | State do contrato |
|---|---|---|
| Onde o progresso é armazenado | Banco de dados do serviço | Dados do contrato + eventos da rede |
| Quem confirma as transições | Lógica do servidor e regras do serviço | Lógica do smart contract (o que é permitido e o que é proibido) |
| Quem define a versão final | Servidor como único árbitro | Rede e contrato como fonte da verdade |
| Alterações administrativas | Possíveis (por exemplo, reverter a entrega de recompensa) | Limitadas pelas regras do contrato e por transações |
| Como o resultado é confirmado | Pelos dados do serviço e da conta | Pelos dados da rede (state do contrato e eventos) |
| Se o serviço for desligado | O progresso e a «versão oficial» podem desaparecer junto com o BD | State e eventos permanecem na rede; a interface pode mudar |
Exemplo: se o resultado da temporada (ranking e recompensa) for registrado on-chain, ele pode ser confirmado pelos dados da rede mesmo com a troca de cliente; se o resultado da temporada for armazenado no servidor, a «versão oficial» desaparece quando o serviço é desligado.
Compromisso: direitos on-chain e resultados on-chain, gameplay off-chain
- On-chain: posse, recompensas raras e resultados de temporadas (o que precisa ser confirmado independentemente do servidor).
- Off-chain: ações de alta frequência (combate, movimentos, matchmaking) por velocidade e UX.
- Consequência: o on-chain fixa eventos raros, mas significativos, e não cada ação do gameplay.
Quanto mais direitos e resultados finais são registrados nos contratos, menor a dependência de servidores para confirmar posse e resultados de temporadas.
Cenário de desligamento do serviço: o que se perde em cada modelo
O desligamento dos servidores afeta ativos e progresso de forma diferente, porque a fonte da verdade varia entre os modelos.
Web2: o desligamento da infraestrutura interrompe a atualização do state server-side e a entrega de dados à conta.
Consequência: o acesso ao progresso e aos itens geralmente termina вместе с сервисом.
Híbrido Web3: o NFT permanece no endereço como registro na rede, mas elementos server-side (progresso, modos, regras de uso) podem desaparecer.
Consequência: o token existe, mas a utilidade termina quando os servidores são desligados.
Fully on-chain: lógica e state ficam nos contratos, então os dados permanecem na rede independentemente de uma única empresa.
Limitação: o acesso conveniente depende de aplicativos clientes e de infraestrutura de leitura de dados (RPC e indexadores).
Limitações do on-chain: taxas, atrasos, UX e risco de contratos
O on-chain aumenta a verificabilidade, mas adiciona taxas, atrasos e exigências de gestão de chaves.
- Capacidade e latência: registrar ações exige transações e confirmações.
- Custo das operações: armazenar e atualizar state on-chain pode ser caro.
- Barreiras de UX: carteira, chaves, assinaturas e recuperação de acesso — uma camada separada de riscos.
- Infraestrutura de acesso: RPC, indexadores e interfaces influenciam a conveniência e a disponibilidade da leitura do state.
- Segurança dos contratos: erros de código e permissões incorretas levam a consequências irreversíveis para state e ativos.
Consequência para o game design: microações frequentes raramente são levadas para o on-chain; mais frequentemente, o on-chain fixa eventos raros, mas significativos (direitos, recompensas, resultados de temporadas).
Motivo da popularidade do híbrido: o blockchain é usado para direitos e eventos econômicos, enquanto o gameplay de alta frequência fica off-chain para evitar taxas e atrasos em cada ação.
A verificabilidade on-chain é paga com taxa e fricção no UX.
Critérios de escolha: quando o on-chain agrega valor e quando não
Filtro por arquitetura: onde direitos sobre ativos e resultados verificáveis são importantes, e onde a velocidade e o UX sem fricção importam mais.
O on-chain costuma ser mais justificável
Quando o valor está ligado à posse do ativo, à procedência e ao mercado secundário.
- Itens colecionáveis e cartas, onde o mercado secundário é importante.
- Economias de recursos e crafting com regras verificáveis por eventos da rede.
- Mundos de longa duração, onde é crítico preservar direitos sobre ativos e resultados de temporadas.
Web2 costuma ser mais racional
Quando velocidade, fricção mínima e ausência de taxas em cada ação são mais importantes.
- Gêneros em tempo real (shooters, ação), onde a latência é crítica.
- Jogos casuais com onboarding em massa sem carteiras e assinaturas.
- Projetos em que os itens não têm valor fora do serviço.
Exemplos (referências por abordagem)
Isto não é uma recomendação nem uma avaliação de qualidade. O objetivo da seção é mostrar como o mercado обычно nomeia arquiteturas diferentes.
Verificação pelos critérios: (1) o progresso fica na conta ou no contrato? (2) existe um cliente/visualização alternativa do state sem o site oficial? (3) a utilidade do NFT é definida pelo contrato ou por regras server-side?
- Ativos tokenizados (frequentemente híbrido) → itens e personagens como NFT, enquanto gameplay e progresso ficam off-chain.
- Formatos econômicos e colecionáveis → com mais frequência fixam on-chain direitos sobre ativos e regras de mercado em torno dos ativos.
- Direções fully on-chain → tentam manter regras e state nos contratos, com o cliente como interface para os dados da rede.
Critério de verificação: o local de armazenamento do progresso e a camada de execução das regras importam mais do que a presença de NFT.
Três erros comuns de percepção
Erros de expectativa обычно surgem quando «posse do token» é misturada com «utilidade funcionando» e com «fonte da verdade».
«Tem NFT — значит o jogo não pode ser encerrado»
O token pode existir na rede, mas o gameplay e o progresso server-side podem desaparecer.
- A posse do token não cria obrigação de o serviço поддерживать as regras do jogo.
- O risco é definido pelo local de armazenamento do progresso e pelo local onde as regras de uso do token são executadas.
Consequência: a verificação deve começar pelo progresso e pelas regras, e não pela presença de NFT.
«On-chain = totalmente descentralizado»
O on-chain pode ser usado de forma pontual: para ativos, mas não para progresso e regras de partida.
- Ativos on-chain não significam progresso on-chain.
- O modelo híbrido pode manter dependências críticas de servidores.
Consequência: a «fonte da verdade» para progresso e regras deve ser buscada no servidor ou no contrato.
«Fully on-chain não tem limitações»
O state do contrato permanece na rede, mas taxas, atrasos e acesso via infraestrutura de leitura afetam o UX.
- Taxas e confirmações limitam a frequência de ações on-chain.
- A disponibilidade de clientes, RPC e indexadores afeta a conveniência da leitura do state.
Consequência: é importante avaliar o número de ações on-chain e a disponibilidade de visualização do state sem um único frontend.
FAQ
O que é on-chain gaming?
Qual é a diferença entre jogos Web2 e Web3 em termos simples?
O que acontece com o NFT se o jogo fechar?
É possível jogar jogos Web3 sem carteira?
É possível сохранar o progresso sem servidores?
Por que ainda há poucos jogos fully on-chain?
Verificação final: on-chain vs Web2 por três sinais
A avaliação do modelo se resume a uma pergunta: onde está a «fonte da verdade» para o progresso e as regras.
- Progresso: o resultado da temporada e recompensas-chave são registrados no contrato ou permanecem no banco de dados do serviço.
- Regras: as transições de state são confirmadas pelo smart contract ou pela lógica do servidor.
- Risco de desligamento: quando o serviço desaparece, só permanecem os dados da rede e um acesso compatível a eles.
Se o progresso e as regras vivem no servidor, elementos on-chain permanecem como ativos, mas não preservam a «versão oficial» do jogo.