A equipa do Lattice anunciou recentemente o Redstone - o seu novo L2 construído com a sua nova contribuição para o OP Stack (a pilha que alimenta o Otimismo L2).

A questão na mente de todos é, portanto, “Os jogos onchain devem ser construídos neste L2, e como é que se compara às alternativas?”. Muitos têm entrado em contacto com a nossa equipa da Paima Studios para a nossa opinião, dado que somos um dos principais construtores de jogos onchain com jogos ao vivo em várias cadeias, e por isso faremos o nosso melhor para mergulhar nas nuances.

NOTA

No momento em que este artigo foi escrito, o Redstone só recentemente foi anunciado. A Web3 é um espaço muito rápido, por isso encorajamo-lo a ler esta postagem do blog com a mente aberta para a Redstone, pois eles inevitavelmente anunciam mais sobre o seu trabalho

Para perceber o Redstone e porque é que existe, tem de primeiro perceber como se compara às outras alternativas que estão a ser ativamente utilizadas no mercado e as suas compensações. Notavelmente, nesta postagem do blog, vamos nos concentrar em dar-lhe o modelo mental correto para que possa entender o que Redstone propõe, não importa o que eles anunciem a seguir.

Onde tudo começou​

Então, quer construir um jogo onchain? Dado que o Redstone é um Ethereum L2, vamos assumir que já está determinado a alavancar o Ethereum.

Então, porque é que não pode implantar o seu jogo diretamente no Ethereum? Pode saber que é porque custa demasiado (mais de > $1 por jogada de jogo no momento em que escrevo), mas sabe porque é que custa demasiado? Acontece que existem dois custos principais: custo de execução e custo de armazenamento de dados - ambos são proibitivamente caros para um jogo. No entanto, tal como as CPUs são mais caras que os discos rígidos, o custo de execução é significativamente mais elevado do 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 uma solução de escalonamento​

Os rollups vêm de várias formas, cada um convertendo os custos de execução em custos de armazenamento à sua maneira:

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

Aproveitar estas soluções faz com que o custo de uma transação para o seu jogo diminua para aproximadamente $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 é a chave para que os jogos tenham sucesso. Embora os rollups estejam definitivamente a ficar mais baratos (os computadores a melhorar, a tecnologia ZK a melhorar, etc.), o custo primário não é executar a computação fora da cadeia, mas sim o custo de publicar os dados no L1.

Para fazer face a isto, a Ethereum vai introduzir uma nova maneira de armazenar dados que é muito mais barata (chamada EIP4844) onde os dados são armazenados apenas temporariamente (na prática, ~2 semanas para que seja longo o suficiente para que qualquer prova de fraude seja postada e que os dados sejam replicados por nós em todo o mundo).

No entanto, o EIP4844 vem com algumas desvantagens:

• Os dados são apenas temporários (terá de encontrar outra solução de armazenamento para mantê-los alojados depois)
• Os dados são limitados, limitando-se a cerca de 2 MiB por bloco (partilhados entre todos os rollups no Ethereum)

Então, como pode ver, embora estejam a ser feitos esforços para reduzir os custos, eles não serão suficientes para tornar os jogos onchain 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 #1: Armazene os dados num servidor centralizado (ou conjunto de servidores)​

Uma alternativa para manter o custo baixo é simplesmente armazenar os dados num servidor centralizado que as pessoas confiam em si para operar, e apenas postar um hash dos dados na cadeia. Uma variante destas ideias é usar um grupo de máquinas operadas independentemente agregadas como multisig. Esse esquema chama-se “Comité de Disponibilidade de Dados” (DAC) e é isso que é utilizado pelo Arbitrum Nova, Arbitrum Orbit e Polygon CDK.

Estes esquemas são muito mais baratos ($0.001 /tx para o Arbitrum Nova se ignorar o mercado de taxas) em troca da rede ser mais centralizada. O principal risco é que se o DAC parar de alojar os dados (ex: eles publicam um hash e nunca partilham os dados desse hash), a rede pára.

Uma nota especial sobre o Arbitrum​

Pode estar curioso para saber porque o Arbitrum aparece duas vezes na lista. Arbitrum fornece 3 ofertas principais no momento:

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

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

Alternativa #2: Armazene os dados noutra rede descentralizada​

Em vez de esperar que o EIP4844 seja implementado com largura de banda limitada na mainnet, 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, oferecem limites de dados mais altos do que os planos da rede principal da Ethereum para suportar também. Estas plataformas não suportam contratos inteligentes e, em vez disso, destinam-se a ser utilizadas puramente como camada de dados para L2s.

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

1. Confiança. O seu rollup agora depende da camada DA para segurança em cima do Ethereum (mas indiscutivelmente melhor que um DAC)
2. Custo. O seu rollup precisa agora de pagar a rede DA pela sua segurança (que tem de pagar no token nativo da camada DA)
3. Velocidade. Os tempos de bloqueio do Celestia são 15s e os tempos de bloqueio Avail são 20s. Por exemplo, os dados precisam de ser liquidados com a Celestia antes de poderem ser colhidos à EVM com o contrato de blobstream da Celestia. Tome este ponto com um grão de sal, 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 bloco mais rápido do que isso).

