Mundos Autónomos (AWs) enfrentam o mesmo trilema. Os AWs precisam da capacidade de escalar para milhões de jogadores concorrentes, este é 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 - desde que existam ativos nativos da Camada 1 (L1) e saídas sem permissão.

Com um rollup otimista, precisa de optar entre escalabilidade e segurança, razão pela qual algumas abordagens de rollup comprometem a segurança ao usar disponibilidade de dados alternativa (DA alt) ou plasma DA para alcançar a escalabilidade. No entanto, com um ZK Rollup, 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 jogo 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 a nossa informação. Possuem estas propriedades porque funcionam numa blockchain verificada por consenso.Jogos comprováveis, usando provas zk, permitem a verificação do estado do jogo e cálculos sem grandes esquemas de consenso. Escrito em idiomas como Cairo, Noirou correrRISC-Zero, estes jogos podem operar de forma independente num zkVM isolado como um navegador, com saídas verificáveis que garantem uma execução verdadeira. Isto amplia as nossas possibilidades na indústria de jogos onchain.

Um exemplo ilustrativo é um jogo como Donkey Kong. Atualmente, para que o seu recorde seja reconhecido no quadro de líderes, tem de jogar numa máquina certificada para prevenir a batota, enquanto grava o seu jogo. No entanto, se Donkey Kong fosse um jogo provável, os jogadores poderiam competir em isolamento. Alcançar um recorde alto apenas exigiria submeter uma prova à organização Donkey Kong para verificação. Este método permite aos jogadores estabelecerem-se como o Rei do Kong a partir do conforto de sua casa, sem necessidade de gravar o seu jogo!

Executar jogos completos dentro de zkVMs isolados é atualmente desafiador. Para resolver isso, o ecossistema Dojo está a trabalhar para simplificar o processo, minimizando a complexidade. Equipas como Tonkestão a avançar no campo do jogo provável, com uma conquista notável sendo a execução de Doomnum zkVM, anunciando "Provable Doom." À medida que os custos de prova diminuem e novos provadores, como Stwo, ao tornar-se disponível, o potencial para projetar jogos e aplicações comprováveis aumenta.

Não precisamos necessariamente de operar os nossos jogos comprováveis dentro de um zkVM isolado para beneficiar das suas características comprováveis. Em vez disso, podemos executar os nossos jogos em redes mini-StarkNet com um número mínimo de participantes e ainda assim alcançar 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, melhorando o jogo principal e ampliando suas capacidades.

Por que se incomodar com jogos comprováveis?

Imagina se o mundo do RuneScape fechasse repentinamente, apagando para sempre as estatísticas de jogo de todos. Haveria alguns jogadores furiosos. Este 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, diversificado e intenso como o RuneScape, livre deste acontecimento?

Este desafio é o que toda a cena de jogos onchain está atualmente a tentar resolver: criar um mundo que seja persistente, eterno e autónomo. Inúmeras equipas estão a explorar 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 jogos comprováveis usando Cairo e Starknet VM. Este artigo tem como objetivo traduzir alguns conceitos de jogos comprováveis em um exemplo prático, inspirado pelo lendário jogo RuneScape.

Inspirado a escrever isto após o discurso lendário de Skystrife chad Kooshobas em Eth Istanbul

Goblins prováveis

Vamos construir um mundo onde possamos provar que os duendes existem e usemos RuneScape como exemplo, vamos focar na zona inicial do jogo, Lumbridge, e seus arredores para explorar:

• Castelo de Lumbridge
• Florestas de Madeira
• Goblins
• Itens de inventário

Para Goblins comprováveis precisamos de:

• 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.
• Acompanhe e salve a progressão do jogador globalmente para uma jogabilidade consistente.
• Desenhar mecânicas para evitar a exploração, garantindo a integridade do jogo.
• Suportar 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 NPC, gestão de estado do jogador, controlo de itens e aplicação de regras. Para escalar, são adicionados mais servidores, 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 escalabilidade eficaz, esta centralização significa que os programadores têm controlo absoluto, incluindo a capacidade de encerrar servidores. É por isso que a indústria de jogos onchain foi criada - para poder ter um RuneScape sem confiança...

O Modo Tradicional da 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

