Leia também: Como aprendi a parar de me preocupar e amar fragmentação de ution
Link de vídeo:
Palestrante: Scott Sunarto (@smsunarto) no Dia da Pesquisa
Edição e finalização do artigo: Justin Zhao (@hiCaptainZ)
Olá, sou Scott (@smsunarto), fundador do August Labs (@ArgusLabs_). Hoje, vou falar sobre um assunto que não abordávamos há algum tempo. Com os roll-ups se tornando o mainstream da época, não discutimos a fragmentação de execução tanto quanto discutimos a fragmentação de dados. Então, vamos revisitar esse tópico um tanto negligenciado - sharding de execução.
Esta será uma conversa fácil. Sei que você ouviu conceitos complexos o dia todo, então tentarei tornar essa discussão o mais prática possível. Eu preparei um design de slide adequado para esta apresentação.
Para quem não me conhece, o engraçado é que sou conhecida no Twitter como uma garota de anime. Também perdi minha formatura da faculdade só para estar aqui, para grande consternação de meus pais. Atualmente, sou o fundador da Argus Labs. Nos vemos como uma empresa de jogos, não uma empresa de infraestrutura ou criptomoeda. Uma das minhas maiores irritações é que todo mundo em jogos criptográficos quer construir ferramentas, mas ninguém quer criar conteúdo ou aplicativos. Precisamos de mais aplicativos que os usuários possam realmente usar.
Anteriormente, co-criei Dark Forest (@darkforest_eth) com meus amigos inteligentes Brian Gu (@gubsheep) e Alan Luo (@alanluo_0). Brian agora está executando o 0xPARC (@0xPARC) e é muito mais inteligente do que eu.
A discussão de hoje se concentrará na execução de sharding, mas em um contexto que a maioria das pessoas não está familiarizada com a discussão sobre a execução de sharding. Geralmente discutimos fragmentação de execução no contexto da camada 1, como fragmentação Ethereum ou fragmentação próxima. Mas hoje, quero mudar um pouco o contexto. Vamos pensar em como seria a fragmentação em um ambiente de roll-up.
A questão básica aqui é por que uma empresa de jogos criaria seu próprio roll-up e o que podemos aprender com World of Warcraft para projetar roll-ups. Além disso, exploraremos como o espaço de design para roll-ups vai muito além das realidades atuais.
Para responder a essas perguntas, vamos voltar a 2020, quando a ideia da Floresta Negra foi concebida pela primeira vez. Nós nos perguntamos: e se criássemos um jogo em que cada ação do jogo fosse uma transação on-chain? A premissa era ridícula naquela época, e ainda é para muitas pessoas hoje. Mas era uma hipótese interessante, então a construímos, e Dark Forest nasceu.
Dark Forest é um jogo MMORTS de exploração espacial full-chain baseado inteiramente em Ethereum, alimentado por ZK-Snarks. Em 2020, o ZK não era tão popular quanto hoje porque quase não havia documentação. A única documentação disponível para Circom é o Google Docs de Jordi Baylina (@jbaylina). Apesar dos desafios, aprendemos muito ao longo do caminho, e Dark Forest é a personificação desses aprendizados.
Dark Forest é um experimento maior do que pensávamos. Temos mais de 10.000 jogadores, trilhões de gasolina gasta, caos no jogo, gente apunhalando pelas costas na corrente. A coisa mais fascinante sobre Dark Forest e jogos on-chain é a natureza da plataforma. Ao ter um jogo full-chain, você abre a porta para projetar espaço para comportamentos emergentes, permitindo que as pessoas construam contratos inteligentes que interagem com o jogo, bem como clientes alternativos e modos de jogo, como Dark Forest Arena e GPU mineradores.
No entanto, com grandes poderes vêm grandes responsabilidades. Quando lançamos Dark Forest no xDai, agora conhecido como Gnosis Chain, acabamos preenchendo todo o espaço de blocos da cadeia. Isso torna a cadeia basicamente inutilizável para qualquer outra coisa, incluindo DeFi, NFTs ou qualquer outra coisa xDAI.
E agora? Chegamos a um beco sem saída? Os jogos full-chain nunca se tornarão uma realidade? Ou vamos voltar a fazer jogos onde apenas pequenas imagens JPEG estão na cadeia e convencer as pessoas de que o dinheiro cresce nas árvores? A resposta é: deixamos o software fazer as coisas. Muitos de nós temos uma visão muito rígida de blockchain e roll-ups, como se não houvesse muito espaço para melhorias. Mas eu discordo. Podemos experimentar e encontrar novas possibilidades.
Fizemos uma pergunta a nós mesmos: se desenhássemos um blockchain do zero para jogos e apenas jogos, como seria? Precisamos de alta taxa de transferência, portanto, precisamos escalar leituras e gravações. A maioria dos blockchains é projetada para ser pesada para gravação. Transações por segundo (TPS) é uma métrica da qual as pessoas se gabam, mas, na realidade, as leituras são igualmente importantes. Como você sabe onde um jogador está se não consegue ler de um nó blockchain? Este é realmente o primeiro gargalo que encontramos na construção de blockchain.
A Dark Forest tem um problema em que os nós completos são muito usados e a E/S explode porque precisamos ler dados do estado na cadeia. Isso resultou em milhares de dólares em custos de servidor, que foram generosamente cobertos para nós pela equipe xDAI. No entanto, isso não é ideal para o longo prazo. Precisamos de alto throughput, não apenas para transações escritas por segundo, mas também para leituras, como buscar dados do próprio blockchain.
Também precisamos de um blockchain escalável horizontalmente para evitar o problema do vizinho barulhento. Não queremos que um jogo popular comece a travar repentinamente no blockchain, interrompendo todo o trabalho. Também precisamos de flexibilidade e customização para que possamos modificar a máquina de estados a ser projetada para o jogo. Isso inclui ter um loop de jogo, tornando-o auto-executável, etc.
Por último, mas não menos importante, para aqueles que não estão familiarizados com a arquitetura dos jogos online, isso pode ser um pouco vago, precisamos de uma alta taxa de ticks. Ticks são a unidade atômica de tempo no mundo do jogo. No contexto das blockchains, temos os blocos como unidades atômicas de tempo. Nos jogos, temos carrapatos. Isso é quase semelhante quando você cria um jogo full-chain, onde a taxa de geração de ticks ou blocos do seu blockchain é igual ao tick do próprio jogo.
Portanto, o que precisamos é de um blockchain com alto throughput, escalabilidade horizontal, flexibilidade e customização e alta taxa de ticks. Esse design pode atender às necessidades do blockchain que projetamos do zero para o jogo.
Se você tiver uma taxa de ticks mais alta ou mais blocos por segundo, o jogo parecerá mais responsivo. Por outro lado, se sua taxa de ticks for baixa, o jogo parecerá lento. Uma coisa importante a lembrar é que, se os pedaços estiverem atrasados, você experimentará um atraso perceptível no jogo. Esta é uma experiência ruim. Se você já lidou com jogadores furiosos gritando com o computador por perder um jogo, essa é uma situação absolutamente terrível.
Atualmente, nossos rollups possuem um bloco por segundo, o que equivale a um tick. Se queremos ter jogos mais legais, precisamos de taxas de ticks mais altas. Por exemplo, o Minecraft, um simples jogo de pixel art, tem 26 ticks por segundo. Ainda estamos muito longe de construir um jogo tão responsivo quanto o Minecraft.
Uma possível solução é implantar nosso próprio rollup. Embora pareça corrigir o problema, na verdade não corrige a causa raiz do problema. Por exemplo, você terá maior taxa de transferência de gravação, mas não exatamente no nível que os jogos precisam. Claro, se o seu jogo tiver cem jogadores, isso será suficiente. No entanto, se você deseja criar um jogo que exija uma taxa de transferência mais alta, há restrições muito rígidas devido à maneira como o I/O é feito na compilação atual.
No lado da leitura, você realmente não obtém um ganho de desempenho. Você ainda precisa contar com indexadores. Você realmente não tem escalabilidade horizontal. Se você tentar iniciar um novo rollup para dimensionar horizontalmente seu jogo, destruirá seu ecossistema de contrato inteligente existente. Os mercados implantados por jogadores não funcionarão com outras cadeias que você lançar para escalar horizontalmente seu jogo. Isso levanta muitas questões.
Finalmente, a alta taxa de ticks e blocos por segundo ainda é um pouco desafiador, embora possamos forçar o máximo que pudermos, podemos obter dois blocos por segundo, talvez três, mas é realmente assim que essas blockchains funcionam. mais longe, porque há um monte de coisas como reorganização que dependem fortemente de ciclos de computação.
Para responder a essa questão, olhamos para o início dos anos 2000 e o final dos anos 1990, quando jogos online como MMOs estavam apenas surgindo. Eles têm um conceito chamado sharding. Este não é um conceito novo, já existia no passado. A palavra "sharding" que usamos na arquitetura de banco de dados na verdade vem de uma referência ao Ultima Online. Eles foram os primeiros a usar a palavra "shard" para explicar seus diferentes servidores.
Então, como funciona o sharding em jogos? Não é uma solução única para todos. É uma ferramenta na caixa de ferramentas, e como você a adapta ao seu jogo varia de caso para caso. Por exemplo, a primeira construção de fragmentação é o que gosto de chamar de fragmentação baseada em localização. Um bom modelo mental é imaginar um sistema de coordenadas cartesianas dividido em quatro quadrantes, cada um com sua própria fatia de jogo. Toda vez que você quiser atravessar um shard, você envia uma comunicação para outro shard dizendo "ei, eu quero me mudar para lá" e você é teletransportado para o seu shard, deixando os jogadores antes de você. Ao fazer isso, você distribui a carga de trabalho do servidor em várias instâncias físicas, em vez de forçar um servidor a fazer toda a computação para todo o mundo do jogo. A segunda configuração agora é mais popular. É chamado de sharding multiverso, onde você tem várias instâncias de jogo que se espelham. Você pode escolher qualquer fragmento para o qual deseja ir e sua carga é balanceada por padrão para que cada servidor não fique superlotado.
Agora, a questão principal é: como você traz esse conceito para o rollup? É por isso que criamos o World Engine. O World Engine é nossa principal infraestrutura, basicamente um classificador de fragmentos opinativo projetado para startups. O nosso é diferente e mais adequado às nossas necessidades do que muitos dos designs de classificadores de fragmentos que vimos nas últimas discussões. A direção da nossa otimização é: A, throughput, B, queremos garantir que não haja bloqueios bloqueando o tempo de execução para garantir que a taxa de ticks e o tempo de bloqueio sejam os mais eficientes possíveis, portanto, é síncrono por padrão, o caminho projetamos que o classificador é uma classificação parcial, em vez de forçar a ordenação total (cada transação precisa acontecer após a outra).
Os principais componentes aqui são que temos duas coisas principais. Temos sharding baseado em EVM, que é como uma cadeia EVM pura, na qual os jogadores podem implantar contratos inteligentes, combinar com jogos, criar mercados com impostos e assim por diante. É como uma corrente normal, certo? Algo como um bloco por segundo ou algo assim, apenas o suficiente para você fazer todos os seus dispositivos e mercados típicos.
O ingrediente secreto aqui é que também usamos um fragmento de jogo, que é essencialmente um mini-blockchain projetado como um servidor de jogo de alto desempenho. Temos uma interface de implementação própria para que você possa personalizar esse fragmento ao seu gosto. Você pode construir seus próprios fragmentos e injetá-los no fragmento base. Você só precisa implementar um conjunto de interfaces padrão, assim como o Cosmos que você conhece, o Cosmos possui uma interface ABC. Basicamente, você pode reunir isso em uma especificação semelhante, trazendo seus próprios fragmentos para a pilha do World Engine.
A chave aqui é que temos uma alta taxa de ticks que atualmente não conseguimos alcançar com a construção de sharding atual. É aqui que quero apresentar o Cardeal. Cardinal é a primeira implementação de fragmentação de jogo do World Engine. Ele usa Entity-Component-System (ECS) com uma arquitetura orientada a dados. Isso nos permite paralelizar o jogo e aumentar o rendimento dos cálculos do jogo. Tem uma taxa de tick configurável de até 20 ticks por segundo. Para o pessoal do blockchain aqui, são 20 blocos por segundo.
Também podemos geolocalizá-lo para reduzir a latência. Por exemplo, você pode ter um classificador nos EUA e os asiáticos precisam esperar 300 milissegundos para que a transação chegue ao classificador. Este é um grande problema em jogos porque 300ms é muito tempo. Se você tentar jogar um jogo FPS com um atraso de 200ms, basicamente, você está morto.
Outro ponto chave que também é importante para nós é que ele é auto-indexado. Não precisamos mais de indexadores externos. Não precisamos dessas estruturas para armazenar em cache o estado do jogo. Isso também nos permite criar mais jogos em tempo real sem problemas de latência, pois o indexador ainda está tentando alcançar os blocos do classificador.
Também temos um sistema de plug-ins que permite que as pessoas paralelizem a validação do ZK, etc. A melhor parte, pelo menos para mim, é que você pode escrever seu código em Go. Não é mais necessário usar Solidity para fazer seu jogo funcionar. Se você já tentou construir um jogo blockchain com Solidity, foi um pesadelo.
No entanto, o ponto principal de nossa construção de shard é que você pode construir qualquer coisa como um shard. Eles são basicamente um espaço de design infinito, como um fragmento pode ser.
Supondo que você não goste de escrever o código do jogo em Go, você pode escolher outras maneiras. No entanto, estamos trabalhando em um shard de jogo Solidity que permitirá que você implemente jogos em Solidity, de uma forma que ofereça a possibilidade de codificação, mantendo muitos dos benefícios do Cardinal. Você também pode criar um fragmento cunhado por NFT com um mempool exclusivo e uma construção de pedido, resolvendo o problema do vizinho barulhento semelhante à cunhagem básica. Você pode até mesmo criar um fragmento de identidade de jogo e usar NFT para representar sua identidade de jogo, para que possa conduzir facilmente transações de identidade de jogo por meio de NFT em vez de compartilhar chaves privadas.
Esta é uma arquitetura de alto nível e não entrarei em muitos detalhes hoje devido a restrições de tempo. Crucialmente, permitimos que os contratos inteligentes EVM sejam combinados com fragmentos de jogo usando pick and pass personalizados. Criamos um wrapper em torno de Geth para permitir a comunicação entre eles, o que abre muito espaço de design em ambas as direções. Somos síncronos por padrão e podemos interoperar de forma integrada e composta entre estilhaços sem bloqueios.
Nosso classificador compartilhado é diferente porque não usa a construção de sequência compartilhada de feixes atômicos que priorizam a classificação global, o que requer um mecanismo de bloqueio e causa problemas como bloqueio do thread principal, levando a taxas de tick e tempos de bloqueio erráticos, e o resultado é atraso no jogo. Ele também impõe limites nos tempos de bloco por shard e requer várias criptoeconomias e construções para evitar a negação de serviço. Há também um grande problema que não vi mencionado em muitas construções de classificador de VCR: se você tiver shards diferentes que dependem uns dos outros e causam impasses, como resolvê-lo? Com o design assíncrono, isso não é um problema, porque todo mundo faz o que quer fazer e depois deixa para lá.
Na verdade, feixes atômicos e roll-ups em fragmentos geralmente não são necessários. Para nosso caso de uso, não precisamos de nada que exija feixes atômicos, nem achamos que devemos projetar nossos Roll-Ups em torno da pureza do caso de uso. Isso também traz muitos outros recursos interessantes. Por exemplo, cada fragmento de jogo pode ter uma camada DA separada para a cadeia de base. Por exemplo, você pode usar o fragmento de base para enviar dados para o Ethereum, e o fragmento do jogo pode enviar dados para o Celestia (semelhante ao comitê de disponibilidade de dados). Você também pode reduzir os requisitos de hardware para executar um nó completo, porque pode executar o nó completo do fragmento base Geth separadamente, sem executar o nó do fragmento do jogo, o que facilita a integração com coisas como o Alchemy.
Para resumir, quero ser honesto aqui que muitas pessoas esperam que seus constructos resolvam todos os seus problemas, mas nós não. Achamos que nossa construção funciona para nós, mas pode não funcionar para o seu caso de uso. É irreal supor que nossas construções funcionarão para todos. Para nós, ele atende às nossas necessidades, oferece alto rendimento, escalabilidade horizontal, flexibilidade e altas taxas de escala, mas não é uma cura para o câncer. Se você precisa de um protocolo DeFi que exija capacidade de composição síncrona, essa construção pode não ser para você.
Em geral, eu realmente acredito no conceito de uma arquitetura blockchain centrada no ser humano. Ao projetar em torno de funções de usuário e casos de uso específicos, você pode fazer compensações melhor, em vez de tentar resolver os problemas de todos. A era do renascimento chegou e todos podem projetar seus próprios Roll-Ups para atender às suas necessidades específicas, em vez de confiar em uma solução geral. Acho que devemos abraçar a Explosão Cambriana. Não crie roll-ups como a camada um com tamanho único porque não foi projetado para resolver o mesmo problema. Pessoalmente, estou ansioso para ver mais pessoas explorando mais o espaço de design do Roll-Up para casos de uso. Por exemplo, como seria um Roll-Up projetado especificamente para troca de ativos? Será baseado em intenção? Como seria um Roll-Up projetado especificamente para CLOBs (Central Limit Order Book) on-chain? Aqui, entrego o microfone para MJ. Obrigado pelo convite.
Versão em inglês:
Ver original
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
Por que a Argus usa sharding para construir uma infraestrutura de jogo de cadeia completa?
Leia também: Como aprendi a parar de me preocupar e amar fragmentação de ution
Link de vídeo:
Palestrante: Scott Sunarto (@smsunarto) no Dia da Pesquisa
Edição e finalização do artigo: Justin Zhao (@hiCaptainZ)
Olá, sou Scott (@smsunarto), fundador do August Labs (@ArgusLabs_). Hoje, vou falar sobre um assunto que não abordávamos há algum tempo. Com os roll-ups se tornando o mainstream da época, não discutimos a fragmentação de execução tanto quanto discutimos a fragmentação de dados. Então, vamos revisitar esse tópico um tanto negligenciado - sharding de execução.
Esta será uma conversa fácil. Sei que você ouviu conceitos complexos o dia todo, então tentarei tornar essa discussão o mais prática possível. Eu preparei um design de slide adequado para esta apresentação.
Para quem não me conhece, o engraçado é que sou conhecida no Twitter como uma garota de anime. Também perdi minha formatura da faculdade só para estar aqui, para grande consternação de meus pais. Atualmente, sou o fundador da Argus Labs. Nos vemos como uma empresa de jogos, não uma empresa de infraestrutura ou criptomoeda. Uma das minhas maiores irritações é que todo mundo em jogos criptográficos quer construir ferramentas, mas ninguém quer criar conteúdo ou aplicativos. Precisamos de mais aplicativos que os usuários possam realmente usar.
Anteriormente, co-criei Dark Forest (@darkforest_eth) com meus amigos inteligentes Brian Gu (@gubsheep) e Alan Luo (@alanluo_0). Brian agora está executando o 0xPARC (@0xPARC) e é muito mais inteligente do que eu.
A discussão de hoje se concentrará na execução de sharding, mas em um contexto que a maioria das pessoas não está familiarizada com a discussão sobre a execução de sharding. Geralmente discutimos fragmentação de execução no contexto da camada 1, como fragmentação Ethereum ou fragmentação próxima. Mas hoje, quero mudar um pouco o contexto. Vamos pensar em como seria a fragmentação em um ambiente de roll-up.
A questão básica aqui é por que uma empresa de jogos criaria seu próprio roll-up e o que podemos aprender com World of Warcraft para projetar roll-ups. Além disso, exploraremos como o espaço de design para roll-ups vai muito além das realidades atuais.
Para responder a essas perguntas, vamos voltar a 2020, quando a ideia da Floresta Negra foi concebida pela primeira vez. Nós nos perguntamos: e se criássemos um jogo em que cada ação do jogo fosse uma transação on-chain? A premissa era ridícula naquela época, e ainda é para muitas pessoas hoje. Mas era uma hipótese interessante, então a construímos, e Dark Forest nasceu.
Dark Forest é um jogo MMORTS de exploração espacial full-chain baseado inteiramente em Ethereum, alimentado por ZK-Snarks. Em 2020, o ZK não era tão popular quanto hoje porque quase não havia documentação. A única documentação disponível para Circom é o Google Docs de Jordi Baylina (@jbaylina). Apesar dos desafios, aprendemos muito ao longo do caminho, e Dark Forest é a personificação desses aprendizados.
Dark Forest é um experimento maior do que pensávamos. Temos mais de 10.000 jogadores, trilhões de gasolina gasta, caos no jogo, gente apunhalando pelas costas na corrente. A coisa mais fascinante sobre Dark Forest e jogos on-chain é a natureza da plataforma. Ao ter um jogo full-chain, você abre a porta para projetar espaço para comportamentos emergentes, permitindo que as pessoas construam contratos inteligentes que interagem com o jogo, bem como clientes alternativos e modos de jogo, como Dark Forest Arena e GPU mineradores.
No entanto, com grandes poderes vêm grandes responsabilidades. Quando lançamos Dark Forest no xDai, agora conhecido como Gnosis Chain, acabamos preenchendo todo o espaço de blocos da cadeia. Isso torna a cadeia basicamente inutilizável para qualquer outra coisa, incluindo DeFi, NFTs ou qualquer outra coisa xDAI.
E agora? Chegamos a um beco sem saída? Os jogos full-chain nunca se tornarão uma realidade? Ou vamos voltar a fazer jogos onde apenas pequenas imagens JPEG estão na cadeia e convencer as pessoas de que o dinheiro cresce nas árvores? A resposta é: deixamos o software fazer as coisas. Muitos de nós temos uma visão muito rígida de blockchain e roll-ups, como se não houvesse muito espaço para melhorias. Mas eu discordo. Podemos experimentar e encontrar novas possibilidades.
Fizemos uma pergunta a nós mesmos: se desenhássemos um blockchain do zero para jogos e apenas jogos, como seria? Precisamos de alta taxa de transferência, portanto, precisamos escalar leituras e gravações. A maioria dos blockchains é projetada para ser pesada para gravação. Transações por segundo (TPS) é uma métrica da qual as pessoas se gabam, mas, na realidade, as leituras são igualmente importantes. Como você sabe onde um jogador está se não consegue ler de um nó blockchain? Este é realmente o primeiro gargalo que encontramos na construção de blockchain.
A Dark Forest tem um problema em que os nós completos são muito usados e a E/S explode porque precisamos ler dados do estado na cadeia. Isso resultou em milhares de dólares em custos de servidor, que foram generosamente cobertos para nós pela equipe xDAI. No entanto, isso não é ideal para o longo prazo. Precisamos de alto throughput, não apenas para transações escritas por segundo, mas também para leituras, como buscar dados do próprio blockchain.
Também precisamos de um blockchain escalável horizontalmente para evitar o problema do vizinho barulhento. Não queremos que um jogo popular comece a travar repentinamente no blockchain, interrompendo todo o trabalho. Também precisamos de flexibilidade e customização para que possamos modificar a máquina de estados a ser projetada para o jogo. Isso inclui ter um loop de jogo, tornando-o auto-executável, etc.
Por último, mas não menos importante, para aqueles que não estão familiarizados com a arquitetura dos jogos online, isso pode ser um pouco vago, precisamos de uma alta taxa de ticks. Ticks são a unidade atômica de tempo no mundo do jogo. No contexto das blockchains, temos os blocos como unidades atômicas de tempo. Nos jogos, temos carrapatos. Isso é quase semelhante quando você cria um jogo full-chain, onde a taxa de geração de ticks ou blocos do seu blockchain é igual ao tick do próprio jogo.
Portanto, o que precisamos é de um blockchain com alto throughput, escalabilidade horizontal, flexibilidade e customização e alta taxa de ticks. Esse design pode atender às necessidades do blockchain que projetamos do zero para o jogo.
Se você tiver uma taxa de ticks mais alta ou mais blocos por segundo, o jogo parecerá mais responsivo. Por outro lado, se sua taxa de ticks for baixa, o jogo parecerá lento. Uma coisa importante a lembrar é que, se os pedaços estiverem atrasados, você experimentará um atraso perceptível no jogo. Esta é uma experiência ruim. Se você já lidou com jogadores furiosos gritando com o computador por perder um jogo, essa é uma situação absolutamente terrível.
Atualmente, nossos rollups possuem um bloco por segundo, o que equivale a um tick. Se queremos ter jogos mais legais, precisamos de taxas de ticks mais altas. Por exemplo, o Minecraft, um simples jogo de pixel art, tem 26 ticks por segundo. Ainda estamos muito longe de construir um jogo tão responsivo quanto o Minecraft.
Uma possível solução é implantar nosso próprio rollup. Embora pareça corrigir o problema, na verdade não corrige a causa raiz do problema. Por exemplo, você terá maior taxa de transferência de gravação, mas não exatamente no nível que os jogos precisam. Claro, se o seu jogo tiver cem jogadores, isso será suficiente. No entanto, se você deseja criar um jogo que exija uma taxa de transferência mais alta, há restrições muito rígidas devido à maneira como o I/O é feito na compilação atual.
No lado da leitura, você realmente não obtém um ganho de desempenho. Você ainda precisa contar com indexadores. Você realmente não tem escalabilidade horizontal. Se você tentar iniciar um novo rollup para dimensionar horizontalmente seu jogo, destruirá seu ecossistema de contrato inteligente existente. Os mercados implantados por jogadores não funcionarão com outras cadeias que você lançar para escalar horizontalmente seu jogo. Isso levanta muitas questões.
Finalmente, a alta taxa de ticks e blocos por segundo ainda é um pouco desafiador, embora possamos forçar o máximo que pudermos, podemos obter dois blocos por segundo, talvez três, mas é realmente assim que essas blockchains funcionam. mais longe, porque há um monte de coisas como reorganização que dependem fortemente de ciclos de computação.
Para responder a essa questão, olhamos para o início dos anos 2000 e o final dos anos 1990, quando jogos online como MMOs estavam apenas surgindo. Eles têm um conceito chamado sharding. Este não é um conceito novo, já existia no passado. A palavra "sharding" que usamos na arquitetura de banco de dados na verdade vem de uma referência ao Ultima Online. Eles foram os primeiros a usar a palavra "shard" para explicar seus diferentes servidores.
Então, como funciona o sharding em jogos? Não é uma solução única para todos. É uma ferramenta na caixa de ferramentas, e como você a adapta ao seu jogo varia de caso para caso. Por exemplo, a primeira construção de fragmentação é o que gosto de chamar de fragmentação baseada em localização. Um bom modelo mental é imaginar um sistema de coordenadas cartesianas dividido em quatro quadrantes, cada um com sua própria fatia de jogo. Toda vez que você quiser atravessar um shard, você envia uma comunicação para outro shard dizendo "ei, eu quero me mudar para lá" e você é teletransportado para o seu shard, deixando os jogadores antes de você. Ao fazer isso, você distribui a carga de trabalho do servidor em várias instâncias físicas, em vez de forçar um servidor a fazer toda a computação para todo o mundo do jogo. A segunda configuração agora é mais popular. É chamado de sharding multiverso, onde você tem várias instâncias de jogo que se espelham. Você pode escolher qualquer fragmento para o qual deseja ir e sua carga é balanceada por padrão para que cada servidor não fique superlotado.
Agora, a questão principal é: como você traz esse conceito para o rollup? É por isso que criamos o World Engine. O World Engine é nossa principal infraestrutura, basicamente um classificador de fragmentos opinativo projetado para startups. O nosso é diferente e mais adequado às nossas necessidades do que muitos dos designs de classificadores de fragmentos que vimos nas últimas discussões. A direção da nossa otimização é: A, throughput, B, queremos garantir que não haja bloqueios bloqueando o tempo de execução para garantir que a taxa de ticks e o tempo de bloqueio sejam os mais eficientes possíveis, portanto, é síncrono por padrão, o caminho projetamos que o classificador é uma classificação parcial, em vez de forçar a ordenação total (cada transação precisa acontecer após a outra).
Os principais componentes aqui são que temos duas coisas principais. Temos sharding baseado em EVM, que é como uma cadeia EVM pura, na qual os jogadores podem implantar contratos inteligentes, combinar com jogos, criar mercados com impostos e assim por diante. É como uma corrente normal, certo? Algo como um bloco por segundo ou algo assim, apenas o suficiente para você fazer todos os seus dispositivos e mercados típicos.
O ingrediente secreto aqui é que também usamos um fragmento de jogo, que é essencialmente um mini-blockchain projetado como um servidor de jogo de alto desempenho. Temos uma interface de implementação própria para que você possa personalizar esse fragmento ao seu gosto. Você pode construir seus próprios fragmentos e injetá-los no fragmento base. Você só precisa implementar um conjunto de interfaces padrão, assim como o Cosmos que você conhece, o Cosmos possui uma interface ABC. Basicamente, você pode reunir isso em uma especificação semelhante, trazendo seus próprios fragmentos para a pilha do World Engine.
A chave aqui é que temos uma alta taxa de ticks que atualmente não conseguimos alcançar com a construção de sharding atual. É aqui que quero apresentar o Cardeal. Cardinal é a primeira implementação de fragmentação de jogo do World Engine. Ele usa Entity-Component-System (ECS) com uma arquitetura orientada a dados. Isso nos permite paralelizar o jogo e aumentar o rendimento dos cálculos do jogo. Tem uma taxa de tick configurável de até 20 ticks por segundo. Para o pessoal do blockchain aqui, são 20 blocos por segundo.
Também podemos geolocalizá-lo para reduzir a latência. Por exemplo, você pode ter um classificador nos EUA e os asiáticos precisam esperar 300 milissegundos para que a transação chegue ao classificador. Este é um grande problema em jogos porque 300ms é muito tempo. Se você tentar jogar um jogo FPS com um atraso de 200ms, basicamente, você está morto.
Outro ponto chave que também é importante para nós é que ele é auto-indexado. Não precisamos mais de indexadores externos. Não precisamos dessas estruturas para armazenar em cache o estado do jogo. Isso também nos permite criar mais jogos em tempo real sem problemas de latência, pois o indexador ainda está tentando alcançar os blocos do classificador.
Também temos um sistema de plug-ins que permite que as pessoas paralelizem a validação do ZK, etc. A melhor parte, pelo menos para mim, é que você pode escrever seu código em Go. Não é mais necessário usar Solidity para fazer seu jogo funcionar. Se você já tentou construir um jogo blockchain com Solidity, foi um pesadelo.
No entanto, o ponto principal de nossa construção de shard é que você pode construir qualquer coisa como um shard. Eles são basicamente um espaço de design infinito, como um fragmento pode ser.
Supondo que você não goste de escrever o código do jogo em Go, você pode escolher outras maneiras. No entanto, estamos trabalhando em um shard de jogo Solidity que permitirá que você implemente jogos em Solidity, de uma forma que ofereça a possibilidade de codificação, mantendo muitos dos benefícios do Cardinal. Você também pode criar um fragmento cunhado por NFT com um mempool exclusivo e uma construção de pedido, resolvendo o problema do vizinho barulhento semelhante à cunhagem básica. Você pode até mesmo criar um fragmento de identidade de jogo e usar NFT para representar sua identidade de jogo, para que possa conduzir facilmente transações de identidade de jogo por meio de NFT em vez de compartilhar chaves privadas.
Esta é uma arquitetura de alto nível e não entrarei em muitos detalhes hoje devido a restrições de tempo. Crucialmente, permitimos que os contratos inteligentes EVM sejam combinados com fragmentos de jogo usando pick and pass personalizados. Criamos um wrapper em torno de Geth para permitir a comunicação entre eles, o que abre muito espaço de design em ambas as direções. Somos síncronos por padrão e podemos interoperar de forma integrada e composta entre estilhaços sem bloqueios.
Nosso classificador compartilhado é diferente porque não usa a construção de sequência compartilhada de feixes atômicos que priorizam a classificação global, o que requer um mecanismo de bloqueio e causa problemas como bloqueio do thread principal, levando a taxas de tick e tempos de bloqueio erráticos, e o resultado é atraso no jogo. Ele também impõe limites nos tempos de bloco por shard e requer várias criptoeconomias e construções para evitar a negação de serviço. Há também um grande problema que não vi mencionado em muitas construções de classificador de VCR: se você tiver shards diferentes que dependem uns dos outros e causam impasses, como resolvê-lo? Com o design assíncrono, isso não é um problema, porque todo mundo faz o que quer fazer e depois deixa para lá.
Na verdade, feixes atômicos e roll-ups em fragmentos geralmente não são necessários. Para nosso caso de uso, não precisamos de nada que exija feixes atômicos, nem achamos que devemos projetar nossos Roll-Ups em torno da pureza do caso de uso. Isso também traz muitos outros recursos interessantes. Por exemplo, cada fragmento de jogo pode ter uma camada DA separada para a cadeia de base. Por exemplo, você pode usar o fragmento de base para enviar dados para o Ethereum, e o fragmento do jogo pode enviar dados para o Celestia (semelhante ao comitê de disponibilidade de dados). Você também pode reduzir os requisitos de hardware para executar um nó completo, porque pode executar o nó completo do fragmento base Geth separadamente, sem executar o nó do fragmento do jogo, o que facilita a integração com coisas como o Alchemy.
Para resumir, quero ser honesto aqui que muitas pessoas esperam que seus constructos resolvam todos os seus problemas, mas nós não. Achamos que nossa construção funciona para nós, mas pode não funcionar para o seu caso de uso. É irreal supor que nossas construções funcionarão para todos. Para nós, ele atende às nossas necessidades, oferece alto rendimento, escalabilidade horizontal, flexibilidade e altas taxas de escala, mas não é uma cura para o câncer. Se você precisa de um protocolo DeFi que exija capacidade de composição síncrona, essa construção pode não ser para você.
Em geral, eu realmente acredito no conceito de uma arquitetura blockchain centrada no ser humano. Ao projetar em torno de funções de usuário e casos de uso específicos, você pode fazer compensações melhor, em vez de tentar resolver os problemas de todos. A era do renascimento chegou e todos podem projetar seus próprios Roll-Ups para atender às suas necessidades específicas, em vez de confiar em uma solução geral. Acho que devemos abraçar a Explosão Cambriana. Não crie roll-ups como a camada um com tamanho único porque não foi projetado para resolver o mesmo problema. Pessoalmente, estou ansioso para ver mais pessoas explorando mais o espaço de design do Roll-Up para casos de uso. Por exemplo, como seria um Roll-Up projetado especificamente para troca de ativos? Será baseado em intenção? Como seria um Roll-Up projetado especificamente para CLOBs (Central Limit Order Book) on-chain? Aqui, entrego o microfone para MJ. Obrigado pelo convite.
Versão em inglês: