De onde vêm os efeitos de rede L2? O que torna o L2 pegajoso?

Autor: Alana Levin; Compilador: Huohuo, blockchain vernacular

Dois anos atrás, os desenvolvedores de aplicativos enfrentaram uma escolha bastante simples ao decidir onde implantar seus aplicativos: Ethereum, Solana, Cosmos ou talvez alguma outra cadeia de camada 1. Rollup ainda não está em uso e poucas pessoas ouviram o termo "pilha modular". As diferenças entre L1s (rendimento, custo, 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, rollups genéricos (Optimistic e zk), infraestrutura IBC avançada, provedores de Rollups como serviço, cadeias de aplicativos e muito mais. **

Mais opções trazem mais perguntas, incluindo: as equipes devem implantar em rollups genéricos ou criar rollups específicos de aplicativos? Se você escolher rollup geral, qual escolher? Se eles seguirem a rota de rollup do aplicativo, qual SDK/rollup-as-a-service usar? Qual nível de disponibilidade de dados escolher? O EigenLayer pode ajudar? Como pensar em sequenciadores? Se eles escolherem seguir a rota OP Stack, haverá um emoji de esfera colorida deixado no ecossistema superchain do Optimism? Essas perguntas são complicadas.

Para restringir o problema, este artigo adotará a estrutura de um aplicativo já implantado no Ethereum que deseja escalar dentro do ecossistema Ethereum. Portanto, o foco estará na árvore de decisão que as equipes de aplicativos enfrentam ao determinar se lançam seu próprio rollup, as suposições sobre quais tipos de aplicativos são particularmente adequados para essa infraestrutura e quando acho que podemos chegar a um ponto crítico para adoção.

1. Estrutura de alto nível

No centro da decisão de rollup de um aplicativo está, na verdade, uma pergunta simples: **se o aplicativo estivesse em sua própria cadeia, os usuários ainda o usariam? **Existem dois subconjuntos desta questão:

1) É mais provável que os usuários usem um aplicativo se ele estiver em sua própria rede?

2) Se o aplicativo estiver em sua própria cadeia, é igualmente possível para o usuário usar o aplicativo?

Os benefícios cumulativos específicos do aplicativo decorrem de um maior controle: Capacidade de extrair 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 (como descontos de gás integrados) , crie ambientes de execução personalizados, implemente controles de acesso (como implantação de permissão) e muito mais.

** Mas esse controle extra vem com o custo da conectividade com o ecossistema maior. **Os aplicativos em uma cadeia compartilhada/universal têm acesso à liquidez já existente nessa cadeia (por exemplo, sem pontes adicionais entre as cadeias), possibilidade de composição com outros aplicativos e usuários já dedicados à atenção dessa cadeia. Construir em uma cadeia comum também requer menos trabalho/sobrecarga de engenharia interna do que um aplicativo executando sua própria cadeia.

Controles melhores poderiam melhorar a experiência do usuário se fossem gratuitos. Portanto, a resposta para a questão central - se os usuários ainda usariam um aplicativo se ele estivesse em sua própria cadeia - realmente depende de quão severo é esse controle versus compensação de conexão. **

2. Quantas conexões o aplicativo pode perder?

As conexões vêm em muitas formas. Os dois mais importantes são: 1) Atenção e 2) Capital.

** Observe a distribuição nativa. Se o projeto da equipe é a primeira coisa com a qual os usuários se envolvem quando entram no ecossistema, é um caso convincente para o aplicativo ter uma distribuição nativa. ** Aplicativos de controle de atenção são mais adequados para iniciar sua própria cadeia; os usuários usarão esse aplicativo independentemente da cadeia em que ele existe. Na minha opinião, exemplos atuais de aplicativos com distribuição nativa incluem Mirror, Zora, Manifold, Sound.xyz e OnCyber. Também existe o argumento de que aplicativos sem uma distribuição forte podem optar por lançar suas próprias cadeias para despertar o interesse.

O segundo componente da "conectividade" é o capital. Muitas vezes, os fundos implantados pelos usuários para um aplicativo são recuperados de outro aplicativo no mesmo ecossistema. Chamo isso de "liquidez compartilhada" e suas implicações são reais. Vimos novos aplicativos escolherem um rollup de uso geral em detrimento de outro devido à maior quantidade de ETH conectada ao ecossistema; o capital existente no ecossistema pode ajudar a remover barreiras à adoção do usuário (em vez de tentar convencer os usuários a entrar em um novo ecossistema). Essas considerações são relevantes para qualquer aplicativo que incorpore alguma forma de financeirização em seu produto. Exemplos fora do DeFi puro podem incluir a coleta de artigos NFT via Mirror, pagar para "roubar" imagens em uma Stealcam ou qualquer coisa com um recurso de gorjeta no produto.

**A perda dessa "conectividade de fundos" significa que os aplicativos precisam forçar os usuários a estacionar seu inventário na cadeia. ** Um motivo pode ser que os consumidores usam muito o aplicativo - a experiência de transição é dolorosa, por isso será mais fácil manter um suprimento saudável de fundos na cadeia. Mas ainda mais convincente do que o estoque ocioso é oferecer aos usuários opções que geram receita. Isso pode parecer uma forma de rendimento nativa da cadeia, um aplicativo construindo um produto adjacente que fornece rendimento (como o protocolo de empréstimo do Blur) ou outra coisa.

