Por volta das 20:30 UTC do dia 30 de abril – sábado, o cluster Mainnet Beta de Solana deixou de produzir blocos como resultado de um consenso paralisado. Nas sete horas seguintes, os operadores do validador trabalharam para identificar o ponto de maior progresso e instituíram coletivamente o reinício da rede. A produção do bloco foi retomada às 03:30 UTC do dia seguinte, e as operadoras de rede continuaram a restaurar os serviços ao cliente nas próximas horas.
O que causou a interrupção?
Uma enorme quantidade de transações de entrada (6 milhões por segundo) congestionou a rede, ultrapassando 100 Gbps de tráfego em nós individuais. Não há evidências de um ataque de negação de serviço, mas evidências indicam que os bots tentaram programaticamente ganhar um novo NFT sendo cunhado usando o popular programa Candy Machine. Como o preço da casa da moeda tinha um piso fixo e não um leilão holandês dinâmico, o primeiro usuário a ligar para a casa da moeda recebia o NFT, o que criava um incentivo econômico para enviar um grande número de transações na esperança de ganhar a casa da moeda.
A razão específica pela qual o consenso parou foi devido a validadores ficando sem memória e travando. A causa raiz do alto uso de memória foi o desembarque de votos insuficientes para finalizar os blocos anteriores, evitando a limpeza de bifurcação abandonada. O número de validadores de forks que precisavam avaliar excedeu sua capacidade de fazê-lo, mesmo após uma reinicialização, necessitando de intervenção manual.
O que está sendo feito?
Desde o início de janeiro, Solana tem sofrido problemas de congestionamento intermitentes resultantes da atividade de bots direcionada às casas da moeda NFT. A interrupção anterior do Mainnet Beta ocorreu em setembro de 2021 e durou 17 horas. A interrupção de 30 de abril compartilha características com a interrupção de setembro, mas a rede desta vez continuou funcionando mesmo quando os volumes de solicitações de transações atingiram 10.000% do nível de setembro, refletindo as atualizações subsequentes feitas pela comunidade de validadores.
A ramificação da versão beta, v1.10, que está atualmente se estabilizando no Testnet, inclui melhorias no uso de memória para prolongar o tempo que os nós podem suportar um consenso lento ou parado. Os nós de teste executando v1.10 implantados na Mainnet Beta continuaram por 2.000 slots adicionais além de seus pares v1.9 com especificações semelhantes.
Três mitigações estão em andamento para tratar da estabilidade e resiliência da rede.
- QUIC – Hoje, Solana usa um protocolo personalizado baseado em UDP bruto para passar transações entre nós RPC e o líder atual. Como o UDP não tem conexão e não possui controle de fluxo e reconhecimento de recebimento, não há uma maneira significativa de desencorajar ou mitigar o comportamento abusivo. Para afetar o controle sobre o tráfego de rede, os protocolos principais do Solana estão sendo reimplementados no QUIC, um protocolo criado pelo Google, projetado para comunicação assíncrona rápida como UDP, mas com sessões e controle de fluxo como TCP. Uma vez adotado, haverá muito mais opções disponíveis para adaptar e otimizar a ingestão de dados.
- QoS de transação ponderada por participação – A largura de banda da rede líder tem uma capacidade fixa e, para usá-la efetivamente, a priorização é uma necessidade para acabar com a prática atual de aceitar transações indiscriminadamente por ordem de chegada, sem levar em conta a fonte. Dado que a Solana é uma rede PoS, estender a utilidade da ponderação de participação para a qualidade de serviço da transação é uma escolha natural. Sob este modelo, um nó com 0,5% de participação terá o direito de transmitir pelo menos 0,5% dos pacotes para o líder, e o restante da rede e nenhuma combinação da participação restante poderá eliminá-los completamente. A QoS ponderada por participação está em desenvolvimento paralelo com o QUIC hoje. A QoS ponderada por participação será mais robusta em conjunto com o QUIC.
- Prioridade de execução baseada em taxas – uma vez ingeridas, as transações ainda podem disputar a modificação dos dados da conta compartilhada. Essa contenção foi tratada por um simples atendimento por ordem de chegada de forma semelhante às ingestões de dados de rede, não deixando aos usuários meios de expressar a urgência da execução de suas transações. Dado que qualquer pessoa pode enviar transações para a rede, a ponderação de stakes não é adequada para essa priorização. Em vez disso, uma nova instrução está sendo introduzida no programa Compute Budget, oferecendo aos usuários a capacidade de especificar uma “taxa adicional” arbitrária a ser cobrada na execução da transação e sua inclusão em um bloco. A proporção dessa taxa para as unidades de computação solicitadas servirá como peso de prioridade de execução de uma transação. As taxas adicionais serão tratadas de forma idêntica à taxa base atual.
As taxas estão chegando a Solana
As taxas da Solana não são as mesmas dos mercados de taxas globais da Ethereum. Em Solana, há menos competição por blockspace do que a capacidade de gravar em um estado específico, como um contrato de cunhagem para um NFT. As transações Solana não interagem com todo o estado Solana, em vez disso, especificam qual estado precisam ler e qual estado precisam gravar. As leituras podem se sobrepor e ser paralelizadas, as gravações não. Isso geralmente é chamado de problema do “ponto de acesso” do banco de dados, que os leilões estaduais são projetados para resolver. Por exemplo, se houver 10 segundos de trabalho que precisam ser gravados no mesmo estado, mas a quantidade de tempo for de 1 segundo, deve haver algum mecanismo que priorize qual trabalho é feito e qual trabalho falha. Como as transações são empacotadas em blocos por prioridade de “taxa mais alta/unidade de computação”,
Em comparação, o Ethereum usa os mercados de taxas para alocar um recurso escasso, ou seja, o blockspace. A priorização de taxas da Solana deve impactar apenas o estado específico, e não todo o bloco. Isso cria um sistema semelhante a ‘taxas de bairro’ em vez de ‘taxas globais’. As transações subsequentes que estão pagando uma taxa mais alta, mas não podem caber neste bloco porque atingiram os limites máximos de gravação em uma conta são derramadas e agendadas para o próximo bloco, mas outras transações que interagem com outras contas ainda podem ser adicionados ao mesmo bloco, mesmo que estejam pagando taxas mais baixas.
A priorização de taxas está em andamento e é direcionada para a versão v1.11.
Fonte: https://solana.com/