Blockchains de Camada 3: Solução de Escalabilidade ou Branding Manipulativo?

Originalmente, as blockchains de Camada 1 eram grandes praças públicas. O Bitcoin era uma praça de liquidação séria, um espaço rude e sem adornos, rígido e inflexível. O Ethereum trouxe a programabilidade para o cenário e, de repente, surgiu uma praça pública onde era possível construir plataformas de emissão de tokens, exchanges, jogos, protocolos de empréstimo, marketplaces de NFTs, DAOs, mercados de previsão e engrenagens financeiras que só faziam sentido na presença de advogados.

Mas o detalhe sobre uma praça pública é que ela atrai pessoas.

Nos primórdios, isso era uma grande vantagem! A atividade on-chain era um sinal de vitalidade, e todos, de desenvolvedores e mineradores a investidores e fundadores, queriam ver essa vitalidade crescer. Eles queriam que o seu canto da internet cripto fosse o local onde o valor era liquidado. Ninguém queria ver sua praça on-chain vazia. O congestionamento era uma medalha de honra, pelo menos no início: a prova cabal de que o mundo havia prestado atenção.

O congestionamento rapidamente virou um fardo. Os usuários do Ethereum conhecem bem o gosto amargo de pagar taxas exorbitantes para que uma transação seja confirmada. O usuário comum tem muito mais probabilidade de fechar a aba do navegador se tiver de pagar $500 para transferir alguns NFTs ou uma pequena quantia em tokens. Durante as bull runs, a hierarquia social on-chain se inverte: as baleias continuam movimentando quantias vultosas, enquanto o restante observa o oráculo de gas e se afasta assustado.

E assim, os primeiros sinais de escalabilidade da Camada 1 surgiram, não em um whitepaper ou nota de pesquisa, mas nos corações e mentes de desenvolvedores, usuários, investidores e protocolos.

Todos sentiam essa dor de maneiras distintas. Os usuários finais ficavam frustrados ao ver sua atividade on-chain ser taxada além de qualquer bom senso. Os desenvolvedores muitas vezes viam-se de mãos atadas diante dos custos crescentes, incapazes de subsidiar seus usuários e impedidos de continuar construindo. Os investidores assistiam desolados ao espetáculo da demanda sendo sufocada pelos custos de infraestrutura. E os desenvolvedores de protocolos ficavam incomodados ao ver seus produtos sendo comparados com base em valor versus custo, tendo de justificar todo o sistema em termos das despesas economizadas por um concorrente. Havia incentivos de sobra para expandir essa tubulação, e cada voz foi ouvida no desenvolvimento de soluções alternativas de escalabilidade.

As redes de Camada 1 ou se aprimoraram internamente, prometendo maior throughput a custos mais baixos — embora nem sempre com sucesso —, ou buscaram reposicionar velocidade e eficiência como propostas de valor em si mesmas. O Ethereum optou por esta última abordagem: uma versão mais enxuta de si mesmo na camada base, enquanto a maior parte da ação on-chain migraria para outro lugar. Uma ficção polida, talvez, mas não de todo desonesta, visto que as camadas superiores eram, de fato e de muitas formas, um anexo da rede principal.

A Camada 2 Não Foi um Acidente

O surgimento das redes de Camada 2 também não ocorreu por mero acaso. Ninguém queria abrir mão da reputação consolidada e da segurança do Ethereum, mas todos desejavam uma infraestrutura mais barata para o seu respectivo nicho na economia de aplicativos, e os rollups surgiram como esse meio-termo. Ao transferir as transações confusas para fora da cadeia principal e permitir que os smart contracts resolvessem disputas de maneira verificável, desenvolvedores e usuários puderam unir o útil ao agradável. A segurança do Ethereum permaneceu intocada, enquanto todos aproveitavam transações mais rápidas, baratas e com menos dores de cabeça.

