Por que a Web3 não consegue ler - ForkLog

# Porque a Web3 não consegue ler

Há alguns anos atrás, a indústria discutia como aumentar a capacidade de processamento das blockchains. Hoje, muitas redes já conseguem lidar com dezenas de milhares de operações, e algumas chegam a anunciar centenas de milhares. No entanto, descobriu-se que gravar dados na blockchain é apenas metade do problema. É ainda necessário encontrá-los, indexá-los, validá-los e entregá-los às aplicações.

Assim, em alguns casos, a velocidade de geração de dados passou a exceder as capacidades da infraestrutura para processá-los. Como é que isto está a mudar a blockchain — a ForkLog explicou.

Quanto mais rápido, mais tempo demora

Há cerca de dez anos, o desenvolvimento das blockchains era descrito através da chamada trilema da escalabilidade. De acordo com esta ideia, as redes são obrigadas a procurar um compromisso entre segurança, descentralização e desempenho. Mas em 2026 fica claro que, mesmo conseguindo resolver parcialmente o problema de throughput, surge um novo desafio.

Por si só, a blockchain não tem interfaces para utilizadores. Esse papel é assumido por várias aplicações. E, por sua vez, elas precisam de receber dados continuamente:

• saldos de endereços;
• histórico de transações;
• estado dos smart contracts;
• eventos e logs;
• analítica de mercado;
• dados para risk management;
• mensagens entre redes.

Quanto mais depressa a rede funciona, mais destes dados é necessário processar.

Entre os utilizadores existe um equívoco comum: se a informação foi registada na blockchain, então basta obtê-la. Na prática, acontece exatamente o contrário. Ler diretamente os «dados brutos» da blockchain em tempo real é um processo lento, caro e tecnicamente complexo. No ecossistema Web3, existe uma camada infraestrutural intermédia, amplamente difundida, que liga as wallets às aplicações dapp.

Por exemplo, para uma aplicação de wallet mostrar o saldo ao utilizador em frações de segundo, ela recorre a providers RPC, indexadores, plataformas de analítica, servidores de cache, bases de dados especializadas, etc.

O processo funciona da seguinte forma:

1. Recolha de dados: Programas especiais «lêem» continuamente a blockchain à medida que surgem novos blocos.
2. Indexação (estruturação): Analisam (fazem parsing) esses dados e organizam-nos em bases de dados clássicas, muito rápidas (por exemplo, PostgreSQL ou ClickHouse). Lá ficam estruturados de uma forma conveniente: «Endereço — Lista de todos os seus tokens».
3. Resposta instantânea: A wallet recebe uma resposta pronta, filtrada, da cache em milissegundos.

Na prática, a maioria das aplicações Web3 populares funciona através de um nível adicional de processamento de informação. Imagine que a blockchain processa 50 000 operações por segundo e, ao mesmo tempo, milhões de wallets enviam pedidos RPC para atualizar os ecrãs. Os servidores dos providers não aguentam esta carga. Ler, indexar e ordenar dados para o utilizador é uma tarefa computacional extremamente complexa. Os indexadores e os serviços de acesso a dados muitas vezes ficam atrás do estado atual da rede em alguns blocos, porque processar, estruturar e entregar dados exige tempo adicional. E não é apenas por causa de «infraestrutura desatualizada», embora também exista. É por causa de um conflito profundo entre as arquiteturas Web2 e Web3.

Os utilizadores e as aplicações comunicam com a blockchain tão ativamente e com tanta frequência quanto, no utilizador comum, no ambiente de internet com resposta instantânea. Quando você faz scroll no feed de uma rede social, a aplicação faz milhares de pedidos por segundo ao servidor para atualizar likes, comentários e imagens. Em Web2, bots de trading podem interrogar os servidores das exchanges milhões de vezes por minuto. Servidores da Google ou da Amazon aguentam facilmente isso, porque são centralizados: os dados ficam, por assim dizer, numa única base de dados enorme, de onde podem ser copiados instantaneamente para milhares de servidores-espelho em todo o mundo.

A blockchain funciona de outra maneira; não está preparada para isso a nível de hardware. Até há pouco tempo, os principais obstáculos de velocidade na blockchain eram a matemática e a criptografia. Era necessário fazer com que milhares de computadores em todo o mundo chegassem rapidamente a acordo (consenso) de que a transação é válida. Os programadores resolveram este problema «ensinando» as máquinas a executar em paralelo 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 é especialmente clara entre o acordo sobre a ordem das transações e a sua execução subsequente, enquanto no Solana e no Aptos o paralelismo é implementado via arquitetura runtime e gestão de conflitos por estado.

No fim, é possível aprovar dezenas de milhares de transações por segundo (TPS). Mas aqui reside a armadilha.

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

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

O aumento de desempenho aumenta a carga sobre todas estas quatro funções simultaneamente. O sistema passa a gerar dados mais depressa do que a infraestrutura consegue lê-los, formando-se o chamado indexer gap.

Na documentação da Helius — um dos maiores providers de infraestrutura do ecossistema Solana — é apontado de forma direta que a estrutura sequencial da blockchain se adapta bem à integridade dos dados e a uma elevada capacidade de processamento, mas torna as consultas históricas lentas e ineficientes. Por isso, a maioria das empresas é obrigada a construir os seus próprios indexadores e bases de dados separadas sobre a blockchain.

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

