Como usar o OPStack para construir o ciclo de clock do jogo full chain?

Autor: Gametaverse

Em geral, os jogos são baseados em loop. Um loop de jogo é um processo iterativo que normalmente consiste em processar a entrada do usuário, atualizar o estado do jogo e renderizar o mundo do jogo. Esse loop continua enquanto o jogo está em execução, normalmente executado dezenas a centenas de vezes por segundo para manter o mundo do jogo fluindo.

No entanto, a arquitetura do blockchain é baseada em push. Blockchain é um banco de dados distribuído que compartilha e armazena informações por meio de nós na rede. Quando um nó gera uma nova transação (como transferência, chamada de contrato, etc.), a transação é enviada para a rede e outros nós a verificam e adicionam ao blockchain após receber a transação. Este é um processo passivo, os nós não procurarão ativamente por novas transações, mas aguardarão que outros nós da rede enviem novas transações. Portanto, a arquitetura do blockchain é considerada baseada em push.

Portanto, é muito importante implementar um sistema de ciclos com ciclos de clock no jogo full-chain. Afinal, no chamado "mundo autônomo", todos esperamos que alguns NPCs ou ambientes virtuais possam evoluir automaticamente ao longo do tempo, em vez de evoluir passivamente seguindo entradas de transação enviadas para o blockchain.

@therealbytes desenvolveu uma cadeia de ticks de prova de conceito (cadeia com ciclos de clock) baseada no OP Stack, que executa uma implementação automática de tick-tick do Game of Life de Conway, vamos ver como ele o implementou.

Para manter a tradução simples, traduzimos literalmente tick em "tick", que significa "ciclo do relógio".

Ticking-Optimism é uma implementação de prova de conceito do "Ticking Blockchain" com base na arquitetura rollup Optimism Bedrock.

Na cadeia de ticks, existe um contrato inteligente especial chamado "tick contract", e cada bloco será chamado automaticamente pelo protocolo. Isso permite que outros contratos inteligentes sejam acionados automaticamente em horários ou intervalos específicos sem exigir que os usuários enviem transações.

Como conseguir

A nova arquitetura rollup modular da Optimism, Optimism Bedrock, introduz um novo tipo de transação chamado "Transação de Depósito". Ao contrário das transações regulares, as transações de depósito:

• Blocos da camada 1.

• Nenhuma verificação de assinatura necessária.

• Compre gás L2 em L1, então o gás L2 não é reembolsável.

No Bedrock original, as transações de depósito eram usadas para duas coisas:

• Executar transações enviadas diretamente para L1.

• Defina as propriedades L1 (número, timestamp, hash, etc.) para contratos L2 pré-implantados em cada bloco.

No último caso, as transações são criadas por nós rollup. Não paga o gás, e o gás utilizado não é descontado do pool de gás.

O Ticking-Optimism modifica o nó rollup e também cria uma "transação de tick" que funciona da mesma maneira, mas em vez de definir a propriedade L1, ele chama a função tick() no contrato pré-implantado para o endereço 0x420000000000000000000000000000000000000A0. Este contrato pode chamar outro contrato definindo sua variável de destino.

Motivação

Para ilustrar o poder dos tickchains, imagine um jogo no blockchain onde vários NPCs (personagens não-jogadores) se movem pelo mapa. Sem uma cadeia de ticks, temos duas abordagens principais de design:

• Atualização preguiçosa. No lado do cliente, os NPCs parecem se mover continuamente, mas suas posições são atualizadas apenas na cadeia quando os usuários enviam transações para interagir com eles. O contrato então calcula a nova localização do NPC com base em sua última atualização on-chain e no número de blocos que passaram desde então.

• Marcação manual. Definimos uma função de atualização que define a posição de cada NPC no mapa e fazemos com que uma conta externa o chame periodicamente.

Com um tickchain, a solução é semelhante ao tique-taque manual, mas o contrato de tick chama a função de atualização automaticamente em vez de manualmente.

As vantagens de usar o "auto-tick" da cadeia de ticks em vez dos ticks manuais são:

• As atualizações são garantidas por contrato.

• A atualização será realizada antes de todas as transações do bloco e não pode ser frontal por fazer parte do próprio protocolo.

• As transações de atualização não participam do mercado regular de gás.

No entanto, os tiques automáticos requerem um blockchain personalizado. Se a taxa de atualização for a mesma, o tique-taque manual e automático exigirá os mesmos recursos de computação no nó. As atualizações preguiçosas, por outro lado, geralmente são mais baratas porque as atualizações on-chain são menores e menos frequentes.

Além disso, o custo computacional das transações de ticks aumenta à medida que o estado que precisa ser atualizado cresce. Isso coloca pressão adicional sobre os desenvolvedores para projetar seus aplicativos de forma que os custos nunca excedam o que a cadeia pode suportar.

Apesar dessas enormes desvantagens, os ticks automáticos são mais adequados do que as atualizações preguiçosas para certos tipos de aplicativos.

1. O estado é sempre explicitamente on-chain e atualizado

Os ticks permitem que contratos inteligentes acessem, a custo constante, um estado dinâmico que é atualizado usando expressões de formato aberto.

O estado (no exemplo acima, a localização do NPC) é sempre legível na cadeia a um custo de gás constante e relativamente baixo. Mas o custo de calcular o estado atual aumentará com o número de blocos desde a última atualização e o custo do gás aumentará ainda mais.

Se estivermos atualizando a posição de uma entidade que se move a uma velocidade constante, podemos calcular onde ela deve estar em qualquer pedaço de sua última posição definida e o número de pedaços desde a atualização. O custo desta operação não cresce com o número de blocos entre as atualizações.

Por outro lado, se o estado que atualizamos for algo como o Jogo da Vida de Conway (ou uma simulação de três gravidades), o custo de atualização cresce linearmente com o número de etapas desde a última atualização. Isso é um problema porque pode crescer além do que os usuários estão dispostos a pagar ou do que a cadeia pode suportar.

2. Diferentes funções dos clientes

Com atualizações preguiçosas, a lógica de atualização precisa ser implementada tanto no contrato inteligente quanto no cliente. Com o tique-taque, ele só precisa ser implementado na blockchain e os clientes podem simplesmente reagir a eventos na cadeia.

3. O código é mais simples e fácil de revisar

As atualizações preguiçosas permitem que os desenvolvedores espalhem sua lógica de atualização em muitas funções e contratos inteligentes, com cada função sendo acionada apenas quando determinadas transações são executadas. Em contraste, a abordagem tick-tick requer apenas uma função de atualização que é garantida para disparar periodicamente. O último facilita a manutenção da consistência e integridade do estado.

Além disso, toda vez que um novo estado de atualização lenta é adicionado (por exemplo, um novo tipo de NPC), todas as funções de atualização podem precisar ser modificadas para considerá-lo. Isso torna a base de código mais complexa e propensa a problemas.

4. Os usuários não pagam o custo de atualização

O custo das atualizações preguiçosas geralmente varia muito, e os usuários podem criar suas transações para que a maior parte do ônus das atualizações recaia sobre os outros. Com ticks, o custo de todas as operações é relativamente estável e não vulnerável a ataques MEV.

Demonstração do jogo da vida de Conway

Eu construí uma demonstração de tickchain que executa uma versão interativa do Jogo da Vida de Conway. A cadeia foi modificada para incluir lógica de autômato celular no mecanismo de execução, tornando-a mais eficiente, permitindo um tabuleiro de jogo maior do que poderia ser implementado como bytecode de contrato inteligente.

O código-fonte da demonstração:

Vídeo de demonstração: