Construindo um mundo virtual: como usar a tecnologia blockchain para manter o tempo para os "deuses digitais"

Escrito por: @therealbytes @_yonada Compilado por: Justin @captainz

Como criadores de mundos virtuais, nosso objetivo é criar ambientes que sejam divertidos e profundamente envolventes para os usuários. Isso exige que encontremos um equilíbrio entre projetar física digital que permita o surgimento de comportamentos complexos e inesperados e garantir que a infraestrutura existente possa suportar esses comportamentos. Para fazer isso, precisamos considerar três dimensões principais da física digital: o tempo, a forma de suas leis e a extensão em que essas leis se aplicam.

tempo

Referimo-nos à passagem do tempo no mundo virtual como a aplicação iterativa das leis do mundo a si mesmo. Cada aplicação discreta é um "instante" no fluxo do tempo neste mundo. Uma maneira de projetar o tempo no mundo é torná-lo contínuo com o tempo externo. Em um mundo virtual baseado em blockchain, cada bloco corresponde a um certo número de momentos passados no mundo, independentemente das transações que o bloco contém. Isso é conhecido como tempo síncrono ou o fenômeno "tick". Essa abordagem pode tornar o mundo mais interessante para os usuários, pois eles podem ver os resultados de suas ações em tempo real. Além disso, resulta em mais tempo no mundo e o mundo vai se atualizando, o que estimula comportamentos interessantes.

No entanto, esta abordagem também tem suas desvantagens. Prazos maiores geralmente requerem mais recursos de computação, que podem exceder rapidamente as capacidades da cadeia ou do servidor. Também pode ser difícil implementar esse sistema em uma blockchain normal, pois todas as alterações na cadeia devem ser iniciadas por transações iniciadas por usuários externos.

Essa dificuldade fica aparente quando você imagina algo aparentemente simples: um jogo on-chain com personagens não-jogadores (NPCs). Na mainnet Ethereum, você pode definir uma função de atualização que define a posição de cada NPC no mapa do jogo e fazer com que uma conta externa o chame periodicamente para atualizar sua posição. Mas isso pode não ser confiável, porque você não pode garantir que a conta externa não será superada pela taxa de gás no bloco que deve chamar a atualização. A estrutura de tempo em seu jogo irá, portanto, variar (pegue a função giveBirth() original do CryptoKitties como exemplo; à medida que a taxa de gás on-chain aumenta, o Axiom Zen realmente precisa aumentar a recompensa por chamar a função giveBirth para garantir que o novo NFT A transação de nascimento é chamada 256 blocos após o usuário criar Kitty). Referimo-nos a este método de utilização de contas externas como "tique-taque manual".

Os rollups personalizados nos dão mais flexibilidade para adicionar a funcionalidade "tick" on-chain, sem necessidade de contas externas e os avanços de tempo sincronizados são garantidos pelo protocolo. Chamamos esse método de "auto-tick". Os ticks automáticos podem ser implementados escrevendo um "contrato de tick" que é chamado pelo próprio protocolo e não por uma conta externa.

Como exemplo, @therealbytes desenvolveu uma cadeia de ticks de prova de conceito baseada no OP Stack que executa uma implementação do Game of Life de Conway que marca automaticamente (você pode encontrar uma demonstração em vídeo aqui). Bytes usa uma transação de sistema modificada para invocar automaticamente o contrato de simulação de autômato celular tick-tick. Para testar completamente os limites da própria cadeia, ele implementou o jogo de duas maneiras: uma como um contrato inteligente do Solidity rodando na cadeia e a outra como uma pré-compilação da própria cadeia. A implementação do Solidity está maximizando a CPU após atingir uma grade de 70x70 com duas atualizações por bloco (1 bloco/seg, ou cerca de 10k células/seg), enquanto a cadeia do mecanismo pré-compilado personalizado está usando cerca de 6% Atingindo a mesma taxa para 256x256 grid com uma CPU mais alta (cerca de 130k células/seg).

Na última frase do último parágrafo, a palavra-chave é "chegar ao limite". As cadeias de tick-tick adicionam uma camada extra de complexidade: cada bloco adicional requer mais estados a serem tocados por transações que simulam o jogo. Eventualmente, os nós de rollup serão limitados pela computação bruta (CPU, disco IO, etc.). A única solução aqui é usar nós de maior capacidade.

Uma alternativa ao "horário síncrono" é o "horário assíncrono". Sob este esquema, a passagem do tempo no mundo não necessariamente avança como o tempo externo avança. Em vez disso, o tempo normalmente avança quando certos eventos (geralmente ações do usuário) ocorrem. Os jogos de tabuleiro tradicionais que não envolvem um cronômetro se enquadram em uma categoria semelhante. Alcançar o tempo assíncrono na cadeia é mais fácil porque esse é o modelo que as cadeias de blocos foram projetadas para suportar. No entanto, também sacrifica alguns recursos que podem tornar o mundo mais interessante (como mover NPCs automaticamente).

WildWood, uma versão inicial de um jogo de prova de conceito de @notdavidhuang e cha0sg0d, revela esse sacrifício. Neste jogo, dois jogadores devem defender sua base de um cerco de NPCs agressivos. Nas versões anteriores do jogo, o movimento do NPC só era acionado quando o jogador se movia - uma implementação impraticável do tempo assíncrono. Depois de adicionar ticks, os NPCs se moveram, mas outro problema persistiu. A cadeia marca a cada segundo, o que significa que se o jogador se mover mais de uma vez por segundo, o jogo deve transmitir a posição do jogador no mapa com atualizações de rollup otimista. No entanto, seus companheiros de equipe não verão seu cliente automaticamente, o que significa que haverá um atraso nas atualizações de posição do jogador. Para superar esse problema, a equipe utilizou o serviço de retransmissão da MUD, uma rede ponto a ponto para transmitir clientes locais para toda a cadeia. Voila, a transição do tempo assíncrono para o tempo síncrono é realizada.

