Resumo

Bem-vindo à série “A Tragédia dos Comuns Criptomoedas” da GCC Research.

Neste conjunto de análises, destacamos os principais bens públicos do blockchain — elementos essenciais que servem de base para o ecossistema cripto, mas que começam a se afastar de seus princípios descentralizados. Esses bens sustentam o Web3, mas frequentemente enfrentam escassez de incentivos, desafios de governança e riscos de centralização. É nesse espaço que o descompasso entre os ideais de descentralização do universo cripto e a redundância robusta necessária para estabilidade prática se torna mais crítico.

Esta edição destaca um dos aplicativos mais notórios do Ethereum: o Polymarket e suas ferramentas de indexação de dados. Desde o início deste ano, temas polêmicos — desde manipulação de oráculos relacionada às probabilidades eleitorais de Trump, apostas ucranianas em terras raras até previsões políticas sobre a cor do terno de Zelensky — colocaram o Polymarket sob os holofotes. A magnitude e o impacto financeiro dessas disputas tornaram impossível ignorá-las.

No entanto, será que esse “mercado de previsões descentralizado” realmente atingiu a descentralização onde ela mais importa — na camada de indexação de dados? Por que infraestruturas descentralizadas como o The Graph ainda não atenderam plenamente às expectativas? E como seria, de fato, uma solução pública de indexação de dados realmente eficiente e sustentável?

I. O efeito dominó de uma falha em plataformas centralizadas de dados

Em julho de 2024, a Goldsky — uma plataforma de infraestrutura de dados blockchain em tempo real para desenvolvedores Web3, especializada em indexação, subgraphs e streaming de dados — sofreu uma interrupção de seis horas. Isso paralisou uma grande parcela do ecossistema Ethereum: interfaces de usuário de DeFi deixaram de exibir posições e saldos dos usuários, mercados de previsão como o Polymarket não mostravam dados corretos e, do ponto de vista do usuário, diversas interfaces de projetos tornaram-se inutilizáveis.

Esse tipo de falha é justamente o que aplicações descentralizadas buscam prevenir. A principal motivação do design do blockchain é eliminar pontos únicos de falha. O ocorrido com a Goldsky expôs uma realidade inquietante: embora blockchains sejam projetados para descentralização, a maior parte da infraestrutura de suporte a aplicações on-chain permanece altamente centralizada.

A origem do problema está no fato de que a indexação e a consulta de dados em blockchain são bens públicos digitais — não-excludentes e não-rivais — e os usuários costumar esperar acesso gratuito ou quase gratuito. No entanto, sustentar essa infraestrutura requer investimento constante em hardware, armazenamento, banda larga e engenharia. Sem um modelo de receita viável, o setor tende a concentrar-se em um “vencedor leva tudo”: quando um provedor ganha vantagem em velocidade e capital, os desenvolvedores canalizam todas as consultas para ele, criando um novo ponto de dependência. Gitcoin e outras entidades sem fins lucrativos já alertaram: “infraestrutura de código aberto gera bilhões em valor, mas seus criadores frequentemente não conseguem sequer pagar o aluguel.”

A lição é clara: o universo descentralizado precisa de esforço urgente — seja em financiamento de bens públicos, redistribuição de incentivos ou modelos comunitários — para diversificar a infraestrutura Web3 e evitar novas formas de centralização. É fundamental que desenvolvedores de DApps adotem estratégias “local-first” e que comunidades técnicas projetem DApps resilientes a falhas na recuperação de dados — garantindo que usuários possam seguir utilizando-os mesmo quando indexadores estejam offline.

II. De onde vêm, de fato, os dados do seu DApp?

Para compreender incidentes como a queda da Goldsky, é preciso mergulhar mais fundo na arquitetura dos DApps. A maioria dos usuários reconhece apenas dois componentes: o contrato on-chain e a interface frontend. Consultam o Etherscan para conferir o status das transações, visualizam informações na interface e interagem com contratos pela UI. Mas afinal, de onde o frontend obtém seus dados?

O papel crucial dos serviços de recuperação de dados

