Os rollups de aplicações estão a emergir como o vencedor claro na escalabilidade de um conjunto específico de aplicações do Ethereum. Estas aplicações beneficiam de garantias de propriedade fortes e sem permissão mas não requerem interações simultâneas entre todos os utilizadores da aplicação. Os jogos totalmente on-chain (FOGs) são o melhor exemplo que se encaixam nesta descrição. Os FOGs beneficiam de uma forte propriedade de ativos no jogo, participação em jogos sem permissão e modding de jogo sem permissão. Ainda assim, a maioria dos jogos não exige que todos os jogadores interajam uns com os outros ao mesmo tempo. Outras aplicações que podem beneficiar das estratégias de escalabilidade de rollup de aplicações incluem mercados NFT, trocas perpétuas e inferência de IA em cadeia.

Os rollups de aplicações já são a implementação de referência para muitos destes casos de utilização. No entanto, as implementações de rollup padrão, ou seja, rollups EVM, ainda têm limites importantes de escalabilidade. Eles provavelmente podem atingir throughputs em torno de 100 transações por segundo. Esse rendimento pode ser suficiente para alguns jogos na cadeia, dependendo do tipo de jogo. No entanto, a maioria dos jogos precisa de um rendimento muito maior para suportar um grande número (> 1000) de jogadores simultâneos. Este artigo centra-se nas abordagens de escalonamento de rollups de aplicações para alcançar centenas de milhares de participantes simultâneos. Para cada abordagem, discuto o tipo adequado de aplicações/jogos e os desafios com que se depara.

Os construtores que estão a usar rollups de aplicações ou aqueles que estão a construir a infra-estrutura para escalar os rollups de aplicações são encorajados a contactar-me e candidatar-se à Alliance. Estou ansioso para trabalhar com fundadores a construir nestas áreas.

Dimensionamento Horizontal

A escalabilidade horizontal é a abordagem mais simples para escalar os rollups de aplicações. No entanto, a simplicidade vem à custa da perda de 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 implementar vários rollups de aplicativos (OP ou ZK) com o mesmo contrato inteligente implantado em todos os rollups. O front-end da aplicação direciona perfeitamente o utilizador para um dos rollups dependendo da capacidade, localização ou opções específicas da aplicação. A Alt Layer demonstrou recentemente este conceito ao lançar um 2048 FOCG escalável. No frontend do jogo, o utilizador tem a opção de selecionar em qual rollup aderir com base na sua localização geográfica. Devido à simplicidade e disponibilidade de prestadores de Rollup-as-a-Service, como a Caldera, que lidam com todo o trabalho de infraestrutura relacionado com a rotação e gestão destes rollups, esta abordagem pode ser facilmente adotada pelos programadores de jogos.

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

Outro desafio é a gestão do estado dos jogadores durante uma transição entre rollup. Em alguns casos, por exemplo, quedas de capacidade, a aplicação pode ter de consolidar várias instâncias de rollup numa única instância para poupar recursos. Nesse caso, todo o estado do jogador ativo precisa ser migrado para a nova instância. As soluções de ponte atuais, especificamente as pontes zk, podem ser críticas para resolver este problema. Usando estas soluções, é possível ligar o estado do jogo do jogador a uma nova instância de rollup, mantendo 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.

ZK State Channels

Outra abordagem de escalabilidade de rollup de aplicações que é mais adequada para jogos multijogador, por exemplo, Poker, são os canais do estado zk. Nestes jogos, as interações dos jogadores acontecem entre um pequeno número de jogadores, por exemplo, 2—10. A jogada entre estes jogadores só é importante enquanto o jogo está a progredir. O resultado final do jogo é, no entanto, mais importante porque afeta o saldo de ativos de cada jogador. Por isso, é importante armazenar o resultado numa camada persistente partilhada.

