XRPL solicita aos operadores de nodes que atualizem para o xrpld 3.2.1 após inundação de manifestos de validadores

Título: XRPL solicita atualização urgente de node após "inundação de manifestos" sobrecarregar recursos da rede O diretor de engenharia da Ripple, Vijay Khanna, em 2º de agosto, solicitou aos operadores de nodes do XRP Ledger que instalem imediatamente o xrpld v3.2.1, após desenvolvedores detectarem uma "inundação de manifestos" de validadores em 31 de julho. O hotfix rápido limita como os nodes processam, armazenam e compartilham dados de manifestos de identidades de validadores desconhecidas — impedindo que atacantes esgotem a memória, armazenamento, largura de banda e CPU dos nodes — e preserva a operação normal do ledger enquanto os operadores implementam a correção. O que aconteceu - Em 31 de julho, desenvolvedores observaram um aumento súbito de manifestos de validadores provenientes de identidades desconhecidas. Embora o ledger continuasse a fechar normalmente, o evento pressionou os recursos dos nodes e as comunicações ponto a ponto. - Não há evidência pública de fundos roubados, transações alteradas ou falha de consenso. Os desenvolvedores não emitiram um CVE nem publicaram estimativa de perda financeira relacionada ao incidente. - A XRPL Operations informou que um pós-mortem técnico será divulgado; até 2º de agosto, a origem da inundação, o volume total e o impacto exato nos recursos permanecem não divulgados. Por que os manifestos de validadores são importantes - Manifestos de validadores são registros assinados criptograficamente que vinculam a identidade mestre estável de um validador às chaves temporárias usadas para mensagens de validação diárias. Quando operadores rotacionam chaves temporárias, publicam um novo manifesto assinado pela chave mestre para que pares possam verificar a mudança. - Antes do hotfix, o xrpld podia aceitar, armazenar em cache e retransmitir manifestos bem estruturados para chaves de validador que não reconhecia. Um atacante poderia explorar esse comportamento criando muitas identidades desconhecidas e forçando pares a desperdiçar memória, armazenamento, largura de banda e poder de processamento ao lidar com esses dados. O repositório de código descreve o problema como abuso de propagação de manifestos. O que há no xrpld 3.2.1 - A versão oficial do xrpld 3.2.1 (datada de 31 de julho; assinada e publicada no início de 1º de agosto) contém seis commits em 13 arquivos. Quatro commits limitam diretamente o tratamento de manifestos não confiáveis. Principais proteções: - Rejeição antecipada de manifestos excessivamente grandes antes que os nodes os decodifiquem completamente, reduzindo o trabalho da CPU por objeto malicioso. - Limites no número de manifestos não confiáveis permitidos em uma única mensagem de rede — aplicados tanto na recepção quanto na preparação de mensagens para pares. Lotes excessivamente grandes são descartados sem desconectar pares não atualizados, facilitando a compatibilidade da implantação. - Limite por node no número de identidades de validadores desconhecidas armazenadas em memória, limitado a 100. Quando cheio, novos manifestos não listados são rejeitados, enquanto validadores confiáveis e lembrados continuam sendo processados. - Alterações na forma como informações de manifestos não confiáveis são retidas e difundidas, direcionadas à difusão entre pares não listados e não aos manifestos de validadores configurados/confiáveis. Isso preserva a rotação legítima das chaves dos validadores enquanto bloqueia o crescimento descontrolado do cache. Orientações e notas para operadores - Khanna aconselhou validadores e operadores de infraestrutura a atualizarem para a v3.2.1 "o mais rápido possível". O processo recomendado: realizar a atualização normal do software, aguardar um a dois minutos para confirmar que o xrpld está em execução e, em seguida, reiniciar novamente o serviço. A segunda reinicialização ajuda a limpar quaisquer manifestos desconhecidos retidos na memória antes da correção. - Operadores também devem confirmar se seus sistemas confiam na chave atual de assinatura GPG da Ripple. A Ripple rotacionou essa chave em 18 de fevereiro; nodes que não confiaram na nova chave podem não receber atualizações automáticas. - Esta atualização é destinada a operadores de infraestrutura (exchanges, custodiantes, back-ends de carteiras, provedores de dados e empresas que executam servidores XRPL). Titulares comuns de XRP não precisam mover fundos, rotacionar chaves ou tomar qualquer medida. Contexto e próximos passos - O hotfix segue o lançamento mais amplo do xrpld v3.2.0 (15 de junho), que renomeou o servidor de referência de rippled para xrpld e exigiu que operadores atualizassem suas configurações. A adoção da v3.2.0 foi mais rápida entre validadores do que na rede completa de nodes; a inundação de manifestos oferece aos operadores restantes outra razão forte para migrar para a v3.2.1. - A XRPL Operations prometeu um pós-mortem técnico que detalhará quando a atividade foi detectada pela primeira vez, se algum node ficou indisponível, o volume de manifestos e quão rapidamente os operadores adotaram a correção. Até que esse relatório seja publicado, os detalhes confirmados permanecem limitados às correções da v3.2.1 e ao pedido para operadores atualizarem e reiniciarem. Conclusão Se você opera infraestrutura XRPL, trate isso como urgente: atualize para o xrpld 3.2.1 e siga a recomendação de reinicialização em duas etapas para limpar quaisquer manifestos não confiáveis retidos. Para a comunidade XRPL em geral, o incidente parece ter sido uma tentativa de esgotamento de recursos, e não uma violação do protocolo — mas o pós-mortem futuro será importante para confirmar o escopo completo.