As transações, ou ações do jogador, devem ser verificadas e processadas por vários nós em toda a rede. Embora este método garanta segurança ao replicar o processamento e usar consenso para dificultar a comprometimento do sistema, também introduz uma significativa restrição em termos de velocidade de processamento de transações - ou seja, TPS. Agora, é claro que isso pode ser contornado usando um sequenciador central único (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 processar as ações dos jogadores. À medida que o número de jogadores e suas ações excedem a capacidade de TPS da blockchain, uma fila se forma, levando a picos nas taxas e a uma experiência de jogador deteriorada. 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 concentrou-se 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 suposições de confiança potencialmente frágeis, o que introduz riscos. Assim, zk é considerado a solução definitiva para escalabilidade, embora ainda não tenha sido totalmente realizada.

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

Uma Forma Comprovada - 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 muitas vezes é esquecido na indústria; se não buscamos criar sistemas sem confiança, qual é o ponto de nossos esforços? Podemos muito bem depender de servidores centrais, que se destacam em suas funções.

No nosso mundo do RuneScape, iremos focar-nos na escalabilidade recursiva, pioneirizada utilizando STARKs.Tarrenceescreveu umpeça aprofundada sobre este tópico, destacando a importância das provas recursivas na manutenção de pressupostos mínimos de confiança na Camada 2, Camada 3.

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

Um diagrama rudimentar:

Vamos analisar isto.

L1 Ethereum

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

L2 Starknet

Nós resolvemos o estado L3 aqui, então qualquer pessoa pode reconstruir o L3 se assim o desejar. É aqui que mantemos um estado do mundo inteiro.

Mundos Reais L3 ou Outros L3

A camada de execução de alto desempenho suporta o estado global para os jogadores. Salvamos o estado final dos Lumbridge Shards aqui. Isso permite que novos shards 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 gerir de forma eficiente e segura o estado de jogo de cada jogador - uma preocupação crucial para todos os jogadores. Ao adotar a fragmentação de cadeias para limitar cada fragmento a um máximo de 30 jogadores - um número teórico que poderia ser maior mas que serve como um exemplo gerível - espelhamos a estrutura dos servidores tradicionais com um aprimoramento crucial: a utilização de provas zk para garantir a integridade das alterações de estado. Isso nos permite escalar horizontalmente para milhares de fragmentos, sem sacrificar qualquer desempenho para o jogador.

Aplicar este método ao RuneScape

Assim como o conceito de escalonamento horizontal nos servidores de jogos tradicionais, estamos a aplicar 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 utilizadores simultâneos de forma eficaz.

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

Vamos analisar no exemplo:

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

• Florestas, com recursos como madeira

Com esta cadeia efémera, os movimentos dos jogadores podem ser rastreados à medida que viajam para a floresta, impondo um nível de física do movimento, fazemos isso com o poder de computação barato que este fragmento permite. Eles podem então proceder ao corte de madeira, adicionando-a ao seu saldo e avançando o seu jogador.

• Goblins e outros monstros de baixo nível

Os goblins poderiam ser eficazmente simulados por um tick de jogo incorporado no sequenciador. Quando o jogo avança, o sequenciador avança o estado e a sua localização até que um utilizador apareça e sejam mortos. Poderíamos consumir uma quantidade significativa da largura de banda dos fragmentos com isto, se escolhermos, uma vez que estamos a limitar a quantidade de jogadores, podemos maximizar os movimentos dos NPCs.

• Vários itens espalhados ou deixados por monstros

Os itens podem ser recolhidos e armazenados no saldo do jogador. Quando o jogador termina a sessão, esses itens serão guardados no estado global. Estes valores não são efémeros e são guardados no L3 para utilização na próxima sessão.

Terminar a Sessão

No final da sua sessão de jogo, os estados dos jogadores são preservados num estado global ao fazer a transição de volta para L3, preparando o cenário para a próxima zona ou sessão. Isto é então verificado no StarkNet L2 e subsequentemente verificado no L1, estabelecendo eficazmente um RuneScape provavelmente justo. Agora, o próximo passo é concretizar esta visão...

O stack completo que estamos a construir é open source - junta-te ao dojo discordou contribuir para o núcleodiretamente.

E que tal fazer a ponte entre estas camadas? Não será um pesadelo para os jogadores.

Sim, a ponte é problemática no momento. No entanto, existe uma solução clara para este problema que já está a ser utilizada no ecossistema da Starknet e em breve estará disponível noutras Camadas 2. Estas são chamadas Provas de armazenamento. Sim, estou a incorporar o meu próprio tweet. A parte 2 irá discutir isto.

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

Por que Provas Recursivas e Cadeias Efêmeras em relação a outros métodos?

Para esclarecer, esta é a abordagem que o Dojo, Cartridge e o ecossistema Realms estão a adotar 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 que conheço também estão a abordar os problemas mais desafiantes neste espaço, e o seu trabalho definitivamente vale a pena verificar.

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

Um tempo para regressar ao Runescape

Criar um RuneScape livre e aberto capaz de suportar milhões de jogadores simultâneos não é uma tarefa fácil. 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 [@lordofafew], Todos os direitos de autor pertencem ao autor original [@lordofafew]. Se houver objeções a esta reimpressão, por favor entre em contato com o Gate Learnequipa e eles vão tratar disso 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 outras línguas são feitas pela equipa Gate Learn. Salvo indicação em contrário, é proibido copiar, distribuir ou plagiar os artigos traduzidos.