Imagine que você está desenvolvendo um protocolo de empréstimos que mostra posições, margem e dívidas dos usuários. Uma implementação simples faria o frontend buscar esses dados diretamente do blockchain. Contudo, a maioria dos contratos não permite consultar todas as posições de um endereço — apenas por ID da posição. Para exibir as posições de um usuário, seria preciso primeiro obter todas as posições abertas e então filtrar as dele — como procurar manualmente entre milhões de registros. Isso é tecnicamente viável, mas extremamente lento e ineficiente, levando até horas para grandes projetos DeFi mesmo em servidores backend.

É aqui que a infraestrutura dedicada se torna indispensável. Provedores como a Goldsky oferecem serviços de indexação de dados que agilizam radicalmente o acesso. O diagrama a seguir mostra os tipos de dados que tais serviços viabilizam para aplicações.

Alguns podem perguntar: O The Graph já não oferece extração descentralizada de dados para Ethereum? Como ele se compara à Goldsky, e por que tantos projetos DeFi optam pela Goldsky em vez do The Graph?

Como The Graph, Goldsky e SubGraph se complementam

Compilando os principais conceitos técnicos:

• SubGraph é um framework para desenvolvedores, permitindo criar códigos que leem e agregam dados on-chain para exibição no frontend.
• The Graph é uma plataforma descentralizada líder em extração de dados, que criou o SubGraph em AssemblyScript. Desenvolvedores usam SubGraph para capturar eventos de contrato e gravar em bancos de dados, possibilitando consultas via GraphQL ou SQL.
• Os provedores que executam SubGraphs são denominados operadores de SubGraph. Tanto The Graph quanto Goldsky atuam como provedores hospedados para projetos SubGraph, já que o código, no fim, precisa rodar em servidores. Veja um exemplo da documentação da Goldsky:

Por que diferentes operadores de SubGraph existem?

Porque o framework define só como extrair dados dos blocos e gravá-los em bancos de dados — não como ocorre o fluxo ou a saída dos dados. Cada operador implementa esses detalhes de forma independente.

Operadores podem incorporar otimizações e modificações proprietárias. Atualmente, o The Graph usa Firehouse para indexação acelerada; já o tempo de execução principal de SubGraph da Goldsky é fechado.

Na prática, o The Graph funciona como um hub descentralizado de operadores SubGraph. Por exemplo, o subgraph Uniswap v3 é mantido por vários operadores, tornando o The Graph um marketplace coletivo onde usuários submetem códigos SubGraph e múltiplos operadores processam as consultas.

Modelo de preços da Goldsky

Como um serviço SaaS centralizado, a Goldsky utiliza o modelo clássico de cobrança por recursos utilizados. Esse padrão já é conhecido da maioria dos engenheiros. Veja abaixo a calculadora de preços da Goldsky:

Modelo de preços do The Graph

O modelo de precificação do The Graph é exclusivo: taxas de consulta e incentivos estão integrados à tokenômica do GRT. Resumidamente:

• Cada consulta a um SubGraph reparte as taxas: 1% do GRT é queimado; 10% vai para o pool de curadores (geralmente desenvolvedores); cerca de 89% é distribuído entre Indexadores e Delegadores por algoritmo.
• Indexadores devem apostar no mínimo 100.000 GRT para participar, sofrendo penalidades em caso de resultados errados. Delegadores apostam GRT junto aos Indexadores e partilham o pool de 89% das recompensas.
• Curadores (frequentemente desenvolvedores) sinalizam interesse apostando GRT em uma curva de ligação (bonding curve) para seus SubGraphs. Quanto mais GRT apostado, mais recursos de Indexadores são atraídos. Recomenda-se na comunidade de 5.000 a 10.000 GRT para garantir indexação constante.

Taxas de Consulta:

O acesso ao The Graph exige cadastro de uma chave de API e pré-pagamento em GRT, com cobrança por requisição feita.

Taxas de Staking de Sinalização:

Para ter SubGraphs indexados, o desenvolvedor deve apostar GRT (“sinalizar”) para atrair operadores. Quando o volume de GRT atinge determinado patamar (exemplo: 10.000), os Indexadores passam a processar aquele SubGraph em produção.

