A equipe Lattice anunciou recentemente Redstone – seu novo L2 construído usando sua nova contribuição para OP Stack (a pilha que alimenta o Optimism L2).

A questão que está na mente de todos é, portanto, “Os jogos on-chain devem ser construídos neste L2 e como ele se compara às alternativas?”. Muitos têm procurado nossa equipe no Paima Studios para obter nossa opinião, visto que somos um dos principais construtores de jogos on-chain com jogos ao vivo em múltiplas cadeias e, portanto, faremos o nosso melhor para mergulhar nas nuances.

OBSERVAÇÃO

No momento em que este artigo foi escrito, Redstone só foi anunciado recentemente. Web3 é um espaço em rápida evolução e, por isso, encorajamos você a ler esta postagem do blog com a mente aberta para Redstone, pois eles inevitavelmente anunciam mais sobre seu trabalho

Para entender o Redstone e por que ele existe, primeiro você precisa entender como ele se compara a outras alternativas que estão sendo usadas ativamente no mercado e suas vantagens e desvantagens. Notavelmente, nesta postagem do blog, nos concentraremos em fornecer o modelo mental correto para que você possa entender o que Redstone propõe, independentemente do que eles anunciarem a seguir.

Onde tudo​começou​

Então você quer construir um jogo onchain? Dado que Redstone é um Ethereum L2, presumiremos que você já decidiu aproveitar o Ethereum.

Então, por que você não pode implantar seu jogo diretamente no Ethereum? Você pode saber que é porque custa muito caro (mais de $ 1 por jogada no momento em que este artigo foi escrito), mas você sabe por que custa muito caro? Acontece que existem dois custos principais: custo de execução e custo de armazenamento de dados – ambos proibitivamente caros para um jogo. No entanto, assim como as CPUs são mais caras que os discos rígidos, o custo de execução é significativamente maior que os custos de armazenamento. Então, e se pudéssemos encontrar uma maneira de converter o custo de execução em custo de armazenamento? Boas notícias: os rollups fazem exatamente isso.

Rollups como​solução​de escalonamento

Os rollups vêm em muitas formas, cada uma convertendo custos de execução em custos de armazenamento à sua maneira:

1. Rollups otimistas: execute o cálculo fora da cadeia e, em seguida, armazene todos os dados necessários para executar a função (apenas dados, sem execução) junto com o valor calculado localmente para o resultado. Só execute a execução se alguém acreditar que o resultado que você postou está incorreto (“à prova de fraude”). \
   Exemplos populares: Arbitrum, Otimismo
2. Rollups ZK: execute o cálculo offchain e, em seguida, armazene todos os dados necessários para executar a função (apenas dados, sem execução) junto com sua prova ZK do resultado calculada localmente. \
   Exemplos populares: ZK Sync, Starknet, Polygon zkEVM
3. Rollup soberano: execute o cálculo fora da cadeia e, em seguida, armazene todos os dados necessários para executar a função (apenas dados, sem execução). \
   Exemplos populares: Rollkit, Paima Engine

Aproveitar essas soluções reduz o custo de uma transação do seu jogo para aproximadamente US$ 0,05 (consulte l2fees para valores atualizados), o que é definitivamente um grande passo na direção certa.

Reduzindo o custo dos​L2s​

Claramente, reduzir os custos destes L2s é fundamental para o sucesso dos jogos. Embora os rollups estejam definitivamente ficando mais baratos (computadores cada vez melhores, tecnologia ZK cada vez melhor, etc.), os custos principais não são a execução da computação offchain, mas sim o custo de postagem dos dados no L1.

Para resolver isso, Ethereum introduzirá uma nova maneira de armazenar dados que é muito mais barata (chamada EIP4844), onde os dados são armazenados apenas temporariamente (na prática, cerca de 2 semanas para que seja tempo suficiente para que qualquer prova de fraude seja publicada e para que os dados sejam replicados por nós em todo o mundo).

EIP4844 tem algumas desvantagens:

• Os dados são apenas temporários (você precisará encontrar outra solução de armazenamento para mantê-los hospedados posteriormente)
• Os dados são limitados, limitados a cerca de 2 MiB por bloco (compartilhados entre todos os rollups no Ethereum)

Então, como você pode ver, embora estejam sendo feitos esforços para reduzir custos, eles não serão suficientes para tornar os jogos on-chain viáveis no L2, dado o crescimento contínuo do interesse no espaço blockchain (a velocidade de adoção é mais rápida do que a velocidade da inovação técnica). )

Alternativa nº 1: Armazene os dados em um servidor centralizado (ou conjunto de servidores )

Uma alternativa para manter o custo baixo é simplesmente armazenar os dados em um servidor centralizado onde as pessoas confiam em você para operar e postar apenas um hash dos dados na cadeia. Uma variante dessas ideias é usar um grupo de máquinas operadas de forma independente e agregadas como um multisig. Esse esquema é chamado de “Comitê de Disponibilidade de Dados” (DAC) e é usado pelo Arbitrum Nova, Arbitrum Orbit e Polygon CDK.

