Uma falha técnica na rede XRP Ledger (XRPL) que desacelerou o processamento de transações transformou-se em uma análise aberta da arquitetura do protocolo. David Schwartz, ex-Diretor de Tecnologia da Ripple e cocriador do sistema, nomeou publicamente os pontos vulneráveis da blockchain destacados pelo incidente.
Os problemas começaram depois que a equipe de Operações do XRP Ledger registrou uma anomalia: os ledgers da rede começaram a fechar significativamente mais devagar do que o habitual. Enquanto os engenheiros procuravam a causa dos atrasos, surgiram questionamentos na comunidade sobre a confiabilidade do sistema descentralizado. Os usuários estavam preocupados se a rede poderia falhar devido à sobrecarga de vários hubs principais. Schwartz entrou na discussão para explicar os limites reais da resiliência do XRPL.
De acordo com a avaliação de Schwartz, o software do XRP Ledger é protegido por um sistema de segurança em várias camadas. No entanto, em teoria, existem apenas dois cenários capazes de paralisar completamente toda a rede:
Falha massiva de infraestrutura: uma situação em que um enorme número de servidores validadores ao redor do mundo falha simultaneamente. Tal desfecho é possível apenas no caso de uma catástrofe natural global, por isso os desenvolvedores o consideram improvável.
Falha do algoritmo de consenso: um erro no próprio mecanismo de obtenção de acordo entre os nós, ou a falha de outra função básica do protocolo no nível do código.
A desaceleração registrada das rodadas é evidência direta de que as margens de segurança tecnológica do sistema diminuíram. Schwartz admitiu que este é um indicador de que a rede está sob um ataque direcionado ou de que um bug oculto foi ativado dentro do código.
Ao mesmo tempo, o arquiteto refutou rumores sobre a vulnerabilidade da blockchain a pontos únicos de falha. A rede é totalmente descentralizada, portanto, desligar ou sobrecarregar até mesmo um grande hub (incluindo seu próprio nó) não tem efeito sobre a operabilidade geral e o tempo de atividade do XRPL.
Como o criador da rede ficou sem logs
O principal problema prático revelou-se a vulnerabilidade dos sistemas de monitoramento da rede durante picos de carga. Quando as rodadas de consenso desaceleraram, os validadores mudaram abruptamente para carga máxima. O próprio nó de Schwartz não suportou o influxo de requisições, fazendo com que as conexões RPC locais travassem no estado CLOSE_WAIT.
Devido a esse travamento, o sistema de monitoramento interno de Schwartz não conseguiu registrar e transmitir dados de diagnóstico no momento mais crítico. Como resultado, o engenheiro teve que reiniciar o servidor sem entender a causa exata da falha.
Durante a discussão, descobriu-se que o hub do cocriador do XRPL estava enviando logs para um host de teste desatualizado da XRP Ledger Foundation (XRPLF).
Atualmente, a equipe de engenheiros e operadores da comunidade está analisando manualmente os logs sobreviventes para isolar e eliminar completamente o defeito. Schwartz resumiu que, apesar da redução temporária das margens de segurança, a equipe não tem motivos para entrar em pânico. Os desenvolvedores têm total controle da situação, e a arquitetura do código possui reserva tecnológica suficiente para manter a rede operacional.
