Cofundador do Ethereum propõe DApps como solução para a falha da Cloudflare em 2025

Quedas de Cloudflare e AWS expuseram a dependência de camadas centralizadas no ecossistema cripto; a defesa por DApps fim a fim recoloca resiliência e desenho de arquitetura no centro do debate.

As interrupções pontuais registradas em 2025 por Cloudflare e Amazon Web Services não derrubaram blockchains, mas deixaram claro onde está o elo frágil de boa parte do mercado: a camada de acesso. Na prática, carteiras, exchanges, indexadores e front-ends de protocolos que dependem de CDN, DNS gerenciado e nuvem centralizada ficaram instáveis, mesmo com as redes subjacentes operando normalmente. Diante disso, o cofundador do Ethereum propôs recolocar os DApps, em seu sentido pleno, como resposta para reduzir pontos únicos de falha na experiência do usuário.

As falhas e a camada de acesso

Cloudflare atua como CDN e proxy reverso para APIs e sites, filtrando ataques e acelerando a entrega de conteúdo. A AWS, por sua vez, hospeda nós, indexadores e serviços de dados que abastecem as interfaces. Quando ambos os pilares oscilam, o efeito dominó ocorre na periferia do sistema: o botão “conectar carteira” não responde, páginas não carregam e chamadas para RPCs falham, ainda que os blocos sigam sendo produzidos. O problema, portanto, não é a contabilidade distribuída do blockchain, mas a dependência de infraestruturas centralizadas que fazem a ponte entre o usuário e a rede.

O que é, de fato, um DApp

Chamar qualquer app que interaja com um contrato de DApp virou um atalho conceitual. Um DApp, no sentido estrito, deve minimizar a necessidade de confiança em infraestrutura específica: front-ends distribuídos (IPFS/Arweave), resolução via nomes on-chain (ENS), múltiplas rotas de RPC e, quando possível, clientes leves no navegador para validar cabeçalhos e mitigar a dependência de gateways. Nesse desenho, uma queda de CDN degrada a experiência, mas não a interrompe; o usuário ainda encontra a interface, endereçada por um nome on-chain e servida por diferentes gateways, e consegue assinar transações com redundância de provedores.

Além da camada de apresentação, a lógica é reduzir monoculturas operacionais. Remover hard-dependencies de um único provedor de nuvem, distribuir indexadores e logs de eventos entre diferentes regiões e permitir failover automático entre RPCs de origens distintas encurta o impacto de incidentes. Não se trata de demonizar nuvem ou CDNs, mas de assumir que resiliência exige diversidade arquitetural e caminhos alternativos quando o atalho mais conveniente falha.

Trade-offs: UX, custo e governança

Descentralizar a entrega e validação implica custos e fricção. Interfaces hospedadas em IPFS podem ter latência maior, rotas redundantes exigem orquestração e monitoramento, e clientes leves no browser ainda são limitados em desempenho. Por outro lado, a padronização de bundles estáticos, uso de gateways múltiplos e caches progressivos tem reduzido essa diferença, enquanto o ganho em disponibilidade durante incidentes se torna tangível. Para serviços que lidam com compliance e KYC, a equação é ainda mais delicada: parte do stack seguirá centralizada, exigindo planos de contingência e degradação graciosa.

A governança também entra no debate. Se a comunidade de um protocolo depende de um domínio, um CDN e uma nuvem, decisões técnicas acabam subordinadas a termos de serviço e a riscos regulatórios. Migrar gradualmente para nomes on-chain, distribuir a hospedagem de ativos estáticos e documentar rotas alternativas para interação direta com contratos reduz não apenas riscos operacionais, mas a superfície de censura. Em 2025, o teste de estresse veio de falhas técnicas; nada impede que o próximo venha de decisões políticas.

Ethereum, concorrência e o desenho de camadas

O argumento do cofundador do Ethereum toca um ponto central da disputa entre camadas 1: escalabilidade sem resiliência de acesso não resolve a experiência do usuário. Blockchains que se vendem como alternativas mais baratas e rápidas ao Ethereum, os chamados “Ethereum Killers”, frequentemente alcançam throughput via validação mais concentrada e dependência de serviços gerenciados em nuvem, o que pode deslocar – e não eliminar – os pontos de falha. Ao usuário final, pouco importa se o gargalo está no consenso ou no CDN: se a interface não carrega, o protocolo “caiu”.

Nesse sentido, o mapa de riscos precisa considerar o stack completo: consenso, dados de histórico, indexação, RPC, front-end e resolução de nomes. Soluções pragmáticas passam por multi-cloud, gateways redundantes, ENS como camada de descoberta, IPFS/Arweave para artefatos estáticos, e clientes leves ou provas de execução para reduzir confiança em terceiros. No curto prazo, a indústria deve convergir para arquiteturas híbridas com monitoramento ativo e rotas de fallback; no longo prazo, a tendência é que a própria web3 incorpore as funções que hoje terceiriza.

Para quem deseja compreender melhor as escolhas técnicas e econômicas por trás de blockchains que disputam espaço com o Ethereum — incluindo como se equilibram escalabilidade, descentralização e dependência de infraestrutura — o BlockTrends oferece o curso Investindo em ‘Ethereum Killers’, que explora o conceito dessas redes, seus trade-offs e cenários de adoção.