Por que o Web3 não sabe ler - ForkLog

# Por que o Web3 não sabe ler

Há alguns anos, a indústria discutia como aumentar a capacidade de transferência das blockchains. Hoje, muitas redes já conseguem processar dezenas de milhares de operações, e algumas chegam a declarar centenas de milhares. No entanto, descobriu-se que gravar dados na blockchain é apenas metade do trabalho. Eles ainda precisam ser encontrados, indexados, verificados e entregues aos aplicativos.

Assim, em alguns lugares, a velocidade de geração de dados passou a exceder as capacidades da infraestrutura para processá-los. Como a blockchain muda por causa disso, a ForkLog analisou.

Quanto mais rápido, mais demora

Cerca de dez anos atrás, o desenvolvimento das blockchains era descrito pela chamada “trilema da escalabilidade”. De acordo com essa ideia, as redes são obrigadas a buscar um compromisso entre segurança, descentralização e desempenho. Mas em 2026 fica claro que, mesmo que o problema de capacidade de transferência seja resolvido parcialmente, surge um novo desafio.

A própria blockchain não tem interfaces com o usuário. Esse papel fica a cargo de diversos aplicativos. E eles, por sua vez, precisam receber dados continuamente:

• saldos dos endereços;
• histórico de transações;
• estado dos smart contracts;
• eventos e logs;
• análises de mercado;
• dados para gerenciamento de risco;
• mensagens entre redes.

Quanto mais rápido funciona a rede, mais desses tipos de dados precisam ser processados

Entre os usuários existe um equívoco comum: se a informação foi gravada na blockchain, então basta obtê-la. Na prática, é exatamente o contrário. Ler dados “brutos” diretamente da blockchain em tempo real é um processo lento, caro e tecnicamente complexo. No ecossistema Web3, é difundida uma camada intermediária de infraestrutura que conecta carteiras aos dapps.

Por exemplo, um aplicativo de carteira, para o usuário ver seu saldo em frações de segundo, faz requisições a provedores de RPC, indexadores, plataformas de análise, servidores de cache, bancos de dados especializados e assim por diante.

O processo funciona assim:

1. Coleta de dados: Programas especiais “leem” continuamente a blockchain à medida que novos blocos surgem.
2. Indexação (estruturação): Eles fazem parsing (desmontam) esses dados e os organizam em bancos de dados clássicos, bem rápidos (por exemplo, PostgreSQL ou ClickHouse). Ali eles ficam estruturados de forma conveniente: “Endereço — Lista de todos os seus tokens”.
3. Resposta instantânea: A carteira recebe uma resposta já pronta e filtrada do cache em milissegundos.

Na prática, a maioria dos aplicativos populares do Web3 funciona por meio de uma camada adicional de processamento da informação. Imagine se a blockchain processa 50 000 operações por segundo e milhões de carteiras, ao mesmo tempo, enviam requisições RPC para atualizar as telas. Os servidores dos provedores não aguentam essa carga. Ler, indexar e ordenar os dados para o usuário é uma tarefa computacional extremamente complexa. Indexadores e serviços de acesso a dados muitas vezes ficam alguns blocos atrás do estado atual da rede, porque processar, estruturar e entregar dados leva tempo adicional. E não é apenas por causa de “infraestrutura desatualizada”, embora isso também exista. É por causa de um conflito profundo entre arquiteturas Web2 e Web3

Os usuários e os aplicativos interagem com a blockchain tão ativamente e com tanta frequência quanto, no dia a dia, a internet tradicional com resposta instantânea. Quando você rola o feed de uma rede social, o aplicativo faz milhares de requisições por segundo ao servidor para atualizar curtidas, comentários e imagens. Em Web2, robôs de trading podem consultar servidores de exchanges milhões de vezes por minuto. Servidores do Google ou da Amazon aguentam isso facilmente, porque são centralizados: os dados ficam, grosso modo, em um único banco enorme de onde podem ser copiados instantaneamente para milhares de servidores-espelho ao redor do mundo.

A blockchain funciona de modo diferente e não está preparada para isso no nível de hardware. Até bem pouco tempo, o principal obstáculo de velocidade nela era a matemática e a criptografia. Era preciso fazer milhares de computadores ao redor do mundo chegarem rapidamente a um acordo (consenso) de que a transação é válida. Os desenvolvedores resolveram esse problema “ensinando” as máquinas a fazer execução paralela e separando consenso e execução. Por exemplo, Solana, Monad e Aptos suportam execução paralela de transações independentes, ao contrário do modelo sequencial clássico do Ethereum. Ao mesmo tempo, no Monad essa separação de coordenação da ordem das transações e sua execução subsequente fica ainda mais evidente, enquanto no Solana e no Aptos o paralelismo é implementado via arquitetura do runtime e gerenciamento de conflitos por estado.

No fim, dá para aprovar dezenas de milhares de transações por segundo (TPS). Mas aqui está a armadilha.

Historicamente, a blockchain cumpria quatro funções ao mesmo tempo:

• execução de transações;
• consenso;
• armazenamento de dados;
• fornecimento de acesso a dados.

O aumento de desempenho eleva a carga sobre todas essas quatro funções simultaneamente. O sistema passa a gerar dados mais rápido do que a infraestrutura consegue lê-los, criando o chamado indexer gap.

Na documentação da Helius — um dos maiores provedores de infraestrutura do ecossistema Solana — consta diretamente que a estrutura sequencial da blockchain é bem adequada para garantir integridade dos dados e alta capacidade de transferência, porém deixa requisições históricas lentas e ineficientes. Por isso, a maioria das empresas é forçada a construir seus próprios indexadores e bases de dados separadas sobre a blockchain.

Analistas da ChainScore Labs chamam indexer gap de um dos principais problemas do ecossistema Solana. Pelas estimativas deles, abordagens tradicionais de indexação lidam mal com a arquitetura da rede, onde alta frequência de blocos e execução paralela de transações criam um fluxo enorme de dados.

O efeito é este: a rede pode confirmar operações quase instantaneamente, mas os aplicativos precisam de bem mais tempo para processar as consequências dessas operações.

As velocidades do Web3 esbarraram na física banal (e não só)

Ou, mais exatamente, na capacidade de processamento de CPUs, discos rígidos e cabos de rede. Descobriu-se que escalabilidade de uma blockchain não é igual à escalabilidade da infraestrutura ao redor dela. E isso precisa ser resolvido o quanto antes

Vamos imaginar uma rede com 100 000 TPS. Não basta apenas gravar a transação; é preciso também:

• salvar o estado;
• atualizar índices;
• responder às requisições das carteiras;
• atender bots;
• atender analistas;
• atender sistemas de busca;
• atender agentes de IA.

Por isso, alta capacidade de transferência cria competição por recursos entre consenso, execução de transações e serviços de infraestrutura sobre a rede.

O desenvolvimento paralelo de algumas das tecnologias envolvidas faz com que esse problema precise ser enfrentado já agora. Para um ser humano, latências de segundos ou até minutos podem ser toleradas. Para agentes de IA, sistemas de trading e serviços autônomos — não. Se uma máquina toma decisões com base em dados on-chain, informação desatualizada significa erro, perda de oportunidade ou até prejuízo financeiro direto.

Ao mesmo tempo, a Ethereum Foundation, na documentação atualizada de 2026, indica que nós de arquivo exigem de 3 a 12 TB de espaço em disco, e a sincronização inicial pode levar até um mês mesmo em equipamentos suficientemente potentes. O limitador são a velocidade de SSD, a quantidade de memória e o desempenho da CPU.

Além disso, desenvolvedores do Geth descrevem separadamente o modelo antigo de armazenamento em arquivo, em que o tamanho do banco do Ethereum podia ultrapassar 20 TB e a sincronização levava meses. Foi exatamente por isso que foi necessário criar uma nova arquitetura de armazenamento path-based para o estado.

Ou seja, sim: “hardware”, processadores, capacidade de transferência da rede, CPU — são limitadores físicos reais na corrida pelo aumento da quantidade de informação. Mas não são os únicos. Servidores modernos já conseguem processar volumes enormes de dados. A questão é outra: quanto milhares de participantes independentes da rede deveriam pagar por isso?

Por exemplo, se para participar plenamente do ecossistema forem necessários dezenas de terabytes de SSD, centenas de gigabytes de RAM, canais de comunicação caros, o número de operadores de infraestrutura inevitavelmente diminui. Assim surge uma nova centralização.

Formalmente, dá para processar os dados, mas não será possível fazer isso de forma barata e descentralizada ao mesmo tempo. O custo de processar informação começa a crescer mais rápido do que o custo das próprias transações.

Como reagiu o mercado

Os participantes da corrida já entendem que os vencedores serão as redes que conseguirão transformar transações em informação acessível com mais rapidez, menor custo e maior confiabilidade. E neste ano, o mercado inesperadamente deslocou o foco para a transição a blockchains modulares.

Se a primeira geração de redes tentava executar todas as tarefas ao mesmo tempo, a nova geração separa as responsabilidades entre camadas especializadas. Em vez de uma única rede, surgiram camadas separadas:

• execution layer — camada de execução (ou de processamento);
• settlement layer — camada de liquidação (ou de acerto);
• consensus layer — camada de consenso;
• data availability layer — camada de disponibilidade de dados.

Desenvolvedores comparam esse processo com a evolução de data centers. Antes, um único servidor fazia todas as funções. Hoje, computação, armazenamento de dados e serviços de rede são escalados de forma independente um do outro

Uma das áreas que mais crescem no mercado são as redes de DA. À primeira vista, a ideia parece estranha: por que criar um blockchain separado para armazenar temporariamente os dados de outro blockchain? Mas é exatamente isso que está acontecendo. Na arquitetura modular, execução de transações e armazenamento de dados podem existir separadamente. O Rollup publica dados em uma camada externa de DA, e não na rede principal. Isso permite reduzir significativamente o custo da escalabilidade e aumentar a capacidade de transferência.

Há alguns anos, RPC era considerado um detalhe técnico. Hoje, é um dos elementos mais importantes da criptoinfraestrutura. Em maio de 2026, Triton One em conjunto com Solana Foundation lançou um anúncio atualizado de RPC 2.0 — uma nova abordagem para construir a arquitetura de leitura de dados na rede

A ideia central consiste em separar o acesso ao estado atual da rede e ao seu histórico. Para isso, são introduzidos dois módulos independentes: um indexa o estado das contas em tempo real, e o segundo otimiza o trabalho com dados históricos. Em vez de fazer varredura completa da blockchain, o sistema cria índices adaptativos para consultas específicas de aplicativos, o que reduz atrasos e o custo do processamento.

Dessa forma, Triton e Solana tentam eliminar uma série de limitações sistêmicas: a arquitetura monolítica de RPC cara e ineficiente, um conjunto limitado de requisições padrão JSON-RPC e a dependência de desenvolvedores de soluções próprias ou proprietárias para trabalhar com dados. No novo modelo, a leitura escala separadamente do consenso, e o acesso ao histórico fica mais rápido graças ao uso de armazenamento coluna-até e dados pré-ordenados.

O projeto se baseia em ferramentas já implementadas no ecossistema — incluindo streaming de dados a partir de validadores (Geyser, Yellowstone gRPC) e soluções para processar histórico. Toda a infraestrutura é distribuída com código aberto, e seu desenvolvimento é coordenado com participação da Solana Foundation.

Como resultado, a Solana tenta, de fato, sair de um “RPC universal” para uma data-infra modular e especializada, que supostamente deve reduzir barreiras para desenvolvedores e tornar o trabalho com dados da blockchain comparável em praticidade a bancos de dados tradicionais.

A modularidade resolve o problema?

Se a Solana conseguir padronizar a camada de leitura, isso pode fortalecer sua posição como rede com infraestrutura de aplicação desenvolvida, e não apenas com alta capacidade de transferência. Mas ao mesmo tempo isso intensifica a concorrência com provedores de RPC independentes e plataformas de infraestrutura, que terão de se adaptar ao novo padrão ou oferecer serviços adicionais acima dele.

A arquitetura modular elimina parte das limitações de infraestrutura, mas as transfere para outras camadas do sistema. É compreensível a busca por reduzir custos e simplificar o acesso a dados sem os quais não funcionam DeFi, NFT, carteiras, análise e ferramentas de compliance. Porém, parece que no próprio “DNA” do Web3 está embutido o efeito de complexificação em cascata: resolver um problema inevitavelmente cria novos desafios.

O novo esquema certamente exigirá uma camada de infraestrutura mais complexa: com indexadores, armazenamentos, cache, pipelines separados e novos pontos de falha. Em vez de uma camada única e simples de RPC, o ecossistema pode acabar com várias implementações paralelas, otimizações incompatíveis e ainda maior dependência de provedores de infraestrutura. Nesse caso, formalmente uma arquitetura aberta nem necessariamente significa um modelo realmente aberto e conveniente para todos acessarem.

Por enquanto, estamos na etapa em que o mercado saiu da concorrência sobre quem consegue extrair dados da rede melhor, para uma disputa sobre quem vai criar primeiro produtos baseados nesses dados. Quem e quanto vai pagar por isso — provavelmente saberemos em breve