Escrito por: Alana Levin; Compilado por: Luffy, Foresight News
Dois anos atrás, os desenvolvedores de aplicativos enfrentaram uma escolha bastante simples ao decidir em qual cadeia implantar seu aplicativo: Ethereum, Solana, Cosmos ou outra blockchain de Camada 1. Naquela época, o Rollup ainda não havia lançado a rede principal e poucas pessoas tinham ouvido falar do termo "pilha modular". As diferenças entre L1s (taxa de transferência, taxas, etc.) são óbvias e relativamente fáceis de entender.
As coisas parecem muito diferentes hoje. Os desenvolvedores de aplicativos se deparam com mais opções: L1, Rollup de uso geral (Optimistic e zk), infraestrutura IBC, provedor Rollup-as-a-service, AppChain e muito mais. Mais opções trazem mais perguntas: as equipes devem implantar aplicativos para rollups genéricos ou criar rollups específicos de aplicativos. Se eles escolherem o Rollup genérico, qual escolher; se eles seguirem a rota do Rollup do aplicativo, qual SDK/Rollup-as-a-service usar, qual camada de disponibilidade de dados escolher, o EigenLayer pode ajudar, como pensar em sequenciadores; se eles escolherem seguir a rota do OP Stack, se ele pode ocupar um lugar no ecossistema da supercadeia do Otimismo.
Para restringir o problema, este artigo adotará a estrutura de um aplicativo já implantado no Ethereum que deseja escalar dentro do ecossistema Ethereum. Portanto, este artigo se concentrará na árvore de decisão que as equipes de aplicativos enfrentam ao decidir lançar seu próprio rollup, quais tipos de aplicativos são particularmente adequados para determinados tipos de infraestrutura e quando acho que podemos atingir o ponto de inflexão da adoção.
Estrutura de alto nível
No centro da decisão de rollup do aplicativo está, na verdade, uma pergunta simples: se o aplicativo fosse criado em sua própria cadeia, os usuários ainda o usariam? O desenvolvimento posterior consiste em duas perguntas:
É mais provável que os usuários usem um aplicativo se ele estiver em sua própria cadeia?
Se o aplicativo estiver em sua própria cadeia, os usuários também o usarão?
Os benefícios de rollups específicos de aplicativos são um melhor controle: a capacidade de abstrair custos de gás, limitar o congestionamento na cadeia causado por outras atividades de aplicativos, experimentar melhor como os tokens são utilizados, explorar diferentes estruturas econômicas (por exemplo, descontos de gás), criar Personalize o ambiente de execução, implementar controles de acesso (como implantação de permissão) e muito mais.
Mas o preço desse controle extra é a perda de conectividade com o ecossistema mais amplo. Os aplicativos em uma cadeia universal têm acesso à liquidez já existente nessa cadeia (por exemplo, não há necessidade de pontes adicionais entre as cadeias), possibilidade de composição com outros aplicativos e atenção do usuário na cadeia. Comparado com aplicativos que executam suas próprias cadeias, construir na cadeia geral também economiza muita sobrecarga de engenharia.
Um melhor controle poderia melhorar a experiência do usuário se fosse gratuito. Portanto, a resposta para a questão principal — se os usuários ainda usariam um aplicativo se ele estivesse em sua própria cadeia — realmente depende dessa troca de controle versus conectividade.
**Quanta conectividade um aplicativo pode sacrificar? **
As conexões vêm de várias formas, sendo as duas mais importantes: 1) atenção e 2) capital.
A atenção está relacionada com a comunicação nativa. Se o projeto de uma equipe for o primeiro projeto com o qual os usuários se envolvem quando entram no ecossistema, o aplicativo é nativamente viral. Aplicativos que podem chamar a atenção são mais adequados para lançar sua própria cadeia; os usuários usarão o aplicativo independentemente da cadeia em que o aplicativo estiver. Na minha opinião, os aplicativos atuais com propagação nativa incluem Mirror, Zora, Manifold, Sound.xyz e OnCyber. Há também um argumento de que aplicativos sem forte divulgação podem optar por lançar suas próprias cadeias para despertar o interesse do usuário (mas acho isso menos atraente se muitas cadeias estiverem seguindo esse caminho ao mesmo tempo).
A segunda forma de conectividade é o capital. Frequentemente, os fundos que os usuários implantam em um aplicativo são transferidos de outro aplicativo no mesmo ecossistema. Chamo isso de "liquidez compartilhada" e suas implicações são reais. Um grande número de novos aplicativos escolhe o Universal Rollup devido à grande quantidade de ETH conectada a esse ecossistema, e o capital existente no ecossistema pode ajudar a remover barreiras à adoção do usuário (em vez de tentar convencê-los a entrar em um novo ecossistema). Esses fatores são considerações para qualquer aplicativo que incorpore alguma forma de financeirização em seu produto. Exemplos fora do DeFi podem incluir: coletar papéis NFT via Mirror, pagar para "roubar" imagens em uma Stealcam ou qualquer coisa com um recurso de gorjeta no produto.
Perder essa "conectividade de fundos" significa que os aplicativos precisam forçar os usuários a estacionar fundos na cadeia. Um motivo pode ser que os consumidores usam muito o aplicativo, afinal, as cadeias cruzadas são dolorosas, portanto, seria mais fácil manter um suprimento saudável de fundos na cadeia. Mas ainda mais atraente do que fundos ociosos é dar aos usuários a opção de gerar rendimento. Isso se parece com o rendimento na forma de cadeias nativas, aplicativos que constroem produtos adjacentes que fornecem rendimento (como o protocolo de empréstimo do Blur) e muito mais.
Atenção e capital também são os motivos pelos quais muitos veem os jogos on-chain como candidatos ideais para acúmulos específicos de aplicativos: eles são economias bastante independentes e dependem muito de uma experiência de usuário tranquila. Em outras palavras, os jogos on-chain se beneficiam de um alto grau de controle e não sofrem perdas significativas se ficarem órfãos. Outros aplicativos adequados para Rollup podem fazê-lo subsidiando transações (por exemplo, as primeiras transações são gratuitas) ou não exigindo pagamento no login (por exemplo, conteúdo on-chain gerado pelo usuário, certos aplicativos sociais, redes DePIN, etc.) Minimiza os requisitos iniciais de capital do usuário.
Claro, existem outras razões pelas quais os projetos querem mais controle sobre sua infraestrutura. Rollups proprietários permitem a capacidade de implantar permissões e rastrear usuários (por exemplo, KYC para sequenciadores pertencentes/operados em cadeia). No entanto, isso também leva à indistinção da linha entre bancos de dados Rollup e bancos de dados centralizados.
Minimize a perda de conectividade
À medida que as soluções de interoperabilidade melhoram, a compensação entre conectividade e controle torna-se menos importante. Pontes e sequenciadores geralmente são a infraestrutura crítica discutida. Eles são um pouco semelhantes no sentido de que ambos fornecem uma maneira de as transações em uma cadeia afetarem as transações em outra cadeia. As pontes fazem isso passando mensagens ou permitindo transferências de ativos, os ordenadores compartilhados fazem isso ingerindo e solicitando transações de várias cadeias. Ambos os ordenadores e pontes compartilhados são necessários para composição atômica - o ordenador contém várias transações (de cadeia cruzada) em um bloco, e a execução real dessas transações geralmente requer uma ponte.
A economia da unidade de Rollups é outra área onde a "conectividade" tem impacto. As taxas de transação L2 consistem em duas partes: 1) o custo de publicação de dados para L1 e 2) o custo que os usuários pagam pela transação. Acumule dados de chamadas de transações em lotes para que o custo de publicação possa ser compartilhado entre os usuários: quanto mais transações, menor o custo médio por usuário. Isso também significa que Rollups menos ativos podem atrasar a publicação de transações para L1 até que tenham um pacote de transação suficientemente grande. A consequência são tempos de finalização mais lentos e uma experiência de usuário insatisfatória. Pedidos compartilhados parecem servir cada vez mais como camadas de agregação, onde o agrupamento de transações de vários rollups menores pode ajudar a criar economia de unidade viável para indivíduos de cauda longa.
** Estamos em um ponto de inflexão? **
A ideia de cadeias de aplicativos e rollups de aplicativos não é nova. Durante muito tempo, porém, pareceu uma área residencial em desenvolvimento: muita infraestrutura estava sendo construída, mas sem moradores. Nos últimos meses, começamos a ver um afluxo de primeiros residentes. Lattice construiu o OpCraft, um mundo autônomo on-chain apoiado por seu próprio rollup; Lit Protocol e Synapse anunciaram seu próprio Rollup (embora ambos sejam mais orientados para infraestrutura do que projetos orientados para aplicativos); Zora lançou o Zorachain. Conversas recentes com equipes de aplicativos maduras (especialmente aquelas que consideram estratégias L2) começaram a explorar se os rollups de aplicativos são adequados para eles.
Minha suposição é que o ponto de inflexão real ocorrerá em (pelo menos) 6 a 12 meses. Aplicativos sociais e de jogos têm a adequação mais óbvia ao mercado de produtos com Rollups específicos para aplicativos: tanto sociais quanto jogos dependem fortemente de indexação, problemas de pedidos (especialmente no jogo) e recursos personalizados (como transações sem gás) para consumo recreativo Os produtos são muito importante. Muitas equipes de aplicativos estão em construção, especialmente jogos, que podem levar anos para serem desenvolvidos e lançados.
Meu outro argumento é que, para aplicativos menos financeiros, o mais importante é atrair a atenção. Até agora, este artigo definiu Rollups de aplicativos como "um aplicativo por Rollup". Mas essa visão pode ser muito estreita. Talvez existam vários aplicativos formando um coletivo para iniciar uma cadeia juntos. Da mesma forma, podemos ver um aplicativo construir sua própria cadeia e incentivar outros aplicativos a serem implantados em cima dela.
Finalmente, acredito firmemente que veremos mais Rollups no futuro. Os projetos que constroem serviços de infraestrutura para rollups de aplicativos irão proliferar. Caldera, Sovereign SDK, Eclipse, Dymension, Conduit, AltLayer, etc. fornecem às equipes de aplicativos soluções de baixo limite para iniciar seu próprio Rollup. Espresso, Astria e SUAVE, da Flashbots, foram alguns dos primeiros exploradores no espaço dos sequenciadores. Os custos iniciais estão diminuindo e a troca de "conectividade" se torna menos importante. Mas um número tão grande de novos provedores de infraestrutura também significa que as equipes de aplicativos podem levar algum tempo para entender as várias opções, e uma guerra vai estourar entre esses jogadores. Novamente, embora haja sinais de adoção, acho que o ponto de inflexão ainda está a alguns meses de distância.
Agradecemos a Devloper, Jill Gunter, Kyle Samani, Jason Maier, Cem Ozer e Viktor Bunin por seus comentários, comentários e conversas que ajudaram a desenvolver muitas dessas ideias.
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.
Sob a tendência de modularização, o aplicativo deve construir sua própria cadeia?
Escrito por: Alana Levin; Compilado por: Luffy, Foresight News
Dois anos atrás, os desenvolvedores de aplicativos enfrentaram uma escolha bastante simples ao decidir em qual cadeia implantar seu aplicativo: Ethereum, Solana, Cosmos ou outra blockchain de Camada 1. Naquela época, o Rollup ainda não havia lançado a rede principal e poucas pessoas tinham ouvido falar do termo "pilha modular". As diferenças entre L1s (taxa de transferência, taxas, etc.) são óbvias e relativamente fáceis de entender.
As coisas parecem muito diferentes hoje. Os desenvolvedores de aplicativos se deparam com mais opções: L1, Rollup de uso geral (Optimistic e zk), infraestrutura IBC, provedor Rollup-as-a-service, AppChain e muito mais. Mais opções trazem mais perguntas: as equipes devem implantar aplicativos para rollups genéricos ou criar rollups específicos de aplicativos. Se eles escolherem o Rollup genérico, qual escolher; se eles seguirem a rota do Rollup do aplicativo, qual SDK/Rollup-as-a-service usar, qual camada de disponibilidade de dados escolher, o EigenLayer pode ajudar, como pensar em sequenciadores; se eles escolherem seguir a rota do OP Stack, se ele pode ocupar um lugar no ecossistema da supercadeia do Otimismo.
Para restringir o problema, este artigo adotará a estrutura de um aplicativo já implantado no Ethereum que deseja escalar dentro do ecossistema Ethereum. Portanto, este artigo se concentrará na árvore de decisão que as equipes de aplicativos enfrentam ao decidir lançar seu próprio rollup, quais tipos de aplicativos são particularmente adequados para determinados tipos de infraestrutura e quando acho que podemos atingir o ponto de inflexão da adoção.
Estrutura de alto nível
No centro da decisão de rollup do aplicativo está, na verdade, uma pergunta simples: se o aplicativo fosse criado em sua própria cadeia, os usuários ainda o usariam? O desenvolvimento posterior consiste em duas perguntas:
Os benefícios de rollups específicos de aplicativos são um melhor controle: a capacidade de abstrair custos de gás, limitar o congestionamento na cadeia causado por outras atividades de aplicativos, experimentar melhor como os tokens são utilizados, explorar diferentes estruturas econômicas (por exemplo, descontos de gás), criar Personalize o ambiente de execução, implementar controles de acesso (como implantação de permissão) e muito mais.
Mas o preço desse controle extra é a perda de conectividade com o ecossistema mais amplo. Os aplicativos em uma cadeia universal têm acesso à liquidez já existente nessa cadeia (por exemplo, não há necessidade de pontes adicionais entre as cadeias), possibilidade de composição com outros aplicativos e atenção do usuário na cadeia. Comparado com aplicativos que executam suas próprias cadeias, construir na cadeia geral também economiza muita sobrecarga de engenharia.
Um melhor controle poderia melhorar a experiência do usuário se fosse gratuito. Portanto, a resposta para a questão principal — se os usuários ainda usariam um aplicativo se ele estivesse em sua própria cadeia — realmente depende dessa troca de controle versus conectividade.
**Quanta conectividade um aplicativo pode sacrificar? **
As conexões vêm de várias formas, sendo as duas mais importantes: 1) atenção e 2) capital.
A atenção está relacionada com a comunicação nativa. Se o projeto de uma equipe for o primeiro projeto com o qual os usuários se envolvem quando entram no ecossistema, o aplicativo é nativamente viral. Aplicativos que podem chamar a atenção são mais adequados para lançar sua própria cadeia; os usuários usarão o aplicativo independentemente da cadeia em que o aplicativo estiver. Na minha opinião, os aplicativos atuais com propagação nativa incluem Mirror, Zora, Manifold, Sound.xyz e OnCyber. Há também um argumento de que aplicativos sem forte divulgação podem optar por lançar suas próprias cadeias para despertar o interesse do usuário (mas acho isso menos atraente se muitas cadeias estiverem seguindo esse caminho ao mesmo tempo).
A segunda forma de conectividade é o capital. Frequentemente, os fundos que os usuários implantam em um aplicativo são transferidos de outro aplicativo no mesmo ecossistema. Chamo isso de "liquidez compartilhada" e suas implicações são reais. Um grande número de novos aplicativos escolhe o Universal Rollup devido à grande quantidade de ETH conectada a esse ecossistema, e o capital existente no ecossistema pode ajudar a remover barreiras à adoção do usuário (em vez de tentar convencê-los a entrar em um novo ecossistema). Esses fatores são considerações para qualquer aplicativo que incorpore alguma forma de financeirização em seu produto. Exemplos fora do DeFi podem incluir: coletar papéis NFT via Mirror, pagar para "roubar" imagens em uma Stealcam ou qualquer coisa com um recurso de gorjeta no produto.
Perder essa "conectividade de fundos" significa que os aplicativos precisam forçar os usuários a estacionar fundos na cadeia. Um motivo pode ser que os consumidores usam muito o aplicativo, afinal, as cadeias cruzadas são dolorosas, portanto, seria mais fácil manter um suprimento saudável de fundos na cadeia. Mas ainda mais atraente do que fundos ociosos é dar aos usuários a opção de gerar rendimento. Isso se parece com o rendimento na forma de cadeias nativas, aplicativos que constroem produtos adjacentes que fornecem rendimento (como o protocolo de empréstimo do Blur) e muito mais.
Atenção e capital também são os motivos pelos quais muitos veem os jogos on-chain como candidatos ideais para acúmulos específicos de aplicativos: eles são economias bastante independentes e dependem muito de uma experiência de usuário tranquila. Em outras palavras, os jogos on-chain se beneficiam de um alto grau de controle e não sofrem perdas significativas se ficarem órfãos. Outros aplicativos adequados para Rollup podem fazê-lo subsidiando transações (por exemplo, as primeiras transações são gratuitas) ou não exigindo pagamento no login (por exemplo, conteúdo on-chain gerado pelo usuário, certos aplicativos sociais, redes DePIN, etc.) Minimiza os requisitos iniciais de capital do usuário.
Claro, existem outras razões pelas quais os projetos querem mais controle sobre sua infraestrutura. Rollups proprietários permitem a capacidade de implantar permissões e rastrear usuários (por exemplo, KYC para sequenciadores pertencentes/operados em cadeia). No entanto, isso também leva à indistinção da linha entre bancos de dados Rollup e bancos de dados centralizados.
Minimize a perda de conectividade
À medida que as soluções de interoperabilidade melhoram, a compensação entre conectividade e controle torna-se menos importante. Pontes e sequenciadores geralmente são a infraestrutura crítica discutida. Eles são um pouco semelhantes no sentido de que ambos fornecem uma maneira de as transações em uma cadeia afetarem as transações em outra cadeia. As pontes fazem isso passando mensagens ou permitindo transferências de ativos, os ordenadores compartilhados fazem isso ingerindo e solicitando transações de várias cadeias. Ambos os ordenadores e pontes compartilhados são necessários para composição atômica - o ordenador contém várias transações (de cadeia cruzada) em um bloco, e a execução real dessas transações geralmente requer uma ponte.
A economia da unidade de Rollups é outra área onde a "conectividade" tem impacto. As taxas de transação L2 consistem em duas partes: 1) o custo de publicação de dados para L1 e 2) o custo que os usuários pagam pela transação. Acumule dados de chamadas de transações em lotes para que o custo de publicação possa ser compartilhado entre os usuários: quanto mais transações, menor o custo médio por usuário. Isso também significa que Rollups menos ativos podem atrasar a publicação de transações para L1 até que tenham um pacote de transação suficientemente grande. A consequência são tempos de finalização mais lentos e uma experiência de usuário insatisfatória. Pedidos compartilhados parecem servir cada vez mais como camadas de agregação, onde o agrupamento de transações de vários rollups menores pode ajudar a criar economia de unidade viável para indivíduos de cauda longa.
** Estamos em um ponto de inflexão? **
A ideia de cadeias de aplicativos e rollups de aplicativos não é nova. Durante muito tempo, porém, pareceu uma área residencial em desenvolvimento: muita infraestrutura estava sendo construída, mas sem moradores. Nos últimos meses, começamos a ver um afluxo de primeiros residentes. Lattice construiu o OpCraft, um mundo autônomo on-chain apoiado por seu próprio rollup; Lit Protocol e Synapse anunciaram seu próprio Rollup (embora ambos sejam mais orientados para infraestrutura do que projetos orientados para aplicativos); Zora lançou o Zorachain. Conversas recentes com equipes de aplicativos maduras (especialmente aquelas que consideram estratégias L2) começaram a explorar se os rollups de aplicativos são adequados para eles.
Minha suposição é que o ponto de inflexão real ocorrerá em (pelo menos) 6 a 12 meses. Aplicativos sociais e de jogos têm a adequação mais óbvia ao mercado de produtos com Rollups específicos para aplicativos: tanto sociais quanto jogos dependem fortemente de indexação, problemas de pedidos (especialmente no jogo) e recursos personalizados (como transações sem gás) para consumo recreativo Os produtos são muito importante. Muitas equipes de aplicativos estão em construção, especialmente jogos, que podem levar anos para serem desenvolvidos e lançados.
Meu outro argumento é que, para aplicativos menos financeiros, o mais importante é atrair a atenção. Até agora, este artigo definiu Rollups de aplicativos como "um aplicativo por Rollup". Mas essa visão pode ser muito estreita. Talvez existam vários aplicativos formando um coletivo para iniciar uma cadeia juntos. Da mesma forma, podemos ver um aplicativo construir sua própria cadeia e incentivar outros aplicativos a serem implantados em cima dela.
Finalmente, acredito firmemente que veremos mais Rollups no futuro. Os projetos que constroem serviços de infraestrutura para rollups de aplicativos irão proliferar. Caldera, Sovereign SDK, Eclipse, Dymension, Conduit, AltLayer, etc. fornecem às equipes de aplicativos soluções de baixo limite para iniciar seu próprio Rollup. Espresso, Astria e SUAVE, da Flashbots, foram alguns dos primeiros exploradores no espaço dos sequenciadores. Os custos iniciais estão diminuindo e a troca de "conectividade" se torna menos importante. Mas um número tão grande de novos provedores de infraestrutura também significa que as equipes de aplicativos podem levar algum tempo para entender as várias opções, e uma guerra vai estourar entre esses jogadores. Novamente, embora haja sinais de adoção, acho que o ponto de inflexão ainda está a alguns meses de distância.
Agradecemos a Devloper, Jill Gunter, Kyle Samani, Jason Maier, Cem Ozer e Viktor Bunin por seus comentários, comentários e conversas que ajudaram a desenvolver muitas dessas ideias.