Para testes, é possível implantar SubGraphs gratuitamente no operador de homologação do The Graph. No ambiente produtivo, porém, é necessário publicar o SubGraph na rede, e os Indexadores escolhem quais indexar com base nos sinais apostados.

Por que desenvolvedores (e contadores) rejeitam preços baseados em tokens

Em boa parte dos projetos, o fluxo do The Graph é considerado complexo. Embora a compra de GRT seja trivial para equipes Web3, o processo de curadoria é demorado e incerto. Os principais entraves:

• Incerteza: desenvolvedores têm dificuldade em saber quanto de GRT apostar ou quanto tempo Indexadores levarão para assumir seu SubGraph.
• Gestão contábil: precificação baseada em tokenômica dificulta o controle de custos, tornando a categorização de despesas mais complexa para empresas e seus contadores.

“Centralizar é simplesmente mais fácil?”

Para a maioria dos desenvolvedores, a Goldsky é mais simples: o modelo de cobrança é direto, o serviço é imediato após o pagamento, e quase não há incertezas. Isso resultou em forte dependência de um único provedor de indexação no universo Web3.

A tokenômica do The Graph pode ser bem-intencionada, mas sua complexidade afasta usuários e jamais deveria ser repassada ao usuário final — em especial o apostar para curadoria, que deveria ser abstraído por uma interface simples de pagamento.

Não é só uma opinião particular: Paul Razvan Berg, renomado engenheiro de smart contracts e fundador da Sablier, criticou publicamente a experiência de publicação e pagamento via GRT no SubGraph como “extremamente ruim”.

III. Soluções já existentes para quedas de indexadores de dados

Como o ecossistema deveria lidar com pontos únicos de falha em indexação de dados? Como visto, usar o The Graph é possível, mas requer apostar (staking) e curadoria em GRT para liberar o acesso à API.

O ecossistema EVM conta com múltiplas alternativas de indexação de dados. Referências úteis: The State of EVM Indexing da Dune, o panorama de ferramentas de indexação do rindexer e este thread (fio) recente.

Este artigo não investiga a causa técnica específica do incidente da Goldsky; de acordo com seu relatório oficial, as informações detalhadas só foram compartilhadas com clientes corporativos. O relato aponta um problema na escrita dos dados indexados no banco, e o acesso foi restaurado apenas graças ao suporte da AWS.

Veja outras alternativas viáveis:

• ponder é uma ferramenta de indexação de dados simples, fácil de instalar e amigável para desenvolvedores. Pode ser autogerenciada em infraestrutura própria.
• local-first é uma filosofia de desenvolvimento que propõe que DApps permaneçam utilizáveis mesmo sem conexão de rede. No universo blockchain, significa garantir experiência de uso enquanto houver conexão com a cadeia, mesmo se indexadores estiverem inoperantes.

Ponder: indexação de dados faça-você-mesmo

Por que recomendar ponder?

• Independência de fornecedores: criado por desenvolvedor autônomo, requer apenas endpoint RPC Ethereum e banco Postgres — sem dependência de serviços gerenciados.
• Ótima experiência para quem desenvolve: escrito em TypeScript e baseado na biblioteca Viem, é de fácil utilização (segundo ampla experiência do autor).
• Desempenho superior.

Há pontos de atenção: o ponder evolui rapidamente, então mudanças podem eventualmente afetar implantações antigas. Para detalhes técnicos e recomendações, acesse a documentação oficial.

Vale citar que ponder iniciou recentemente uma estratégia comercial alinhada à “teoria da separação”, conforme analisado anteriormente.

Em resumo: bens públicos beneficiam todos, mas cobrar por eles reduz o bem-estar coletivo ao excluir usuários marginais (não pareto-ótimo). Precificação diferenciada poderia maximizar o excedente, mas é difícil de implementar. A teoria da separação propõe isolar um subgrupo homogêneo, cobrando apenas dele e mantendo os demais isentos.

Como ponder aplica esse conceito:

