Beep, beep, beep. Beep, beep, beep.

O sono de Steven é interrompido pelo som áspero de seu telefone, arrancando-o abruptamente de seus sonhos. No escuro, a tela brilha intensamente, vibrando furiosamente em sua mesa de cabeceira. Bip, bip, bip. Ele geme, esfregando os olhos sonolentos, e alcança o aparelho. Semicerrou os olhos para ler a mensagem, seu coração afunda - o nó está inativo. Sem hesitar, ele pula da cama, meio vestido, tentando desbloquear o telefone enquanto mais mensagens chegam. Então ele percebe - o cluster inteiro está inativo.

Neste exato momento, em todo o mundo, em cidades e fusos horários dispersos, centenas de operadores de nó estão encarando seus celulares com a mesma realização: o momento que eles temem chegou - uma interrupção.

Introdução

Como todos os sistemas distribuídos, o Solana opera sob a realidade de que uma única falha de implementação ou um caso de borda obscuro pode levar a uma falha em toda a rede. As interrupções, embora disruptivas, são uma parte inevitável da manutenção de uma infraestrutura distribuída complexa, seja em blockchains descentralizadas, exchanges centralizadas ou até mesmo grandes provedores de serviços em nuvem, como Amazon ou Microsoft.

A questão não é se as falhas ocorrerão, mas quando - e como a rede evolui para se adaptar e se fortalecer contra incidentes futuros. Apesar dos testes simulados rigorosos, de um testnet incentivado e de um programa ativo de recompensa por bugs, nenhum sistema - não importa o quão bem projetado - pode antecipar todos os possíveis modos de falha. As lições mais valiosas vêm das operações do mundo real.

Nos últimos cinco anos, a Solana passou por sete incidentes separados de interrupção, cinco dos quais foram causados por bugs do cliente e dois pela incapacidade da rede de lidar com uma enxurrada de spam de transações. As versões iniciais da Solana não tinham mecanismos-chave de gestão de congestionamento, como taxas de prioridade e mercados de taxas locais, que posteriormente se mostraram essenciais para mitigar o estresse da rede. A falta de tais mecanismos resultou em períodos prolongados de desempenho degradado e congestionamento ao longo de 2022, já que a rede essencialmente incentivou o spam.

Instâncias históricas de interrupções e desempenho degradado da Solana

Este artigo analisará detalhadamente cada interrupção do Solana, examinando as causas raiz, eventos desencadeadores e as medidas tomadas para resolvê-las. Além disso, discutiremos os aspectos-chave dos reinícios de rede, relatórios de bugs e os conceitos fundamentais de falhas de vivacidade e segurança. Embora essas seções sejam melhor lidas em ordem, cada uma é projetada para poder ser lida independentemente, permitindo que os leitores pulem para os tópicos ou incidentes de interrupção que mais lhes interessam.

Vida e Segurança

De acordo com o teorema CAP, também conhecido como Teorema de Brewer, um sistema distribuído só pode alcançar duas de três propriedades:

• Consistência - Toda leitura vê todas as gravações anteriores.
• Disponibilidade - Cada pedido recebe uma resposta.
• Tolerância de partição - O sistema continua operando apesar das partições de rede.

Para blockchains, a tolerância à partição é essencial — as interrupções de rede são inevitáveis. Isso força uma escolha entre AP (Disponibilidade + Tolerância à Partição) e CP (Consistência + Tolerância à Partição). Como a maioria das cadeias de PoS de finalidade rápida, a Solana prioriza a consistência sobre a disponibilidade, tornando-a um sistema CP. Ela interrompe durante falhas críticas em vez de servir dados obsoletos ou permitir gravações inseguras. Embora isso signifique que o software do nó possa entrar em um estado irreversível que requer intervenção manual, isso garante que os fundos do usuário permaneçam seguros.

A posição de Solana dentro dos trade-offs do teorema da PAC

Falha de Vida: ocorre quando o blockchain para de progredir, impedindo que as transações sejam confirmadas e os blocos sejam produzidos devido à inatividade do validador, partições de rede ou paralisações de consenso. No contexto do teorema CAP, isso corresponde a uma perda de disponibilidade.

Falha de segurança: ocorre quando o estado finalizado do blockchain é alterado ou bifurcado incorretamente. Isso pode levar a históricos conflitantes ou gastos duplos, muitas vezes causados por bugs de consenso ou ataques maliciosos. No contexto do teorema da PAC, isso corresponde a uma perda de consistência.

