Os rollups de aplicativos estão emergindo como os vencedores claros no dimensionamento de um conjunto específico de aplicativos da Ethereum. Esses aplicativos se beneficiam de fortes garantias de propriedade sem permissão, mas não exigem interações simultâneas entre todos os usuários do aplicativo. Os jogos totalmente on-chain (FOGs) são o melhor exemplo que se enquadra nesta descrição. Os FOGs se beneficiam de uma forte propriedade de ativos no jogo, participação em jogos sem permissão e modificação de jogos sem permissão. Ainda assim, a maioria dos jogos não exige que todos os jogadores interajam ao mesmo tempo. Outros aplicativos que podem se beneficiar das estratégias de escalabilidade de rollup de aplicativos incluem mercados NFT, trocas perpétuas e inferência de IA na cadeia.

Os rollups de aplicativos já são a implementação ideal para muitos desses casos de uso. Entretanto, as implementações de rollup padrão, ou seja, rollups de EVM, ainda possuem importantes limites de escalabilidade. Eles provavelmente podem atingir rendimentos em torno de 100 transações por segundo. Esse rendimento pode ser suficiente para alguns jogos on-chain, dependendo do tipo de jogo. No entanto, a maioria dos jogos precisa de um rendimento muito maior para suportar um grande número (> 1.000) de jogadores simultâneos. Este artigo se concentra nas abordagens de dimensionamento de rollups de aplicativos para alcançar centenas de milhares de participantes simultâneos. Para cada abordagem, discuto o tipo adequado de aplicativos/jogos e os desafios enfrentados.

Os criadores que usam rollups de aplicativos ou que estão construindo a infraestrutura para dimensionar rollups de aplicativos são incentivados a entrar em contato comigo e se inscrever na Alliance. Estou ansioso para trabalhar com fundadores construindo nessas áreas.

Dimensionamento horizontal

A escalabilidade horizontal é a abordagem mais simples para dimensionar rollups de aplicativos. No entanto, a simplicidade custa a perda da capacidade de composição, o que os torna adequados apenas para um pequeno conjunto de aplicações, como jogos para um jogador.

Escalabilidade horizontal significa simplesmente implantar vários rollups de aplicativos (OP ou ZK) com o mesmo contrato inteligente implantado em todos os rollups. O front-end do aplicativo direciona perfeitamente o usuário para um dos rollups dependendo da capacidade, localização ou opções específicas do aplicativo. Alt Layer demonstrou recentemente esse conceito ao lançar um FOCG 2048 escalável. Na interface do jogo, o usuário tem a opção de selecionar em qual rollup ingressar com base em sua localização geográfica. Devido à simplicidade e disponibilidade de provedores de rollup como serviço, como a Caldera, que cuidam de todo o trabalho de infraestrutura relacionado à rotação e ao gerenciamento desses rollups, essa abordagem pode ser facilmente adotada pelos desenvolvedores de jogos.

Apesar da simplicidade, existem alguns problemas na abordagem de escalabilidade multi-rollup. A primeira é a comutação de rede rollup. As carteiras atuais, por exemplo, Metamask, requerem aprovação manual para se conectarem a uma nova rede, ou seja, instância rollup. Isso leva a uma experiência de usuário difícil e confusa para jogadores que precisam se conectar manualmente a várias “redes” para jogar o mesmo jogo. Felizmente, é possível abstrair esta complexidade com soluções de AA. Ou seja, EIP 4337 e carteiras incorporadas como Privy e 0xPass.

Outro desafio é a gestão do estado dos jogadores durante a transição entre rollup. Em alguns casos, por exemplo, queda de capacidade, o aplicativo pode precisar consolidar diversas instâncias de rollup em uma única instância para economizar recursos. Nesse caso, todo o estado do jogador ativo precisa ser migrado para a nova instância. As soluções de pontes atuais, especificamente as pontes zk, podem ser críticas na resolução deste problema. Usando essas soluções, é possível fazer a ponte entre o estado do jogo do jogador e uma nova instância de rollup, mantendo ao mesmo tempo uma prova da validade desse estado. No entanto, a latência das soluções de ponte existentes pode ser menos ideal para casos de uso de jogos.

Canais estaduais ZK

Outra abordagem de escalonamento de rollup de aplicativos que é mais adequada para jogos multijogador, por exemplo, pôquer, são os canais de estado zk. Nestes jogos, as interações dos jogadores acontecem entre um pequeno número de jogadores, por exemplo, 2–10. O jogo entre esses jogadores só é importante enquanto o jogo avança. O resultado final do jogo é, no entanto, mais importante porque afecta o equilíbrio dos activos de cada jogador. Portanto, é importante armazenar o resultado em uma camada persistente compartilhada.

Nesse caso, o acúmulo de aplicativos representa a camada de informações compartilhadas onde os resultados do jogo são armazenados e onde existem os ativos do jogo. Para cada jogo no rollup, um ZK State Channel pode ser iniciado para servir este jogo. Durante o jogo, cada jogador gera transações e cria um ZKP comprovando que seguiu as regras do jogo. As provas de interações de outros jogadores agregam provas anteriores usando provas recursivas. Quando o jogo termina, o ZKP final é submetido ao rollup do aplicativo para comprovar a validade do jogo e a validade do resultado final. A mudança de estado resultante do jogo altera os estados do jogador no pacote cumulativo de aplicativos.

