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 o gás L2 no 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çosaAtualizaçã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.
Ticking manual (Ticking 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:
**- Atualizações 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 uma expressão de formulário 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 rede pode suportar.
2. A função do cliente é diferente
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 custos 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ômatos celulares no mecanismo de execução, tornando-a mais eficiente, permitindo tabuleiros de jogo maiores do que poderiam ser implementados como bytecode de contrato inteligente.
O código-fonte da demonstração:
Vídeo de demonstração:
Ver original
Esta página pode conter conteúdos de terceiros, que são fornecidos apenas para fins informativos (sem representações/garantias) e não devem ser considerados como uma aprovação dos seus pontos de vista pela Gate, nem como aconselhamento financeiro ou profissional. Consulte a Declaração de exoneração de responsabilidade para obter mais informações.
Como usar o OPStack para construir o ciclo de clock do jogo full chain?
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 o gás L2 no 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çosaAtualizaçã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.
Ticking manual (Ticking 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:
**- Atualizações 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
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 rede pode suportar.
2. A função do cliente é diferente
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 custos 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ômatos celulares no mecanismo de execução, tornando-a mais eficiente, permitindo tabuleiros de jogo maiores do que poderiam ser implementados como bytecode de contrato inteligente.
O código-fonte da demonstração:
Vídeo de demonstração: