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

O sono de Steven é quebrado pelos toques ásperos de seu telefone, arrastando-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 de forma grogue, e alcança o dispositivo. Apertando os olhos para a mensagem, seu coração afunda – o nó está para baixo. Sem hesitar, ele sai da cama, semivestido, atrapalhando-se para desbloquear seu telefone à medida que mais mensagens chegam. Em seguida, ele o atinge – todo o cluster está para baixo.

Neste exato momento, em todo o mundo, em cidades e fusos horários dispersos, centenas de operadores de nós estão a olhar para os seus telemóveis com a mesma realização: O momento que temiam chegou - uma interrupção.

Introdução

Como todos os sistemas distribuídos, a Solana opera sob a realidade de que uma falha de implementação única 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 infraestruturas distribuídas complexas - quer em blockchains descentralizados, exchanges centralizadas, ou até mesmo grandes provedores de serviços em nuvem como a Amazon ou a 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 futuros incidentes. Apesar de testes simulados rigorosos, uma testnet incentivada e 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 experimentou sete incidentes de interrupção separados, cinco dos quais foram causados por bugs de cliente e dois pela incapacidade da rede de lidar com inundações de spam de transações. As versões iniciais da Solana careciam de mecanismos-chave de gestão de congestionamentos, como taxas de prioridade e mercados de taxas locais, que mais tarde se revelaram essenciais na mitigação do stress da rede. A falta desses mecanismos levou a períodos prolongados de desempenho degradado e congestionamento ao longo de 2022, uma vez que a rede essencialmente incentivou o spam.

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

Este artigo analisará cada interrupção da Solana em detalhe, examinando as causas raiz, eventos desencadeantes 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 estas seções sejam melhor lidas em ordem, cada uma foi projetada para se sustentar sozinha, permitindo que os leitores pulem para os tópicos ou incidentes de interrupção que mais lhes interessam.

Vivacidade 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 das três propriedades:

• Consistência - Cada leitura vê todas as escritas anteriores.
• Disponibilidade - Cada pedido recebe uma resposta.
• Tolerância à partição - O sistema continua a funcionar 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 rápida finalização, o Solana prioriza a consistência em detrimento da disponibilidade, tornando-se um sistema CP. Ele pára 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 irreparável que exige 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

Liveness Failure: ocorre quando o blockchain para de progredir, impedindo que as transações sejam confirmadas e os blocos sejam produzidos devido ao tempo de inatividade do validador, partições de rede ou interrupções de consenso. No contexto do teorema da PAC, isto corresponde a uma perda de disponibilidade.

Falha de segurança: ocorre quando o estado finalizado do blockchain é alterado ou bifurcado de forma imprópria. Isso pode levar a históricos conflituosos ou gastos duplicados, frequentemente causados por bugs de consenso ou ataques maliciosos. No contexto do teorema CAP, isso corresponde a uma perda de consistência.

Solana prioriza a segurança sobre a vivacidade. Assim, a rede irá parar em casos de estresse extremo na rede ou falha de consenso, em vez de arriscar a corrupção do estado. Embora as interrupções sejam disruptivas e possam afetar aplicações, usuários e validadores, elas são preferíveis às consequências catastróficas de um livro-razão inconsistente ou corrompido.

Reinícios de rede

Reiniciar a rede Solana envolve identificar o último slot de bloco confirmado com otimismo e reinicializar nós a partir de um instantâneo de estado local confiável desse slot. Como o slot de reinicialização não é determinado on-chain, os operadores do validador devem chegar a um consenso off-chain para chegar a um acordo sobre um ponto de reversão seguro. Essa coordenação ocorre publicamente no canal #mb-validadores no Solana Tech Discord, onde os operadores profissionais de validadores se comunicam em tempo real. A maioria dos operadores tem sistemas de alerta automatizados que os notificam no momento em que a produção do bloco para, garantindo uma resposta rápida.