Os canais de estado ZK movem as interações do jogo para fora da cadeia. Portanto, as atividades e transações no jogo não contam para o rendimento do rollup do aplicativo. Usando essa abordagem, os rollups de aplicativos podem ser dimensionados massivamente para suportar dezenas ou centenas de milhares de jogadores simultâneos. As transações de rollup de aplicativos serão apenas a verificação dos ZKPs gerados e das transações de atualização de estado, resultando em um fator de escala de 100–1000x. Várias equipes, incluindo a Ontropy , têm se concentrado no desenvolvimento desta tecnologia.

Uma desvantagem dessa abordagem é que ela exige que os jogadores executem a lógica do jogo e gerem os ZKPs em seus dispositivos. Muitas vezes, essas provas são leves e, ao utilizar sistemas de prova de última geração como o Halo2, a prova pode levar menos de alguns segundos. No entanto, isso ainda pode levar a uma experiência de usuário degradada para jogadores com dispositivos com recursos limitados.

Uma modificação nesta abordagem que pode aliviar esse problema é atribuir um dos participantes do canal de estado zk como um sequenciador temporário. Este sequenciador receberá as transações de cada jogador e gerará os ZKPs correspondentes e compartilhará os ZKP com todos os participantes do canal. Essa modificação pode ser considerada como ZK L3s efêmeros que se contentam com o pacote cumulativo de aplicativos. A equipe do Cartridge vem implementando essa arquitetura projetando um sequenciador especializado chamado Katana.

A abordagem do canal zk state tem muito potencial. No entanto, existem várias questões em aberto relacionadas ao ambiente de execução dentro do canal de estado zk e como otimizá-lo para recursão de prova. Os ambientes zkEVM atuais não são muito eficientes e a maioria deles atualmente não suporta recursão de prova. As alternativas incluem zkVMs leves ou até mesmo o uso de circuitos zk especializados para interações do jogador se o número de ações possíveis para o jogador for limitado.

Mudando o ambiente de execução

Uma terceira abordagem para a escalabilidade do rollup de aplicativos é alterar o ambiente de execução do rollup. Apesar da maturidade e abundância das ferramentas de desenvolvimento EVM, elas não são adequadas para aplicações de alto desempenho, como jogos. Além disso, o modelo de execução e armazenamento de thread único EVM leva a uma taxa de transferência reduzida que pode ser melhorada.

A principal vantagem desta abordagem é que melhorar o rendimento do rollup não requer sacrificar a capacidade de composição ou restringir o número de casos de uso. Essa abordagem pode funcionar para qualquer aplicativo Web 3, desde que o ambiente de execução possa atingir o rendimento exigido pelo aplicativo. Isso os torna a única solução viável para aplicações que exigem acesso a um estado compartilhado, como AMMs, protocolos de empréstimo e outras aplicações DeFi.

Expandindo a funcionalidade EVM por meio de pré-compilações

A primeira abordagem é que o rollup permaneça compatível com EVM e resolva algumas das limitações de rendimento por meio de pré-compilações. A ideia aqui é simples. Uma pré-compilação é simplesmente mover operações EVM computacionalmente dispendiosas para o nível do nó. Uma operação que exigiria centenas ou milhares de OPs de EVM e consumiria mais de 100 mil gás pode ser simplificada em uma única operação com custos de gás 100 vezes mais baixos. A expansão do ambiente de rollup com pré-compilações costuma ser chamada de EVM+. Exemplos desta abordagem incluem o apoio à privacidade na cadeia e o apoio a esquemas de assinatura mais eficientes, por exemplo, assinaturas BLS. Por exemplo, o jogo de pôquer zkHoldem usa operações especializadas FHE e zk para conseguir distribuição e revelação de cartas de pôquer privadas. O desenvolvimento dessas pré-compilações especializadas costuma ser um esforço compartilhado entre o desenvolvedor de rollup de aplicativos e os provedores de Raas que gerenciam a implantação e a manutenção da infraestrutura de rollups de aplicativos.

Usando um ambiente de execução não EVM

Outra abordagem para melhorar o ambiente de execução do rollup é libertar-se do EVM. Essa abordagem está se tornando mais popular entre os desenvolvedores que são novos no ecossistema Ethereum e entre os desenvolvedores que acreditam que Solidity não é a melhor linguagem para desenvolver aplicativos complexos.

Hoje temos aplicativos rollup que são executados em tempos de execução WASM, SVM, Cairo e até mesmo Linux. A maioria dessas abordagens permite que os desenvolvedores escrevam seus contratos inteligentes em linguagens de alto nível, como Rust ou C. A desvantagem é que a interoperabilidade com os contratos existentes do Solidity é frequentemente perdida. Porém, ainda é possível criar compatibilidade com o EVM. Por exemplo, a caneta da Aributrum emprega um coprocessador para tornar os contratos da Stylus compatíveis com o EVM. Este design aproxima a Stylus de uma arquitetura EVM+ do que de uma arquitetura não EVM.

