Mundos Autônomos (AWs) enfrentam o mesmo trilema. Os AWs precisam da capacidade de escalar para milhões de jogadores simultâneos, este é um problema difícil de resolver.

Rollups resolvem parcialmente o trilema, convertendo-o em um dilema, graças à herança da segurança da camada de liquidação - desde que haja 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 disponibilidade de dados alternativos (DA alt) ou DA plasma para alcançar escalabilidade. No entanto, com um ZK Rollup, você pode comprovar a integridade do estado com pressupostos mínimos de confiança, visando resolver os três desafios: escalabilidade, segurança e descentralização. Zk é o objetivo final.

Donkey Kong com integridade - de onchain para comprovável e de volta

Os jogos Onchain prometem-nos liberdade de expressão e soberania sobre as nossas informações. Eles possuem essas propriedades porque funcionam em uma blockchain verificada por consenso.Jogos comprováveis, usando zk proofs, permitem a verificação do estado do jogo e cálculos sem grandes esquemas de consenso. Escrito em linguagens como Cairo, Noirou executandoRISC-Zero, esses jogos podem operar de forma independente em um zkVM isolado como um navegador, com saídas verificáveis garantindo 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 reconhecida no quadro de líderes, você deve jogar em uma máquina certificada para evitar trapaças, enquanto registra sua jogabilidade. No entanto, se Donkey Kong fosse um jogo comprovável, os jogadores poderiam competir em isolamento. Alcançar uma alta pontuação simplesmente exigiria enviar uma prova para a organização Donkey Kong para verificação. Este método permite que os jogadores se estabeleçam como o Rei do Kong no conforto de sua casa, sem a necessidade de gravar sua jogabilidade!

Executar jogos completos dentro de zkVMs isolados é atualmente desafiador. Para lidar com isso, o ecossistema Dojo está trabalhando para simplificar o processo, minimizando a complexidade. Equipes como Tonk estão avançando na arena de jogos prováveis, com um feito notável sendo a execução de Doomem um zkVM, anunciando "Doom Probabilístico". À medida que os custos de prova diminuem e novos provadores, como Stwo, torna-se disponível, o potencial para projetar jogos e aplicativos comprováveis se expande.

Não precisamos necessariamente operar nossos jogos comprováveis dentro de um zkVM isolado para aproveitar seus atributos comprováveis. Em vez disso, podemos executar nossos jogos em redes mini-StarkNet com um número mínimo de participantes e ainda assim obter segurança garantida.

É importante notar que a abordagem não é binária. Por exemplo, você poderia operar um jogo onchain em um EVM e depois adicionar um jogo baseado em Cairo por cima, aprimorando o jogo principal enquanto amplia suas capacidades.

Por que se preocupar com jogos comprováveis?

Imagine se o mundo do RuneScape de repente desligasse, apagando para sempre as estatísticas de jogo de todos. Haveria alguns jogadores furiosos. Este cenário certamente ocorrerá em algum momento quando os desenvolvedores decidirem fechar os servidores. Podemos fazer melhor? Podemos criar um mundo tão rico, diversificado e intenso quanto o RuneScape que esteja livre de que isso aconteça?

Este 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. Numerosas equipes estão explorando várias abordagens, que é exatamente o tipo de inovação e experimentação necessária.

Muita inovação está sendo investida em jogos onchain, mas nosso foco está em explorar a árvore de tecnologia de jogo comprovável 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.

Inspirado a escrever isso após o lendário discurso de Chad Kooshobas, Skystrife, em Eth Istanbul

Goblins Prováveis

Vamos construir um mundo onde possamos provar que os goblins existem e usar RuneScape como exemplo, vamos nos concentrar na zona inicial do jogo, Lumbridge, e seus arredores para explorar:

• Castelo de Lumbridge
• Florestas de Madeira
• Goblins
• Itens do Inventário

Para Goblins comprováveis precisamos:

• Simular movimentos dinâmicos de duendes e criaturas para um mundo de jogo animado.
• Ativar atualizações de inventário em tempo real quando os jogadores pegam itens.
• Rastreie e salve a progressão do jogador globalmente para uma jogabilidade consistente.
• Desenvolver mecânicas para evitar exploração, garantindo a integridade do jogo.
• Suporte de escalabilidade para milhões de jogadores concorrentes.

Escalando Jogos Tradicionais Modernos

O desenvolvimento tradicional de jogos depende de servidores centralizados para funções essenciais como progressão, comportamento de NPCs, gerenciamento de 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 de 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, a indústria de jogos onchain foi criada - para poder ter um RuneScape sem confiança...

O Modo Tradicional de Blockchain

Ao tentar replicar a funcionalidade de um servidor centralizado usando uma abordagem de blockchain tradicional, embora 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

Transações, ou ações de jogador, devem ser verificadas e processadas por vários nós em toda a rede. Embora este método garanta segurança replicando o processamento e usando 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, é claro que isso pode ser evitado usando um único sequenciador central (como praticamente todos os L2), no entanto, mais pressupostos de confiança.

Transações Por Segundo

O limite de TPS em uma VM de blockchain restringe a capacidade de um jogo de processar as ações dos jogadores. À medida que o número de jogadores e suas ações excede a capacidade de TPS da blockchain, uma fila se forma, levando a picos nas taxas e a 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 focou em um roadmap centrado no rollup, 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 e potencialmente frágeis suposições de confiança, o que introduz riscos. Assim, zk é considerado a solução final para escalabilidade, embora ainda não tenha sido totalmente realizada.