Esses esquemas são muito mais baratos (US$ 0,001/tx para Arbitrum Nova se você ignorar o mercado de taxas) em troca de a rede ser mais centralizada. O principal risco é que, se o DAC parar de hospedar os dados (ex: eles postarem um hash e nunca compartilharem os dados desse hash), a rede será interrompida.

Uma nota especial sobre​Arbitrum​

Você pode estar curioso para saber por que o Arbitrum aparece duas vezes na lista. Arbitrum oferece 3 ofertas principais no momento:

• Arbitrum One (a principal rede Arbitrum que é um rollup completo com dados no Ethereum)
• Arbitrum Nova (um L2 que usa um DAC)
• Arbitrum Orbit (uma pilha para criar L3s para Arbitrum One)

Como você pode ver, o problema com Nova é que não há uma boa maneira de aproveitar o DeFi para o seu jogo (os usuários teriam que ir para (Nova -> ETH L1 -> One) e gastar muito em gás apenas para fazer a ponte), enquanto a nova pilha Orbit permite que você vá facilmente (Orbit -> One). Além disso, como Orbit é uma pilha para criar L3s, você pode usar um L3 existente como Xai Games que alimenta seu próprio DAC ou ativar seu próprio L3 (embora se você tiver um L3 específico do jogo cuja única conexão com Ethereum é postar ocasionalmente hashes, você pode estar melhor com web2.5)

Alternativa nº 2: Armazene os dados em outra​rede​descentralizada

Em vez de esperar que o EIP4844 seja implementado com largura de banda limitada na rede principal, outros projetos como Celestia, Avail e EigenDA decidiram implementar um conceito semelhante como uma cadeia separada (chamada camada de Disponibilidade de Dados (“DA”)), e concentrando-se puramente neste caso de uso, eles oferecem limites de dados mais altos do que os planos da rede principal Ethereum também suportar. Essas plataformas não suportam contratos inteligentes e, em vez disso, destinam-se apenas a ser usadas como camada de dados para L2s.

Notavelmente, é possível criar uma pilha OP com dados do Celestia, bem como uma Órbita Arbitrum com dados do Celestia também. Isso traz algumas compensações:

1. Confiar. Seu rollup agora depende da camada DA para segurança no topo do Ethereum (mas sem dúvida melhor que um DAC)
2. Custo. Seu rollup agora precisa pagar à rede DA por sua segurança (que você deve pagar no token nativo da camada DA)
3. Velocidade. Os tempos de bloco Celestia são 15s e os tempos de bloco Avail são 20s. Por exemplo, os dados precisam ser transferidos para a Celestia antes de poderem ser transferidos para o EVM com o contrato blobstream da Celestia. Porém, considere este ponto com cautela, já que todos os L2s em geral emulam tempos de bloqueio mais rápidos do que o Ethereum pode realmente fornecer (dado que os tempos de bloqueio do Ethereum são de apenas 15s, apesar do Arbitrum usar um tempo de bloqueio mais rápido que este).

Este tipo de configuração é usado principalmente por Mantle (OP Stack + EigenLayer DA) e Manta Pacific (OP Stack + Celestia). O custo para estes ainda está para ser visto, mas a equipe Celestia reivindica aproximadamente US$ 0,001, o que significa que o custo de armazenamento em uma camada DA (em relação ao custo de execução de um mercado de taxas no lado EVM) é mínimo.

Alternativa nº 3: Armazene os dados em um DAC que possa ser​desafiado​

Finalmente, podemos falar sobre o que Redstone está oferecendo. Se você não gosta das vantagens de armazenar dados em uma camada DA, mas não gosta da centralização de um DAC, você pode, em vez disso, construir um DAC onde poderá punir financeiramente o comitê se ele não disponibilizar os dados .

Para ajudar a entender o que isso significa, vamos ver como funciona o protocolo DAC:

Como escrever​dados​

1. Sequencer for Redstone recebe sua transação
2. O sequenciador envia os dados para o DAC para serem armazenados
3. DAC retorna uma confirmação de que os dados estão armazenados
4. O sequenciador posta o hash dos dados no L1

Como ler​dados​

1. Sincronize uma cadeia Ethereum em busca de hashes que foram submetidos ao contrato rollup
2. Consulte os dados para o hash do DAC
3. Calcule o estado do L2 com base nesses dados

Então, o que Redstone​muda​

Ao ler os dados, se os dados não estiverem disponíveis, você pode contestar o DAC alegando que ele não disponibilizou os dados (ou seja, os dados não podem ser baixados do servidor).

Para incentivar adequadamente todos a serem honestos, estabelecemos as seguintes regras de corte:

1. Se um desafiante for desonesto (os dados realmente estavam disponíveis), ele será eliminado (caso contrário, você poderia atacar financeiramente a rede desafiando cada bloco)
2. Se o DCA for desonesto (os dados não estão disponíveis), eles serão cortados.

Parece uma solução simples, mas a dificuldade está em descobrir quem é o culpado se ocorrer um problema. Pense no seguinte cenário:

1. O sequenciador posta um hash sem compartilhar os dados reais
2. Alguém desafia o sequenciador
3. O sequenciador, vendo o desafio, disponibiliza os dados