O efeito é este: a rede pode confirmar operações quase instantaneamente, mas às aplicações é necessário muito mais tempo para processar as consequências dessas operações.

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

Ou, mais precisamente, na capacidade de processamento de CPUs, discos rígidos e cabos de rede. Descobriu-se que a escalabilidade da blockchain não é igual à escalabilidade da infraestrutura em redor. E é preciso lidar com isso o mais depressa possível

Vamos imaginar uma rede com 100 000 TPS. Não é preciso apenas registar a transação, mas também:

• manter o estado;
• atualizar índices;
• responder a pedidos das wallets;
• atender bots;
• atender analistas;
• atender motores de busca;
• atender agentes de IA.

Por isso, um alto throughput cria competição por recursos entre o consenso, a execução das transações e os serviços infraestruturais em cima da rede.

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

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

Além disso, os programadores do Geth descrevem separadamente o modelo antigo de armazenamento de arquivo, no qual o tamanho da base da Ethereum podia exceder 20 TB e a sincronização levava meses. Foi por isso que foi necessário criar uma nova arquitetura de armazenamento baseada em path.

Ou seja, sim: «hardware», processadores, largura de banda de rede, CPU — são limitadores físicos reais na corrida pelo crescimento da quantidade de informação. Mas não são os únicos. Servidores modernos já conseguem processar enormes volumes de dados. A questão é outra: quanto é que milhares de participantes independentes da rede devem pagar por isso?

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

Formalmente, é possível processar dados, mas não dá para fazê-lo ao mesmo tempo de forma barata e descentralizada. O custo de processar informação começa a crescer mais depressa do que o custo das próprias transações.

Como o mercado reagiu

Os participantes da corrida já entendem que as redes vencedoras serão aquelas que transformarem transações em informação acessível de forma mais rápida, mais barata e mais fiável. E, de forma inesperada, ao longo do ano atual, o mercado mudou o foco para a transição para blockchains modulares.

Se a primeira geração de redes tentava executar todas as tarefas em simultâneo, a nova geração divide responsabilidades entre camadas especializadas. Em vez de uma única rede, surgiram camadas separadas:

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

Os desenvolvedores comparam este processo à evolução dos data centers. Antes, um servidor fazia todas as funções de uma vez. Hoje, computação, armazenamento e serviços de rede escalam de forma independente.

Um dos segmentos que mais cresce no mercado são as redes DA. À primeira vista, a ideia parece estranha: para que criar uma blockchain separada para guardar temporariamente os dados de outra blockchain? Mas é exatamente isso que acontece. Na arquitetura modular, a execução de transações e o armazenamento de dados podem existir separadamente. O Rollup publica dados numa camada DA externa, e não na rede principal. Isso permite reduzir significativamente o custo da escalabilidade e aumentar o throughput.

Há alguns anos atrás, o RPC era considerado um detalhe técnico. Hoje, é um dos elementos mais importantes da criptoinfraestrutura. Em maio de 2026, a Triton One, em conjunto com a Solana Foundation, lançou um anúncio atualizado do 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 outro otimiza o trabalho com dados históricos. Em vez de varrer completamente a blockchain, o sistema cria índices adaptativos para consultas específicas das aplicações, reduzindo atrasos e o custo de processamento.

Assim, a Triton e a Solana tentam eliminar uma série de limitações sistémicas: a arquitetura monolítica de RPC cara e ineficiente, o conjunto estreito de padrões de pedidos JSON-RPC e a dependência dos programadores 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 torna-se mais rápido graças ao uso de storage colunar e dados pré-ordenados.

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

Como resultado, a Solana está, de facto, a tentar passar de um RPC «universal» para uma infraestrutura de dados modular e especializada, que supostamente deve reduzir barreiras para programadores e tornar o trabalho com dados de blockchain comparável em conveniência com bases de dados tradicionais.

A modularidade resolve o problema?

Se a Solana conseguir padronizar a camada de leitura, isso pode reforçar a sua posição como rede com infraestrutura de aplicações bem desenvolvida, e não apenas com elevada capacidade de processamento. Mas, ao mesmo tempo, aumenta a concorrência com providers RPC independentes e plataformas de infraestrutura, que terão de se adaptar ao novo padrão ou oferecer serviços adicionais sobre ele.

A arquitetura modular elimina parte das limitações infraestruturais, mas leva-as para outras camadas do sistema. É compreensível o desejo de reduzir custos e facilitar o acesso a dados sem os quais não funcionam DeFi, NFTs, wallets, analítica e ferramentas de compliance. No entanto, parece que o próprio coração da Web3 traz um efeito de complexificação em cascata: ao resolver um problema, inevitavelmente surgem novos desafios.

O novo esquema vai exigir inevitavelmente uma camada infraestrutural de sobreposição mais complexa: com indexadores, storage, cache, pipelines separados e novos pontos de falha. Em vez de uma única camada RPC simples, o ecossistema pode acabar com várias implementações paralelas, otimizações incompatíveis e uma dependência ainda maior de providers de infraestrutura. Nesse caso, uma arquitetura formalmente aberta não significa necessariamente um modelo de acesso verdadeiramente aberto e conveniente para todos.

Por enquanto, estamos numa fase em que o mercado passou da competição entre quem consegue extrair melhor os dados da rede para uma competição entre quem vai criar primeiro produtos baseados nesses dados. Quem e quanto vai pagar por isso — provavelmente vamos saber já em breve