Os operadores de nós que executam o XRP Ledger estão sendo orientados a agir rapidamente. O Diretor de Engenharia da Ripple, Vijay Khanna, instou os provedores de infraestrutura em 2 de agosto a concluírem uma atualização de nó do XRP Ledger para a versão 3.2.1 do xrpld depois que desenvolvedores identificaram uma inundação de manifests de validadores atingindo a rede em 31 de julho. O ledger continuou produzindo blocos durante todo o incidente, mas o episódio expôs uma fraqueza de exaustão de recursos que a Ripple agora se moveu para fechar com um hotfix direcionado.
Summary
Principais pontos
- Uma inundação de manifests de validadores em 31 de julho levou a Ripple a lançar o xrpld 3.2.1 como um hotfix de emergência publicado em 1º de agosto.
- O XRP Ledger continuou fechando ledgers normalmente durante todo o evento, sem perda confirmada de fundos, transações alteradas ou falha de consenso.
- Quatro novas proteções agora limitam o tamanho de manifests, o tamanho de lotes de mensagens, o crescimento do cache para chaves de validadores desconhecidos e o compartilhamento de saída de dados não confiáveis.
- Os operadores devem atualizar, confirmar que o xrpld está em execução e, em seguida, reiniciar uma segunda vez para limpar quaisquer manifests que tenham persistido antes do patch.
- A Ripple rotacionou sua chave GPG de assinatura de pacotes em 18 de fevereiro, portanto os operadores devem confiar na nova chave para que a atualização seja instalada corretamente.
O que desencadeou a atualização de nó do XRP Ledger
A inundação se concentrou em manifests de validadores, os registros assinados criptograficamente que vinculam a identidade mestre permanente de um validador à chave temporária que ele usa para o tráfego de validação do dia a dia. Quando um validador rotaciona essa chave temporária, ele transmite um novo manifest assinado por sua chave mestre para que os pares na rede possam verificar que a alteração é legítima.
Antes da correção, os nós aceitavam, armazenavam em cache e retransmitiam manifests vinculados a chaves de validadores que nunca tinham visto antes, desde que os dados fossem estruturalmente válidos. Isso criou uma brecha: alguém poderia gerar um grande número de identidades desconhecidas e forçar cada nó conectado a consumir memória, armazenamento, largura de banda e poder de processamento apenas para lidar com o ruído. O registro público de código vinculado ao incidente o descreve como uma falha de propagação de manifests, em vez de uma violação de qualquer conta ou chave.
Apesar da pressão sobre os recursos dos nós, a XRP Ledger Operations relatou que a rede continuou fechando ledgers normalmente o tempo todo. Essa distinção é importante: a inundação sobrecarregou a infraestrutura, mas nunca chegou ao ponto de interromper o consenso ou corromper o histórico de transações.
Por dentro do hotfix xrpld 3.2.1
A resposta da Ripple, datada de 31 de julho e publicada como um lançamento assinado no início de 1º de agosto, reúne seis commits em 13 arquivos alterados, quatro dos quais restringem diretamente como os nós lidam com manifests de validadores não reconhecidos. Juntos, eles formam quatro proteções projetadas para impedir que o mesmo tipo de inundação volte a drenar os recursos dos nós.
A primeira rejeita um manifest superdimensionado antes mesmo que um nó termine de decodificá-lo, cortando o custo de processamento de objetos anormalmente grandes logo na entrada. A segunda limita quantos manifests não confiáveis podem trafegar dentro de uma única mensagem de rede, seja quando um nó está recebendo dados ou preparando-os para os pares; lotes superdimensionados são descartados sem encerrar automaticamente a conexão, o que permite que nós com e sem patch continuem se comunicando durante a implantação.
Uma terceira alteração limita quantas identidades de validadores desconhecidos o cache de manifests de um nó pode armazenar, com o código final definindo esse teto em 100. Uma vez que o cache esteja cheio, novas chaves não listadas são recusadas, enquanto validadores confiáveis e previamente reconhecidos continuam operando sem interrupção. O quarto ajuste altera como dados de manifests não confiáveis se espalham pela rede, restringindo o compartilhamento de saída de boatos de pares não listados, enquanto deixa intocados os dados vinculados a validadores configurados ou aprovados. Esse equilíbrio é intencional: a rotação normal de chaves de validadores ainda funciona, mas o crescimento descontrolado do cache vindo de desconhecidos não.
O que os operadores de nós precisam fazer agora
As orientações de Khanna são diretas, mas precisam ser seguidas na ordem correta. Os operadores devem instalar a atualização padrão, aguardar de um a dois minutos, confirmar que o xrpld está realmente em execução e então reiniciar o serviço uma segunda vez.
Essa segunda reinicialização não é uma formalidade. Quaisquer manifests que o nó de um operador tenha absorvido e armazenado antes do patch ainda podem estar na memória ou em disco. Instalar a 3.2.1 muda como o software lida com novos manifests daqui para frente, mas apenas uma nova reinicialização limpa os dados que o nó coletou enquanto ainda estava vulnerável. Pular essa etapa traz o risco de deixar manifests obsoletos e não confiáveis no lugar, mesmo depois que o código em si tenha sido corrigido.
Há um segundo ponto importante a destacar: a confiança em pacotes. A Ripple rotacionou a chave GPG que usa para assinar pacotes do xrpld em 18 de fevereiro, e instalações que ainda não confiaram nessa chave substituta podem não obter a atualização automaticamente. Qualquer pessoa que gerencie infraestrutura XRPL deve verificar sua configuração de chave de assinatura antes de presumir que a atualização será aplicada sem problemas.
É importante notar que esta atualização de nó do XRP Ledger é voltada diretamente para a infraestrutura, não para os detentores individuais. Corretoras, custodiante, back-ends de carteiras, provedores de dados e qualquer empresa que execute seus próprios servidores XRPL precisam confirmar a versão do seu nó e o status de reinicialização. Detentores comuns de XRP não precisam mover fundos, alterar chaves de carteiras ou abrir novas contas por causa desse problema — a correção vive inteiramente na camada de servidor.
Por que a ausência de danos ainda importa
Nenhum identificador de CVE ou estimativa de perda financeira foi publicado em conexão com a inundação, e as evidências disponíveis apontam para recursos de nós sobrecarregados e tráfego ponto a ponto, em vez de qualquer roubo confirmado, transação alterada ou quebra de consenso. Esse é um resultado genuinamente tranquilizador para uma rede que liquida bilhões em valor, mas não significa que o incidente não teve custo. Ataques de exaustão de recursos que não tocam em fundos ainda podem degradar o serviço, desacelerar provedores de infraestrutura e criar brechas para tentativas subsequentes se a aplicação de patches atrasar.
Essa é a peça que ainda falta no registro público. A XRP Ledger Operations afirmou que um relatório técnico pós-incidente será publicado, mas até 2 de agosto esse relatório ainda não havia sido divulgado. Até que ele seja publicado, a identidade de quem enviou a inundação, o volume real de manifests envolvidos e a rapidez com que os operadores de nós em toda a rede adotaram a 3.2.1 permanecem questões em aberto. Espera-se também que o relatório esclareça quando os desenvolvedores detectaram pela primeira vez o tráfego incomum e se algum nó individual se tornou inacessível, mesmo que o ledger compartilhado em si nunca tenha parado de produzir blocos.
Esta não é a primeira transição forçada de software da rede neste ano. O hotfix 3.2.1 segue a implantação maior da 3.2.0 em 15 de junho, que renomeou o servidor de referência de rippled para xrpld e exigiu sua própria rodada de atualizações de configuração — o mesmo lançamento que levou o operador de infraestrutura XRPL David Schwartz a migrar sua configuração antes das novas mudanças de nomenclatura e protocolo. Os operadores de nós também tiveram que cumprir um prazo anterior da versão 3.1.3 vinculado à ativação de uma emenda. Em conjunto, o padrão sugere que a camada de infraestrutura do XRPL está sendo pressionada a acompanhar um ciclo de atualizações mais apertado, e operadores que ficam para trás em qualquer lançamento específico correm o risco de carregar vulnerabilidades que a rede já corrigiu em outros lugares.
FAQ
O que causou a necessidade da atualização de nó do XRP Ledger?
Uma inundação de manifests de validadores ocorreu em 31 de julho, causando exaustão de recursos nos nós, o que exigiu o hotfix xrpld 3.2.1 para mitigar o problema.
A inundação de manifests causou perda de fundos ou falhas de consenso no XRP Ledger?
Nenhuma perda financeira confirmada, transações alteradas ou falhas de consenso do ledger foram observadas durante a inundação, de acordo com a XRP Ledger Operations.
Quais são as principais proteções introduzidas no xrpld 3.2.1?
A atualização limita o tamanho de manifests, o tamanho de lotes de mensagens, o crescimento do cache de chaves desconhecidas (limitado a 100 entradas) e o compartilhamento de saída de manifests não confiáveis.
Quem precisa atualizar para o xrpld 3.2.1 e quais são as etapas operacionais?
Provedores de infraestrutura que executam nós XRPL — incluindo corretoras, custodiante e operadores de carteiras — devem atualizar, verificar se o software está em execução e então realizar uma segunda reinicialização para limpar quaisquer manifests persistentes.
{“@context”:”https://schema.org”,”@type”:”FAQPage”,”mainEntity”:[{“@type”:”Question”,”name”:”O que causou a necessidade da atualização de nó do XRP Ledger?”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”Uma inundação de manifests de validadores ocorreu em 31 de julho, causando exaustão de recursos nos nós, o que exigiu o hotfix xrpld 3.2.1 para mitigar o problema.”}},{“@type”:”Question”,”name”:”A inundação de manifests causou perda de fundos ou falhas de consenso no XRP Ledger?”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”Nenhuma perda financeira confirmada, transações alteradas ou falhas de consenso do ledger foram observadas durante a inundação, de acordo com a XRP Ledger Operations.”}},{“@type”:”Question”,”name”:”Quais são as principais proteções introduzidas no xrpld 3.2.1?”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”A atualização limita o tamanho de manifests, o tamanho de lotes de mensagens, o crescimento do cache de chaves desconhecidas (limitado a 100 entradas) e o compartilhamento de saída de manifests não confiáveis.”}},{“@type”:”Question”,”name”:”Quem precisa atualizar para o xrpld 3.2.1 e quais são as etapas operacionais?”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”Provedores de infraestrutura que executam nós XRPL — incluindo corretoras, custodiante e operadores de carteiras — devem atualizar, verificar se o software está em execução e então realizar uma segunda reinicialização para limpar quaisquer manifests persistentes.”}}]}
Artigo produzido com a assistência de inteligência artificial e revisado pela equipe editorial.