Neste caso, o conjunto de aplicações representa a camada de informação partilhada onde os resultados do jogo são armazenados e onde os ativos do jogo existem. Para cada jogo no rollup, pode ser iniciado um Canal ZK State para servir este jogo. Durante o jogo, cada jogador gera transações e cria um ZKP provando que seguiu as regras do jogo. Provas de interações de outros jogadores agregam provas anteriores usando provas recursivas. Quando o jogo termina, o ZKP final é submetido ao conjunto de aplicações para provar a validade do jogo e a validade do resultado final. A mudança de estado resultante do jogo muda os estados do jogador no rollup de aplicação.

Os canais do estado ZK movem as interações do jogo fora da cadeia. Por isso, as atividades e transações no jogo não contam para o rendimento do conjunto de aplicações. Usando esta abordagem, os rollups de aplicações podem ser escalados massivamente para suportar dezenas ou centenas de milhares de jogadores simultâneos. As transações de rollup de aplicações serão apenas a verificação dos ZKPs gerados e as transações de atualização de estado, resultando num fator de escala de 100—1000x. Várias equipas, incluindo a Ontropy, têm estado a concentrar-se no desenvolvimento desta tecnologia.

Uma desvantagem desta abordagem é que exige que os jogadores executem a lógica do jogo e gerem os ZKPs nos seus dispositivos. Muitas vezes, estas provas são leves e, aproveitando sistemas de prova de última geração como o Halo2, a prova pode levar menos do que alguns segundos. No entanto, isso ainda pode levar a uma UX degradada para jogadores com dispositivos com recursos limitados.

Uma modificação desta abordagem que pode aliviar este 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 partilhará o ZKP com todos os participantes do canal. Esta modificação pode ser considerada como ZK L3s efémeros que se ajustam ao conjunto de aplicações. A equipa do Cartridge tem implementado esta arquitectura desenhando um sequenciador especializado chamado Katana.

A abordagem do canal zk state tem muito potencial. No entanto, existem várias questões em aberto relacionadas com o ambiente de execução dentro do canal zk state e como otimizá-lo para prova de recursão. Os ambientes atuais do ZkeVM não são muito eficientes e a maioria deles atualmente não suporta recursão à prova. As alternativas incluem zKVMs leves ou 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.

Alterar o Ambiente de Execução

Uma terceira abordagem para a escalabilidade do rollup de aplicações é 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 EVM single-threaded 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 utilização. Esta abordagem pode funcionar para qualquer aplicação Web 3, desde que o ambiente de execução possa atingir o rendimento exigido pela aplicação. Isto torna-os a única solução viável para aplicações que exigem o acesso a um estado partilhado como AMMs, protocolos de empréstimo e outras aplicações DeFi.

Expandir a funcionalidade EVM através de pré-compilações

A primeira abordagem é que o rollup permaneça compatível com EVM e resolVA algumas das limitações de throughput através de pré-compilações. A ideia aqui é simples. Uma pré-compilação é simplesmente mover operações EVM computacionalmente caras para baixo para o nível do nó. Uma operação que exigiria centenas ou milhares de OPs EVM e consuma 100k+ de gás pode ser simplificada numa única operação com custos de gás 100x mais baixos. Expandir o ambiente de rollup com pré-compilações é muitas vezes chamado EVM+. Exemplos desta abordagem incluem o suporte à privacidade na cadeia e o suporte a esquemas de assinatura mais eficientes, por exemplo, assinaturas BLS. Por exemplo, o jogo de póquer ZKHoldem utiliza operações FJE e zk especializadas para conseguir a negociação e revelação de cartas de poker privadas. O desenvolvimento destas pré-compilações especializadas é muitas vezes um esforço partilhado entre o programador de rollup de aplicações e os fornecedores Raas que gerem a implementação e manutenção dos rollups de aplicação infra.

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

Outra abordagem para melhorar o ambiente de execução de rollup é libertar-se do EVM. Esta abordagem está a tornar-se mais popular entre os programadores que são novos no ecossistema Ethereum e os desenvolvedores que acreditam que o Solidity não é a melhor linguagem para desenvolver aplicações complexas.

