Um jogo como @RuneScape pode em breve rodar onchain?

Conteúdo escrito originalmente por @lordOfAFew

Todos aspiramos a um mundo autônomo, livre de corrupção, malícia e desprezo; um mundo que seja persistente, eterno e autônomo.
Como conseguimos isso? Assim como no trilema da blockchain, sempre haverá um nível de compromisso necessário nessas empreitadas.

Mundos Autônomos (AWs) enfrentam o mesmo trilema. Os AWs precisam da capacidade de escalar para milhões de jogadores simultâneos, o que é um problema difícil de resolver.
Os Rollups resolvem parcialmente o trilema ao convertê-lo em um dilema, graças à herança da segurança da camada de liquidação—contanto que existam ativos nativos da Camada 1 (L1) e saídas sem permissão.

Com um rollup otimista, você precisa escolher entre escalabilidade e segurança, razão pela qual algumas abordagens de rollup comprometem a segurança ao usar alternativas de disponibilidade de dados (alt DA) ou plasma DA para alcançar escalabilidade. Entretanto, com um ZK Rollup, você pode provar a integridade do estado com suposições de confiança mínimas, visando abordar os três desafios: escalabilidade, segurança e descentralização. Zk é o objetivo final.

Donkey Kong com integridade - do onchain ao provável e de volta
Jogos onchain nos prometem liberdade de expressão e soberania sobre nossas informações. Eles possuem essas propriedades porque rodam em uma blockchain verificada por consenso. Jogos prováveis, usando provas zk, permitem a verificação do estado do jogo e cálculos sem grandes esquemas de consenso. Escritos em linguagens como Cairo, Noir ou rodando RISC-Zero, esses jogos podem operar de forma independente em uma zkVM isolada como um navegador, com saídas verificáveis que garantem uma execução verdadeira. Isso amplia nossas possibilidades na indústria de jogos onchain.

Um exemplo ilustrativo é um jogo como Donkey Kong. Atualmente, para ter sua pontuação alta reconhecida no ranking, você deve jogar em uma máquina certificada para evitar trapaças, enquanto grava sua jogabilidade. No entanto, se Donkey Kong fosse um jogo provável, os jogadores poderiam competir em isolamento. Conseguir uma pontuação alta exigiria simplesmente enviar uma prova à organização Donkey Kong para verificação. Esse método permite que os jogadores se estabeleçam como o Rei do Kong do conforto de suas casas, sem a necessidade de gravar sua jogabilidade!
Rodar jogos completos dentro de zkVMs isoladas é atualmente desafiador. Para resolver isso, o ecossistema Dojo está trabalhando para simplificar o processo, minimizando a complexidade. Equipes como a Tonk estão avançando na arena de jogos prováveis, com uma conquista notável sendo a execução de Doom em uma zkVM, anunciando "Provable Doom." À medida que os custos de prova diminuem e novos provedores, como Stwo, se tornam disponíveis, o potencial para projetar jogos e aplicações prováveis se amplia.

Não precisamos necessariamente operar nossos jogos prováveis dentro de uma zkVM isolada para nos beneficiar de seus atributos prováveis. Em vez disso, podemos rodar nossos jogos em redes mini-StarkNet com um número mínimo de participantes e ainda garantir segurança.
É importante notar que a abordagem não é binária. Por exemplo, você poderia operar um jogo onchain em uma EVM e depois sobrepor um jogo baseado em Cairo, melhorando o jogo principal enquanto amplia suas capacidades.

Por que se preocupar com jogos prováveis?
Imagine se o mundo de RuneScape de repente fechasse, apagando para sempre as estatísticas de jogo de todos. Haveria alguns gamers furiosos. Esse cenário está destinado a ocorrer em algum momento quando os desenvolvedores decidirem fechar os servidores. Podemos fazer melhor? Podemos criar um mundo tão rico, diverso e intenso quanto RuneScape que seja livre de que isso aconteça?

Esse desafio é o que toda a cena de jogos onchain está atualmente se esforçando para resolver: criar um mundo que seja persistente, eterno e autônomo. Várias equipes estão explorando diversas abordagens, que é exatamente o tipo de inovação e experimentação necessárias.

Muita inovação está sendo investida em jogos onchain, mas nosso foco está em explorar a árvore de tecnologia de jogos prováveis usando Cairo e Starknet VM.Este artigo tem como objetivo traduzir alguns conceitos de jogos comprováveis em um exemplo prático, inspirado no lendário jogo RuneScape.