Foi uma solução tanto política quanto técnica. O Ethereum não precisou se transformar em uma Solana, e os desenvolvedores não precisaram abandonar o ecossistema. Os fundos de venture capital não precisaram admitir que a demanda por aplicativos cripto havia ficado aquém de suas expectativas ambiciosas, enquanto os usuários puderam continuar acreditando na promessa de descentralização e abertura do Ethereum, aproveitando taxas mais baixas e maior velocidade. Todos preservaram suas narrativas e todos conseguiram o que queriam.

Optimism, Arbitrum, Base e outros rollups baseados em tecnologia optimistic ou zero-knowledge, além de zkSync, Starknet e as diversas iniciativas de escala da Polygon — e, a bem da verdade, a própria compreensão de todo o setor sobre o que representa uma Camada 2 — basearam-se nessa visão compartilhada do problema e dessa solução em particular. À parte os pormenores técnicos sobre fraud proofs, validity proofs, ambientes de execução, camadas de liquidação e settlement chains, todas as vozes do ecossistema concordavam com as linhas gerais do problema e da solução. Os desenvolvedores que construíam no Ethereum queriam maximizar seu throughput de transações, mas também minimizar custos e atritos para seus usuários finais. Em outras palavras, todos queriam exatamente o que temos hoje em Base, Optimism, Arbitrum, etc.: uma cadeia de liquidação com transações mais rápidas e baratas que, de alguma forma, continuava fingindo ser o Ethereum.

A Camada 2 fazia todo o sentido como resposta ao congestionamento da camada base e à consequente disparada nas taxas. E é por isso, em parte, que estamos falando de uma Camada 3: porque a Camada 2 resolveu o congestionamento da primeira camada e agora todos já miram o próximo patamar de escalabilidade.

A Proposta da Camada 3

Uma Camada 3, ao menos de acordo com a cartilha oficial, consiste em blockchains específicas para aplicações (appchains) construídas sobre redes de Camada 2. Em outras palavras, aplicativos específicos podem consolidar seu próprio nicho dentro do ecossistema mais amplo. Um jogo não precisa rodar no mesmo ambiente que uma plataforma de mídia social, e um protocolo de empréstimo não precisa compartilhar sua camada de liquidação com um mercado de previsão. Uma plataforma de fidelidade pode preferir seu próprio token de gas, enquanto um jogo de tiro competitivo talvez precise de uma camada de liquidação própria para suportar transações de alta frequência. Um aplicativo corporativo pode priorizar privacidade, permissões de acesso e throughput previsível, enquanto uma exchange de derivativos pode buscar tempos de bloco menores e latências reduzidas para seus order books.

Um ecossistema tão diverso quanto o de cripto necessita de uma camada de liquidação tão multifacetada quanto o Ethereum, argumenta a proposta. Contudo, desenvolvedores e usuários de aplicativos específicos não querem ter de compartilhar smart contracts, carteiras, tokens de gas, bridges ou disponibilidade de dados com o resto do mundo. Todos querem uma Camada 3.

O Arbitrum Orbit e a ZK Stack da zkSync oferecem um vislumbre do futuro: um cenário em que desenvolvedores podem construir seus próprios ZK-Rollups ou Optimistic Rollups sob medida, cada qual com seu token de gas, soluções de disponibilidade de dados, estruturas de governança, premissas de liquidação, throughput e características de performance próprios. O Arbitrum Orbit, por exemplo, viabiliza a criação de redes personalizadas sobre a Arbitrum One ou Nova, com opções de customização que vão da camada de liquidação à disponibilidade de dados. O discurso é sedutor, como seria de se esperar em um setor movido a aportes de venture capital — throughput dedicado, desempenho focado na aplicação, gas tokenizado, UX aprimorada, tudo no conforto de sua própria cadeia particular —, mas as realidades econômicas e técnicas subjacentes são difíceis de ignorar. Um rollup construído sobre outro rollup pode ser a solução que todos buscam, ou pode ser apenas a ponta de um problema ainda maior.

