! [Interpretação da tecnologia Dapp Rollup: Como tornar o APP de alto rendimento mainstream?] ](https://cdn-img.panewslab.com//panews/2022/10/20/images/f8bb1f8b126f9f3317749e6564bff7e7.jpg)
O aplicativo Rollup está emergindo como um claro vencedor no dimensionamento de um conjunto específico de aplicativos Ethereum. Esses aplicativos se beneficiam de garantias de propriedade fortes e sem permissão, mas não exigem interação simultânea entre todos os usuários do aplicativo. Os jogos totalmente on-chain são o melhor exemplo. Os jogos on-chain beneficiam de uma forte propriedade dos ativos do jogo, permitindo a participação anónima no jogo e permitindo a modificação anónima do jogo. Ainda assim, a maioria dos jogos não exige que todos os jogadores interajam ao mesmo tempo. Outros aplicativos que podem se beneficiar da estratégia de escalonamento de rollup do aplicativo incluem mercados NFT, trocas perpétuas e inferência de IA on-chain.
! [Interpretação da tecnologia Dapp Rollup: Como tornar o APP de alto rendimento mainstream?] ](https://cdn-img.panewslab.com//panews/2022/10/20/images/f20241526a9e4945c106e2f36e2dc54b.jpg)
O pacote cumulativo de aplicativos já é a implementação preferida para muitos desses casos de uso. No entanto, a implementação padrão do Rollup, EVMRollup, ainda tem limitações de escalabilidade importantes. Eles podem atingir uma taxa de transferência de cerca de 100 transações por segundo. Esta taxa de transferência pode ser suficiente para alguns jogos on-chain, dependendo do tipo de jogo. No entanto, a maioria dos jogos requer uma taxa de transferência mais alta para suportar um grande número de jogadores simultâneos (mais de 1000). Este artigo se concentra em como o pacote cumulativo de aplicativos é dimensionado para alcançar centenas de milhares de participantes simultâneos. Para cada abordagem, discuto o tipo adequado de aplicação/jogo e os desafios que enfrenta.
Dimensionar horizontalmente
A escalabilidade horizontal é a maneira mais fácil de dimensionar o pacote cumulativo de aplicativos. No entanto, essa simplicidade vem em detrimento da capacidade de composição, o que os torna adequados para apenas um pequeno subconjunto de aplicativos, como jogos single-player.
Escalabilidade horizontal significa simplesmente implantar vários pacotes cumulativos de aplicativos (Optimistic ou ZK) e implantar o mesmo contrato inteligente em todos os rollups. O front-end do aplicativo direciona perfeitamente o usuário para um dos rollups com base na capacidade, localização ou opções específicas do aplicativo. A Alt Layer demonstrou recentemente este conceito ao lançar um jogo FOCG escalável de 2048. No front-end do jogo, os usuários podem escolher qual Rollup participar com base em sua localização geográfica. Devido à sua simplicidade e disponibilidade de provedores de rollup-as-a-service como Caldera, que lidam com todo o trabalho de infraestrutura associado à rotação e gerenciamento desses rollups, essa abordagem pode ser facilmente adotada por desenvolvedores de jogos.
! [Interpretação da tecnologia Dapp Rollup: Como tornar o APP de alto rendimento mainstream?] ](https://cdn-img.panewslab.com//panews/2022/10/20/images/b872ea4023eb627e81fc61022f05f2bc.jpg)
Ainda assim, existem alguns problemas com a abordagem de extensão multi-rollup. O primeiro problema é o switch de rede Rollup. As carteiras atuais, como a Metamask, exigem aprovação manual para se conectar a uma nova rede, a instância do Rollup. Isso cria uma experiência de usuário difícil e confusa para os jogadores, já que os jogadores precisam se conectar manualmente a várias "redes" para jogar o mesmo jogo. Felizmente, essa complexidade pode ser apagada com uma solução de abstração de conta (AA). Exemplos incluem EIP 4337 e carteiras incorporadas, como Privy e 0xPass.
Outro desafio é gerenciar o estado do jogador durante as transições entre rollups. Em alguns casos, como quedas de capacidade, um aplicativo pode precisar consolidar várias instâncias de Rollup em uma única instância para conservar recursos. Nesse caso, o estado de todos os jogadores ativos precisa ser migrado para a nova instância. As soluções de ponte atuais, especialmente as pontes ZK, podem desempenhar um papel fundamental na resolução deste problema. Usando essas soluções, você pode fazer a ponte entre o estado do jogo de um jogador e uma nova instância do Rollup, mantendo a prova da validade desse estado. No entanto, a latência das soluções de ponte existentes pode não ser ideal para casos de uso de jogos.
Canal de status ZK
Outra extensão de rollup de aplicativos que é mais adequada para jogos multiplayer, como o poker, é o canal de estado ZK. Nestes jogos, a interação do jogador ocorre entre um pequeno número de jogadores, como 2-10 pessoas. A jogabilidade entre esses jogadores só é importante enquanto o jogo está acontecendo. No entanto, o resultado final do jogo é mais importante, pois afeta o equilíbrio patrimonial de cada jogador. Portanto, é importante armazenar os resultados em uma camada de persistência compartilhada.
Nesse caso, o pacote cumulativo de aplicativos representa uma camada de informações compartilhada, onde os resultados do jogo são armazenados e onde os ativos do jogo também existem. Para cada jogo no Rollup, você pode iniciar um canal de estado ZK para servir o jogo. Durante o jogo, cada jogador gera transações e cria ZKP, provando que seguiu as regras do jogo. Provas de outras interações do jogador agregam a prova anterior usando provas recursivas. Quando o jogo termina, o ZKP final é submetido ao aplicativo Rollup para provar a validade da jogabilidade e o resultado final. A mudança de estado produzida pelo jogo altera o estado do jogador no aplicativo Rollup.
! [Interpretação da tecnologia Dapp Rollup: Como tornar o APP de alto rendimento mainstream?] ](https://cdn-img.panewslab.com//panews/2022/10/20/images/279d2bd0b1395674a145b42e73523ce3.jpg)
O canal de estado ZK move as interações do jogo para fora da cadeia. Portanto, a atividade e as transações no jogo não contam para a taxa de transferência do pacote cumulativo de aplicativos. Usando essa abordagem, o Rollup de aplicativos pode ser dimensionado massivamente para suportar milhares de jogadores simultâneos. A transação para o pacote cumulativo de aplicativos só validará as transações ZKP geradas e de atualização de status com um fator de escala de 100-1000x. Várias equipas, incluindo a Ontropy, têm vindo a desenvolver a tecnologia.
Uma desvantagem dessa abordagem é que ela exige que os jogadores executem a lógica do jogo em seus próprios dispositivos e gerem ZKPs. Muitas vezes, essas provas são leves e podem ser concluídas em segundos com sistemas de prova de ponta, como o Halo2. No entanto, isso ainda pode levar a uma experiência de jogador reduzida para dispositivos com recursos limitados.
Uma das maneiras de mitigar esse problema é designar um dos participantes do canal zk state como um sequenciador temporário. O sequenciador receberá a transação de cada jogador e gerará o ZKP correspondente, compartilhando o ZKP com todos os participantes do canal. Esta modificação pode ser pensada como uma liquidação ZK L3 de curta duração para o aplicativo Rollup. A equipe do Cartridge implementou essa arquitetura projetando um sequenciador dedicado chamado Katana.
A abordagem do canal de estado zk tem um grande potencial. No entanto, existem várias questões em aberto relacionadas ao ambiente de execução dentro do canal de estado zk e como otimizar a prova recursiva. Os ambientes zkEVM atuais não são eficientes, e a maioria atualmente não suporta recursão de prova. As alternativas incluem zkVM leve, ou até mesmo usar circuitos zk especializados para lidar com a interação do jogador se o jogador tiver um número limitado de movimentos possíveis.
Alterar o ambiente de execução
Uma terceira maneira de estender o pacote cumulativo de aplicativos é alterar o ambiente de execução do Rollup. Apesar de sua maturidade e abundância de ferramentas de desenvolvimento EVM, eles não são adequados para aplicações de alto desempenho, como jogos. Além disso, o modelo de execução e armazenamento single-threaded do EVM resulta em taxa de transferência reduzida, que pode ser melhorada por meio de melhorias.
A principal vantagem dessa abordagem é que aumentar a taxa de transferência do Rollup não requer sacrificar a capacidade de composição ou limitar o número de casos de uso. Essa abordagem pode ser usada para qualquer aplicativo Web 3, desde que o ambiente de execução possa atingir a taxa de transferência exigida pelo aplicativo. Isso os torna a única solução viável para aplicativos que precisam de acesso ao estado compartilhado, como AMMs, protocolos de empréstimo e outros aplicativos DeFi.
Estendendo a funcionalidade EVM com pré-compilação
Primeiro, o Rollup mantém o EVM em conformidade e ultrapassa alguns limites na taxa de transferência de endereços pré-compilados. A ideia aqui é simples. A pré-compilação é o movimento descendente das operações EVM de computação intensiva para o nível do nó. Uma operação que requer centenas ou milhares de opcodes EVM e consome 100.000+ gás pode ser simplificada para uma única operação com uma redução de 100x nos custos de gás. A pré-compilação que estende o ambiente de Rollup é frequentemente referida como EVM+. Exemplos desta abordagem incluem o apoio à privacidade on-chain e o apoio a esquemas de assinatura mais eficientes, como as assinaturas BLS. Por exemplo, o poker zkHoldem usa operações FHE e zk dedicadas para permitir a negociação e apresentação de cartões privados. O desenvolvimento dessas pré-compilações especializadas normalmente é um esforço conjunto entre o desenvolvedor do pacote cumulativo de aplicativos e o provedor Raas que gerencia a implantação e a manutenção da infraestrutura do pacote cumulativo de aplicativos.
Usando um ambiente de execução não-EVM
Outra maneira de melhorar o ambiente de execução do Rollup é se livrar do EVM. Essa abordagem está ganhando popularidade entre novos desenvolvedores no ecossistema Ethereum, bem como entre desenvolvedores que acreditam que o Solidity não é a melhor linguagem para desenvolver aplicativos complexos.
Hoje, temos aplicativos Rollup rodando em tempos de execução WASM, SVM, Cairo e até mesmo Linux. A maioria desses métodos permite que os desenvolvedores escrevam contratos inteligentes usando linguagens de alto nível, como Rust ou C. A desvantagem é que a interoperabilidade com os contratos Solidity existentes é frequentemente perdida. No entanto, a compatibilidade com EVM ainda pode ser criada. Por exemplo, a caneta do Aributrum usa um coprocessador para tornar o contrato EVM da Stylus compatível. Este design aproxima a Stylus da arquitetura EVM+ do que da arquitetura não-EVM.
! [Interpretação da tecnologia Dapp Rollup: Como tornar o APP de alto rendimento mainstream?] ](https://cdn-img.panewslab.com//panews/2022/10/20/images/be666ff84c513ab1de2a247236a723a2.jpg)
Ambiente de execução misto
A terceira abordagem, que é particularmente popular com FOGs, é o melhor recurso que combina os dois primeiros. Esta abordagem combina compatibilidade EVM com um ambiente de execução dedicado não-EVM. Os ambientes não-EVM concentram-se na execução de alto desempenho de primitivos de jogos principais. O gerenciamento de ativos de jogos, como transações NFT no jogo, pode ser tratado por contratos padrão do Solidity.
A vantagem dessa abordagem é que a compatibilidade com EVM garante o alinhamento com o ecossistema de desenvolvedores maior e os produtos existentes. Ele também permite a capacidade de composição sem permissão. Os desenvolvedores podem modificar e estender a lógica do jogo adicionando contratos inteligentes EVM/Solidity. Ao mesmo tempo, os motores de jogos não EVM construídos especificamente alcançam um rendimento elevado que o EVM não consegue.
Exemplos dessa 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 em uma camada separada, chamada Game Shard, que é executada em cima da camada compatível com EVM. O Game Shard também foi projetado para permitir o dimensionamento horizontal para ajustar a taxa de transferência total de rollup com base na demanda. Da mesma forma, a arquitetura Keystone da Curio combina um mecanismo de jogo de alto rendimento com um EVM como um ambiente de execução Rollup. O desafio aqui é alcançar a interoperabilidade perfeita entre motores EVM e motores de jogos.
! [Interpretação da tecnologia Dapp Rollup: Como tornar o APP de alto rendimento mainstream?] ](https://cdn-img.panewslab.com//panews/2022/10/20/images/246295e5b8867825147e0129ef32c4d9.jpg)
Considerações sobre disponibilidade de dados
Na discussão anterior, o foco era aumentar a taxa de transferência de transações do Rollup, que é o principal aspeto do dimensionamento do Rollup de aplicativos. Outros tópicos relacionados a essa maior taxa de transferência incluem disponibilidade de dados (DA), descentralização de pedidos e velocidade de liquidação. Para pacotes cumulativos de aplicativos de alta taxa de transferência, a disponibilidade de dados é o mais urgente desses problemas.
Um único pacote cumulativo de aplicativos pode ter uma taxa de transferência de mais de 10.000 transações por segundo. É impossível usar o Ethereum como a camada de disponibilidade de dados para essas transações. Primeiro, o custo médio de publicação de dados de transferência ETH L2 simples em L2 pode exceder US$ 0,1. Esses custos são muito altos para a maioria dos pacotes cumulativos de aplicativos. Além disso, o L1 do Ethereum atualmente não pode suportar rollups que aproveitam o L1 para disponibilidade de dados com cerca de 8.000 transações por segundo.
Os pacotes cumulativos de aplicativos dependerão principalmente de soluções de DA externas. Celestia e EigenDA estão atualmente posicionados como as opções mais viáveis para o aplicativo Rollup. Por exemplo, o Eclipse planeja usar o Celestia como a camada de disponibilidade de dados para seu pacote cumulativo de base SVM de alta taxa de transferência. Argus e motores de jogos de alto rendimento também estão planejados para usar inicialmente Celestia. Da mesma forma, o EigenDA promete uma taxa de transferência de dados de até 10 MB por segundo e também pode fornecer uma solução viável para vários pacotes cumulativos de aplicativos.
No entanto, a principal desvantagem de integrar Celestia ou EigneDA é a fuga de valor económico. Os rollups de aplicativos devem pagar taxas para a camada DA, bem como taxas de liquidação no Ethereum L1. A taxa de liquidação é fundamental para o Rollup do aplicativo porque vincula a segurança do Rollup à segurança do Ethereum. As garantias DA são menos importantes no contexto do FOG, onde o valor da transação é muito menor do que essas redes. Além disso, Celestia e EigenDA prometem taxas baixas porque essas redes estão apenas em alta e a utilização será baixa inicialmente. Quando essas redes DA atingem alta utilização, as taxas de DA também podem se tornar proibitivas. Na minha opinião, o pacote cumulativo de aplicativos deve usar um DAC (Data Availability Board) simples para provar a disponibilidade dos dados cumulativos.
Em conclusão, acho que os pacotes cumulativos de aplicativos são a melhor solução existente para dimensionar aplicativos de alto rendimento, especialmente jogos totalmente on-chain. Estender esses aplicativos com o Rollup é fundamental para alcançar a adoção convencional além dos usuários nativos de criptografia.
Ver original
Esta página pode conter conteúdo de terceiros, que é fornecido apenas para fins informativos (não para representações/garantias) e não deve ser considerada como um endosso de suas opiniões pela Gate nem como aconselhamento financeiro ou profissional. Consulte a Isenção de responsabilidade para obter detalhes.
Interpretação da tecnologia Dapp Rollup: Como tornar o APP de alto rendimento mainstream?
Escrito por Mohamed Fouda
Compilado: DeepTide TechFlow
! [Interpretação da tecnologia Dapp Rollup: Como tornar o APP de alto rendimento mainstream?] ](https://cdn-img.panewslab.com//panews/2022/10/20/images/f8bb1f8b126f9f3317749e6564bff7e7.jpg)
O aplicativo Rollup está emergindo como um claro vencedor no dimensionamento de um conjunto específico de aplicativos Ethereum. Esses aplicativos se beneficiam de garantias de propriedade fortes e sem permissão, mas não exigem interação simultânea entre todos os usuários do aplicativo. Os jogos totalmente on-chain são o melhor exemplo. Os jogos on-chain beneficiam de uma forte propriedade dos ativos do jogo, permitindo a participação anónima no jogo e permitindo a modificação anónima do jogo. Ainda assim, a maioria dos jogos não exige que todos os jogadores interajam ao mesmo tempo. Outros aplicativos que podem se beneficiar da estratégia de escalonamento de rollup do aplicativo incluem mercados NFT, trocas perpétuas e inferência de IA on-chain.
! [Interpretação da tecnologia Dapp Rollup: Como tornar o APP de alto rendimento mainstream?] ](https://cdn-img.panewslab.com//panews/2022/10/20/images/f20241526a9e4945c106e2f36e2dc54b.jpg)
O pacote cumulativo de aplicativos já é a implementação preferida para muitos desses casos de uso. No entanto, a implementação padrão do Rollup, EVMRollup, ainda tem limitações de escalabilidade importantes. Eles podem atingir uma taxa de transferência de cerca de 100 transações por segundo. Esta taxa de transferência pode ser suficiente para alguns jogos on-chain, dependendo do tipo de jogo. No entanto, a maioria dos jogos requer uma taxa de transferência mais alta para suportar um grande número de jogadores simultâneos (mais de 1000). Este artigo se concentra em como o pacote cumulativo de aplicativos é dimensionado para alcançar centenas de milhares de participantes simultâneos. Para cada abordagem, discuto o tipo adequado de aplicação/jogo e os desafios que enfrenta.
Dimensionar horizontalmente
A escalabilidade horizontal é a maneira mais fácil de dimensionar o pacote cumulativo de aplicativos. No entanto, essa simplicidade vem em detrimento da capacidade de composição, o que os torna adequados para apenas um pequeno subconjunto de aplicativos, como jogos single-player.
Escalabilidade horizontal significa simplesmente implantar vários pacotes cumulativos de aplicativos (Optimistic ou ZK) e implantar o mesmo contrato inteligente em todos os rollups. O front-end do aplicativo direciona perfeitamente o usuário para um dos rollups com base na capacidade, localização ou opções específicas do aplicativo. A Alt Layer demonstrou recentemente este conceito ao lançar um jogo FOCG escalável de 2048. No front-end do jogo, os usuários podem escolher qual Rollup participar com base em sua localização geográfica. Devido à sua simplicidade e disponibilidade de provedores de rollup-as-a-service como Caldera, que lidam com todo o trabalho de infraestrutura associado à rotação e gerenciamento desses rollups, essa abordagem pode ser facilmente adotada por desenvolvedores de jogos.
! [Interpretação da tecnologia Dapp Rollup: Como tornar o APP de alto rendimento mainstream?] ](https://cdn-img.panewslab.com//panews/2022/10/20/images/b872ea4023eb627e81fc61022f05f2bc.jpg)
Ainda assim, existem alguns problemas com a abordagem de extensão multi-rollup. O primeiro problema é o switch de rede Rollup. As carteiras atuais, como a Metamask, exigem aprovação manual para se conectar a uma nova rede, a instância do Rollup. Isso cria uma experiência de usuário difícil e confusa para os jogadores, já que os jogadores precisam se conectar manualmente a várias "redes" para jogar o mesmo jogo. Felizmente, essa complexidade pode ser apagada com uma solução de abstração de conta (AA). Exemplos incluem EIP 4337 e carteiras incorporadas, como Privy e 0xPass.
Outro desafio é gerenciar o estado do jogador durante as transições entre rollups. Em alguns casos, como quedas de capacidade, um aplicativo pode precisar consolidar várias instâncias de Rollup em uma única instância para conservar recursos. Nesse caso, o estado de todos os jogadores ativos precisa ser migrado para a nova instância. As soluções de ponte atuais, especialmente as pontes ZK, podem desempenhar um papel fundamental na resolução deste problema. Usando essas soluções, você pode fazer a ponte entre o estado do jogo de um jogador e uma nova instância do Rollup, mantendo a prova da validade desse estado. No entanto, a latência das soluções de ponte existentes pode não ser ideal para casos de uso de jogos.
Canal de status ZK
Outra extensão de rollup de aplicativos que é mais adequada para jogos multiplayer, como o poker, é o canal de estado ZK. Nestes jogos, a interação do jogador ocorre entre um pequeno número de jogadores, como 2-10 pessoas. A jogabilidade entre esses jogadores só é importante enquanto o jogo está acontecendo. No entanto, o resultado final do jogo é mais importante, pois afeta o equilíbrio patrimonial de cada jogador. Portanto, é importante armazenar os resultados em uma camada de persistência compartilhada.
Nesse caso, o pacote cumulativo de aplicativos representa uma camada de informações compartilhada, onde os resultados do jogo são armazenados e onde os ativos do jogo também existem. Para cada jogo no Rollup, você pode iniciar um canal de estado ZK para servir o jogo. Durante o jogo, cada jogador gera transações e cria ZKP, provando que seguiu as regras do jogo. Provas de outras interações do jogador agregam a prova anterior usando provas recursivas. Quando o jogo termina, o ZKP final é submetido ao aplicativo Rollup para provar a validade da jogabilidade e o resultado final. A mudança de estado produzida pelo jogo altera o estado do jogador no aplicativo Rollup.
! [Interpretação da tecnologia Dapp Rollup: Como tornar o APP de alto rendimento mainstream?] ](https://cdn-img.panewslab.com//panews/2022/10/20/images/279d2bd0b1395674a145b42e73523ce3.jpg)
O canal de estado ZK move as interações do jogo para fora da cadeia. Portanto, a atividade e as transações no jogo não contam para a taxa de transferência do pacote cumulativo de aplicativos. Usando essa abordagem, o Rollup de aplicativos pode ser dimensionado massivamente para suportar milhares de jogadores simultâneos. A transação para o pacote cumulativo de aplicativos só validará as transações ZKP geradas e de atualização de status com um fator de escala de 100-1000x. Várias equipas, incluindo a Ontropy, têm vindo a desenvolver a tecnologia.
Uma desvantagem dessa abordagem é que ela exige que os jogadores executem a lógica do jogo em seus próprios dispositivos e gerem ZKPs. Muitas vezes, essas provas são leves e podem ser concluídas em segundos com sistemas de prova de ponta, como o Halo2. No entanto, isso ainda pode levar a uma experiência de jogador reduzida para dispositivos com recursos limitados.
Uma das maneiras de mitigar esse problema é designar um dos participantes do canal zk state como um sequenciador temporário. O sequenciador receberá a transação de cada jogador e gerará o ZKP correspondente, compartilhando o ZKP com todos os participantes do canal. Esta modificação pode ser pensada como uma liquidação ZK L3 de curta duração para o aplicativo Rollup. A equipe do Cartridge implementou essa arquitetura projetando um sequenciador dedicado chamado Katana.
A abordagem do canal de estado zk tem um grande potencial. No entanto, existem várias questões em aberto relacionadas ao ambiente de execução dentro do canal de estado zk e como otimizar a prova recursiva. Os ambientes zkEVM atuais não são eficientes, e a maioria atualmente não suporta recursão de prova. As alternativas incluem zkVM leve, ou até mesmo usar circuitos zk especializados para lidar com a interação do jogador se o jogador tiver um número limitado de movimentos possíveis.
Alterar o ambiente de execução
Uma terceira maneira de estender o pacote cumulativo de aplicativos é alterar o ambiente de execução do Rollup. Apesar de sua maturidade e abundância de ferramentas de desenvolvimento EVM, eles não são adequados para aplicações de alto desempenho, como jogos. Além disso, o modelo de execução e armazenamento single-threaded do EVM resulta em taxa de transferência reduzida, que pode ser melhorada por meio de melhorias.
A principal vantagem dessa abordagem é que aumentar a taxa de transferência do Rollup não requer sacrificar a capacidade de composição ou limitar o número de casos de uso. Essa abordagem pode ser usada para qualquer aplicativo Web 3, desde que o ambiente de execução possa atingir a taxa de transferência exigida pelo aplicativo. Isso os torna a única solução viável para aplicativos que precisam de acesso ao estado compartilhado, como AMMs, protocolos de empréstimo e outros aplicativos DeFi.
Estendendo a funcionalidade EVM com pré-compilação
Primeiro, o Rollup mantém o EVM em conformidade e ultrapassa alguns limites na taxa de transferência de endereços pré-compilados. A ideia aqui é simples. A pré-compilação é o movimento descendente das operações EVM de computação intensiva para o nível do nó. Uma operação que requer centenas ou milhares de opcodes EVM e consome 100.000+ gás pode ser simplificada para uma única operação com uma redução de 100x nos custos de gás. A pré-compilação que estende o ambiente de Rollup é frequentemente referida como EVM+. Exemplos desta abordagem incluem o apoio à privacidade on-chain e o apoio a esquemas de assinatura mais eficientes, como as assinaturas BLS. Por exemplo, o poker zkHoldem usa operações FHE e zk dedicadas para permitir a negociação e apresentação de cartões privados. O desenvolvimento dessas pré-compilações especializadas normalmente é um esforço conjunto entre o desenvolvedor do pacote cumulativo de aplicativos e o provedor Raas que gerencia a implantação e a manutenção da infraestrutura do pacote cumulativo de aplicativos.
Usando um ambiente de execução não-EVM
Outra maneira de melhorar o ambiente de execução do Rollup é se livrar do EVM. Essa abordagem está ganhando popularidade entre novos desenvolvedores no ecossistema Ethereum, bem como entre desenvolvedores que acreditam que o Solidity não é a melhor linguagem para desenvolver aplicativos complexos.
Hoje, temos aplicativos Rollup rodando em tempos de execução WASM, SVM, Cairo e até mesmo Linux. A maioria desses métodos permite que os desenvolvedores escrevam contratos inteligentes usando linguagens de alto nível, como Rust ou C. A desvantagem é que a interoperabilidade com os contratos Solidity existentes é frequentemente perdida. No entanto, a compatibilidade com EVM ainda pode ser criada. Por exemplo, a caneta do Aributrum usa um coprocessador para tornar o contrato EVM da Stylus compatível. Este design aproxima a Stylus da arquitetura EVM+ do que da arquitetura não-EVM.
! [Interpretação da tecnologia Dapp Rollup: Como tornar o APP de alto rendimento mainstream?] ](https://cdn-img.panewslab.com//panews/2022/10/20/images/be666ff84c513ab1de2a247236a723a2.jpg)
Ambiente de execução misto
A terceira abordagem, que é particularmente popular com FOGs, é o melhor recurso que combina os dois primeiros. Esta abordagem combina compatibilidade EVM com um ambiente de execução dedicado não-EVM. Os ambientes não-EVM concentram-se na execução de alto desempenho de primitivos de jogos principais. O gerenciamento de ativos de jogos, como transações NFT no jogo, pode ser tratado por contratos padrão do Solidity.
A vantagem dessa abordagem é que a compatibilidade com EVM garante o alinhamento com o ecossistema de desenvolvedores maior e os produtos existentes. Ele também permite a capacidade de composição sem permissão. Os desenvolvedores podem modificar e estender a lógica do jogo adicionando contratos inteligentes EVM/Solidity. Ao mesmo tempo, os motores de jogos não EVM construídos especificamente alcançam um rendimento elevado que o EVM não consegue.
Exemplos dessa 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 em uma camada separada, chamada Game Shard, que é executada em cima da camada compatível com EVM. O Game Shard também foi projetado para permitir o dimensionamento horizontal para ajustar a taxa de transferência total de rollup com base na demanda. Da mesma forma, a arquitetura Keystone da Curio combina um mecanismo de jogo de alto rendimento com um EVM como um ambiente de execução Rollup. O desafio aqui é alcançar a interoperabilidade perfeita entre motores EVM e motores de jogos.
! [Interpretação da tecnologia Dapp Rollup: Como tornar o APP de alto rendimento mainstream?] ](https://cdn-img.panewslab.com//panews/2022/10/20/images/246295e5b8867825147e0129ef32c4d9.jpg)
Considerações sobre disponibilidade de dados
Na discussão anterior, o foco era aumentar a taxa de transferência de transações do Rollup, que é o principal aspeto do dimensionamento do Rollup de aplicativos. Outros tópicos relacionados a essa maior taxa de transferência incluem disponibilidade de dados (DA), descentralização de pedidos e velocidade de liquidação. Para pacotes cumulativos de aplicativos de alta taxa de transferência, a disponibilidade de dados é o mais urgente desses problemas.
Um único pacote cumulativo de aplicativos pode ter uma taxa de transferência de mais de 10.000 transações por segundo. É impossível usar o Ethereum como a camada de disponibilidade de dados para essas transações. Primeiro, o custo médio de publicação de dados de transferência ETH L2 simples em L2 pode exceder US$ 0,1. Esses custos são muito altos para a maioria dos pacotes cumulativos de aplicativos. Além disso, o L1 do Ethereum atualmente não pode suportar rollups que aproveitam o L1 para disponibilidade de dados com cerca de 8.000 transações por segundo.
Os pacotes cumulativos de aplicativos dependerão principalmente de soluções de DA externas. Celestia e EigenDA estão atualmente posicionados como as opções mais viáveis para o aplicativo Rollup. Por exemplo, o Eclipse planeja usar o Celestia como a camada de disponibilidade de dados para seu pacote cumulativo de base SVM de alta taxa de transferência. Argus e motores de jogos de alto rendimento também estão planejados para usar inicialmente Celestia. Da mesma forma, o EigenDA promete uma taxa de transferência de dados de até 10 MB por segundo e também pode fornecer uma solução viável para vários pacotes cumulativos de aplicativos.
No entanto, a principal desvantagem de integrar Celestia ou EigneDA é a fuga de valor económico. Os rollups de aplicativos devem pagar taxas para a camada DA, bem como taxas de liquidação no Ethereum L1. A taxa de liquidação é fundamental para o Rollup do aplicativo porque vincula a segurança do Rollup à segurança do Ethereum. As garantias DA são menos importantes no contexto do FOG, onde o valor da transação é muito menor do que essas redes. Além disso, Celestia e EigenDA prometem taxas baixas porque essas redes estão apenas em alta e a utilização será baixa inicialmente. Quando essas redes DA atingem alta utilização, as taxas de DA também podem se tornar proibitivas. Na minha opinião, o pacote cumulativo de aplicativos deve usar um DAC (Data Availability Board) simples para provar a disponibilidade dos dados cumulativos.
Em conclusão, acho que os pacotes cumulativos de aplicativos são a melhor solução existente para dimensionar aplicativos de alto rendimento, especialmente jogos totalmente on-chain. Estender esses aplicativos com o Rollup é fundamental para alcançar a adoção convencional além dos usuários nativos de criptografia.