Se o Web3 é descentralizado, por que os DeFi dApps ainda quebram quando a nuvem cai?

Em 20 de outubro, um soluço na região US-EAST-1 da Amazon desencadeou uma reação em cadeia em toda a indústria de criptografia. Base de moedas relatou serviço degradado, Infurá e a Alchemy publicaram notas de incidentes relacionados à AWS, e várias carteiras e rollups começaram a expirar.

Nenhuma dessas falhas veio dos próprios blockchains. O consenso estava bem. O problema estava tudo envolvido: bancos de dados em nuvem, gateways RPC, DNS, indexadores e sistemas de gerenciamento de chaves que transformam um blockchain em um aplicativo utilizável.

Foi um forte lembrete de que grande parte da Web3 ainda depende fortemente da Web2. Quando uma região da AWS espirrou, um quarto da interface do usuário da criptografia pegou um resfriado.

A monocultura invisível

Por trás da retórica da descentralização existe um mapa de dependência silencioso que parece surpreendentemente centralizado. Um dApp típico começa com um front-end hospedado em S3 ou Cloudflare Pages, servido por meio de um CDN como Fastly e resolvido por Route 53 ou Cloudflare DNS.

Abaixo deles estão RPCs de leitura e gravação, geralmente Infura, Alchemy ou QuickNode, muitos dos quais são executados na AWS ou em outra das “3 grandes” nuvens. Em seguida, vêm indexadores como The Graph ou Covalent, serviços de sequenciamento em rollups e sistemas de custódia ou gerenciamento de chaves, como Fireblocks. Cada camada introduz um único ponto de falha.

Quando os serviços DynamoDB e DNS da AWS falharam, várias camadas foram atingidas simultaneamente. A API da Coinbase ficou lenta, Infura e Alchemy relataram problemas upstream da AWS e vários rollups viram seus sequenciadores pararem até intervenção manual. Até mesmo o indexador do The Graph para zkSync já havia mostrado fragilidade semelhante semanas antes.

A ilusão de redundância também se desfez. Dois provedores de RPC independentes prometem, cada um, tempo de atividade de “quatro noves”, mas se ambos estiverem na mesma região de nuvem, suas falhas estarão correlacionadas. Estatisticamente, a independência entra em colapso: o coeficiente de correlação efetivo entre as pilhas centradas na AWS pode chegar a 0,9.

Essa concentração não se limita à criptografia. A AWS ainda detém cerca de 30-32% do compartilhamento global de nuvem, o Azure cerca de 20% e o Google Cloud 13%. Uma interrupção de seis horas em uma região importante afeta o DNS, o armazenamento de objetos e os serviços de banco de dados usados ​​por milhares de empresas.

Para aplicativos criptográficos, isso significa que entre 10% e 30% dos front-ends ou funções de leitura baseados em EVM podem degradar durante tal evento. Gravações e transações que dependem de sequenciadores ou caminhos de assinatura de custódia podem congelar completamente.

O mito da independência

É fácil combinar resiliência em cadeia com resiliência de aplicativo. Blockchains como Ethereum ou Solana pode manter o consenso através de nós globais; no entanto, as ferramentas que as pessoas realmente utilizam dependem muitas vezes de intermediários centralizados. A interrupção de cinco horas de Solana em fevereiro de 2024 foi uma falha na rede, mas a interrupção da AWS não foi. Era fora da rede e muito mais comum.

Cada camada adiciona seu próprio calcanhar de Aquiles.

• Os sequenciadores em L2s ainda são, em sua maioria, configurações de operador único. Se sua conexão com o RPC do Ethereum for interrompida, sua capacidade de postar novos lotes também será interrompida.
• A entrega de conteúdo e o DNS apresentam fragilidade adicional: o problema do resolvedor da Cloudflare em 14 de julho deixou partes da Internet inacessíveis por quase uma hora.
• Mesmo o armazenamento “descentralizado” ainda pode depender de uma única empresa. A interrupção do gateway IPFS da Infura em 20 de setembro interrompeu o acesso a ativos que teoricamente estavam espelhados na rede.
• As plataformas de custódia e gerenciamento de chaves, como Fireblocks, usadas por bolsas e fundos, sofreram atrasos no processamento em 26 de outubro e 17 de setembro, paralisando retiradas e liquidações.

Essas falhas são importantes porque afetam a confiança do usuário mais do que o tempo de atividade do protocolo jamais poderia. Uma carteira exibindo um saldo obsoletoou uma transação-ponte presa no limbo, corrói a confiança na própria descentralização que afirma oferecer.

Os reguladores começaram a notar. A Lei de Resiliência Operacional Digital (DORA) da UE, em vigor em janeiro de 2025, obriga as entidades financeiras a testar e reportar dependências de TIC de terceiros. Espera-se que o regime de “Terceiros Críticos” do Reino Unido coloque os hiperscaladores sob supervisão direta no próximo ano.

Como a custódia de criptomoedas, os emissores de stablecoins e as plataformas de ativos tokenizados agora se sobrepõem às finanças regulamentadas, as mesmas expectativas para a diversificação da nuvem também se aplicarão aqui em breve. A dependência da nuvem de um único fornecedor está se transformando em um risco no nível do conselho.

A solução não é glamorosa, mas está chegando

As soluções estão sendo enviadas. No curto prazo, os desenvolvedores estão introduzindo RPCs de quorum de provedor que consultam vários endpoints, auto-hospedados, SaaS e descentralizados (como Pocket Network) e exibem um resultado apenas se dois em cada três concordarem. Ferramentas como o Helios trazem a verificação de clientes leves diretamente para carteiras e aplicativos móveis, permitindo que os usuários validem dados sem depender de um gateway centralizado.

As equipes de infraestrutura estão adotando configurações multi-CDN e multi-DNS com failover ativo. Para armazenamento, executar o próprio gateway IPFS ou espelhar ativos no Arweave ou Irys está se tornando padrão. No mundo rollup, projetos como Espresso, Radius e Astria estão construindo sequenciadores compartilhados ou descentralizados, enquanto o OP Stack começou a implementar provas de falhas sem permissão.

Mais adiante no roteiro, a proposta PeerDAS da Ethereum visa tornar as verificações de disponibilidade de dados acessíveis o suficiente para serem executadas no nível da carteira. Combinado com clientes leves, isso poderia levar a verificação para as bordas da rede, e não para o centro da nuvem.

A pressão institucional reforçará estas mudanças. De acordo com as regras DORA e CTP do Reino Unido, as arquiteturas multinuvem estão se tornando uma política, não uma preferência. Espere que grandes custodiantes e exchanges exijam a diversificação de fornecedores entre RPCs, indexadores e provedores de gerenciamento de chaves.

Nada disto tornará a criptografia totalmente independente da infraestrutura tradicional, mas reduzirá a distância entre os ideais de descentralização e a confusa realidade operacional. A lição de 20 de outubro não é que os blockchains falharam, mas sim que os andaimes de suporte ainda não foram alcançados.

Um aplicativo verdadeiramente descentralizado não significa que cada usuário execute um servidor; isso significará que nenhum servidor pode derrubar o sistema. Até que esse seja o padrão, toda interrupção do “Web3” ainda começará da mesma maneira: quando a nuvem espirra, o blockchain estremece.