Algumas motivações são claras, enquanto outras permanecem difusas. Usuários finais não se preocupam com camadas em si, mas costumam ser bastante sensíveis aos custos e benefícios de UX. O desenvolvedor de um jogo pode estar disposto a gastar mais em custos de infraestrutura em troca de uma retenção melhor, mas esse mesmo desenvolvedor talvez não queira que seus usuários percebam que estão em um ambiente de liquidação alternativo. Em suma, uma Camada 3 funciona muito bem, desde que os usuários não precisem pensar sobre ela. Se a UX do jogo for refinada o bastante, o jogador casual talvez nem sequer perceba a diferença entre uma Camada 1 e uma Camada 3.

A proposta para os desenvolvedores é semelhante, mas traz nuances extras: em teoria, um rollup soberano voltado a um aplicativo é sinônimo de throughput, desempenho e flexibilidade com gas, sem distrações para o protocolo em si; na prática, o desenvolvedor é forçado a gerenciar cada detalhe da infraestrutura e das operações, da segurança da bridge à UX da carteira, capacidade de atualização e taxas de transação. Quem desenvolve no Ethereum sabe que compartilha o mesmo ambiente de liquidação com os demais, o que serve como um lembrete salutar de que ele é apenas uma peça em uma engrenagem imensa; no entanto, a soberania cobra seu próprio preço.

Já o discurso para as empresas é ainda mais complexo. Envolve desempenho, mas também posicionamento estratégico: todos adoram uma boa narrativa, e fundadores adoram anunciar aos usuários que agora possuem sua própria rede. No universo dos investimentos de venture capital, a distância entre “construímos um contrato interessante” e “lançamos uma revolucionária Camada 3” é muito pequena.

A Empresa Que Descobre uma Nova Camada

Certo dia, na sede da Moonforge Studios, uma funcionária levanta os olhos do almoço e se dá conta de que o único jogo da empresa, dois protótipos em andamento, seu token, seu community manager exausto e seu CEO — que fala sem parar sobre barreiras competitivas de infraestrutura — correm sério risco de serem esquecidos pelo mercado cripto. Os custos do jogo não são absurdos, mas também não favorecem o crescimento orgânico da base de usuários, e a economia de tokens, o comércio de itens em NFT e as compras in-game pesam no bolso do usuário comum. A equipe de produto discute com a engenharia sobre abstração de gas, taxas de transação e custos de crafting de itens, questionando se uma rede sob medida conseguiria mitigar essas despesas e otimizar a UX geral do produto. Os engenheiros mostram-se ansiosos para expor suas ideias, mas o CTO logo lembra a todos da necessidade de manter a compatibilidade com o ecossistema mais amplo. O líder de produto quer que qualquer usuário possa interagir com o jogo sem sequer pensar em blockchains, carteiras e tokens — o custo do gas deve ser invisível, assim como a UX de saque caso ele decida resgatar seus ativos in-game. O CFO está mais interessado em saber como as taxas da rede poderiam rentabilizar o jogo: o token de gas poderia virar uma fonte de receita? A tokenomics do token in-game poderia ser alterada para incentivar a adesão? O time de token quer atrelar tudo ao ativo do jogo, mas o marketing prefere explorar a narrativa abrangente do metaverso. O CEO escuta atentamente e já imagina o impacto do comunicado à imprensa sobre o lançamento da nova Camada 3 de alto desempenho da Moonforge, voltada para economias de fantasia on-chain.

Não há nada de inerentemente errado nesse cenário hipotético, exceto, talvez, pela premissa inicial de que um jogo precisa de uma camada de liquidação exclusiva para existir.

Havendo demanda suficiente, uma Camada 3 feita sob medida pode sim aprimorar o desempenho de uma economia específica, isolando os usuários dos custos, riscos e fricções de interagir com o ecossistema mais amplo do Ethereum. Os desenvolvedores poderiam subsidiar o próprio gas, ditar seus termos e condições e oferecer um ambiente propício ao sucesso do produto. Na teoria, um ambiente de liquidação dedicado e desenhado para uma aplicação melhoraria a experiência de todos os envolvidos.