Assunção de confiança das camadas ZK em comparação com as camadas OP. A suposição ZK permanece forte com um baixo nível de participação, permitindo a existência de mini rollups zk.

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 buscando criar sistemas sem confiança, qual é o ponto de nossos esforços? Poderíamos muito bem depender de servidores centrais, que se destacam em suas funções.

Em nosso mundo RuneScape, estaremos focando na escalabilidade recursiva, pioneira usando STARKs.Tarrenceescreveu umpeça detalhada 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.

Em nosso mundo, podemos alavancar provas recursivas para dimensionar e fragmentar o mundo, garantindo que o goblin que alguém derrota seja de fato um goblin.

Um diagrama grosseiro:

Vamos analisar isso.

L1 Ethereum

Nós resolvemos o estado final aqui, para que qualquer pessoa possa reconstruir o L2 se escolher. Isso é o que todo rollup verdadeiro faz.

L2 Starknet

Nós resolvemos o estado L3 aqui, então qualquer pessoa pode reconstruir o L3 se escolherem. É aqui que mantemos um estado de todo o mundo.

L3 Reinos Mundo ou Outros L3

A camada de execução de alto desempenho que suporta o estado global para os jogadores. Salvamos o estado final dos fragmentos de Lumbridge aqui. Isso permite que novos fragmentos sejam criados rapidamente quando necessário, restaurando os saldos dos jogadores.

Fragmentos Efêmeros de Lumbridge

"Efêmero" significa temporário, enfatizando a importância de gerenciar de forma eficiente e segura o estado de jogo de cada jogador - uma preocupação primordial para todos os jogadores. Ao adotar o chain sharding 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 um aprimoramento 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 qualquer desempenho para o jogador.

Aplicando este método ao 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 vários fragmentos menores, permitimos que o sistema escale e acomode milhões de usuários simultâneos de forma eficaz.

A diferença fundamental 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 caminhar no exemplo:

Quando os jogadores chegam em Lumbridge, eles são alocados para uma cadeia efêmera que tem capacidade, facilitando interações com até 29 outros jogadores, garantindo alto desempenho por meio de transações rápidas e de baixo custo. Agora mais profundo:

• 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 a potência de computação barata que esse fragmento permite. Eles podem então proceder a cortar lenha, adicionando-a ao seu saldo e avançando seu jogador.

• Goblins and other low-level monsters

Goblins poderiam ser efetivamente simulados por um tick de jogo integrado no sequenciador. Quando o jogo avança, o sequenciador avança o estado e a localização deles até que um usuário apareça e eles sejam mortos. Poderíamos ocupar uma quantidade significativa da largura de banda de shards com isso se escolhermos, já que estamos limitando a quantidade de jogadores, podemos maximizar os movimentos de NPC.

• Vários itens espalhados ao redor ou deixados por monstros

Os itens podem ser coletados e armazenados no saldo do jogador. Quando o jogador encerra a 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

Ao final da sessão de jogo, os estados dos jogadores são preservados em um estado global ao fazer a transição de volta para L3, preparando o cenário para a próxima zona ou sessão. Isso é então verificado no StarkNet L2 e posteriormente verificado no L1, estabelecendo efetivamente um RuneScape provavelmente justo. Agora, o próximo passo é concretizar essa visão…

O stack completo que estamos construindo é de código aberto - junte-se ao sala de prática Gateou contribuir para o núcleodiretamente.

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 esse problema que já está sendo utilizada no ecossistema Starknet e em breve estará disponível em outros Layer 2s. Estes são chamados Provas de Armazenamento. Sim, estou incorporando meu próprio tweet. A parte 2 discutirá isso.

https://twitter.com/lordOfAFew/status/1762796441494520267

Por que Provas recursivas e Cadeias efêmeras em vez de outros métodos?

Para esclarecer, esta é a abordagem que o Dojo, Cartridge e o ecossistema Realms estão adotando para dimensionar o mundo que imaginamos. É importante notar que esta não é a única forma, e explorar uma variedade de abordagens é benéfico. Algumas das mentes mais brilhantes que conheço também estão enfrentando os problemas mais desafiadores neste espaço, e seu trabalho definitivamente vale a pena conferir.

• Lattice - O OP Plasma com Redstone permite transações muito baratas.
• Playmint- Motor Otimista Único para jogabilidade rápida
• PoP- Fragmentação EVM personalizada
• Argus- Fragmentos de jogo EVM personalizados
• Curio- Abordagem modificada do servidor EVM

Um tempo para retornar ao Runescape

Criar um RuneScape gratuito e aberto capaz de suportar milhões de jogadores simultâneos não é uma tarefa pequena. No entanto, a inteligência e criatividade coletivas 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-24 meses. É hora de voltar ao RuneScape, ou talvez mais apropriadamente, dar as boas-vindas ao amanhecer do RealmScape. ;)

Aviso Legal：

1. Este artigo é reimpresso de [Gate@lordofafew], Todos os direitos autorais pertencem ao autor original [@lordofafew]. Se houver objeções a este reenvio, entre em contato com o Gate Learnequipe e eles vão lidar com isso prontamente.
2. Aviso de responsabilidade: As opiniões expressas 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. Salvo indicação em contrário, é proibido copiar, distribuir ou plagiar os artigos traduzidos.