Resumo dos eventos
Entre aproximadamente 1:15 e 3:45 da manhã do dia 21 de novembro de 2024, horário do Pacífico (horário UTC+8: 21 de novembro de 2024, das 5:15 às 7:45 da tarde), a rede principal Sui sofreu uma paralisação completa. Todos os nós de validação entraram em um loop de travamento, resultando na interrupção total do processamento de transações.
Causa do problema
O assert! no código de controle de bloqueio acionou um erro: se o custo de execução estimado for zero, isso fará com que os nós de validação travem. Este problema ocorre sob todas as seguintes condições:
1. O controle de bloqueio foi definido para o modo TotalGasBudgetWithCap:
Este modo foi brevemente ativado na versão do protocolo 63 e subsequentemente retirado, antes de ser reativado com o escalonador acumulativo na versão do protocolo 68.
2. A rede recebeu transações que continham simultaneamente as seguintes condições:
Entradas de objetos compartilhados mutáveis
Zero comandos MoveCall
Quando a rede recebe esse tipo de transação, todos os nós de validação travam imediatamente.
O que é controle de bloqueio?
A arquitetura baseada em objetos da rede Sui suporta processamento paralelo em larga escala de diferentes transações de usuários, algo que não é viável na maioria das outras redes. No entanto, se várias transações tentarem escrever no mesmo objeto compartilhado ao mesmo tempo, essas transações devem ser executadas em ordem, e há um limite para a quantidade de transações que podem ser processadas envolvendo esse objeto específico.
O sistema de controle de bloqueio previne a sobrecarga da rede, limitando a taxa de transações que escrevem no mesmo objeto compartilhado, evitando pontos de verificação que demoram muito para serem executados.
Recentemente, atualizamos o sistema de controle de bloqueio para melhorar a utilização de objetos compartilhados ao estimar com mais precisão a complexidade das transações. No entanto, há um bug no código do novo modo TotalGasBudgetWithCap, que causou este problema.
Como resolver o problema?
Após a identificação do problema, a correção do código foi bastante direta (veja PR #20365). Esta correção foi implantada na mainnet (v1.37.4) e na testnet (v1.38.1).
PR #20365: Modificou bump_object_execution_cost para usar adição saturada e permitir transações com custo 0.
🌟 Mainnet v1.37.4:
https://github.com/MystenLabs/sui/releases
Com a resposta ativa da comunidade de nós de validação, levou apenas 15 minutos desde a publicação da correção até a recuperação normal da rede Sui.
O que aprendemos?
O sistema de detecção e resposta a eventos funcionou bem: alarmes automáticos e relatórios da comunidade foram acionados quase simultaneamente, e mobilizamos rapidamente recursos da equipe para diagnóstico e correção.
A comunidade de nós de validação se destacou: Após a publicação da correção, a rede Sui quase imediatamente voltou ao normal.
Medidas preventivas
Sistema de teste aprimorado: Adicionar mais tipos de transações adversárias semelhantes às que desencadearam essa falha para identificar problemas potenciais.
Otimização do processo de construção: Aumentar a velocidade de geração de binários para depuração e lançamento, reduzindo ainda mais o tempo de resposta a eventos. Parte do tempo durante essa interrupção foi devido à espera pela versão de lançamento da construção.
Agradecemos o apoio da comunidade e dos nós de validação, que garantiram a rápida recuperação da rede Sui!