Mas e se essa demanda não existir? E se um token exclusivo, assim como uma economia de tokens sob medida, não ganhar tração? E se a promessa de um rollup soberano for usada apenas como pretexto para inflar a base de usuários com campanhas vazias de marketing antes de entregar qualquer valor real? E se o desejo de construir uma stack de UX de alto desempenho e autocontida for apenas uma cortina de fumaça para promover o projeto como descolado, inovador e visionário? E se uma Camada 3 não for o que o produto realmente necessita?

Tudo depende de quem está fazendo a pergunta. Uma empresa que desenvolve o ambiente de liquidação para um jogo, aplicativo social, pacote corporativo ou DEX de derivativos pode ter prioridades muito diferentes das de uma equipe de protocolo que lança um produto nesse mesmo ambiente. Para a empresa, uma rede proprietária é uma declaração de intenções; para a equipe do protocolo, pode ser um obstáculo à adoção e uma afronta aos princípios do Ethereum. Uma empresa que constrói sua própria carteira, sequenciador, bridge, token de liquidação, disponibilidade de dados, mecanismo de governança e camada de UX pode tentar convencer os usuários de que tudo gira em torno de uma experiência fluida, mas, na realidade, trata-se de diferenciação, posicionamento de mercado e atratividade para fundos de venture capital.

Onde o Termo da Moda Falha

Existem excelentes razões para que redes de Camada 3 fracassem, ou ao menos tenham um desempenho abaixo do esperado. A primeira delas diz respeito à complexidade, tanto técnica quanto política.

Camadas de liquidação existem para liquidar, mas também precisam coordenar uma lista crescente de serviços secundários: disponibilidade de dados, suporte a carteiras, bridging, nós RPC, exploradores de blocos, indexação, monitoramento, fraud proofs, atualizações, precificação de gas e afins. Se um ambiente de liquidação específico for complexo demais de operar, monitorar e manter, ele fracassará. Se o protocolo em si — e, por extensão, a empresa por trás dele — não puder arcar com esses custos, ele fracassará. Em outras palavras, criar uma camada de liquidação própria para o seu app não é um atalho fácil. Trata-se, na verdade, de um dos caminhos mais difíceis para construir um negócio sustentável em cripto. Se operar um rollup já é desafiador, construir um rollup sobre outro rollup adiciona obstáculos pelas razões erradas.

A principal fragilidade de uma Camada 3, no entanto, reside na sua herança de segurança, que frequentemente ignora os desafios práticos de sustentar uma blockchain. Camadas de liquidação liquidam sobre outras camadas de liquidação, que por sua vez liquidam no Ethereum. A impressão geral é de que todos querem uma Camada 3 porque desejam a segurança do Ethereum, mas sem arcar com os custos de sua finalidade de liquidação. Estruturalmente, cada camada adicional introduz mais premissas ao modelo de segurança, amplia os vetores de ataque e multiplica as chances de falha. Uma camada de liquidação construída sobre uma L2 fica sujeita aos mesmos riscos dessa L2: fraud proofs, riscos na publicação de dados, censura na sequenciação e centralização na gestão de chaves. Os mesmos riscos se estendem à camada construída sobre a Camada 3. Se a segurança da cadeia for questionável ou suas premissas falhas, os usuários assumirão todo o risco. Na prática, isso costuma se traduzir em segurança frágil nas carteiras, pior UX de bridging, governança on-chain insegura, estratégias instáveis de disponibilidade de dados, carência de monitoramento e auditoria e um processo problemático de resolução de disputas.

