
XRP Ledger defiende el parche de emergencia para un fallo que permitía crear XRP ilimitados
La Fundación XRP Ledger rechazó las afirmaciones de que su parche de seguridad de emergencia se impuso a los operadores de la red.

Los desarrolladores de XRP Ledger han defendido el parche de seguridad de emergencia utilizado para corregir un fallo capaz de crear XRP por encima del suministro fijo de la red, y afirmaron que no podían esperar la habitual votación de dos semanas de los validadores de la red sin exponer el fallo a los atacantes.
La corrección, publicada el 25 de septiembre, llegó tres días después de un informe de recompensa por errores y entró en vigor inmediatamente en cualquier servidor que la instalara. Según dijeron, fue la primera omisión deliberada del proceso normal de enmiendas desde que se introdujo el sistema hace más de diez años.
“Con una votación de enmienda normal, la corrección habría sido pública durante semanas antes de entrar en vigor, lo que habría puesto en riesgo la seguridad de la red”, los desarrolladores de XRPL dijeron en una publicación en X el domingo.
La corrección acelerada generó preguntas sobre el nivel de descentralización de XRPL. En su sitio web, XRPL afirma ser una blockchain pública y totalmente descentralizada —una caracterización que ha sido central en los argumentos de que su token nativo, XRP, no es un valor.
La corrección de seguridad de XRPL “generó muchas preguntas”
El fundador de Cyber Capital, Justin Bons, dijo el jueves que comercializar XRP entre inversores minoristas como descentralizado equivalía a un “fraude descarado”. Argumentó que la versión de emergencia del 25 de septiembre se distribuyó únicamente como binarios, retuvo temporalmente el código fuente y presionó a los operadores para actualizarse.
Sin embargo, la Fundación XRPL dijo que la decisión de omitir el proceso normal de enmiendas fue tomada conjuntamente por la Fundación, RippleX, los desarrolladores principales y los validadores después de evaluar la gravedad del fallo.
“Ninguna parte podía tomar esa decisión por sí sola. Cada validador y operador de nodos elige qué software ejecutar, y la versión 3.4.1 solo pasó a ser obligatoria mediante una votación normal de enmienda con el apoyo de más del 80% de los validadores durante dos semanas. Los cambios del protocolo siguen tramitándose mediante enmiendas”, dijo la fundación.
XRP Kuwait, un operador independiente de validadores, también rechazó las afirmaciones de que las actualizaciones coordinadas indicaban un control centralizado.
“No estamos de acuerdo con la afirmación de que la coordinación de los operadores para actualizarse sea, por sí misma, una prueba de control centralizado”, dijo. “La coordinación no es lo mismo que el control. Los operadores independientes pueden evaluar una situación, comunicarse entre sí y llegar a la misma conclusión sin renunciar a su independencia.”
El fallo podría haber creado XRP ilimitados
El fallo era un desbordamiento de enteros en el motor de pagos de XRP Ledger que había estado presente desde 2015, según el informe de divulgación de vulnerabilidades del proyecto.
Los saldos de XRP se almacenan como enteros de 64 bits con un máximo fijo. Cuando una suma superaba ese máximo, el cálculo volvía a un número menor en lugar de fallar.
Un atacante podía aprovechar esto creando cientos de ofertas con precios especialmente diseñados, cada una solicitando una cantidad muy grande de XRP, y luego enviando un pago que las consumiera todas.
El motor acreditaría a cada propietario de las ofertas el importe total, pero cobraría al comprador únicamente el pequeño total resultante del desbordamiento. La diferencia serían XRP recién creados y utilizables.
El ataque requería ofertas construidas deliberadamente y no podía activarse mediante la actividad normal de trading, según el informe. Los desarrolladores dijeron que no encontraron pruebas de que el problema hubiera sido explotado en ninguna red pública.