Uma vez que seja alcançado um consenso sobre o slot correto de reinício, os operadores utilizam a ferramenta de contabilidade para gerar uma nova imagem local, reiniciar os seus validadores e aguardar que pelo menos 80% do total da participação volte online. Só então a rede retoma a produção e validação de blocos. Verificar que existe no máximo 20% de participação offline quando o cluster reinicia garante margem de segurança suficiente para permanecer online no caso de os nós bifurcarem ou voltarem a ficar offline imediatamente após o reinício.

Relatório de bugs

Os programas de recompensa por falhas recompensam os pesquisadores de segurança por identificar e relatar vulnerabilidades de software. Esta é uma linha crítica de defesa, pois incentiva proativamentedetetar bugs antes que possam ser explorados. Os pesquisadores de segurança e os desenvolvedores que identificarem potenciais vulnerabilidades no cliente Agave são incentivados a reportá-las através dos canais de segurança apropriados.As diretrizes detalhadas de divulgação podem ser encontradas no repositório do Agave GitHub.

As recompensas são oferecidas por relatórios 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
• Disponibilidade ou Perda de Disponibilidade: Até 5.000 SOL

Além disso, o cliente FireDancer tem um programa de recompensa por bugs separado hospedado através da Immunefi, oferecendo uma recompensa máxima de $500.000 USDC por descobertas críticas.

Instâncias de interrupção

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

Turbine Bug: dezembro 2020

Tempo de inatividade: Aproximadamente seis horas

Questão principal: Bug de propagação de bloco

Correções:

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

Esta interrupção foi causada por um anteriormente conhecido problema de reparação de bloco e processamento de códigodesencadeado por um bug não identificado emTurbina, mecanismo de propagação de blocos 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 detetou independentemente a inconsistência.

Uma vez que cada partição detinha apenas uma participação minoritária, nenhuma poderia alcançar um consenso de supermaioria para progredir na cadeia. O problema subjacente resultou de como as estruturas de dados internas da Solana rastreiam blocos e seu estado computado. O sistema usava o número de slot da Prova de História (PoH) (um identificador u64) para referenciar o estado e o bloco nesse 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 assumiu que a outra tinha o mesmo bloco, levando a um conflito fundamental:

• Nós que detêm o bloco A rejeitaram bifurcações derivadas do bloco B
• Nós que detêm o bloco B rejeitaram bifurcações derivadas do bloco A

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

A solução para esta questão foi a de permitir 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 não são tratados de forma diferente das 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 de peso suficiente de participação para voltar online, pois a Solana requer pelo menos 80% de participação para retomar a produção de blocos.

O Protocolo da Uva IDO: setembro 2021

Tempo de inatividade: Dezassete 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 retransmissão de transações
• Comportamento de repetição de RPC configurável
• Priorização de transação de voto TPU

Em 14 de setembro de 2021, Solana experimentou uma grande paralisação da rede após o lançamento pela Grape Protocol de sua oferta inicial de DEX on-chain (IDO) na plataforma de crowdfunding Raydium AcceleRaytor. Dentro de 12 minutos do IDO, a rede ficou sobrecarregada por uma enxurrada sem precedentes de transações impulsionadas por bots e parou de produzir slots enraizados. Esses bots executaram efetivamente um ataque distribuído de negação de serviço (DDoS), empurrando 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 de transação excederam 1 Gbps, com 120.000 pacotes por segundo.
• Por vezes, o tráfego 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 do Grape IDO de 14 de setembro de 2021(Fonte de dados: Jump Crypto)

Um dos bots estruturou suas transações para bloquear 18 contas-chave, incluindo o programa global de token SPL e o extinto programa Serum DEX. Isso bloqueou todas as transações que interagiam com essas contas, reduzindo drasticamente a capacidade de processamento paralelo do Solana. Em vez de executar transações de forma independente, a rede ficou congestionada, processando as transações sequencialmente, exacerbando o congestionamento.

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 impulsionadas por bots e, por sua vez, encaminharam transações em excesso para o próximo líder, amplificando a congestão. O reinício 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 tentam automaticamente transações falhadas, uma funcionalidade projetada para melhorar a fiabilidade. No entanto, este mecanismo de repetição exacerbou a inundação de transações em situações de congestionamento extremo, mantendo transações antigas em circulação em vez de permitir à rede recuperar. A Solana 1.8 introduziu um comportamento de repetição RPC configurável, permitindo que as aplicações otimizem as repetições com tempos de expiração mais curtos e estratégias de retrocesso exponencial.

