O quase desastre da Solana: como a rede chegou a 4,5% de uma paralisação
Em 12 de agosto de 2026, a Solana teve seu contato mais próximo com uma paralisação em nível de rede desde a última grande interrupção em fevereiro de 2024 — mas desta vez, a causa não tinha nada a ver com código com bugs ou spam de bots. Foi uma falha de roteamento, profunda nas entranhas da infraestrutura da internet.
O que Aconteceu
Uma falha de roteamento no BGP (Border Gateway Protocol) atingiu a TeraSwitch, uma provedora de hospedagem usada por uma parcela significativa dos validadores da Solana. O BGP é o protocolo que determina como os dados encontram seu caminho pela internet entre redes — quando ele se comporta mal, blocos inteiros de servidores podem efetivamente desaparecer do mapa da internet, mesmo que os próprios servidores estejam funcionando normalmente.
A falha derrubou aproximadamente 90 validadores simultaneamente, representando 28,83% de todo o SOL apostado.
Por que Esse Número Importou
O mecanismo de consenso da Solana tem um limite crítico: se 33,34% do SOL apostado ficar offline de uma vez, a rede não consegue mais finalizar transações, e a produção de blocos é interrompida totalmente — exigindo o tipo de reinício coordenado do validador que marcou as falhas passadas da Solana.
Em 12 de agosto, a rede ficou a 4,51 pontos percentuais desse limite. Foi perto, mas a Solana nunca chegou a parar de fato.
Por que a Rede Continuou Operando
Ao contrário dos incidentes maiores anteriores da Solana — como a falha do fork-choice de ~8,5 horas em setembro de 2022, ou a parada de cinco horas em fevereiro de 2024 causada por um loop de recompilação no carregador do Berkeley Packet Filter (BPF) — este evento não envolveu nenhum bug de consenso ou falha no nível do cliente.
Durante a janela de aproximadamente 30–33 minutos:
A produção de blocos continuou sem interrupções
As transações continuaram sendo processadas e finalizadas normalmente
Nenhum recurso de usuários ficou em risco
597 de 699 validadores apostados continuaram votando
Como era puramente uma questão de rede/infraestrutura, e não uma falha do protocolo central da Solana, ela se resolveu assim que o roteador afetado reconvergiu — sem patch de emergência, sem reinício coordenado, sem necessidade de atualização do cliente.
A Lição Real: Concentração de Infraestrutura
Este incidente redefiniu a conversa sobre a confiabilidade da Solana. Por anos, as quedas da rede foram atribuídas a spam de transações e a bugs de software no cliente de validador. Desta vez, a vulnerabilidade era a concentração de infraestrutura — muitos validadores dependendo do mesmo provedor de hospedagem e do mesmo caminho de roteamento na internet, criando um ponto único de falha que não tinha nada a ver com o código da blockchain.
Como resposta, a Solana Foundation apertou as regras de diversidade de infraestrutura. A partir de 1º de maio de 2026, validadores apoiados pela Foundation devem garantir:
Nenhum ASN único (sistema autônomo / rede de hospedagem) mantém mais de 25% da participação da rede
Nenhum operador de data center mantém mais de 15% da participação da rede
Esses limites não impedirão todos os sustos futuros, mas foram projetados para impedir que uma falha de roteamento de um único provedor ameace o consenso novamente.
Contexto: Um Longo Período de Estabilidade
O timing é notável. Antes deste evento, a Solana havia mantido 100% de uptime a nível de cluster por cerca de 30 meses consecutivos após sua última grande indisponibilidade em fevereiro de 2024 — seu trecho mais longo de confiabilidade desde o lançamento. O susto de 12 de agosto não quebrou essa sequência de paradas reais, mas foi um lembrete de que "uptime" depende de mais do que apenas código limpo — depende também da infraestrutura física e de rede por baixo.
Fontes: relatórios de status da Solana Foundation; análise do incidente por Spotted Crypto e Bitcoin Foundation, agosto de 2026.