Hoje temos aplicações de rollup que estão a ser executadas em WASM, SVM, Cairo e até mesmo em tempos de execução Linux. A maioria destas abordagens permite que os programadores escrevam o seu contrato inteligente em linguagens de alto nível, como Rust ou C. A desvantagem é que a interoperabilidade com os contratos Solidity existentes é muitas vezes perdida. No entanto, ainda é possível criar compatibilidade com o EVM. Por exemplo, a caneta da Aributrum emprega um co-processador para tornar os contratos Stylus compatíveis com o EVM. Este design aproxima a Stylus de uma arquitectura EVM+ do que de uma não-EVM.

Ambientes de execução híbridos

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 dos principais primitivos do jogo. A gestão de ativos no jogo, por exemplo, a negociação dos NFTs no jogo pode ser tratada por contratos Solidity standard.

A vantagem desta abordagem é que a compatibilidade EVM garante o alinhamento com um ecossistema maior de desenvolvedores e produtos existentes. Também permite uma composição sem permissão. Os programadores podem fazer mods e estender a lógica do jogo adicionando contratos inteligentes EVM/Solidity. Enquanto isso, o motor de jogo especializado não-EVM atinge o elevado rendimento que não pode ser satisfeito pelo EVM.

Exemplos desta abordagem são o World Engine da Argus e o Keystone da Curio. O World Engine separa a execução da lógica do jogo numa camada separada chamada Game Shard que é executada em cima da camada compatível com EVM. O Game Shard também foi concebido para permitir uma escala horizontal para ajustar o rendimento total do rollup com base na procura. Da mesma forma, a arquitetura Keystone do Curio aglupa um motor 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 da escalabilidade dos rollups de aplicações, o que está a aumentar o rendimento da transação de rollup. Existem outros tópicos relacionados com este aumento de rendimento, tais como Disponibilidade de Dados (DA), descentralização do sequenciador e velocidade de liquidação. A disponibilidade de dados é o mais urgente destes problemas para os rollups de aplicações de alto rendimento.

Um único conjunto de aplicações pode potencialmente atingir throughputs superiores a 10k tps. Não é possível usar o Ethereum como uma camada DA para estas transações. Primeiro, o custo médio de publicação dos dados de uma simples transferência L2 ETH em L1 pode exceder $0,10. Estes custos são demasiado elevados para a maioria dos rollups de aplicações. Mais importante, 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. A Celestia e a eiGenda estão atualmente posicionadas como a opção mais viável para rollups de aplicações. Por exemplo, o Eclipse planeia usar o Celestia para o seu rollup baseado em SVM de alto rendimento. Argus e motores de jogo de alto rendimento também planeiam inicialmente usar Celestia inicialmente. Da mesma forma, o eiGenda que promete um rendimento de dados de até 10 MB/s pode ser uma solução viável para vários rollups de aplicações.

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

Em conclusão, acredito que os rollups de aplicações são a melhor solução existente para escalar aplicações de alto rendimento em geral e jogos totalmente on-chain em específico. Escalar esses rollups de aplicativos é a chave para alcançar a adoção convencional que vai além dos usuários nativos de criptografia. Na Alliance, queremos concretizar esta visão apoiando os fundadores que estão a construir isto

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

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

Isenção de responsabilidade：

1. Este artigo foi reimpresso da [Alliance]. Todos os direitos autorais pertencem ao autor original [Mohamed Fouda]. Se houver objeções a esta reimpressão, contacte a equipa do Gate Learn, e eles tratarão disso imediatamente.
2. Isenção de responsabilidade: As opiniões e opiniões expressas neste artigo são exclusivamente do autor e não constituem nenhum conselho de investimento.
3. As traduções do artigo para outras línguas são feitas pela equipa do Gate Learn. A menos que mencionado, é proibido copiar, distribuir ou plagiar os artigos traduzidos.