Solana prioriza a segurança em detrimento da vida. Assim, a rede será interrompida em casos de estresse extremo da rede ou falha de consenso, em vez de risco de corrupção estatal. Embora as interrupções sejam disruptivas e possam afetar aplicativos, usuários e validadores, elas são preferíveis às consequências catastróficas de um livro-razão inconsistente ou corrompido.

Reinicializações de rede

Reiniciar a rede Solana envolve identificar o último slot de bloco confirmado de forma otimista e reiniciar os nós a partir de um snapshot de estado local confiável desse slot. Como o slot de reinício não é determinado on-chain, os operadores do validador devem chegar a um consenso off-chain para concordar com um ponto seguro de rollback. Essa coordenação ocorre publicamente no canal #mb-validators no Solana Tech Discord, onde operadores profissionais de validadores se comunicam em tempo real. A maioria dos operadores possui sistemas de alerta automatizados que os notificam no momento em que a produção de blocos é interrompida, garantindo uma resposta rápida.

Uma vez que um consenso é alcançado sobre o slot de reinicialização correto, os operadores usam a ferramenta de contabilidade para gerar um novo instantâneo local, reiniciar seus validadores e esperar que pelo menos 80% da aposta total retorne online. Só então a rede retoma a produção e validação de blocos. Verificar se há no máximo 20% de participação offline quando o cluster é reiniciado garante margem de segurança suficiente para permanecer on-line no caso de nós bifurcarem ou voltarem offline imediatamente após a reinicialização.

Relatório de Bugs

Os programas de recompensa por bugs recompensam os pesquisadores de segurança por identificar e relatar vulnerabilidades de software. Essa é uma linha crítica de defesa, pois incentiva proativamente pegar bugs antes que possam ser explorados. Os pesquisadores e desenvolvedores de segurança que identificam possíveis vulnerabilidades no cliente Agave são incentivados a denunciá-las por meio de canais de segurança adequados. Diretrizes detalhadas de divulgação podem ser encontradas no repositório do GitHub Agave.

Recompensas são oferecidas para relatos válidos de vulnerabilidades críticas, com pagamentos baseados na gravidade:

• Perda de fundos: até 25.000 SOL
• Violações de consenso ou segurança: Até 12.500 SOL
• Vivacidade ou perda de disponibilidade: até 5.000 SOL

Além disso, o cliente FireDancer tem um programa separado de recompensa por bugshospedado através do Immunefi, oferecendo uma recompensa máxima de $500,000 USDC para descobertas críticas.

Instâncias de Desligamento

As seções a seguir fornecem uma análise cronológica detalhada das interrupções e períodos de desempenho degradado da Solana, a partir do lançamento do Mainnet Beta em 16 de março de 2020. Este exame destacará os principais incidentes, suas causas básicas e as melhorias subsequentes da rede, oferecendo informações sobre como a Solana evoluiu para melhorar a estabilidade e a resiliência ao longo do tempo.

Bug da turbina: dezembro de 2020

Tempo de inatividade: Aproximadamente seis horas

Problema raiz: Bug de propagação de bloco

Correções:

• Acompanhe os blocos pelo hash em vez do número do slot
• Corrija locais na turbina onde a detecção de falhas pode ser feita mais cedo
• Propague a primeira falha detectada para todos os validadores através do gossip

Essa interrupção foi causada por um problema de reparo de bloco e processamento de código anteriormente conhecidodesencadeado por um bug não identificado emMecanismo de propagação de bloco da Solana. A falha ocorreu quando um validador transmitiu dois blocos diferentes para o mesmo slot e os propagou para duas partições separadas (A e B), enquanto uma terceira partição detectou independentemente a inconsistência.

Uma vez que cada partição detinha apenas uma participação minoritária, nenhuma delas poderia alcançar um consenso de supermaioria para avançar a cadeia. A questão subjacente derivava de como as estruturas internas de dados da Solana rastreiam blocos e seu estado computado. O sistema utilizava o número do slot de Prova de História (PoH) (um identificador u64) para fazer referência ao estado e ao bloco naquele slot. Uma vez que a rede se dividiu em partições, os nós interpretaram erroneamente os blocos A e B como idênticos, impedindo a reparação adequada e a sincronização de blocos.

Cada partição assumia que a outra tinha o mesmo bloco, levando a um conflito fundamental:

• Nós que possuem o bloco A rejeitaram forks derivados do bloco B
• Nós que seguram o bloco B rejeitaram bifurcações derivadas do bloco A

Uma vez que as transições de estado diferiam entre as partições, os validadores não conseguiam reparar ou conciliar as bifurcações, impedindo a finalização.