Goblins Comprováveis
Vamos construir um mundo onde podemos provar que goblins existem e usaremos RuneScape como exemplo. Focaremos na zona inicial do jogo, Lumbridge, e seus arredores para explorar:
- Castelo de Lumbridge
- Florestas Arborizadas
- Goblins
- Itens de Inventário

Para Goblins Comprováveis, precisamos:
- Simular movimentos dinâmicos de goblins e criaturas para um mundo de jogo vibrante.
- Habilitar atualizações de inventário em tempo real quando os jogadores pegam itens.
- Rastrear e salvar o progresso dos jogadores globalmente para uma jogabilidade consistente.
- Projetar mecânicas para prevenir exploração, garantindo a integridade do jogo.
- Suportar escalabilidade para milhões de jogadores simultâneos.

Escalando Jogos Tradicionais Modernos
O desenvolvimento de jogos tradicionais depende de servidores centralizados para funções essenciais como progresso, comportamento de NPCs, gerenciamento do estado do jogador, controle de itens e aplicação de regras. Para escalar, mais servidores são adicionados, e o estado do jogo é dividido (sharding), permitindo instâncias separadas de áreas do jogo para diferentes grupos de jogadores. Embora seja uma solução de escalonamento eficaz, essa centralização significa que os desenvolvedores têm controle total, incluindo a capacidade de desligar servidores. É por isso que a indústria de jogos on-chain foi criada - para poder ter um RuneScape sem confiança...

A Maneira Tradicional de Blockchain
Ao tentar replicar a funcionalidade de um servidor centralizado usando uma abordagem tradicional de blockchain, embora seja teoricamente viável, torna-se impraticável e quase impossível escalar além de alguns milhares de usuários simultâneos devido a várias limitações:

Validação de Transações
As transações, ou ações dos jogadores, devem ser verificadas e processadas por múltiplos nós na rede. Embora esse método garanta segurança ao replicar o processamento e usar consenso para tornar mais difícil comprometer o sistema, também introduz um gargalo significativo em termos de velocidade de processamento de transações - ou seja, TPS. Agora, isso, é claro, pode ser contornado usando um sequenciador central único (como praticamente todos os L2), no entanto - mais suposições de confiança.

Transações Por Segundo
O limite de TPS em uma VM de blockchain restringe a capacidade de um jogo de processar ações de jogadores. À medida que o número de jogadores e suas ações excedem a capacidade de TPS da blockchain, forma-se um backlog, levando a picos nas taxas e uma deterioração na experiência do jogador. Isso efetivamente limita o número de jogadores simultâneos que um único sequenciador de blockchain pode gerenciar. Para superar essas limitações, o Ethereum se concentrou em um roteiro centrado em rollups, movendo a execução para a camada de rollup.
Operar nosso mundo em um rollup pode aumentar significativamente a escalabilidade, mas sem zk Proofs, ainda dependemos de grandes mecanismos de consenso ou amplas suposições de confiança potencialmente instáveis, que introduzem riscos. Assim, zk é considerado a solução definitiva para escalonamento, embora ainda não tenha sido totalmente realizado.
A suposição de confiança de camadas ZK em comparação com camadas OP. A suposição ZK permanece forte com um baixo nível de participação, permitindo que mini zk rollups existam.

Uma Maneira Comprovável - Usando Provas Recursivas e Múltiplas Camadas
O objetivo de qualquer blockchain é permitir que os usuários tenham confiança absoluta em suas ações. Este princípio é frequentemente esquecido na indústria; se não estamos tentando criar sistemas sem confiança, qual é o objetivo de nossos esforços? Poderíamos muito bem confiar em servidores centrais, que se destacam em suas funções.
No nosso mundo de RuneScape, estaremos focando em escalonamento recursivo, pioneiro usando STARKs. Tarrence escreveu um artigo aprofundado sobre este tópico, destacando a importância das provas recursivas na manutenção de suposições mínimas de confiança na Camada 2, Camada 3.

No nosso mundo, podemos aproveitar as provas recursivas para escalar e dividir o mundo, garantindo que o goblin que qualquer um derrota seja de fato um goblin.
Um diagrama rudimentar:

Vamos detalhar isso.

L1 Ethereum
Nós estabelecemos o estado final aqui, para que qualquer um possa reconstruir o L2 se assim desejar. Isso é o que todo verdadeiro rollup faz.

L2 Starknet
Nós estabelecemos o estado L3 aqui, para que qualquer um possa reconstruir o L3 se assim desejar. Aqui é onde mantemos um estado do mundo inteiro.

L3 Realms World ou Outro L3
A camada de execução de alto desempenho que suporta o estado global para os jogadores. Nós salvamos o estado final dos Lumbridge Shards aqui. Isso permite que novos shards sejam criados rapidamente quando necessário, restaurando os saldos dos jogadores.