• A implantação exige conhecimentos técnicos — os desenvolvedores precisam configurar dependências externas (endpoint RPC, banco de dados).
• Há manutenção contínua (por exemplo, uso de proxies para balanceamento de carga e garantia de consulta de dados na linha de execução correta). Para alguns desenvolvedores, pode ser desafiador.
• Agora ponder disponibiliza implantação automatizada em beta via Marble: basta submeter o código e realizar a implantação com um clique.

Esse modelo “separa” quem busca conveniência — que paga pelo serviço hospedado da Marble — enquanto autogerenciadores seguem usando ponder gratuitamente.

Ponder versus Goldsky:

• Ferramentas autogerenciadas e permissionless como ponder atraem projetos menores que valorizam autonomia e flexibilidade.
• Projetos de grande porte com alta demanda de performance costumam optar por serviços gerenciados como Goldsky, que garantem mais disponibilidade e redundância.

Ambos os modelos apresentam riscos. O incidente da Goldsky evidencia a importância de todo desenvolvedor manter um indexador ponder próprio como backup. E ao usar ponder, atenção também à validade das respostas RPC — recentemente, Safe notificou um incidente envolvendo dados RPC inválidos e falha de indexador. Não há prova de que o caso da Goldsky foi causado por isso, mas o risco existe.

O paradigma local-first no desenvolvimento

A abordagem local-first gerou intenso debate nos últimos anos. Essencialmente, ela busca:

• Disponibilidade offline
• Colaboração multiusuário entre dispositivos

Grande parte das discussões técnicas local-first menciona CRDTs (Conflict-free Replicated Data Types) — estruturas que resolvem automaticamente conflitos em edições distribuídas. Elas funcionam como protocolos de consenso leves, mantendo a consistência dos dados entre dispositivos.

No desenvolvimento blockchain, esses requisitos são menos rigorosos: o principal objetivo é garantir alguma funcionalidade ao usuário mesmo se backends indexadores estiverem offline, aproveitando a consistência intrínseca do blockchain.

Na prática, DApps local-first podem:

• Armazenar localmente informações essenciais — saldos, posições — garantindo ao usuário visualizar o último estado conhecido mesmo sem indexador;
• Degradar de modo inteligente — buscar dados críticos diretamente do RPC caso indexadores estejam fora do ar, permitindo visualização parcial de dados on-chain em tempo real.

Essa estratégia aumenta consideravelmente a resiliência das aplicações. Em um cenário ideal, o DApp local-first permitiria ao usuário rodar um nó local e consultar dados com ferramentas como TrueBlocks. Para saber mais sobre indexação descentralizada e local, consulte o thread (fio) Literally no one cares about decentralized frontends and indexers.

IV. Conclusão

A interrupção de seis horas na Goldsky foi um alerta para todo o ecossistema Web3. Apesar dos blockchains serem desenhados para descentralização e resiliência, a maioria das aplicações ainda depende fortemente de infraestrutura centralizada de dados — expondo todo o ecossistema a novos riscos sistêmicos.

Este artigo detalhou por que o The Graph, embora amplamente reconhecido, encontra barreiras de adoção devido à complexidade do GRT e à experiência desenvolvedor pouco amigável. Também apresentamos estratégias para criar indexação de dados mais robusta — sugerindo a adoção de frameworks autogerenciados como ponder como soluções de backup, destacando o modelo inovador de comercialização do ponder — e exploramos o paradigma local-first, incentivando desenvolvedores de DApps a manterem a usabilidade mesmo na ausência de indexadores.

Com mais frequência, desenvolvedores Web3 reconhecem pontos únicos de falha em indexação de dados como uma vulnerabilidade crítica. A GCC convida a comunidade a priorizar esse desafio fundamental e a experimentar indexadores de dados descentralizados ou arquiteturas que mantenham os frontends dos DApps operacionais mesmo durante quedas de indexadores.

Avisos:

1. Republicado de TechFlow. Os direitos autorais permanecem com o autor original, shew. Em caso de dúvidas sobre esta republicação, entre em contato com a equipe Gate Learn para solução.
2. Aviso: As opiniões expressas neste artigo são exclusivamente do autor e não configuram recomendação de investimento.
3. Traduções feitas pela equipe Gate Learn não podem ser copiadas, distribuídas ou plagiadas sem a devida atribuição ao Gate.com.