A remediação para este problema foipermitir que os serviços rastreiem blocos por hash em vez de número de slot. Se qualquer número de blocos para o mesmo slot criar partições, eles são tratados da mesma forma que as partições com blocos que ocupam slots diferentes. Os nós serão capazes de reparar todas as bifurcações possíveis, e o consenso será capaz de resolver as partições.

Embora o bug tenha sido a causa inicial da interrupção, a maior parte do tempo de inatividade resultou da espera para que peso suficiente de participação voltasse online, já que o Solana requer pelo menos 80% de participação de stake para retomar a produção de blocos.

O Grape Protocol IDO: setembro de 2021

Tempo de inatividade: Dezessete horas

Problema raiz: estouro de memória causado por transações de bot

Correções:

• Ignorar bloqueios de gravação em programas
• Limites de taxa na transmissão de transações
• Comportamento de repetição de RPC configurável
• Priorização de transações de voto TPU

Em 14 de setembro de 2021, Solana passou por uma grande paralisação de rede após o lançamento do Grape Protocol de sua oferta inicial de DEX (IDO) na plataforma de crowdfunding Raydium AcceleRaytor. Dentro de 12 minutos do IDO, a rede foi sobrecarregada por um inédito fluxo de transações impulsionadas por bots e parou de produzir slots enraizados. Esses bots efetivamente executaram um ataque distribuído de negação de serviço (DDoS), levando as cargas de transação além da capacidade da rede.

No pico de congestionamento:

• Alguns validadores estavam recebendo mais de 300.000 transações por segundo.
• Os dados brutos da transação excederam 1 Gbps, com 120.000 pacotes por segundo.
• O tráfego às vezes excedia os limites físicos das interfaces de rede, causando perda de pacotes na porta do switch antes mesmo de chegar aos validadores.

Slots Solana por segundo durante a interrupção da Grape IDO de 14 de setembro de 2021 (Fonte de dados: Jump Crypto)

Um dos bots estruturou suas transações para gravar 18 contas-chave, incluindo o programa global de tokens SPL e o programa Serum DEX agora desativado. Isso bloqueou todas as transações que interagiam com essas contas, reduzindo severamente a capacidade de processamento paralelo da Solana. Em vez de executar transações de forma independente, a rede ficou congestionada, processando transações sequencialmente, exacerbando a congestão.

Uma correção que ignora bloqueios de gravação em programas já foi desenvolvida e programada para lançamento. Mais tarde, a reinicialização da rede habilitou essa atualização, removendo permanentemente esse vetor de ataque.

Durante o evento IDO, os validadores receberam uma enxurrada de transações orientadas por bots e, por sua vez, encaminharam o excesso de transações para o próximo líder, ampliando o congestionamento. A reinicialização da rede introduziu limites de taxa no encaminhamento de transações para evitar que futuras tempestades de transações sobrecarreguem os líderes.

Os nós RPC da Solana repetem automaticamente transações com falha, um recurso projetado para melhorar a confiabilidade. No entanto, esse mecanismo de repetição exacerbou a inundação de transações sob congestionamento extremo, mantendo transações antigas em circulação em vez de permitir que a rede se recuperasse. O Solana 1.8 introduziu um comportamento de repetição de RPC configurável, permitindo que os aplicativos otimizem novas tentativas com tempos de expiração mais curtos e estratégias de recuo exponencial.

Sob forte congestionamento, os líderes do Solana não incluíram transações de votos, que são fundamentais para manter o consenso. Como resultado, a falta de votos confirmados levou a um impasse de consenso, interrompendo a produção de novos blocos raiz. Versões posteriores do cliente Solana introduziram um mecanismo para priorizar transações de votos, evitando que elas fossem abafadas por transações regulares em eventos futuros.

Um segundo bug: estouro de número inteiro

Durante a reinicialização da rede, um segundo problema surgiu. Os validadores relataram valores de participação ativa extremamente flutuantes. Esse problema decorreu de um bug em que a porcentagem de aposta foi multiplicada incorretamente por 100, excedendo o valor máximo possível. O mecanismo de inflação criou tantos novos tokens SOL que transbordou um inteiro não assinado de 64 bits. Este bug foi rapidamente identificado e corrigido antes de uma segunda reinicialização.

Alto congestionamento: janeiro de 2022

Tempo de inatividade: Nenhum

Causa raiz: Transações duplicadas excessivas

Correção parcial:

• Solana 1.8.12 e 1.8.14 lançamentos
• Otimização da deduplicação SigVerify
• Melhorias no desempenho do cache do executor

