Após a desaceleração na XRPL, David Schwartz explicou os riscos da rede

A desaceleração das transações na rede XRP Ledger, causada por uma falha técnica, resultou em uma análise mais ampla da arquitetura do protocolo. David Schwartz, ex-diretor de tecnologia da Ripple e um dos desenvolvedores do sistema, explicou os pontos vulneráveis da rede em uma avaliação pública após o incidente.

Fechamentos de livro desacelerados iniciaram uma investigação

O problema surgiu quando a equipe de operações do XRP Ledger registrou uma anomalia na rede. O fechamento dos livros na rede estava ocorrendo de forma visivelmente mais lenta do que o normal, levando os engenheiros a investigar a origem do atraso. Durante esse processo, surgiram questões sobre a resiliência da estrutura descentralizada dentro da comunidade.

Schwartz afirmou que o software XRPL é protegido por uma estrutura de segurança em múltiplas camadas. No entanto, ele destacou que existem dois cenários principais que poderiam parar completamente a rede. O primeiro seria a desativação simultânea de muitos servidores validador em todo o mundo. Schwartz mencionou que tal cenário só seria considerado possível em caso de um grande desastre natural em escala global.

O segundo cenário envolve um erro no algoritmo de consenso ou a corrupção de um dos principais recursos do protocolo a nível de código. Schwartz expressou que a desaceleração registrada no último evento indica que a margem de segurança tecnológica do sistema está diminuindo, o que pode sinalizar um ataque direcionado ou um erro oculto ativado dentro do código.

David Schwartz enfatizou que as possibilidades de paralisar toda a rede estão limitadas à perda massiva de infraestrutura ou à falha do mecanismo de consenso, e que a desaceleração recente indica uma diminuição na margem de segurança.

Resposta às alegações de ponto único de falha

Schwartz também rejeitou as alegações de que a rede está ligada a um único nó ou centro. Ele afirmou que o XRPL opera de forma completamente descentralizada, e que o fechamento de um grande centro, ou mesmo de seu próprio nó, ou a sobrecarga deste, não afetaria diretamente a funcionalidade geral da rede.

A Ripple, como uma das principais empresas do ecossistema XRP, desenvolve infraestruturas de pagamento e soluções financeiras baseadas em blockchain. O XRP Ledger é conhecido por operar de forma independente da Ripple, sendo uma rede blockchain de código aberto.

Sistemas de monitoramento falharam sob carga

Durante o incidente, o problema mais evidente foi que os sistemas de monitoramento da rede falharam sob carga intensa. Quando os ciclos de consenso desaceleraram, os validadores rapidamente passaram a operar em carga máxima. O próprio nó de Schwartz não conseguiu suportar o tráfego intenso de solicitações e as conexões RPC locais ficaram presas no estado CLOSE_WAIT.

Mini dicionário: RPC é um método de comunicação que permite que um software solicite dados de outro sistema remotamente e execute comandos. CLOSE_WAIT refere-se a uma situação em que uma conexão recebeu um sinal de fechamento do lado oposto, mas o processo do lado local ainda não foi concluído.

Devido a esse bloqueio, o sistema de monitoramento interno de Schwartz não conseguiu registrar e transmitir os dados de diagnóstico no momento mais crítico. Por isso, o engenheiro teve que reiniciar o servidor sem esclarecer a causa exata da falha.

Schwartz relatou que, devido ao bloqueio das conexões em seu nó, os dados de diagnóstico foram perdidos no momento mais crítico e o servidor foi reiniciado sem que ele visse exatamente o que causou o problema.

Registros enviados para um antigo servidor de teste estão sendo analisados

Durante a investigação, também foi descoberto que os registros do centro pertencente a um dos desenvolvedores do XRPL foram enviados para uma antiga máquina principal de teste da XRP Ledger Foundation. Isso dificultou ainda mais a coleta completa dos dados no momento do incidente.

A equipe de engenharia e os operadores da comunidade estão tentando isolar o erro examinando manualmente os registros restantes. Schwartz observou que, embora tenha havido uma diminuição temporária na margem de segurança, a equipe manteve a situação sob controle e que a arquitetura da rede possui reservas técnicas suficientes para continuar operando.