Ontem, sem nada para fazer, fui ver as notícias do círculo, e de repente vi que o número de usuários ativos diários do Pixels ultrapassou a marca de 153.000, e os jovens do grupo estavam todos tão empolgados, gritando que o mercado de touros chegou, vamos nos apressar, mas eu, que estou no círculo Web3 e lutando com códigos há quase dez anos, minha primeira reação não foi "Está muito quente, preciso entrar", mas sim minha cabeça instantaneamente zumbindo, surgindo uma pergunta técnica que atinge a alma — são dezenas de milhares de pessoas espalhadas por vários países ao redor do mundo, e os servidores de jogos estão configurados para transmitir o estado completo da fazenda a cada 100 milissegundos, pense bem, do nosso centro de dados em Singapura, como esse pacote de dados vai ser enviado para o celular ou computador dos jogadores no Brasil, na América do Sul, quantos milissegundos são desperdiçados nesse processo?
Quem já jogou aqueles jogos de fazenda Web2 tradicionais sabe que, mesmo com uma latência de 200 milissegundos, ao cortar uma árvore, a experiência é apenas ligeiramente atrasada, e ainda assim todos conseguem se divertir. Mas a Pixels não é um jogo tradicional — ela carrega o gene da blockchain, o que significa que cada vez que você colhe uma planta rara, isso precisa ser mintado como NFT na blockchain! Essa ‘janela de confirmação on-chain’ destrói completamente as contas econômicas que existiam antes com a simples sincronização de estados do servidor; hoje, vamos preparar um chá e discutir a arquitetura técnica por trás disso!
Primeiro obstáculo: a ilusão de 100 milissegundos e os limites físicos transoceânicos
Como de costume, vamos começar pela camada mais baixa da arquitetura técnica. Segundo a lógica de sincronização dos servidores de jogos predominantes no mercado, a Pixels, sendo um jogo de fazenda social mais casual, provavelmente utiliza o modelo de ‘sincronização de estado’ e não aquele rigoroso ‘frame sync’ — o que é sincronização de estado? Em resumo, é quando o servidor detém a única ‘verdade’ do mundo e tudo que os jogadores veem em seus clientes são os ‘resultados’ enviados pelo servidor, se o servidor diz que você plantou, então você realmente plantou; enquanto o frame sync, usado em e-sports, faz com que todos os clientes dos jogadores rodem uma cópia de cálculo completa, e desde que todos os comandos de operação sejam idênticos, o estado final do mundo será absolutamente consistente!
A escolha da Pixels por sincronização de estado é algo que dá para adivinhar até de olhos fechados, afinal, plantar uma cenoura não exige a precisão milimétrica de um DOTA, onde cada 16,67 milissegundos é crucial. Um intervalo de 100 milissegundos de transmissão é mais do que suficiente para vermos as plantações crescendo e os animais passeando no mapa!
Mas! O problema está exatamente nessa palavra ‘global’. Veja como a distribuição geográfica da latência no mundo físico é assustadora — se levarmos em conta que um nó em Cingapura pode ter apenas 20 milissegundos, enquanto os caras da costa oeste dos EUA enfrentam 80 milissegundos, e os jogadores europeus cerca de 120 milissegundos, já os da América do Sul podem chegar a 200 milissegundos ou mais! Ontem, enquanto olhava o globo na frente do computador, fiz uma conta: se a equipe da Pixels for realmente honesta e tiver servidores em três regiões-chave do mundo, como Cingapura na Ásia, Frankfurt na Europa e Virgínia nas Américas, com a qualidade de rede atual, conseguimos manter a latência entre 20 a 50 milissegundos nessa mesma região; mas uma vez que cruzamos regiões? Temos que lidar com a amarga latência física de 100 a 200 milissegundos! Isso significa que, se um jogador de Cingapura e um jogador do Brasil interagirem na mesma fazenda, o pacote de dados de sincronização de estado terá que viajar de Cingapura, atravessar o oceano até Virgínia, e depois ir até o Brasil, o que pode facilmente ultrapassar 300 milissegundos de latência!
Mas a transmissão de estado está programada para 100 milissegundos, o que é complicado. O ritmo de todo o servidor será arrastado pelo jogador com a conexão mais lenta. As opções para a equipe do projeto são limitadas: ou diminuem a frequência de transmissão, como para 200 milissegundos; ou forçam os jogadores mais rápidos a esperar pelos mais lentos. Claro, eles também podem optar por uma ‘divisão regional de servidores’, mas se fizerem isso, a tão almejada visão de ‘servidores globais’ do Web3 se tornará apenas uma tática de marketing enganosa!
Segundo obstáculo: Faça as contas sobre essa confusão de 150 mil conexões na ‘blockchain’
E ainda não acabou, o que é mais problemático é a latência invisível da blockchain, que é o verdadeiro gargalo! Veja, na abordagem atual da Pixels, eles colocam todos os estados de jogo de alta frequência e irrelevantes nos servidores centralizados off-chain, e só nos eventos críticos que envolvem dinheiro real, como mintar NFTs ou transferir tokens, os dados são ancorados na blockchain da Ronin! Todos sabemos que a Ronin foi projetada para jogos, com um tempo médio de confirmação de bloco de cerca de 3 segundos e taxas de transação em torno de 0,003 dólares, parece até atrativo, certo?
Mas não se esqueça, isso é comparativo. Se a Pixels tivesse corrido para a mainnet da ETH sem pensar, a cena seria de dar medo — mesmo que cada transmissão de estado fosse apenas jogar um hash na blockchain, com o tempo médio de confirmação de bloco de 12 segundos da ETH e taxas de Gas que chegam a 2 dólares, isso não é brincadeira; se estivesse na blockchain da BTC, seria ainda mais surreal, com confirmações levando dez minutos e taxas começando em 10 dólares! Irmão, pense bem, para um jogo que precisa de uma resposta em 100 milissegundos, dez minutos da BTC versus 12 segundos da ETH é como pedir uma entrega urgente e receber uma charrete vagarosa, é de enlouquecer! É por isso que, após todos esses anos, não conseguimos ver nem uma sombra de um “jogo completamente on-chain” que possa ser amplamente adotado; a infraestrutura subjacente simplesmente não permite isso!
Como um desenvolvedor veterano, não consigo conter a curiosidade e simulei um cenário extremo de teste de estresse: pense bem, se os 150 mil usuários ativos da Pixels estiverem online ao mesmo tempo, e cada um clicar uma vez por segundo, seja para mover um pouco, plantar uma semente ou regar, o servidor terá que lidar com um total de 150 mil operações por segundo! Se esse jogo realmente fosse ‘tudo on-chain’, isso significaria que a blockchain teria que processar 150 mil transações por segundo, ou seja, um TPS de 150 mil. Adivinha? A mainnet da ETH suporta no máximo cerca de 30 TPS, para rodar esse jogo precisaríamos aumentar a capacidade em 5000 vezes; a TPS da BTC é de cerca de 7, o que significa que precisaríamos de um aumento de mais de 20 mil vezes!
Portanto, a única solução viável para a Pixels não é uma escolha, mas sim um caminho obrigatório — servidores off-chain suportando cada uma das 150 mil operações de alta frequência por segundo, enquanto a blockchain lida tranquilamente com menos de um por cento dos eventos de ativos críticos, cerca de 1500 por segundo! Nesse contexto, o TPS de 20 da Ronin pode parecer apertado, mas com um pouco de tecnologia de empacotamento em lote, dá para usar; o TPS de 30 da ETH também é aceitável, mas considerando que os custos são 1000 vezes maiores, não precisa ser um gênio para saber qual escolher!
O terceiro obstáculo: essa maldita “sincronização otimista” e o vácuo das transações internacionais
Mas não se empolgue muito, pois há uma armadilha profunda escondida aqui — a latência de espera durante a sincronização global dos servidores off-chain! A Pixels deve manter a consistência do estado do jogo entre seus servidores nas três regiões globais, ou surgirão eventos absurdos: como eu, na Ásia, já ter colhido uma abóbora incrível, enquanto os jogadores na América ainda a veem crescendo no solo. Se os dados não coincidirem, o sistema econômico do jogo pode colapsar! Antigamente, em jogos Web2 tradicionais, conseguíamos resolver isso com replicação de banco de dados e processamento de fluxo de dados, mantendo a latência abaixo de 50 milissegundos sem problemas, mas a Pixels não pode fazer isso, pois está sob a espada da “confirmação de ativos na blockchain”! Qualquer alteração de estado que envolva ativos, como quando você encontra um item lendário, o servidor off-chain pode sincronizar em velocidade máxima, mas ainda assim terá que esperar os longos 3 segundos de confirmação da Ronin para que isso seja considerado finalizado!
Isso significa que a sincronização de estado entre servidores de diferentes regiões está sendo estrangulada por essa janela de confirmação de 3 segundos na blockchain. A prática comum na indústria é implementar um mecanismo de “sincronização otimista”: ou seja, o servidor assume que sua operação será bem-sucedida, faz o jogo rodar e, após 3 segundos, se descobrir que a transação na blockchain falhou ou ficou congestionada, o servidor reverte o estado do jogo! Para ser honesto, essa abordagem exige um conhecimento profundo na lógica de resolução de conflitos, pois, se mal feita, pode deixar os jogadores furiosos!
Falando nisso, há uma lógica central que ainda não consegui entender completamente — como eles garantem a segurança total nas transações de ativos entre regiões? Imagine a situação: um jogador veterano de Cingapura quer vender um terreno NFT valioso para um comprador no Brasil. No nível do servidor off-chain, isso é apenas uma questão de alterar algumas linhas de código, e o estado do terreno é instantaneamente transferido. Mas, na camada da blockchain, a verdadeira transferência de propriedade legal deve esperar os 3 segundos de confirmação de bloco da Ronin! Isso cria um vácuo extremamente perigoso — durante esses breves 3 segundos, o jogo já mostrará que o terreno pertence ao rapaz brasileiro, mas, ao consultar o explorador da blockchain, ainda aparecerá o nome do jogador de Cingapura!
Se, durante esses 3 segundos críticos, algum servidor central falhar ou a rede tiver uma enorme flutuação, há uma grande probabilidade de que esse estado seja perdido ou que surgem lógicas contraditórias! Veja, embora as transações da BTC sejam lentas como uma lesma e levem 10 minutos, uma vez que são confirmadas, são inalteráveis; a ETH pode levar 12 segundos, mas também é uma confirmação final! Apenas a Pixels, com essa confirmação de 3 segundos na blockchain, combinada com uma sincronização otimista off-chain, cria uma condição de ‘inconsistência temporária’ extremamente frágil, o que é arriscado para ativos financeiros como NFTs de terrenos, que podem facilmente envolver milhares de dólares!
Quarto obstáculo: os ‘teletransportes fantasmas’ no meio das oscilações de rede
Vamos aprofundar um pouco mais nas oscilações de rede e na perda de pacotes, seguindo os padrões de avaliação de latência reconhecidos na indústria de jogos online, 1 a 30 milissegundos é considerado extremamente rápido, 31 a 50 milissegundos é bom, 51 a 100 milissegundos é apenas jogável, e uma vez que ultrapassa 100 milissegundos, a única opção é dar uma avaliação negativa! A Pixels está agarrada a esse intervalo de 100 milissegundos, o que significa que se sua latência de rede subir um pouco acima de 100 milissegundos, você perderá sem dúvida um pacote de atualização de estado extremamente importante, e terá que esperar pelo próximo ciclo de 100 milissegundos para ‘salvar a situação’! Se sua rede for um pouco pior, com uma taxa de perda de 5%, isso significa que a cada 20 transmissões, você perderá 1, e na sua tela, verá jogadores ao lado “teleportando” de forma estranha ou seu movimento de cavar preso no ar!
Quando estávamos desenvolvendo jogos tradicionais, lidávamos com isso usando o protocolo UDP com um mecanismo de retransmissão, adicionando alguns algoritmos de compensação preditiva do cliente, e basicamente conseguíamos fazer os jogadores não perceberem. Mas a Pixels não pode fazer isso, pois está amarrada à validação da blockchain. Uma vez que a previsão da ação do cliente está errada, não dá para simplesmente sobrescrever com novos dados como antes. Temos que seguir um processo extremamente complicado e caro de reversão na blockchain, um custo que o projeto simplesmente não pode arcar!
O limite e a avaliação final do veterano
Portanto, agora, o que eu, como veterano, estou mais de olho não são os gráficos de tokens decorativos, mas se a Pixels terá coragem de divulgar seu mapa de distribuição global de servidores e painel de monitoramento de latência em tempo real! Se eles realmente investirem pesado, implantando servidores de borda de alta qualidade em pontos-chave na América do Norte, Europa e Ásia, e garantirem que a maioria dos jogadores tenha latência abaixo de 100 milissegundos, então eu realmente teria que aplaudir essa arquitetura como impressionante e madura; mas se ao investigar descobrirmos que eles estão economizando dinheiro e apenas sustentando um único data center em Cingapura, enquanto os jogadores da Europa e dos EUA enfrentam latências de mais de 200 milissegundos, então essa “grande ecologia de servidores globais” será apenas uma conversa fiada para enganar investidores! Além disso, a estabilidade do tempo de bloco da Ronin é crucial — se a blockchain parecer boa, mas durante os picos de mineração, a rede travar, fazendo o tempo de bloco subir de 3 segundos para 10 segundos ou mais, isso destruirá todas as suposições técnicas que permitem a sincronização suave do estado off-chain, e todo o ciclo econômico do jogo poderá travar!
No fim das contas, se você descascar essa camada técnica, verá que o intervalo de 100 milissegundos para a transmissão de estado é, na essência, um compromisso forçado entre a experiência do jogador e os altos custos de infraestrutura dos servidores! Se o intervalo fosse reduzido para 50 milissegundos, seria mais fluido, mas a equipe do projeto teria que alugar mais servidores de ponta e comprar conexões internacionais mais caras, o que poderia quebrar o projeto em minutos; mas se aumentasse para 200 milissegundos, os jogadores sentiriam que o jogo é extremamente ‘desconectado’, lento como um produto inacabado! Estou pensando que esse número mágico de 100 milissegundos é, sem dúvida, o ponto de inflexão que a equipe calculou dia e noite. Afinal, estamos jogando um jogo de agricultura, não um FPS onde cada milissegundo conta. 100 milissegundos já é suficiente para que a animação da cenoura crescendo pareça suave e natural; mas não é um jogo de turnos onde você pode tolerar segundos de latência! Buscar esse ponto de equilíbrio é como a escolha do Bitcoin por uma confirmação de 10 minutos para garantir segurança, enquanto a Ethereum optou por 12 segundos para maximizar a usabilidade, todas essas decisões refletem os trade-offs dos melhores arquitetos de design!
Minha conclusão inicial, depois de fazer contas até tarde, é que a distribuição global da latência dos 150 mil jogadores na Pixels é, na maioria das vezes, de 20 milissegundos para os jogadores da Ásia, até mais de 200 milissegundos para os da América do Sul, e o intervalo mediano gira em torno de 80 a 120 milissegundos. Para ser justo, esse nível de latência na rede pode ser tolerável para joguinhos casuais de plantar e colher, mas se o jogo decidir se tornar ambicioso e adotar interações em tempo real e trocas rápidas entre jogadores, ou até mesmo atividades PVP com movimentação, essa latência será um desastre! A raiz de todos esses problemas é, na verdade, a inevitável latência de confirmação da blockchain e a demanda por interações em tempo real dos jogos, que criam um abismo intransponível. Enquanto esse nó não for desfeito, não podemos relaxar; estou sempre de olho nessa conta técnica, então vamos focar menos em promessas e mais em dados reais de latência!
\u003cc-52/\u003e\u003cc-53/\u003e\u003cm-54/\u003e\u003ct-55/\u003e