Os problemas de infraestrutura da Degen Chain serviram de lição para todo o ecossistema. Projetada como uma Camada 3 rápida, barata e focada na comunidade, conectada à Base por meio das ferramentas do Arbitrum Orbit, ela atraiu usuários em busca de alternativas à lentidão e às taxas pesadas de gas do Ethereum. Quando o incidente ocorreu, a maioria dos usuários desconhecia os detalhes técnicos do funcionamento da Camada 3; no entanto, diante das falhas de infraestrutura — uma atualização mal testada por um provedor resultou em inatividade, estado corrompido e perda de ativos —, não hesitaram em culpar a equipe pela migração, pelas brechas na bridge e pelo roubo de gas. No nível mais básico, os problemas refletiram uma incompreensão geral sobre o funcionamento da segurança da bridge e da liquidação. Usuários com maior conhecimento técnico — cientes das ferramentas do Arbitrum Orbit, da liquidação na Base e da prova de conceito da própria Degen Chain — eram muito mais céticos quanto às alegações de que a Camada 3 era segura, disponível e confiável. Na prática, parece que poucos entenderam que suas chaves privadas não eram os únicos pontos de controle: o processo de migração e verificação do state root dependia de várias entidades externas confiáveis, nenhuma das quais — aos olhos de muitos — demonstrava ser plenamente confiável.

Isso não é necessariamente uma crítica exclusiva à Degen Chain — é uma constatação de que poucas pessoas entendem como funciona a infraestrutura de liquidação de uma Camada 3, e que viabilizar uma é um feito extremamente complexo do ponto de vista técnico e operacional. Os percalços da Degen Chain não diferem dos enfrentados pelas primeiras Camadas 2, ressalvando-se que poucos compreendem até que ponto uma Camada 3 depende de entidades externas confiáveis para operar, monitorar e manter seu ambiente. É difícil prever com certeza os riscos no longo prazo, mas é perfeitamente viável avaliar os de curto prazo. Uma quantidade de usuários, liquidez ou desenvolvedores abaixo do esperado pode ser fatal para o futuro de uma rede de liquidação, especialmente em um cenário de disputa feroz pela mesma audiência. O suporte deficiente de carteiras ou a escassez de liquidez impõem barreiras pesadas a um ambiente iniciante. Pior ainda: uma falha operacional pode minar a confiança na Degen Chain e, por tabela, nas ferramentas do Arbitrum Orbit que a sustentam. Qualquer um desses fatores isolados, ou combinados, abala profundamente a maturidade de uma Camada 3 recém-lançada.

Outro ponto vulnerável de um ambiente de liquidação sob medida é o isolamento de liquidez, um desafio operacional que quase nunca surge nas discussões teóricas. O problema se manifesta porque a maioria das Camadas 3 de menor porte não consegue capturar liquidez suficiente para atender aos seus usuários. Os ativos nessas redes podem sofrer com tokenomics frágeis, ausência de bridges nativas para outras redes ou outras L3s, falta de suporte adequado de carteiras ou indisponibilidade de dados on-chain em exploradores de blocos convencionais. Em suma, uma camada de liquidação L3 com poucos usuários e liquidez escassa pode cair no ciclo desfavorável de repelir novos provedores de liquidez e travar a adesão. Desenvolvedores também podem calcular mal o nível de atrito na UX que os usuários toleram ao migrar para um ambiente isolado. Na prática, isso costuma resultar em redes que, em tese, processam milhões de transações por segundo, mas não conseguem atrair um único usuário devido à integração precária com a infraestrutura existente e a uma economia de tokens pouco competitiva.

Redes Reais e Resultados Reais