As razões acima (atenção e capital) também são o motivo pelo qual muitos veem os jogos on-chain como candidatos ideais para acúmulos específicos de aplicativos: eles são economias bastante independentes, controlam a mentalidade dos consumidores e são uma espécie de classificação e prevenção. O congestionamento é uma categoria importante para uma experiência de usuário agradável.

Em outras palavras, os jogos on-chain se beneficiam de um alto grau de controle e não são significativamente afetados se forem isolados. Outros aplicativos adequados para acúmulo de aplicativos podem fazê-lo subsidiando transações (por exemplo, as primeiras transações são gratuitas) ou não exigindo pagamento inicial (por exemplo, conteúdo on-chain gerado pelo usuário, certos aplicativos sociais, redes DePIN, etc.) Minimize os requisitos iniciais de capital do usuário.

Claro, existem outras razões pelas quais os projetos querem mais controle sobre sua infraestrutura. Ter um rollup introduz permissão para implantar ou a capacidade de implementar os requisitos de triagem do usuário (como KYC em sequenciadores pertencentes/operados pela cadeia). Nesses casos, no entanto, a linha entre bancos de dados rollup e bancos de dados centralizados torna-se cada vez menos clara.

3. Minimize a perda de conexão

À medida que as soluções de interoperabilidade melhoram, a conectividade versus compensação de controle torna-se menos crítica. **Pontes e sequenciadores geralmente são a infraestrutura crítica discutida nesta questão. 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. Um ordenador compartilhado faz isso ingerindo e ordenando transações de várias cadeias, criando um mecanismo de coordenação que permite que as ações em uma cadeia afetem as ações em outra. A composição atômica requer sequenciadores e pontes compartilhados - é garantido que o sequenciador contém várias transações (entre domínios) 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 são compostas por dois fatores: 1) o custo de publicação de dados para L1 e 2) o custo que os usuários pagam pela inclusão. **Os lotes do operador rollup chamam dados para transações, permitindo que os custos de publicação sejam distribuídos 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 o lançamento de transações em L1 até que tenham um tamanho de lote suficientemente grande. A consequência é um tempo de finalização mais lento e uma pior experiência do usuário. Pedidos compartilhados parecem servir cada vez mais como camadas de agregação, onde transações em lote de vários rollups menores podem ajudar a criar economia de unidade viável para a existência da cauda longa.

4. Estamos em um ponto de inflexão?

A ideia de cadeias de aplicativos e rollups de aplicativos não é nova. No entanto, por muito tempo, parecia uma área residencial em desenvolvimento: muita infraestrutura estava sendo construída, mas não havia moradores.

Mas nos últimos meses, começamos a ver o primeiro afluxo de residentes. A Lattice construiu o OpCraft, um mundo autônomo on-chain apoiado por seu próprio rollup. Projetos como o Lit Protocol e o Synapse anunciaram seus próprios rollups (embora ambos sejam mais voltados para infraestrutura do que para aplicativos). Zora lançou Zorachain. Conversas recentes com equipes de camadas de aplicativos mais maduras (especialmente aquelas que consideram estratégias L2) começaram a explorar se o rollup de aplicativos é adequado 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 do produto ao mercado com acúmulos específicos de aplicativos: sociais e de jogos dependem muito da indexação (e se beneficiam muito por não ter que competir com o estado compartilhado), problemas de pedido (especialmente na jogabilidade) e recursos personalizados (como transações sem gás) são especialmente úteis para produtos de consumo voltados para o entretenimento**. Muitas dessas equipes de aplicativos ainda estão em construção. Os jogos, em particular, podem levar anos para serem desenvolvidos e lançados.

Meu outro argumento é que chamar a atenção é o fator mais crítico para menos aplicativos financeiros. Até agora, este artigo definiu rollups de aplicativos como "um aplicativo por rollup". Mas essa visão pode ser muito estreita. Talvez vários aplicativos decidam formar um coletivo, reunir sua "atenção" e iniciar uma cadeia juntos. Da mesma forma, podemos ver um aplicativo importante decidir construir sua própria cadeia e incentivar outros aplicativos a serem implantados nela - na verdade, usando seu próprio aplicativo para testar a adoção da infraestrutura que deseja controlar.

Finalmente, acredito muito que veremos mais rollups no futuro. Houve uma proliferação de projetos de construção de serviços de infraestrutura para rollups de aplicativos. Caldera, Sovereign SDK, Eclipse, Dymension, Conduit, AltLayer, etc. fornecem soluções de baixa elevação para as equipes iniciarem seu próprio Rollup.

Espresso, Astria e SUAVE, da Flashbots, são alguns dos primeiros participantes no espaço dos sequenciadores. Os custos de configuração estão diminuindo e a compensação de "conectividade" se torna menos severa. Ambos reforçam o caso de adoção. **Mas um número tão grande de novos provedores de infraestrutura também significa que as equipes de aplicativos podem reservar um tempo para entender as várias opções e colocar esses vários jogadores à prova de batalha antes de escolher um vencedor. ** Novamente, embora haja sinais de adoção, acho que o ponto de inflexão ainda está a alguns meses de distância.