Se você for um observador externo que não estava monitorando a cadeia em tempo real, os dados parecerão disponíveis (se você consultar o DAC após o fato, você obterá os dados conforme o esperado), então parece que o desafiante estava mentindo, mesmo que eles não estivessem.

Se a sua solução para este problema é assumir que o sequenciador nunca mentiria apenas para um jogo, então por que não usar um DAC padrão? Além disso, assumir que o sequenciador é honesto não combina bem com o conceito de uma “superchain” do sequenciador compartilhado, o que significa que os ativos não podem usar o sequenciador compartilhado para serem transferidos entre cadeias OP Stack (então você se depara com o mesmo problema do Arbitrum Nova, a menos que Redstone é implantado como um L3)

Como a equipe da Lattice planeja lidar com isso será o ponto-chave a ser observado à medida que mais documentação e informações de roteiro forem disponibilizadas.

Alternativa nº 4: use​ZK​

Observe que o problema de não compartilhamento de dados (ataques de retenção de dados) que afeta Redstone não é exclusivo dos rollups do Optimistic. ZK Rollups cujos dados são armazenados fora da cadeia (chamados “Validiums”) sofrem do mesmo problema, razão pela qual as pessoas geralmente estão mais interessadas em rollups (que postam todos os dados em uma cadeia).

Portanto, os rollups ZK, em geral, não ajudarão você a reduzir o custo de dados do seu jogo com segurança. Eles podem definitivamente ajudar a dimensionar seu jogo de muitas outras maneiras (mover mais computação para a máquina local do usuário, usar provas recursivas para agrupar muitas interações, seja no estilo rollup ou no estilo canal de estado, etc.), mas isso é um tópico para um postagem futura.

Como posso diminuir ainda mais os custos do meu jogo se o problema é o próprio Solidity ?

Em toda esta postagem do blog falamos sobre como lidar com os custos de armazenamento. No entanto, alguns jogos podem ser limitados pela CPU (mesmo que sejam executados em uma cadeia EVM centralizada). Se este for você, você pode estar interessado em usar um rollup Sovereign para permitir escalar seu jogo além dos limites do EVM usando o Paima Engine.

O Paima Engine permite criar máquinas de estado específicas do aplicativo em Javascript que você pode implantar em qualquer cadeia EVM de sua escolha (incluindo Redstone!). Esses rollups soberanos podem acessar informações EVM (incluindo dados do mecanismo MUD) e, portanto, podem funcionar como uma ótima maneira de fazer qualquer parte do seu jogo rodar muito mais rápido e mais barato.

​Conclusão​

Concluindo, reduzir o custo dos dados é o passo mais crucial para reduzir os custos dos jogos on-chain. Existem muitas soluções diferentes com diferentes compensações que existem hoje, e Redstone se apresenta como mais seguro do que o DAC padrão, mas resta saber se é significativamente mais seguro e se a diferença é significativa o suficiente para ser uma alternativa viável para soluções apoiadas pela camada DA. Para projetos que precisam dimensionar a computação com base nos dados, existem soluções como o Paima Engine para resolver o problema.

Como aviso final, lembre-se de que os detalhes do Redstone ainda não foram totalmente anunciados. Esta postagem do blog deve fornecer o modelo mental correto para entender seus anúncios futuros, então vamos manter a mente aberta e ver o que eles propõem no futuro.

​Estúdios​Paima

Paima Studios, fundado em abril de 2022, é o principal desenvolvedor do Paima Engine: um mecanismo Web3 construído usando uma nova tecnologia de camada 2 que permite a construção de jogos on-chain, gamificação e mundos autônomos. Paima Engine é uma maneira fácil e segura de entrar no Web3, pois pode ser usado com habilidades em Web2 e não expõe usuários ou desenvolvedores a riscos e hacks comuns do Web3.

• Base de código do Paima Engine: https://github.com/PaimaStudios/paima-engine
• Documentação Paima: https://docs.paimastudios.com/
• Modelo Paima: https://github.com/PaimaStudios/paima-game-templates
• Pacote Paima NPM: <a href="https://www.npmjs.com/package/@paima/sdk""> https://www.npmjs.com/package/@paima/sdk

Você também pode saber mais em nossas redes sociais:

• Youtube: <a href="https://www.youtube.com/@paimastudios""> https://www.youtube.com/@paimastudios
• Discord: http://discord.gg/jZ59ArVaxv
• Reddit: https://reddit.com/r/paima
• Twitter: https://twitter.com/PaimaStudios

Quer trabalhar juntos? Não hesite em nos contactar através da nossa página de contato: https://paimastudios.com/contact/

Isenção de responsabilidade:

1. Este artigo foi reimpresso de [blog.paimastudios]. Todos os direitos autorais pertencem ao autor original [paimastudios]. Se houver objeções a esta reimpressão, entre em contato com a equipe do Gate Learn e eles cuidarão disso imediatamente.
2. Isenção de responsabilidade: As opiniões e pontos de vista expressos 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 do Gate Learn. A menos que mencionado, é proibido copiar, distribuir ou plagiar os artigos traduzidos.