Ambientes de execução híbrida

Uma terceira abordagem que é particularmente popular nos FOGs é combinar as melhores características das duas abordagens anteriores. Esta abordagem combina a compatibilidade EVM com o ambiente de execução especializado não EVM. Os ambientes não EVM concentram-se na execução de alto desempenho das primitivas principais do jogo. O gerenciamento de ativos no jogo, por exemplo, a negociação de NFTs no jogo, pode ser feito por contratos padrão do Solidity.

A vantagem desta abordagem é que a compatibilidade do EVM garante o alinhamento com um ecossistema maior de desenvolvedores e produtos existentes. Ele também permite composição sem permissão. Os desenvolvedores podem modificar e estender a lógica do jogo adicionando contratos inteligentes EVM/solididade. Enquanto isso, o mecanismo de jogo não EVM especializado atinge um alto rendimento que não pode ser satisfeito pelo EVM.

Exemplos desta abordagem são World Engine da Argus e Keystone da Curio. O World Engine separa a execução da lógica do jogo em uma camada separada chamada Game Shard, que é executada sobre a camada compatível com EVM. O Game Shard também foi projetado para permitir o dimensionamento horizontal para ajustar o rendimento total do rollup com base na demanda. Da mesma forma, a arquitetura Keystone do Curio agrupa um mecanismo de jogo de alto rendimento com o EVM como ambiente de execução de rollup. O desafio aqui é conseguir uma interoperabilidade perfeita entre o motor EVM e o motor de jogo.

Considerações sobre disponibilidade de dados

Na discussão anterior, o foco estava no aspecto principal do dimensionamento de rollups de aplicativos, que é aumentar o rendimento da transação de rollup. Existem outros tópicos relacionados a esse aumento de rendimento, como Disponibilidade de Dados (DA), descentralização do sequenciador e velocidade de liquidação. A disponibilidade de dados é o problema mais urgente para rollups de aplicativos de alto rendimento.

Um único pacote cumulativo de aplicativos pode atingir taxas de transferência superiores a 10 mil tps. Usar Ethereum como camada DA para essas transações não é possível. Primeiro, o custo médio de publicação dos dados de uma simples transferência ETH L2 em L1 pode exceder US$ 0,10. Esses custos são muito altos para a maioria dos rollups de aplicativos. Mais importante ainda, o L1 do Ethereum atualmente não pode suportar mais do que aproximadamente 8k TPS [1] para rollups que usam o L1 para DA.

Os rollups de aplicativos dependerão principalmente de soluções de DA externas. Celestia e EigenDA estão atualmente posicionadas como a opção mais viável para rollups de aplicativos. Por exemplo, o Eclipse planeja usar o Celestia para seu rollup baseado em SVM de alto rendimento. Argus e motores de jogos de alto rendimento também planejam inicialmente usar Celestia. Da mesma forma, o EigenDA, que promete uma taxa de transferência de dados de até 10 MB/s, pode ser uma solução viável para vários rollups de aplicativos.

A integração da Celestia ou da EigneDA tem, no entanto, a principal desvantagem da fuga de valor económico. O rollup do aplicativo deve pagar taxas pela camada DA, além das taxas de liquidação no Ethereum L1. As taxas de liquidação são críticas para o rollup do aplicativo porque alinham a segurança do rollup com a segurança do Ethereum. As garantias DA são menos importantes, especialmente no contexto dos FOG, onde os valores das transações são muito menores. Além disso, Celestia e EigenDA prometem taxas baixas porque estas redes são novas e inicialmente terão baixa utilização. Quando estas redes DA atingem uma elevada utilização, as taxas DA também podem tornar-se excessivas. Na minha opinião, os rollups de aplicativos deveriam usar um simples Comitê de Disponibilidade de Dados (DAC) para atestar a disponibilidade dos dados rollup[3] .

Concluindo, acredito que os rollups de aplicativos são a melhor solução existente para dimensionar aplicativos de alto rendimento em geral e jogos totalmente on-chain em específico. Dimensionar esses rollups de aplicativos é a chave para alcançar uma adoção generalizada que vai além dos usuários nativos de criptografia. Na Alliance, queremos transformar esta visão em realidade, apoiando os fundadores que estão construindo esta

Gostaria de agradecer a Matt Katz, Kevin Zhang, Tarrence van As e Larry Liu por seus valiosos comentários sobre este artigo.

[1] Supõe que 50% do limite de gás do bloco Ethereum será apenas para armazenar dados usando calldata, tamanho médio de tx de 10 bytes. Tempos de bloqueio de 12 segundos

Isenção de responsabilidade:

1. Este artigo foi reimpresso de [Aliança]. Todos os direitos autorais pertencem ao autor original [Mohamed Fouda]. Se houver objeções a esta reimpressão, entre em contato com a equipe do Gate Learn e eles cuidarão disso imediatamente.
2. Isenção de responsabilidade: As opiniões e pontos de vista expressos neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe do Gate Learn. A menos que mencionado, é proibido copiar, distribuir ou plagiar os artigos traduzidos.