Os casos de uso mais evidentes para uma Camada 3 estão nos jogos e aplicativos sociais, onde o valor financeiro capturado por transação é baixo, mas o volume geral é alto. A Xai, uma infraestrutura para jogos baseada em ZKP construída sobre o Arbitrum Orbit, é o principal exemplo de um ambiente de liquidação voltado a jogos. Criada para permitir que games integrem propriedade digital sem repassar os atritos de UX de uma rede compartilhada aos jogadores, ela registrou forte adoção com títulos como The Lost Glitches e Tollan Universe, contabilizando milhões de transações em seu ecossistema. Argumento semelhante vale para as redes Apex e Boss da Proof of Play, desenhadas para jogos e responsáveis por impulsionar títulos como Pirate Nation e outros sucessos play-to-earn on-chain. O valor financeiro por transação no ecossistema de games é reduzido, mas a frequência é expressiva para os padrões do mercado cripto; nesse contexto, a capacidade de isolar custos de gas e fricções de UX torna-se extremamente valiosa para estúdios e jogadores.

A Degen Chain, por seu lado, exemplifica a tese dos social tokens em camadas sob medida. Construída sobre o Arbitrum Orbit, a rede registrou uma explosão de uso entre projetos e desenvolvedores nativos do Farcaster que buscavam uma alternativa aos custos de UX do Ethereum para microtransações e NFTs. Seu futuro, entretanto, segue incerto diante de problemas de infraestrutura e de uma base de usuários relativamente pequena. Ainda assim, o projeto provou que ambientes de liquidação de Camada 3 possuem apelo concreto para usuários, desenvolvedores e organizações maiores que pretendem migrar suas operações sem renunciar às garantias de segurança da rede Ethereum.

O mesmo se aplica à ApeChain e à Treasure Chain, que representam o outro extremo: comunidades consolidadas e ecossistemas de jogos de grande porte que preferem construir suas próprias estruturas de liquidação em vez de depender de um ambiente compartilhado. Argumentação semelhante pode ser feita para a Orbs, que não se posiciona comercialmente como uma Camada 3, mas sim como uma infraestrutura cross-chain para protocolos DeFi, buscando viabilizar liquidação dedicada a finanças descentralizadas em diversas cadeias, incluindo o Ethereum. Por fim, as redes da ZK Stack e o conceito abrangente da Elastic Network simbolizam a visão oposta: um universo de ZK-Rollups interconectados por uma camada comum de liquidação, viabilizando recursos especializados por rede em vez de por desenvolvedor individual.

Pensamento Crítico Além da Stack

Não há nada de errado em utilizar um ecossistema de gas customizado. Contudo, é fundamental lembrar que a grande maioria dos usuários de cripto não quer ser forçada a navegar por uma infraestrutura complexa, especialmente se a interação deles com a tecnologia blockchain se resumir a um único aplicativo. Usuários se importam com a experiência entregue pelo produto, não com os fundamentos técnicos subjacentes ou com o posicionamento da empresa que o criou. Se uma carteira exige um processo de saque confuso em várias etapas toda vez que o usuário decide realizar seus tokens, a percepção de conveniência e facilidade desaparece, pouco importando o discurso da empresa sobre sua suposta UX de liquidação superior. Acima de tudo, qualquer empresa que promova sua própria infraestrutura precisa ter em mente que rodadas de venture capital e euforia passageira raramente compensam um design de produto deficiente.

Ambientes de liquidação de Camada 3 trazem um desafio singular aos usuários finais em matéria de UX e captura de valor. No entanto, é um custo pequeno a pagar por um produto mais eficiente, desde que a empresa não se esqueça de que são seus diferenciais fundamentais que sustentam o sucesso do negócio. É difícil cravar se um ambiente com taxas de gas dedicadas é indiscutivelmente superior a um ambiente compartilhado em todos os casos — mas é prudente afirmar que nenhuma empresa se beneficia ao tratar qualquer um dos lados como a salvação definitiva para a indústria cripto.

É nesse ponto que a precificação do Netts se torna prática no dia a dia: ela permite consultar os preços atuais de TRON Energy para que se possa comprar TRON Energy, buscar a melhor cotação de TRON Energy e analisar o custo-benefício de ofertas baratas de TRON Energy antes de realizar uma transferência de USDT e consumir TRON Energy. Em suma, a escolha da taxa passa a ser um valor totalmente transparente antes de iniciar a transação.