Una falla técnica en la red XRP Ledger (XRPL) que ralentizó el procesamiento de transacciones se ha convertido en un análisis abierto de la arquitectura del protocolo. David Schwartz, ex director de tecnología de Ripple y cocreador del sistema, nombró públicamente los puntos vulnerables de la cadena de bloques que el incidente puso de manifiesto.
Los problemas comenzaron después de que el equipo de Operaciones de XRP Ledger registrara una anomalía: los ledgers de la red comenzaron a cerrarse significativamente más lento de lo habitual. Mientras los ingenieros buscaban la causa de los retrasos, surgieron preguntas en la comunidad sobre la fiabilidad del sistema descentralizado. Los usuarios se preocuparon por si la red podría fallar debido a la sobrecarga de varios hubs clave. Schwartz intervino en la discusión para explicar los límites reales de la resiliencia de XRPL.
Según la evaluación de Schwartz, el software de XRP Ledger está protegido por un sistema de seguridad de múltiples capas. No obstante, en teoría solo existen dos escenarios capaces de paralizar por completo toda la red:
Falla masiva de la infraestructura: una situación en la que un enorme número de servidores validadores en todo el mundo fallan simultáneamente. Tal resultado solo es posible en caso de una catástrofe natural global, por lo que los desarrolladores lo consideran improbable.
Falla del algoritmo de consenso: un error en el propio mecanismo para alcanzar un acuerdo entre nodos, o el fallo de otra función básica del protocolo a nivel de código.
La ralentización registrada de las rondas es evidencia directa de que los márgenes de seguridad tecnológica del sistema han disminuido. Schwartz admitió que esto es un indicador de que la red está bajo un ataque dirigido o de que un bug oculto se ha activado dentro del código.
Al mismo tiempo, el arquitecto refutó los rumores sobre la vulnerabilidad de la cadena de bloques a puntos únicos de falla. La red está completamente descentralizada, por lo que apagar o sobrecargar incluso un hub grande (incluido su propio nodo) no tiene efecto sobre la operatividad general ni el tiempo de actividad de XRPL.
Cómo el creador de la red se quedó sin registros
El principal problema práctico resultó ser la vulnerabilidad de los sistemas de monitoreo de la red durante las cargas máximas. Cuando las rondas de consenso se ralentizaron, los validadores cambiaron abruptamente a la carga máxima. El propio nodo de Schwartz no pudo soportar la afluencia de solicitudes, lo que provocó que las conexiones RPC locales se colgaran en el estado CLOSE_WAIT.
Debido a este cuelgue, el sistema de monitoreo interno de Schwartz no pudo registrar ni transmitir datos de diagnóstico en el momento más crítico. Como resultado, el ingeniero tuvo que reiniciar el servidor sin comprender la causa exacta de la falla.
Durante la discusión, se reveló que el hub del cocreador de XRPL estaba enviando registros a un host de prueba obsoleto de la XRP Ledger Foundation (XRPLF).
Actualmente, el equipo de ingenieros y operadores de la comunidad está analizando manualmente los registros supervivientes para aislar y eliminar por completo el defecto. Schwartz resumió que, a pesar de la reducción temporal de los márgenes de seguridad, el equipo no tiene razones para entrar en pánico. Los desarrolladores tienen la situación completamente bajo control, y la arquitectura del código cuenta con una reserva tecnológica suficiente para mantener la red operativa.