Sob uma congestionamento intenso, os líderes da Solana não conseguiram incluir transações de voto, que são críticas 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 voto, evitando que sejam afogadas por transações regulares em eventos futuros.

Um Segundo Bug: Overflow de Inteiro

Durante o reinício da rede, surgiu um segundo problema. Os validadores relataram quantidades de apostas ativas extremamente flutuantes. Este problema resultou de um bug em que a percentagem de participação foi incorretamente multiplicada 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.

Alta Congestão: Janeiro de 2022

Tempo de inatividade: Nenhum

Causa raiz: Transações duplicadas excessivas

Correção parcial:

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

Entre 6 e 12 de janeiro de 2022, a rede principal Solana sofreu um grave congestionamento da rede, levando a um desempenho degradado e interrupções parciais. A interrupção foi impulsionada por bots fazendo spam em transações duplicadas excessivas, reduzindo significativamente a capacidade da rede. Os blocos demoraram mais tempo do que o esperado para serem processados, fazendo com que o próximo líder bifurcasse e reduzisse ainda mais o rendimento. No auge, as taxas de sucesso das transações caíram até 70%. O cliente lutou para lidar com as transações cada vez mais complexas e de alta computação da rede, expondo limitações em sua capacidade de atender à demanda.

Ocorreu instabilidade adicional de 21 a 23 de janeiro, com a congestão persistindo. Em 22 de janeiro, o ponto de extremidade RPC público (https://api.mainnet-beta.solana.com) foi desligado devido a abuso, pois chamadas RPC em lote enviadas em massa sobrecarregaram o sistema.

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

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

Tempo de inatividade: Oito horas

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

Correções:

• Imposto sobre robôs no programa da máquina de doces
• Melhorias de memória no Solana v1.10

Em 30 de abril de 2022, Solana experimentou uma onda sem precedentes de pedidos de transação. Alguns nós relataram alcançar seis milhões de pedidos por segundo, gerando mais de 100 Gbps de tráfego por nó. Essa onda foi impulsionada por bots tentando garantir NFTs recém-criados através do programa Metaplex Candy Machine. Esse mecanismo de cunhagem operava com base no princípio de primeiro a chegar, primeiro a ser servido, criando um forte incentivo econômico para inundar a rede com transações e ganhar a cunhagem.

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 assim o consenso. A baixa capacidade de votação impediu a finalização de blocos anteriores, evitando que os forks abandonados fossem limpos. Como resultado, os validadores ficaram sobrecarregados com o grande número de forks que tinham de avaliar, ultrapassando a sua capacidade mesmo após reinícios e exigindo intervenção manual para restaurar a rede.

Embora esta interrupção tenha semelhanças com o incidente de setembro de 2021, o Solana demonstrou uma resiliência melhorada. Apesar de ter recebido 10.000% mais pedidos 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 escalabilidade.

30 de abril / 1 de maio de 2022 Desligamento da Máquina de Doces, validadores ativos (Fonte de dados: Jump Crypto)

A reinicialização da rede demorou menos de 1,5 horas depois que a captura canônica foi acordada. A 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 por resolver. O líder ainda processava transações que disputavam os mesmos dados de conta com base no princípio de primeiro a chegar, primeiro a ser servido, sem prevenção eficaz contra spam, deixando os utilizadores incapazes de priorizar a urgência das suas transações. Para resolver isso, foram propostos três mecanismos de longo prazo como soluções práticas.

A Adoção do QUIC: Anteriormente, Solana dependia do protocolo de rede UDP (User Datagram Protocol) para enviar transações através do Gulf Stream, dos nós RPC para o líder atual. Embora rápido e eficiente, o UDP é sem conexão, falta de controle de fluxo e de confirmações de recebimento. Portanto, não há uma maneira significativa de desencorajar ou mitigar comportamentos abusivos. Para controlar o tráfego de rede, o protocolo de ingestão de transações do validador (ou seja, a Etapa de Busca do TPU) foi reimplementado com 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 sessões seguras e estratégias avançadas de controlo de fluxo do TCP. Isso permite impor limites às fontes de tráfego individuais para que a rede possa concentrar-se no processamento de transações genuínas. O QUIC também tem um conceito de fluxos separados, portanto, se uma transação for descartada, não bloqueia as restantes. O QUIC foi eventualmente integrado no cliente da Solana Labs com o lançamento 1.13.4.

Peso da Participação na Qualidade do Serviço (PPQS): Um novo sistema que prioriza o tráfego de rede com base na participação dos validadores foi introduzido, garantindo que aqueles com uma participação mais elevada possam enviar transações de forma mais eficiente. Sob este mecanismo, um validador com 3% da participação total pode enviar até 3% dos pacotes totais para o líder. O SWQoS atua como uma medida de resistência Sybil, tornando mais difícil para atores maliciosos inundar 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 a sua origem.

Introdução de taxas prioritárias:Uma vez que as transações são ingeridas, elas ainda competem para acessar os dados da conta compartilhada. Anteriormente, essa contenção era resolvida com base em uma simples ordem de chegada, não fornecendo aos usuários nenhuma maneira de sinalizar a urgência de suas transações. Como qualquer pessoa pode enviar transações, a ponderação da participação não é adequada para priorização nesta 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 cobrada 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

A Metaplex introduziu rapidamente uma taxa de imposto de bot codificada de 0,01 SOL em transações de cunhagem interagindo com o programa Candy Machine para combater o spam impulsionado por bots. Este mecanismo antisspam impôs uma taxa mínima para dissuadir atividades maliciosas sem penalizar os utilizadores legítimos que cometeram erros acidentais. O imposto foi aplicado em cenários específicos, incluindo:

• Tentando cunhar quando a Máquina de Doces não estava ao vivo
• Tentando criar quando não restarem itens
• Transações onde a cunhagem ou definição da coleção não foi a instrução final
• Uso de ID de coleção incorreto
• Instruções de Coleção de Conjunto Descombinadas
• Uma incompatibilidade entre o signatário-pagador do conjunto de recolha e as instruções de 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 deter o token de permissão necessário

Esta dissuasão económica revelou-se altamente eficaz. Os franco-atiradores da Casa da Moeda foram rapidamente drenados e a atividade de spam cessou. Nos primeiros dias, os botters perderam coletivamente mais de 426 SOL.

Bug do Nonce Durável: Junho de 2022

Tempo de inatividade: Quatro horas e meia

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

Correções:

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

Um bug de tempo de execução permitiu que certas transações nonce duráveis fossem processadas duas vezes — uma como uma transação regular e outra como uma transação 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, já que 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, este impediu que a maioria de dois terços necessária chegasse a um consenso.

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

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

Leia o nosso artigo de blog Helius anterior para Entenda mais sobre Nonces duráveis e seus usos.

Bug do Bloco Duplicado: setembro de 2022

Tempo de inatividade: Oito horas e meia

Problema raiz: Um erro nas regras de escolha de bifurcação levou a uma falha de consenso

Corrigir:

• Patch do cliente

Esta interrupção foi desencadeada por um validador a produzir erroneamente blocos duplicados na mesma altura de bloco. Isto ocorreu porque tanto o nó principal do validador como o seu nó sobressalente de contingência se tornaram ativos simultaneamente, utilizando a mesma identidade de nó mas propondo blocos diferentes. Esta condição persistiu durante pelo menos 24 horas antes da interrupção, durante as quais a rede lidou corretamente com as slots de líder duplicadas do validador.

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

Os garfos são uma ocorrência rotineira em Solana, e os validadores normalmente os resolvem alinhando-os no garfo com a maioria dos votos (o garfo mais pesado). Quando um validador seleciona a bifurcação errada, ele deve alternar para a bifurcação mais pesada para ficar em sincronia com a rede. No entanto, neste caso, os validadores não poderiam reverter para o banco mais pesado se o seu slot correspondesse ao seu último slot votado. Essa falha fez com que os validadores permanecessem presos, impedindo que o consenso progredisse e, finalmente, levando à interrupção da rede.

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

No exemplo acima, o validador com defeito C produz blocos duplicados para os seus slots de líder de 5 a 8. Quando o validador G assume como o próximo líder, ele observa apenas um dos duplicados e estende seu fork em conformidade. No entanto, o líder seguinte, o validador D, deteta ambos os blocos duplicados do validador C e decide descartá-los, construindo em vez disso o seu fork em cima do slot 4.

À medida que a rede avança, o fork construído pelo validador G ganha votos da maioria da participação, estabelecendo-se como a cadeia canônica. Reconhecendo que o seu próprio fork está a perder, o validador D tenta mudar para o fork do validador G. No entanto, a transição falha devido a um bug na lógica de seleção do fork. Este problema surge porque o ancestral comum dos dois forks - um bloco duplicado no slot 5 - não foi tratado corretamente, impedindo o validador D de reconhecer o fork da maioria. Como resultado, o validador D permanece preso no seu próprio fork, incapaz de se juntar à cadeia principal.

A questão foi resolvida após uma revisão pela equipa principal.Um patch foi mesclado no ramo principal e retroportado para todos os ramos de lançamento.

Bloco grande 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 do cliente forçando os produtores de bloco a abortar se gerarem blocos grandes

O serviço de retransmissão personalizado de fragmentos de um validador falhou, transmitindo um bloco excepcionalmente grande (quase 150.000 fragmentos), várias ordens de magnitude maior do que um bloco padrão, durante o seu slot de líder. Isso sobrecarregou os filtros de deduplicação do validador, fazendo com que os dados fossem continuamente retransmitidos. O problema se agravou à medida que novos blocos foram produzidos, eventualmente saturando o protocolo.

Interrupção de bloco grande, fragmentos por bloco, fevereiro de 2023(Fonte: Laine, Michael Hubbard)

O aumento do tráfego anormal na rede sobrecarregou a Turbine, forçando a transmissão de dados de bloco através do protocolo de Reparo de Bloco de fallback significativamente mais lento. Embora a Turbine seja projetada para suportar blocos grandes filtrando-os, os serviços de encaminhamento de fragmentos funcionam a montante dessa lógica de filtragem, diminuindo sua eficácia. Durante o período de degradação, os líderes de bloco mudaram automaticamente para o modo de apenas voto, um mecanismo de segurança no qual os líderes excluem transações econômicas não votadas.

A causa raiz do problema foi uma falha na lógica de deduplicação nos serviços de encaminhamento de fragmentos, impedindo a retransmissão redundante de fragmentos. Além disso, o filtro de deduplicação no pipeline de retransmissão não foi originalmente projetado para evitar looping dentro da árvore Turbine, exacerbando o problema.

A rede foi reiniciada manualmente com um downgrade para a última versão de software validador estável conhecida. Para mitigar esses problemas, Solana v1.13.7 e v1.14.17 introduziu melhorias na lógica de desduplicação, melhorando a 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 o carregador legado 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 de programas usados com freqüê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.

Os LoadedPrograms forneciam uma visão global e com reconhecimento de bifurcação dos programas armazenados em cache, reduzindo a duplicação de dados contábeis e permitindo que threads de execução de transações carregassem novos programas cooperativamente, evitando conflitos de compilação. Uma característica fundamental deste sistema era rastrear o slot onde um programa se torna ativo (conhecido como a altura efetiva do slot) para detetar 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 do seu slot de implantação, que estava armazenado na sua conta on-chain. No entanto, os programas implantados usando carregadores legados não mantiveram este slot de implantação nas suas contas. Os LoadedPrograms atribuíram a estes programas uma altura efetiva do slot de zero como solução alternativa.

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

Se uma transação referenciou posteriormente este programa descarregado, o LoadedPrograms recompilou-o e reinseriu uma entrada na sua altura de slot efetiva. Tipicamente, isto tornaria o programa disponível para execução na próxima iteração. No entanto, para programas de carregamento herdados, a nova saída JIT foi atribuída a altura de slot de sentinela de zero, colocando-a atrás da entrada descarregada anterior. Como resultado, o LoadedPrograms nunca reconheceu o programa como carregado, desencadeando um loop contínuo de recompilação em cada iteração.

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

Este bug foi identificado na semana anterior durante uma investigação sobre uma interrupção do cluster Devnet, e uma correção foi agendada 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, impedindo ocorrências futuras.

Pacote de Correção de Vulnerabilidade Coordenada: agosto de 2024

Tempo de inatividade: Nenhum

Problema raiz: Pressuposto de alinhamento de endereço ELF incorreto

Correções:

• Atualização de patch

No dia 5 de agosto, Os engenheiros principais da Anza foram alertados para uma vulnerabilidade no cliente Agave, reportada por um pesquisador externo. Um atacante poderia ter explorado essa falha para fazer com que os validadores líderes travassem, levando a uma paralisação em toda a rede. Em resposta, os engenheiros da Anza desenvolveram rapidamente um patch, que várias empresas de segurança de terceiros auditaram.

Os programas Solana são compilados usando LLVM no Formato executável e vinculável (ELF). A vulnerabilidade resultou de uma suposição incorreta de alinhamento de endereço nesses 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 saltar para um endereço inválido. Isso resultaria em uma falha de segmentação do host, travando o validador.

Um atacante poderia ter explorado essa vulnerabilidade por:

• Criar um programa Solana malicioso que usa o CALL_REG opcode.
• Manipular o arquivo ELF para desalinear a seção .text.
• Implantar e invocar o programa na rede, desencadeando falhas no validador.

Processo de Atualização do Patch

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

Em 7 de agosto, vários membros do A Fundação Solana tinha contactado os validadores através de mensagens privadas em várias plataformas de comunicação, informando-os de um próximo patch crítico e compartilhando uma mensagem com hash que confirmou a data e o identificador único do incidente. Vários membros proeminentes de Anza, Jito e Solana Foundation 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, 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.

Até as 20h UTC do dia 8 de agosto, uma supermaioria da participação foi corrigida, garantindo a segurança da rede. Após isso, a vulnerabilidade e sua correção correspondente foram divulgadas publicamente, acompanhadas por um apelo para que todos os validadores restantes façam a atualização.

A distribuição silenciosa do patch e a coordenação nos bastidores dos validadores levantaram preocupações sobre a descentralização de Solana. Pouco depois do 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 comunicar com eles, ou alguns deles, voluntariamente, não se confunde com centralização."

Semana Blockchain da Coreia (KBW) 2024

Penso que é 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 comunicar com eles, ou com alguns deles, voluntariamente, não se confunde com centralização.

Conclusão

Até à data desta escrita, a Solana passou mais de um ano sem falhas, alcançando um marco importante para a remoção da etiqueta “beta” do mainnet-beta. A frequência de falhas parece estar a diminuir à medida que a rede amadurece, e a introdução do Firedancer espera-se que aumente a diversidade de clientes, reduzindo o risco de bugs não descobertos ou casos limite causarem um encerramento completo em toda a cluster. No entanto, alguns líderes da comunidade, incluindo o fundador da Helius, Mert Mumtaz, previram que as falhas vão continuar. O tempo dirá.

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

Aviso legal:

1. Este artigo foi reproduzido a partir de [Hélio]. Todos os direitos autorais pertencem ao autor original [Lostin]. Se houver objeções a esta reimpressão, contacte o Gate Learnequipa e eles vão tratar do assunto prontamente.
2. Aviso de responsabilidade: As opiniões expressas neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. A equipa do Learn gate faz traduções do artigo para outras línguas. Copiar, distribuir ou plagiar os artigos traduzidos é proibido, a menos que seja mencionado.