David Schwartz explica los riesgos de la red tras la desaceleración en XRPL

La desaceleración de las transacciones en la red XRP Ledger, provocada por un fallo técnico, ha llevado a una revisión más amplia de la arquitectura del protocolo. David Schwartz, ex director de tecnología de Ripple y uno de los desarrolladores del sistema, explicó en una evaluación pública posterior al incidente los puntos vulnerables destacados de la red.

La desaceleración de los cierres de libro inició una revisión

El problema surgió cuando el equipo de operaciones de XRP Ledger registró una anomalía en la red. El cierre de los libros en la red fue notablemente más lento de lo habitual, lo que llevó a los ingenieros a investigar la fuente de la demora. Durante este proceso, también surgieron preguntas sobre la resiliencia de la estructura descentralizada dentro de la comunidad.

Schwartz afirmó que el software de XRPL está protegido por una arquitectura de seguridad de múltiples capas. Sin embargo, señaló que existen dos escenarios fundamentales que podrían detener completamente la red. El primero es la desactivación simultánea de numerosos servidores validador en todo el mundo. Schwartz comentó que tal escenario solo podría considerarse posible en caso de un gran desastre natural a escala global.

El segundo escenario se refiere a un error en el algoritmo de consenso o a la corrupción a nivel de código de una de las funciones fundamentales del protocolo. Schwartz indicó que la desaceleración registrada en la última ronda muestra que el margen de seguridad tecnológica del sistema se ha reducido, lo que podría señalar un ataque dirigido o un error oculto activado dentro del código.

David Schwartz enfatizó que las posibilidades de paralizar toda la red están limitadas a la pérdida masiva de infraestructura o a la corrupción del mecanismo de consenso, y que la reciente desaceleración indica una disminución en el margen de seguridad.

Respondió a la afirmación de un único punto de fallo

Schwartz también rechazó las afirmaciones de que la red depende de un solo nodo o centro. Afirmó que XRPL opera en una estructura completamente descentralizada y que el cierre de un gran centro, o incluso de su propio nodo, o su sobrecarga, no afectaría directamente la operatividad general de la red.

Ripple, como una de las principales empresas del ecosistema XRP, desarrolla infraestructuras de pago y soluciones financieras basadas en blockchain. XRP Ledger, por su parte, es conocido como una red de blockchain de código abierto que opera de manera independiente de Ripple.

Los sistemas de monitoreo fallaron bajo carga

Durante el incidente, se reveló que el problema más concreto fue que los sistemas de monitoreo de la red se debilitaron bajo una carga intensa. Cuando las rondas de consenso se desaceleraron, los validadores de repente pasaron a una carga máxima. El propio nodo de Schwartz no pudo soportar el tráfico intenso de solicitudes y las conexiones RPC locales quedaron atascadas en estado CLOSE_WAIT.

Mini glosario: RPC es un método de comunicación que permite a un software solicitar datos de otro sistema de forma remota y ejecutar comandos. CLOSE_WAIT se refiere a una situación en la que una conexión ha recibido una señal de cierre del otro lado, pero el proceso en el lado local aún no se ha completado.

Debido a este bloqueo, el sistema de monitoreo interno de Schwartz no pudo registrar y enviar datos de diagnóstico en el momento más crítico. Por esta razón, el ingeniero tuvo que reiniciar el servidor sin poder aclarar la causa exacta de la falla.

Schwartz informó que, debido al bloqueo de las conexiones en su nodo, los datos de diagnóstico se perdieron en el momento más crítico y el servidor fue reiniciado sin ver exactamente por qué había fallado.

Se están revisando los registros enviados a un antiguo servidor de prueba

Durante la revisión, también se descubrió que los registros del centro de uno de los desarrolladores de XRPL se enviaron a una antigua máquina principal de prueba de la Fundación XRP Ledger. Esta situación dificultó aún más la recopilación completa de los datos en el momento del incidente.

El equipo de ingeniería y los operadores de la comunidad están tratando de aislar el error revisando manualmente los registros restantes. Schwartz señaló que, aunque hubo una reducción temporal en el margen de seguridad, el equipo mantuvo la situación bajo control y que la arquitectura de la red tiene suficientes reservas técnicas para continuar funcionando.