Este tipo de configuração é utilizado principalmente pelo Mantle (OP Stack + EigenLayer DA) e pela Manta Pacific (OP Stack+Celestia). O custo destes ainda está para ser visto, mas a equipa Celestia reivindica aproximadamente $0.001, o que significa que o custo de armazenamento numa camada DA (relativo ao custo de execução de um mercado de taxas no lado do EVM) é mínimo.

Alternativa #3: Armazene os dados num DAC que possa ser desafiado​

Finalmente, podemos falar sobre o que a Redstone está a oferecer. Se não gosta das compensações de armazenar dados numa camada DA, mas não gosta da centralização de um DAC, pode construir um DAC onde pode punir financeiramente o comité se eles não disponibilizarem os dados.

Para ajudar a perceber o que isto significa, vamos rever um fluxo de como funciona o protocolo DAC:

Como escrever dados​

1. O sequenciador para Redstone recebe a sua transação
2. O sequenciador envia os dados para o DAC para serem armazenados
3. O DAC devolve um reconhecimento de que os dados estão armazenados
4. O sequenciador posta o hash dos dados para o L1

Como ler dados​

1. Sincronize uma cadeia Ethereum à procura de hashes que foram submetidos ao contrato de rollup
2. Consultar os dados para o hash do DAC
3. Calcular o estado do L2 com base neste dado

Então, o que é que o Redstone muda​

Ao ler dados, se os dados não estiverem disponíveis, pode contestar o DAC alegando que não disponibilizou os dados (também conhecido como os dados não podem ser transferidos do servidor).

Para incentivar adequadamente toda a gente a ser honesto, estabelecemos as seguintes regras de corte:

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

Isto 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 partilhar os dados reais
2. Alguém desafia o sequenciador
3. O sequenciador, vendo o desafio, e disponibiliza os dados

Se é um observador externo que não estava a monitorizar a cadeia em tempo real, os dados parecem disponíveis (se consultar o DAC após o facto de obter os dados conforme o esperado), então parece que o desafiante estava a mentir mesmo que não estivesse.

Se a sua solução para este problema é assumir que o sequenciador nunca mentiria apenas para um jogo, então porque não usar um DAC padrão em vez disso. Além disso, supor que o sequenciador seja honesto não se compõe bem com o conceito de uma “supercadeia” de sequenciador partilhado, o que significa que os ativos não podem usar o sequenciador partilhado para serem transferidos entre cadeias OP Stack (então encontra o mesmo problema que o Arbitrum Nova a menos que o Redstone seja implementado como um L3)

A forma como a equipa do Lattice planeia lidar com isto será o ponto chave a ter em atenção à medida que mais documentação e informações sobre o roteiro são disponibilizadas.

Alternativa #4: Utilizar ZK​

Note que o problema com os dados não serem partilhados (ataques de retenção de dados) que afeta o Redstone não é exclusivo dos rollups otimistas. Os 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 publicam todos os dados numa cadeia).

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

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

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 numa cadeia de EVM centralizada que operam). Se este é você, pode estar interessado em usar um rollup soberano para lhe permitir escalar o seu jogo além dos limites do EVM usando o Paima Engine.

O Paima Engine permite criar máquinas de estado específicas da aplicação em Javascript que pode implementar em qualquer cadeia EVM de sua escolha (incluindo Redstone!). Estes rollups soberanos podem aceder a informações EVM (incluindo dados do motor MUD) e, portanto, podem funcionar como uma ótima maneira de fazer qualquer parte do seu jogo correr muito mais rápido e barato.

Conclusão​

Em conclusão, reduzir o custo dos dados é mais o passo mais crucial para reduzir os custos de jogos em cadeia. Existem muitas soluções diferentes existentes com diferentes compensações que existem hoje, e a Redstone apresenta-se como mais segura 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 às soluções apoiadas pela camada DA. Para projetos que precisam de escalar a computação em cima dos dados, existem soluções como o Paima Engine para resolver o problema.

Como aviso final, lembre-se que os detalhes do Redstone ainda não foram totalmente anunciados. Esta postagem no blog deve dar-lhe o modelo mental certo para entender os seus futuros anúncios, por isso vamos manter a mente aberta e ver o que eles propõem daqui para frente.

Estúdios Paima​

Os Paima Studios, fundados em abril de 2022, são os principais desenvolvedores do Paima Engine: um motor Web3 construído com a nova tecnologia de camada 2 que permite a construção de jogos onchain, gamificação e mundos autónomos. O Paima Engine é uma maneira segura e fácil de entrar na Web3, pois pode ser usado com competências Web2 e não expõe os utilizadores ou programadores a riscos e hacks comuns da Web3.

• Base de código do Paima Engine: https://github.com/PaimaStudios/paima-engine
• Documentação do 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

Também pode aprender mais com as 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 em conjunto? Não hesite em contactar-nos através da nossa página de contacto: https://paimastudios.com/contact/

Isenção de responsabilidade：

1. Este artigo foi reimpresso de [blog.paimastudios]. Todos os direitos de autor pertencem ao autor original [paimastudios]. Se houver objeções a esta reimpressão, contacte a equipa do Gate Learn, e eles tratarão disso imediatamente.
2. Isenção de responsabilidade: As opiniões e opiniões expressas neste artigo são exclusivamente do autor e não constituem nenhum conselho de investimento.
3. As traduções do artigo para outras línguas são feitas pela equipa do Gate Learn. A menos que mencionado, é proibido copiar, distribuir ou plagiar os artigos traduzidos.