Entre 6 de janeiro e 12 de janeiro de 2022, a mainnet da Solana experimentou uma grave congestão de rede, resultando em desempenho degradado e interrupções parciais. A interrupção foi causada por bots enviando transações duplicadas excessivas, reduzindo significativamente a capacidade da rede. Os blocos demoraram mais do que o esperado para processar, fazendo com que o próximo líder bifurcasse e reduzisse ainda mais a taxa de transferência. No auge, as taxas de sucesso das transações caíram até 70%. O cliente teve dificuldades em lidar com as transações de alta complexidade e alta computação da rede, expondo limitações em sua capacidade de atender à demanda.

Instabilidade adicional ocorreu de 21 a 23 de janeiro, com congestionamento persistente. Em 22 de janeiro, o ponto de extremidade RPC público (https://api.mainnet-beta.solana.com) ficou offline devido a abusos, já que as chamadas RPC em lote com spam sobrecarregaram o sistema.

Para resolver esses problemas, o Lançamento do Solana 1.8.12 especificamente visou o esgotamento do cache do programa, enquanto a versão 1.8.14 introduziu melhorias no cache Sysvar, descarte de SigVerify e deduplicação de SigVerify.

Spam de Máquina de Doces: Abril / Maio de 2022

Tempo de inatividade: Oito horas

Problema raiz: Spam de transações de contas de bots

Corrige:

• Imposto bot sobre o programa da máquina de doces
• Melhorias de memória no Solana v1.10

Em 30 de abril de 2022, Solana experimentou um aumento sem precedentes nas solicitações de transações. Alguns nós relataram atingir seis milhões de solicitações por segundo, gerando mais de 100 Gbps de tráfego por nó. Esse aumento foi impulsionado por bots que tentavam garantir NFTs recém-criados por meio do programa Metaplex Candy Machine. Esse mecanismo de cunhagem operava com base no princípio do primeiro a chegar, primeiro a ser servido, criando um forte incentivo econômico para inundar a rede com transações e ganhar o cunho.

30 de abril / 1 de maio de 2022, interrupção da Máquina de Doces, pacotes por segundo de entrada (Fonte de dados: Jump Crypto)

À medida que o volume de transações disparou, os validadores ficaram sem memória e falharam, paralisando o consenso. A falta de capacidade de votação impediu a finalização dos blocos anteriores, evitando que os forks abandonados fossem limpos. Como resultado, os validadores ficaram sobrecarregados com a quantidade de forks que tinham que avaliar, excedendo sua capacidade mesmo após reinícios e exigindo intervenção manual para restaurar a rede.

Embora essa interrupção tenha semelhanças com o incidente de setembro de 2021, a Solana demonstrou uma maior resiliência. Apesar de ter experimentado 10.000% mais solicitações de transação do que na interrupção anterior, a rede permaneceu operacional por muito mais tempo, refletindo as melhorias feitas pela comunidade de validadores em resposta aos desafios anteriores de dimensionamento.

30 de abril / 1º de maio de 2022, interrupção da Máquina de Doces, validadores ativos(Fonte de dados: Jump Crypto)

A reinicialização da rede levou menos de 1,5 horas após a captura de tela canônica ter sido acordada. Solana v1.10 incluiu melhorias no uso da memória para prolongar o tempo que os nós podem suportar um consenso lento ou interrompido.

No entanto, questões fundamentais permaneceram sem solução. O líder ainda processava transações competindo pelos mesmos dados de conta com base no critério de chegada, sem prevenção eficaz contra spam, deixando os usuários incapazes de priorizar a urgência de suas transações. Para resolver isso, três mecanismos de longo prazo foram propostos como soluções práticas.

A adoção do QUIC: Anteriormente, a Solana dependia do protocolo de rede UDP (User Datagram Protocol) para enviar transações através do Gulf Stream de nós RPC para o líder atual. Embora rápido e eficiente, o UDP é sem conexão, sem controle de fluxo e confirmações de recebimento. Assim, não há uma maneira significativa de desencorajar ou mitigar o comportamento abusivo. Para efetuar o controle sobre o tráfego de rede, o protocolo de ingestão de transações do validador (ou seja, o Estágio de Busca do TPU) foi reimplementado com o QUIC.

O QUIC tenta oferecer o melhor do TCP e do UDP. Facilita a comunicação rápida e assíncrona semelhante ao UDP, mas com as sessões seguras e as estratégias avançadas de controle de fluxo do TCP. Isso permite impor limites às fontes de tráfego individuais para que a rede possa se concentrar no processamento de transações genuínas. O QUIC também possui um conceito de fluxos separados, portanto, se uma transação for descartada, ela não bloqueia as restantes. O QUIC foi eventualmente integrado no cliente da Solana Labs com o lançamento 1.13.4.

Ponderação de Stake de Qualidade de Serviço (SWQoS): Um novo sistema que prioriza o tráfego de rede com base na participação mantida pelos validadores foi introduzido, garantindo que aqueles com participação mais alta possam enviar transações de forma mais eficiente. Sob esse mecanismo, um validador com 3% da participação total pode enviar até 3% dos pacotes totais para o líder. SWQoS atua como uma medida de resistência à Sybil, tornando mais difícil para atores maliciosos inundarem a rede com transações de baixa qualidade. Esta abordagem substitui o modelo anterior de primeiro a chegar, primeiro a ser servido, que aceitava transações indiscriminadamente sem considerar sua origem.

Introdução de Taxas Prioritárias:Uma vez que as transações são ingeridas, elas ainda competem para acessar dados de conta compartilhados. Anteriormente, essa contenda era resolvida com base em um simples critério de primeiro a chegar, primeiro a ser servido, não proporcionando aos usuários nenhuma maneira de sinalizar a urgência de suas transações. Como qualquer um pode enviar transações, a ponderação do stake não é adequada para a priorização nessa fase. Para resolver isso, uma nova instrução foi adicionada ao programa de Orçamento de Cálculo, permitindo aos usuários especificar uma taxa adicional coletada na execução e inclusão no bloco. A relação taxa-unidade de cálculo determina a prioridade de execução de uma transação, garantindo uma abordagem mais dinâmica e orientada pelo mercado para a ordenação de transações.

Imposto do Bot da Máquina de Doces

Metaplex rapidamente introduziu um imposto de bot codificado de 0,01 SOL em transações de cunhageminteragindo com o programa da Máquina de Doces para combater o spam impulsionado por bots. Este mecanismo anti-spam impôs uma taxa mínima para desencorajar atividades maliciosas sem penalizar usuários legítimos que cometeram erros acidentais. O imposto foi aplicado em cenários específicos, incluindo:

• Tentando fazer mint quando a Máquina de Doces não estava ativa
• Tentando criar quando não restarem itens
• Transações em que a cunhagem ou a definição da coleção não foi a instrução final
• Uso de ID de coleção incorreto
• Instruções de coleta de conjunto incompatíveis
• Uma incompatibilidade entre o pagador assinante e as instruções de coleta e cunhagem
• Transações suspeitas envolvendo programas proibidos
• Tentativa de criar a partir de uma Máquina de Doces protegida pela Lista de Permissões sem possuir o token de lista de permissões necessário

Esse dissuasor econômico se mostrou altamente eficaz. Os snipers da Mint foram rapidamente esgotados e a atividade de spam cessou. Nos primeiros dias, os botters perderam coletivamente mais de 426 SOL.

Bug de Nonce Durável: junho de 2022

Tempo de inatividade: Quatro horas e meia

Problema raiz: Bug de nonce durável levando a falha de consenso

Correções:

• Incapacidade temporária de transações nonce duráveis
• Atualização Solana 1.10.23

Um bug de tempo de execução permitiu que certas transações de nonce duráveis fossem processadas duas vezes—uma vez como uma transação regular e novamente como uma transação de nonce—se elas usassem um blockhash recente em vez de um nonce durável no campo recent_blockhash. Isso levou a um comportamento não determinístico entre os validadores, pois alguns nós rejeitaram a segunda execução, enquanto outros a aceitaram. Criticamente, uma vez que mais de um terço dos validadores aceitaram o bloco, isso impediu que a maioria necessária de dois terços chegasse a um consenso.

Ao contrário das transações padrão, as transações de nonce duráveis não expiram e exigem um mecanismo único para evitar a execução dupla. Elas são processadas de forma sequencial usando um valor de nonce on-chain vinculado a cada conta, que é rotacionado toda vez que uma transação de nonce durável é processada. Uma vez rotacionada, a mesma transação de nonce não deve ser válida novamente.

Para mitigar o problema, as transações de nonce duráveis foram temporariamente desativadas. Uma correção foi posteriormente implementada no Solana 1.10.23, que impediu a execução duplicada separando os domínios nonce e blockhash. A atualização garantiu que, ao avançar contas nonce, o blockhash é hashed com uma cadeia de caracteres fixa, tornando um blockhash inválido como um valor nonce. Como resultado, uma transação executada uma vez como uma transação regular não pode ser reexecutada como uma transação durável e vice-versa. Além disso, um novo tipo DurableNonce substituiu os valores de hash de bloqueio anteriores no estado da conta nonce, adicionando segurança de tipo e evitando problemas semelhantes no futuro.

Leia nosso artigo anterior do blog Helius para entenda mais sobre nonces duráveis e seus usos.

Bug de Bloco Duplicado: Setembro de 2022

Tempo de inatividade: Oito horas e meia

Problema raiz: Um bug nas regras de escolha de fork levou a uma falha de consenso

Corrigir:

• Patch do cliente

Esta interrupção foi desencadeada por um validador produzindo erroneamente blocos duplicados na mesma altura de bloco. Isso ocorreu porque tanto o nó primário do validador quanto seu nó reserva de contingência se tornaram ativos simultaneamente, usando a mesma identidade de nó, mas propondo blocos diferentes. Esta condição persistiu por pelo menos 24 horas antes da interrupção, durante as quais a rede lidou corretamente com os slots de líder duplicados do validador.

O cluster eventualmente parou quando a rede encontrou um fork irreparável devido a um bug na lógica de seleção de fork. Esse bug impediu os produtores de blocos de construir sobre o bloco anterior, levando a uma falha no consenso.

Os forks são uma ocorrência rotineira na Solana, e os validadores normalmente os resolvem alinhando-se ao fork com a maioria dos votos (o fork mais pesado). Quando um validador seleciona o fork errado, ele precisa mudar para o fork mais pesado para se manter sincronizado com a rede. No entanto, neste caso, os validadores não podiam retornar ao banco mais pesado se seu slot correspondesse ao último slot votado. Essa falha fez com que os validadores ficassem presos, impedindo o progresso do consenso e levando, em última instância, à interrupção da rede.

Bug de bloco duplicado, escolha de bifurcação, interrupção, setembro de 2022(Fonte: Laine, Michael Hubbard)

No exemplo acima, o validador C defeituoso produz blocos duplicados para seus slots líderes 5 a 8. Quando o validador G assume como o próximo líder, ele observa apenas uma das duplicatas e estende sua bifurcação de acordo. No entanto, o líder seguinte, o validador D, detecta ambos os blocos duplicados do validador C e decide descartá-los, em vez de construir sua bifurcação em cima do slot 4.

À medida que a rede progride, a bifurcação construída pelo validador G ganha votos da maioria das participações, estabelecendo-se como a cadeia canônica. Reconhecendo que sua bifurcação está perdendo, o validador D tenta mudar para a bifurcação do validador G. No entanto, a transição falha devido a um bug na lógica de seleção de bifurcação. Esse problema surge porque o ancestral comum das duas bifurcações — um bloco duplicado no slot 5 — não foi tratado corretamente, impedindo que o validador D reconhecesse a bifurcação majoritária. Como resultado, o validador D permanece preso em seu próprio garfo, incapaz de se juntar novamente à cadeia principal.

O problema foi resolvido após uma revisão pela equipe principal.Uma correção foi mesclada na ramificação principal e retroportada para todas as ramificações de lançamento.

Grande Bloco Sobrecarrega Turbina: Fevereiro de 2023

Tempo de inatividade: Quase 19 horas

Problema raiz: Falha da lógica de deduplicação nos serviços de encaminhamento de fragmentos

Correções:

• Múltiplas melhorias na lógica de deduplicação e filtragem do Turbine
• Adicionar patch de cliente forçando os produtores de bloco a abortar se eles gerarem blocos grandes

O serviço de encaminhamento de fragmentação personalizado de um validador funcionou mal, transmitindo um bloco excepcionalmente grande (quase 150.000 fragmentos), várias ordens de magnitude maiores do que um bloco padrão, durante seu slot líder. Isso sobrecarregou os filtros de eliminação de duplicação do validador, fazendo com que os dados fossem continuamente reencaminhados. O problema se agravou à medida que novos blocos foram produzidos, acabando por saturar o protocolo.

Grande bloqueio, fragmentos por bloco, fevereiro de 2023 (Fonte: Laine, Michael Hubbard)

O aumento no tráfego de rede anormal sobrecarregou a Turbine, forçando os dados do bloco a serem transmitidos por meio do protocolo de Reparo de Bloco de fallback significativamente mais lento. Embora a turbina seja projetada para suportar grandes blocos filtrando-os, os serviços de encaminhamento de trituração funcionam a montante dessa lógica de filtragem, diminuindo sua eficácia. Durante o período degradado, os líderes de bloco mudaram automaticamente para o modo somente voto, um mecanismo de segurança no qual os líderes excluem transações econômicas sem voto.

A causa raiz do problema foi uma falha na lógica de eliminação de duplicação nos serviços de encaminhamento de fragmentação, impedindo a retransmissão redundante de fragmentos. Além disso, o filtro de desduplicação na tubulação de retransmissão não foi originalmente projetado para evitar looping dentro da árvore da turbina, agravando o problema.

A rede foi reiniciada manualmente com uma degradação para a última versão estável conhecida do software do validador. Para mitigar esses problemas, Solana v1.13.7 e v1.14.17 introduziram melhorias na lógica de deduplicação, melhorando sua capacidade de evitar a saturação do filtro e garantindo um desempenho de rede mais robusto.

Loop de Recompilação Infinita: fevereiro de 2024

Tempo de inatividade: Quase cinco horas

Problema raiz: Bug causando um loop de recompilação infinito no cache JIT

Correções:

• Desativar carregador herdado v1.17.20

O validador Agave just-in-time (JIT) compila todos os programas antes de executar transações que os referenciam. Para otimizar o desempenho, a saída JIT dos programas usados com frequência é armazenada em cache, reduzindo recompilações desnecessárias. Como parte do Agave v1.16, o mecanismo de cache existente, LoadedPrograms, foi substituído por uma nova implementação chamada ExecutorsCache, que introduziu várias eficiências.

O LoadedPrograms forneceu uma visão global, consciente de bifurcações, de programas em cache, reduzindo a duplicação de dados contábeis e permitindo que threads de execução de transações carreguem novos programas cooperativamente, evitando conflitos de compilação. Um recurso-chave deste sistema era rastrear o slot onde um programa se torna ativo (conhecido como altura de slot efetiva) para detectar invalidações de cache quando os dados do programa on-chain são atualizados.

A altura efetiva do slot da maioria dos programas foi derivada de seu slot de implantação, que foi armazenado em sua conta on-chain. No entanto, os programas implantados usando carregadores herdados não mantiveram esse slot de implantação em suas contas. LoadedPrograms atribuiu a esses programas uma altura de slot efetiva de zero como uma solução alternativa.

Uma exceção ocorreu quando uma instrução de implantação foi detectada, sinalizando que o bytecode de um programa foi substituído. Neste caso, LoadedPrograms inseriu temporariamente uma entrada com a altura do slot efetiva correta. No entanto, como uma transação nunca fez referência a esta entrada, ela era altamente suscetível a ser removida. Quando removido, a saída do JIT foi descartada e o programa foi marcado como descarregado, mas a altura do slot efetiva foi mantida.

Se uma transação posterior referenciou este programa não carregado, os LoadedPrograms o recompilaram e reinseriram uma entrada na sua altura de slot efetiva. Tipicamente, isso tornaria o programa disponível para execução na próxima iteração. No entanto, para programas de carregador legados, a nova saída JIT foi atribuída a altura de slot sentinela zero, colocando-a atrás da entrada não carregada anterior. Como resultado, LoadedPrograms nunca reconheceu o programa como carregado, desencadeando um loop contínuo de recompilação em cada iteração.

No Agave v1.16, LoadedPrograms não suportava carregamento cooperativo, permitindo que a transação de disparo fosse empacotada em um bloco. Esse bloco foi então propagado pela rede, fazendo com que cada validador o reproduzisse e entrasse no mesmo loop de recompilação infinito. Como mais de 95% da participação do cluster estava executando o Agave v1.17 durante a interrupção, a maioria dos validadores ficou parada nesse bloco, interrompendo a rede.

Este bug foi identificado na semana anterior durante uma investigação sobre uma interrupção no cluster Devnet, e um patch foi agendado para implantação.@jeff.washington/2024-02-06-solana-mainnet-beta-outage-report-619bd75b3ce0">A mitigação escolhida foi retroceder as alterações para Agave v1.17 e remover imediatamente um gate feature após o reinício da rede. Isso desativou o carregador legado responsável por acionar o bug, evitando ocorrências futuras.

Patch de Vulnerabilidade Coordenada: Agosto de 2024

Tempo de inatividade: Nenhum

Problema raiz: Suposição incorreta de alinhamento de endereço ELF

Correções:

• Atualização de patch

No dia 5 de agosto, Os engenheiros do núcleo de Anza foram alertados sobre uma vulnerabilidade no cliente Agave, relatada por um pesquisador externo. Um atacante poderia ter explorado essa falha para derrubar os validadores líderes, levando a uma paralisação em toda a rede. Em resposta, os engenheiros da Anza desenvolveram rapidamente um patch, que foi então auditado por várias empresas de segurança de terceiros.

Os programas Solana são compilados usando LLVM no Formato executável e vinculável (ELF). A vulnerabilidade surgiu de uma suposição de alinhamento de endereço incorreto dentro desses arquivos ELF gerados. Embora a higienização do ELF normalmente imponha várias verificações de integridade, ela não validou o alinhamento da seção .text. Essa supervisão poderia ter permitido que um arquivo ELF criado com códigos maliciosos definisse uma seção .text desalinhada, levando a máquina virtual a pular para um endereço inválido. Isso resultaria em uma falha de segmentação do host, travando o validador.

Um intruso poderia ter explorado esta vulnerabilidade ao:

• Criando um programa Solana malicioso que usa o opcode CALL_REG.
• Manipulando o arquivo ELF para desalinhar a seção .text.
• Implantando e invocando o programa na rede, desencadeando falhas no validador.

Processo de atualização de patch

Qualquer atualização de patch lançada publicamente imediatamente tornaria a vulnerabilidade clara para todos. Isso poderia permitir que um atacante tempo suficiente para engenharia reversa da vulnerabilidade e interromper a rede antes que uma quantidade suficiente de participação fosse atualizada. Uma massa crítica de validadores precisaria adotar qualquer lançamento de patch o mais rápido possível para evitar tal cenário.

Até 7 de agosto, vários membros do A Fundação Solana entrou em contato com validadores por meio de mensagens privadas em várias plataformas de comunicação, informando-os de um próximo patch crítico e compartilhando uma mensagem em hash que confirmou a data e o identificador exclusivo do incidente. Vários membros proeminentes de Anza, Jito e da Fundação Solana compartilharam esse hash no X, GitHub e LinkedIn para verificar a precisão da mensagem. Exemplo de hash compartilhado:

No dia seguinte, os membros do núcleo continuaram a entrar em contato com os validadores, ressaltando a importância da urgência e da confidencialidade. No horário pré-determinado, 8 de agosto, às 14h UTC, os operadores do validador receberam uma mensagem adicional contendo instruções para baixar, verificar e aplicar o patch. O patch foi hospedado no repositório Github de um engenheiro conhecido do Anza, não no repositório principal do Agave. As instruções incluíam a verificação dos arquivos de patch baixados em relação aos shasums fornecidos.

Por volta das 20h UTC de 8 de agosto, uma supermaioria de participação havia sido corrigida, garantindo a segurança da rede. Depois disso, a vulnerabilidade e seu patch correspondente foram divulgados publicamente, acompanhados por uma chamada para que todos os validadores restantes atualizem.

A distribuição silenciosa do patch e a coordenação nos bastidores dos validadores levantaram preocupações sobre a descentralização da Solana. Pouco tempo após o incidente, o diretor executivo da Fundação Solana, Dan Albert, abordou essas críticas em uma entrevista à imprensa.

"Acho importante não confundir centralização com capacidade de coordenação. Existem 1.500 nós produtores de blocos em todo o mundo que são operados por quase tantos indivíduos.... A capacidade de se comunicar com eles, ou com alguns deles, voluntariamente, não se confunde com centralização."

Semana Blockchain da Coreia (KBW) 2024

Acho importante não confundir centralização com a capacidade de coordenar. Existem 1.500 nós produtores de blocos em todo o mundo que são operados por quase tantos indivíduos.... A capacidade de comunicar com eles, ou alguns deles, voluntariamente, não deve ser confundida com centralização.

Conclusão

Até o momento desta escrita, a Solana passou mais de um ano sem interrupções, atingindo um marco importante para remover a tag “beta” da mainnet-beta. A frequência de interrupções parece estar diminuindo à medida que a rede amadurece e a introdução do Firedancer é esperada para melhorar a diversidade de clientes, reduzindo o risco de bugs não descobertos ou casos extremos causando um desligamento completo em todo o cluster. No entanto, alguns líderes da comunidade, incluindo o fundador da Helius, Mert Mumtaz, previram que as interrupções continuarão. O tempo dirá.

Muito obrigado a Zantetsu (Shinobi Systems) e OxIchigo por rever versões anteriores deste trabalho.

Aviso Legal:

1. Este artigo é reproduzido de [Helius]. Todos os direitos autorais pertencem ao autor original [Perdido]. Se houver objeções a esta reimpressão, entre em contato com o Aprender gateequipe e eles lidarão com isso prontamente.
2. Isenção de responsabilidade: Os pontos de vista e opiniões expressos neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. A equipe de Aprendizado da gate faz traduções do artigo para outros idiomas. Copiar, distribuir ou plagiar os artigos traduzidos é proibido, a menos que mencionado.