Shards Efêmeros de Lumbridge
"Efêmero" significa temporário, enfatizando a importância de gerenciar de forma eficiente e segura o estado do jogo de cada jogador - uma preocupação primordial para todos os jogadores. Ao adotar o sharding em cadeia para limitar cada shard a um máximo de 30 jogadores - um número teórico que poderia ser maior, mas serve como um exemplo gerenciável - espelhamos a estrutura dos servidores tradicionais com uma melhoria crucial: a utilização de zk proofs para garantir a integridade das mudanças de estado. Isso nos permite escalar horizontalmente para milhares de shards, sem sacrificar o desempenho para o jogador.

Aplicando esse método a RuneScape
Assim como o conceito de escalonamento horizontal em servidores de jogos tradicionais, estamos aplicando uma estratégia semelhante aqui. Ao dividir o mundo do jogo em numerosos shards menores, habilitamos o sistema a escalar e acomodar milhões de usuários simultâneos de forma eficaz.

A principal diferença entre servidores de jogos tradicionais e essa abordagem é que os jogadores mantêm controle total sobre seu estado de jogo, garantindo maior autonomia e segurança. Cada bit de estado pode ser reconstruído!

Vamos ilustrar com um exemplo:
Quando os jogadores chegam a Lumbridge, eles são alocados a uma cadeia efêmera que tem capacidade, facilitando interações com até 29 outros jogadores enquanto garante alto desempenho por meio de transações rápidas e de baixo custo. Agora, vamos aprofundar:

Florestas, com recursos como madeira
Com essa cadeia efêmera, os movimentos dos jogadores podem ser rastreados enquanto viajam para a floresta, impondo um nível de física de movimento; fazemos isso com o poder computacional barato que esse shard permite. Eles podem então proceder a cortar madeira, adicionando-a ao seu saldo e avançando seu personagem.

Goblins e outros monstros de baixo nível
Goblins poderiam ser efetivamente simulados por um tick de jogo embutido no sequenciador. Quando o jogo avança, o sequenciador atualiza o estado e sua localização até que um usuário apareça e eles sejam eliminados. Poderíamos aproveitar uma quantidade significativa da largura de banda dos shards nisso, se assim desejarmos, uma vez que estamos limitando a quantidade de jogadores, podemos maximizar os movimentos dos NPCs.

Vários itens espalhados ou deixados por monstros
Itens podem ser coletados e armazenados no saldo de um jogador. Quando o jogador encerra sua sessão, esses itens serão salvos no estado global. Esses valores não são efêmeros e são salvos no L3 para uso na próxima sessão.

Encerrando a Sessão
Na conclusão de sua sessão de jogo, os estados dos jogadores são preservados em um estado global ao retornar ao L3, preparando o palco para sua próxima zona ou sessão. Isso é então verificado no StarkNet L2 e, posteriormente, verificado no L1, estabelecendo efetivamente um RuneScape comprovadamente justo. Agora, o próximo passo é materializar essa visão…
Todo o stack que estamos construindo é de código aberto - junte-se ao dojo discord ou contribua ao núcleo diretamente.

E quanto à ponte entre essas camadas? Isso não será um pesadelo para os jogadores?
Sim, a ponte é problemática no momento. No entanto, há uma solução clara para essa questão que já está sendo utilizada no ecossistema Starknet e em breve estará disponível em outras Layer 2s. Essas são chamadas de Storage Proofs.

Por que Proofs recursivos e Chains efêmeras em vez de outros métodos?
Para esclarecer, essa é a abordagem que Dojo, Cartridge e o ecossistema Realms estão adotando para escalar o mundo que imaginamos. É importante notar que este não é o único método, e explorar uma variedade de abordagens é benéfico.Algumas das mentes mais brilhantes também estão abordando os problemas mais desafiadores neste espaço, e seu trabalho definitivamente vale a pena conferir.
Lattice - OP Plasma com Redstone permite transações muito baratas.
Playmint - Motor Otimista Único para jogabilidade rápida
PoP - Sharding EVM sob medida
Argus - Shards de jogo EVM personalizados
Curio - Abordagem de servidor EVM modificada

É hora de retornar ao Runescape
Criar um RuneScape livre e aberto capaz de suportar milhões de jogadores simultâneos não é uma tarefa pequena. No entanto, a inteligência coletiva e a criatividade da indústria de jogos onchain são forças formidáveis. Portanto, é razoável antecipar o surgimento de jogos como este e outros nos próximos 12 a 24 meses.

Link do artigo: https://t.co/xoozUyhOcq