Leis das formas fechadas e abertas

Os construtores de mundo também devem decidir se seu mundo virtual segue uma representação de forma aberta ou fechada. As expressões de forma fechada têm um número fixo de operações. No entanto, o número de operações expressas de forma aberta (ou recursivamente) cresce de acordo com as variáveis dadas. Sob representações de forma aberta, o estado futuro do mundo só pode ser calculado aplicando repetidamente as leis do mundo a estados conhecidos. Ambientes gráficos complexos, como Dwarf Fortress, geralmente se enquadram nessa categoria. As representações de forma fechada, por outro lado, permitem que qualquer estado futuro seja calculado a partir de estados passados e o tempo decorrido entre eles (assumindo que nenhuma ação futura do usuário altere o estado), como taxas de extração de recursos no Age of Empires II.

Formulários abertos podem tornar os mundos virtuais mais interessantes porque, assim como o mundo real, eles são imprevisíveis. Prever o estado futuro do mundo requer cada vez mais tempo e recursos de computação (o jogo da vida de Conway implementado na cadeia é um bom exemplo: você não pode calcular estados futuros arbitrários porque precisa executar o jogo no tempo). Além disso, comportamentos macroscópicos inesperados podem surgir de interações microscópicas simples. Em um mundo regido por uma forma fechada, esses comportamentos emergentes geralmente só acontecem externamente, por meio das ações dos usuários (eles mesmos como na forma aberta), e não dentro da própria física do mundo.

O trade-off entre formas abertas e fechadas envolve um equilíbrio semelhante ao do tempo. Formas fechadas podem tornar o mundo potencialmente menos interessante, mas também o tornam mais eficiente computacionalmente. A forma fechada pode ser usada com tempo síncrono ou assíncrono. Quando implementados em um blockchain, eles têm vantagens significativas sobre os formulários abertos quando se trata de sincronização de tempo. Como o custo é constante por qualquer período de tempo, o mundo pode ser projetado para que o estado da cadeia seja atualizado apenas quando um usuário envia uma transação, mas é definido para o estado após o tempo decorrido desde a última atualização.

Intervalo de tempo e forma

Considere a abordagem padrão atual para a dinâmica on-chain, uma abordagem conhecida como "atualizações preguiçosas". Em uma atualização preguiçosa, o jogador inicia o início e o fim de uma ação, mas os tempos intermediários são simulados em vez de calculados diretamente. Por exemplo, um jogador planta uma macieira no 1º pedaço e depois colhe as maçãs no 10º pedaço. A lógica de atualização preguiçosa pode ser escrita para que os jogadores possam colher uma maçã por unidade de tempo, um total de 9 maçãs. Isso é perfeitamente adequado para atualizar a lógica com funções de formulário fechado (como uma maçã por bloco), mas falha se a lógica de cultivo mudar com base na entrada entre as ações do jogador. Se no bloco 5 uma chuva forte aumenta a taxa de crescimento das maçãs e no bloco 7 uma praga de gafanhotos quase destrói a colheita, então no bloco 10 não importa quantas maçãs o jogador pode colher Computacional, a menos que você realmente aplique todos os eventos que aconteceram (você não terá poder de computação suficiente para alcançar o novo estado). Ainda assim, as atualizações preguiçosas são ótimas para cálculos baratos de certos mobs (como plantas com uma taxa de crescimento fixa), mas ainda não são suficientes para uma caixa de ferramentas completa para um mundo dinâmico.

No mundo real, o tempo está em toda parte e passa ao mesmo tempo, e o universo é potencialmente infinito (embora com algumas complicações de relatividade). Em um mundo virtual, no entanto, isso não é necessariamente o caso.

Primeiro, os mundos virtuais podem ser claramente limitados. As possibilidades de intriga geralmente aumentam com o tamanho - mais coisas estão acontecendo em um mundo de 20 bilhões de galáxias do que em um mundo de dois átomos - mas o mesmo acontece com o custo computacional. Ambos os relacionamentos estão intimamente relacionados aos dois trade-offs mencionados anteriormente: a passagem do tempo e a forma física.

Em segundo lugar, o tempo não precisa passar em todos os lugares do mundo virtual. O mundo pode ser dividido em regiões discretas com diferentes lapsos de tempo para reduzir a carga computacional do mundo. Por exemplo, regras de física mais complexas e caras podem ser usadas em áreas com atividade do usuário e regras de física mais simples em locais onde não há atividade. A desvantagem dessa abordagem é dupla: ela pode fazer o mundo parecer inconsistente e carente de completude, o que limita o espaço de design para as regras mundiais e pressiona os construtores de mundos a evitar confundir os usuários; Limitar a propagação da causalidade dentro do mundo, se as ações de uma área não pode ter consequências em áreas distantes, o espaço entre as duas é congelado no tempo. O tamanho da área onde as regras de física se aplicam é uma importante consideração de design que afetará os recursos de que um mundo precisa e o nível de diversão que ele pode alcançar.

Para criar um mundo virtual interessante e envolvente, é necessário equilibrar cuidadosamente eficiência computacional e diversão. Isso inclui decidir que tipo de tempo usar (síncrono ou assíncrono) e avaliar a forma das leis da física que governam o mundo. O tamanho da área à qual se aplicam as leis da física é outra decisão importante. Ao fazer essas escolhas com cuidado, os construtores de mundo podem não apenas manter a carga computacional do mundo interessante de gerenciar, mas também fornecer a outros desenvolvedores uma base altamente fértil para inovação.